Continuous product discovery for enterprise companies

Parvezsh Ahamed, Trisha Shrivastava
Thu 15 Apr 2021
Share this blog:

According to Marty Cagan, the purpose of product discovery is to address these critical risks:

  • Will the customer buy or choose to use it? (Value risk)
  • Can the user figure out how to use it? (Usability risk)
  • Can we build it? (Feasibility risk)
  • Does this solution work for our business? (Business viability risk)

Discovery is about the need for speed. This lets us try out many ideas, and for the promising ideas, try out multiple approaches. There are many different types of ideas, many different types of products, and a variety of different risks that we need to address (value risk, usability risk, feasibility risk, and business risk). So, we have a wide range of techniques, each suitable to different situations.

Product discovery is most often seen as the prelude to building a new product. Whatever Product Discovery framework or methodology you use, it’s usually to find a new problem to solve, validate that the problem is worth solving, and test possible solutions. However, the true power of Product Discovery emerges when you extend it through the product’s 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. 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.

There’s no point building a new feature if it doesn’t fit the product’s vision and strategy. It won’t help you reach the product vision, and it’s 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.

Ways of doing product discovery

There are different cheap and effective ways to do product discovery. Some of them are - showing mockups, sending surveys, or doing fake door testing.

Mockups of your feature idea can help your users understand the purpose of it. Make sure you collect useful feedback from your users when you share this mockup with them.

Surveys can be paired with a mockup or live on its own. The idea is to ask thoughtful questions to your users, collect their feedback, and draw conclusions.

Fake Door Testingis a minimum viable product where you pretend to provide a product, feature, or service to Web page or app visitors. Without developing anything just yet, you communicate to visitors that the thing exists and ask them to act on it. If they do, you know they want it, and it’s time for you to start working on developing it.

Mining Your Feedback

In some ways Continuous Product Discovery is easier than initial Product Discovery. As users already have your product, you should be collecting feedback they provide. The more common problems you solve, the broader and more effective your product will be.

There are many ways of validating a problem, user testing, surveys, asking questions in a user community, to name a few. It’s important to get a diversity of users in your validation of a problem. Focus on those who liked or were engaged with the product, but didn’t continue with it. They can be a great source for problem validation as will be they more interested in the product’s success than randomly selected people.

Now that you’ve made it here, you should know enough about the feature idea to decide on whether it’s good or not. With product discovery, there will be many ideas that don’t make the cut — possibly more than you expect. Don’t get discouraged, though. That means that you’re on the right track. It’s much better to discard an idea at this point than when your team dives into development.

Prioritising problems

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?

Impact is difficult to measure precisely. So, I choose from a multiple-choice scale: 3 for “massive impact”, 2 for “high”, 1 for “medium”, 0.5 for “low”, and finally 0.25 for “minimal”. These numbers get multiplied into the final score to scale it up or down.

Next, I multiply the impact score with the confidence I have about its impact. Confidence is a percentage, and I use another multiple-choice scale to help avoid decision paralysis. 100% is “high confidence”, 80% is “medium”, 50% is “low”. Anything below that is “total moonshot”.

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


What’s next? You’ve determined your feature idea has potential, or maybe it doesn’t. Either way, the next step is to start over from the very beginning.

If you scrapped the feature, you might need to ask different questions during customer research. Or, you might need to re-evaluate if you’re really isolating the customer’s problem. If you built it, then assess how customers are using it.

Remember, product discovery is an on-going process, a craft. As we strive for Product Excellence, we have to keep coming back to customer feedback or deep user insights. It’s the foundation for how we build, not only a great product, but also a product-led culture that keeps delivering great products.

First phase is just interviews and data gathering. Second phase is synthesizing all the data into themes. Third phase is to prioritize features that can be delivered. Repeat several times a year. There is a real art to creating the conversation guides and mixing interviews up with activities.

Pitfalls of Continuous Product Discovery Processes

Treating Product Discovery as an ongoing/continuous/recurring process is important to establish the habit of being customer-centric as a Product Team.However, there are risks to continuously digging through data for new insights, trying to get in touch with users every week, and running experiments too often (in relation to your traffic/capacities).

Fear of Missing Out - Weekly customer interactions are great for shaping the team and creating a user-first company culture. However, talking to users in the wrong cadence can lead to iterative and small step thinking. Incremental improvements of a well-established product or feature can be useful, but when you want and need to think big(ger), investing time upfront is important.

Too Much Research - Getting distracted by every new bit of insight can lead to a lack of decision-making and focussing on shipping what has already been validated. Go to user research only if you have a pressing need to answer a research question and the operational capacity to build features/products for it.

False Starts - Make sure to align your discovery efforts to fit into the overall strategy of your product or company. Discovering a problem that doesn’t fit into the company’s strategy will only waste time.

The Wrong Numbers - It doesn't make sense to chase quantitative experiments if you don't have the numbers. Focus on the most effective validation to build the product/feature, it need not be quantitative always.


See the industry’s most advanced decision support system

Get an overview of the most advanced Health Cloud built to help healthcare care as one.
Tags: Product Discovery
Parvezsh Ahamed, Trisha Shrivastava
Continuous product discovery for enterprise companies

Accelerate Your Digital Transformation with the Innovaccer Health Cloud

Request a free demo of the #1 healthcare data platform to know how you can generate millions in savings just like our superhero customers.

errorhi there

errorhi there

errorhi there