Wait. Why are you giving tips for product managers?
I know you may want to discount this entire post, because for much of my career my title has been something like the Vice President of Software Engineering or Chief Technology Officer. It's true that I've been the top technologist in every company I've worked at for the last fifteen years. But what's also true is that in every one of those organizations I've been responsible for new product development.
And if you know anything about new product development, you know that finding the product-market fit is the biggest challenge of all. That challenge in huge companies is often called product management. In companies under 300 (at least the ones I've worked at), it goes to whoever has the best talent at stepping in between developers and prospects. So with that said, and with fifteen years of doing it, here are my five tips for product managers.
1. Not making a decision is not ok.
It would be fantastic to say that every decision I've ever made was right, but it's not true. I've made bad calls just like everyone else. But what I've tried to steer clear of isn't “horrible decision,” instead what I've worked against every day for fifteen years is the lack of a decision. The truth is that we never have perfect information. So you have to make a call.
But some people wait for perfect information. They want more data. More surveys. More interviews. And the team never starts or ends anything because they're waiting on decisions that haven't been made. If you're in the key role of a product manager and you're not making at least one call a day, you need to start looking at what's going on.
2. Opinionated products are the way to go.
Everyone wants a feature. Everyone has suggestions. And so what are you inclined to do? You put those suggestions on a list. I don't. I make it clear that our product has a perspective. A way it thinks about the market. What I call an opinion. And if the suggestion fits within the context of our product's opinions, I want it. If it doesn't – if it's something that honestly we will likely never do – I am up front about it. It helps you. It helps them. And it helps your teams because you don't have long lists of crap you'll never do.
3. It's not done until it's done done.
You knew I couldn't write about this without bringing up “done done“, right? Even if, and especially if, you're building software – the release requires more than just the coded features. If you're changing data, you need something to migrate old data. You need tutorials for new features. You need to train internal staff. So don't call it done simply because an engineer calls it done. They're missing half the list. Only call it done when there's nothing left to say after “done” except done – that's how you get to “done done.”
4. Process is what makes things repeatable, but don't turn it into the “master”
We all know that if you do something well, people will expect you to do it well again. And again. And I'd love to love process like the next guy. But keep it slim. Because when process turns into sign-offs and paper forms, you may spend more time in meetings dealing with paperwork than making the trade-offs you need to make. So make sure you have a process – one for getting feedback, one for figuring out pricing, etc. But keep it light enough that it doesn't slow you down.
5. Keep engineers engaged with your early customers
Years ago I watched a company throw their code/product over the wall. The moment it had been tested and demonstrated that it was working, it was passed to a completely different team. This resulted in a ton of backlash because the new team was responsible for launching a product they didn't know, didn't understand, weren't prepared to handle questions on, and more.
So these days, at Emphasys Software, when my NPD team builds a new product, we take it into the market first. We launch the first three or four clients. We collect all the questions, and figure out the answers. We hear about the bugs, and we notice the gaps between how we thought our feature would work and how the customer is actually using it. All of that is incredibly useful feedback. So excluding us from that and hearing of it secondhand would only hurt everyone. So we stay in the loop until we've settled into some stability. And we use that early feedback to help us think about the future roadmap as well.
I could go on, because we've not talked about pricing, beta testing, getting out of the building, re-writes, and roadmaps. Maybe I'll write more. But first I want to know what your top takeaways are. Share them below.