There’s one essential piece behind innovative product, and that’s the product mindset. If you want to be truly innovative, you need to be explorers. You need to take (calculated) risks. You need to try different ideas and techniques, and you need to fail half of the time. If you’re not failing, it means that you’re not exploring deep enough and that you’re playing it safe. And playing it safe is not innovative.
What does the product mindset look like? It actually has a name—continuous product discovery.
Let’s take that concept apart:
- Continuous - It happens all the time. It never starts, and it never stops. You are continuously doing it.
- Product - You’re pushing your product further. You don’t seek isolated features, and you are solving problems in a way that helps your customers and your team care about usability, activation, and adoption. You want to make it lovable in the long run.
- Discovery - You are essentially doing research. You are exploring the unknown and trying to push the boundaries of technology one step further beyond the known horizons.
Now, there are a few essential points in there that I’d like to explicitly emphasize:
- Product teams tend to schedule discovery as a task that happens prior to development. This resembles a waterfall, right? Usually, they do a design phase and call it discovery, and that’s not continuous. Teams need to make sure that discovery happens all the time, and they need to measure “time to value” – the time between having an idea and the problem being solved. (This can be observed by seeing how customers begin to use the system differently.) The shorter that time is, the better you are.
- You need to be comparing and contrasting multiple opportunities that you have and multiple solutions for a chosen problem. Don’t fall in love with your first idea. Teresa Torres has a great example in her talk: If you see Usain Bolt running alone, you know that he’s fast, but how do you know if he’s the fastest runner in the world? You need to let him race other runners to see where he stands. The same holds for ideas. You need to have a competition of ideas, and a great metric we’re setting up at Mews is to count the number of ideas thrown away. The more you have, the better you are.
SVPG uses the below diagram to talk about discovery, which is very important, as it clearly shows how discovery runs in parallel with delivery and how it informs delivery. It also explains that discovery uses quick and dirty prototypes to explore ideas and that it’s only in the delivery where you build the production-grade product.
I have a diagram of my own that helps me explain to product managers what steps they should be thinking to take while doing discovery:
First, keep in mind that these two circles are spinning in parallel all the time. You need to make sure that you have a clear need—you're solving someone’s problem. Establish a metric that shows you the problem is there, and at all times, you need to make sure you are on the right track. Continuously observe your customer’s behaviour through different means (e.g., looking over their shoulder, gathering data through Hotjar and Heap, etc.) and talk to your customers every week. The longer you go without customer feedback, the bigger the risk that you are going in the wrong direction. Don’t let them design your product but keep confirming that your hypotheses are the correct ones. Seek different opportunities and different solutions and compare and contrast to find what’s better. Run cheap experiments. Throw ideas away. Make sure you spin through those loops as fast as possible and minimize “time to value” from ideas to solved problems.
It sounds complicated, right? Despite that, companies love to look for industry experts instead of seasoned product managers. Industry experts will give them an advantage for a little while because they have the expertise, their level of common sense is higher, and they give you a quick way to build an average product that copies whatever they have been using in the past. You need to be experimenting to be innovative. You need to hire experts in experimentation because you’re asking them to develop something that hasn’t been seen before. Through discovery, they will quickly gain all the industry knowledge they need. Unless you’re in specific industries, your industry is not rocket science (Hi, Elon!). Of course, having a product manager with expertise in a given industry is a plus because they will be able to use that expertise to bridge gaps and build MVP much faster. But imagine you’re building a platform for garbage collectors. How many garbage collectors who are also great product managers are out there in the world? (If you are one, ping me. We’re hiring!) At a certain point, that is, you need to start using product mindset.
Building a production-grade software is expensive. Invest only once you have enough confidence (through common sense or through evidence) that you are on the right track. Once done, gather feedback and ensure that you have solved the problem. You’ve already established the metric that demonstrates the problem that should have changed by now, and this is where it begins because there’s much more to managing product, especially when you need to make sure that everyone understands what you’ve built.
For more engineering insights shared by Mews tech team: