{"id":5922,"date":"2018-11-26T16:24:20","date_gmt":"2018-11-26T16:24:20","guid":{"rendered":"https:\/\/www.prodpad.com\/?p=5922"},"modified":"2025-01-13T16:27:16","modified_gmt":"2025-01-13T16:27:16","slug":"continuous-product-discovery","status":"publish","type":"post","link":"https:\/\/www.prodpad.com\/blog\/continuous-product-discovery\/","title":{"rendered":"What is Continuous Product Discovery and are you Doing it right?"},"content":{"rendered":"\n

Product Discovery is most often seen as the prelude to building a new product. Whatever Product Discovery framework or methodology du jour you use, it\u2019s usually in order to find a new problem to solve, to validate that the problem is worth solving and to test possible solutions.

However, the true power of Product Discovery emerges when you extend it through the product\u2019s lifetime, rather than just constraining it to the creation of new products.

In short, product managers should be doing Continuous Product Discovery – all the time.<\/p>\n\n\n

\n
\"Product<\/figure>\n<\/div>\n\n\n

For every change, new feature, improvement, or rework, you should be doing Product Discovery so that you can constantly validate that there is a real problem to solve, that it is a real problem, and that solving it is worthwhile. Most importantly, you can see that solving this problem fits within the product vision and strategy.

Understanding this last point is crucial. There\u2019s no point tacking on a new feature if it doesn’t fit the product\u2019s vision and strategy. It won’t help you reach the product vision<\/a>, and it\u2019s likely to be a feature that only a few people, if any, use, since it has nothing to do with the reason that they use your product in the first place.

Continuous Product Discovery differs from initial Product Discovery because you already (hopefully) have customers and users with whom you can validate a problem. Of course you should also look at validating problems with potential and former users to ensure a wide range of opinions.<\/p>\n\n\n\n

Continuous Product Discovery – Mining Your Feedback<\/h2>\n\n\n\n

In some ways Continuous Product Discovery is easier than initial Product Discovery. As users already have your product, you should be collecting the reams and reams of feedback they provide (you are, aren’t you?). This feedback is your raw material to mine for new problems, unresolved problems, and resolved problems that change as the market and wider environment evolve.

A downside of this feedback is it’s sheer volume – it can be hard to keep up with. And it will inevitably include a lot of noise as people provide feedback specific to their situation. However, this volume and noise can work to your advantage, as with Continuous Product Discovery you\u2019re looking for the common problems. You can quickly find these common problems in feedback and also see how they\u2019re manifested in different ways for different users and situations.

The more common problems you solve, the broader and more effective your product will be.<\/p>\n\n\n

\n
\"Sorting<\/figure>\n<\/div>\n\n\n

Showing up Those Subtle but Difficult Problems<\/h2>\n\n\n\n

Even more powerfully, this volume of feedback can surface those subtle but difficult problems which aren\u2019t caught with initial Product Discovery because you don’t have the time or people to collect data.

The nature of initial Product Discovery means your time and access to people are often limited. The problems you\u2019re testing or discovering are the ones that people are currently aware of. All of which is good, but you need to weed out those that are transient problems (like when your dog dribbles water on the kitchen floor but you don\u2019t bother cleaning it up because it\u2019ll dry in five minutes). More importantly, you will struggle to discover the subtle problems that people aren\u2019t aware of and those problems that slowly surface over time.

The volume of information that is captured with Continuous Product Discovery allows both the problems that users aren\u2019t aware of to be discovered and for slow problems to surface. But only if you actively look for them. As the volume of feedback grows, you can spot patterns that point to these subtle problems so you can then delve into them to validate their existence and characterise them.

While customer feedback is often the most significant part of Continuous Product Discovery, the knowledge garnered from metrics and product usage tracking should not be forgotten. Combined, they give you a potent weapon for problem discovery.<\/p>\n\n\n\n

Careful Validation Required<\/h2>\n\n\n\n

The next step is, of course, validation. There are many ways of validating a problem, user testing, surveys, asking questions in a user community, to name a few. Be careful that you don’t keep returning to the same people during validation. It may be easier to go back to the same helpful people, but it\u2019s extremely important to get a diversity of users in your validation of a problem.

What about outside your current user base? With Continuous Product Discovery you aren’t trying both validate the product and the market, and as you’ve already identified your market you can look for similar people who currently aren’t customers. Previous trial users and cancelled accounts can be a great source of external validation. Your outreach to these people shouldn’t be a random crap shoot though. Focus on those who liked or were engaged with the product, but didn’t continue with it. For example, their situation changed and the product failed to fit, or the product didn’t quite meet their needs, or they weren’t ready for the product at the time of trial. They can be a great source for problem validation as will be they more interested in the product\u2019s success than randomly selected people.<\/p>\n\n\n

\n
\"Continuous<\/figure>\n<\/div>\n\n\n

How to Prioritise Those Problems<\/h2>\n\n\n\n

Continuous Product Discovery is likely to surface lots of problems so you will need to prioritise them for validation and eventually for delivery.

Firstly, ask whether the problems fit with your product vision and strategy. If they don’t then you can park them until they do.

Next, look at the impact that solving the problem will have for your users and your company. Will it widen the market? Will it increase the value of the product to users? Will it make the product more important to users? Is the problem broad and far-reaching? Is the problem one faced by your high-value users?

It would be great if there was a magical scoring system that produced a single number and was right all the time, but this sort of prioritisation is always a judgement call.

Once you’ve established your priorities you can roadmap the problems and start to work on breaking them down into sensible parts. This results in something to be passed on to developers (or manufacturers) to be implemented, built, or otherwise delivered.

Done well, Continuous Product Discovery is an incredibly effective and powerful way of keeping your product relevant and valued by your customers.<\/p>\n\n\n\n

How can ProdPad Help with Continuous Product Discovery?<\/h2>\n\n\n\n

ProdPad can help you to create an effective Continuous Product Discovery process by:<\/p>\n\n\n\n