Why am I in the favor of continuous product discovery

Product management is like dating. You meet someone (an idea), you like them and you start spending more time with them. You go out on a date (idea validation) to see if you two are compatible. When you’re sure that you’ve found a match, you finally decide to settle and exchange vows of spending a lifetime together (a lifetime of discovery in the product-market fit.)

Everything is sunshine and roses until the day you realize that a lot has changed in your relationship. You begin to see differences in thought and actions on a daily basis. You start seeing a shift in priorities, career aspirations, and beliefs over time. At first you ignore the signs of discontentment, but sooner things start getting worse. Only a few people can revive their relationship from this stage. For others, who find it easier to part ways, the failure becomes a mystery. Why didn’t my relationship work? What could I have done to save it?

There could be many reasons but one of the reasons why relationships go stale is because people don’t make efforts in closing the differences. They imagine that after the initial hard work of swooning over their partner, the relationship would survive on its own. But what they don’t understand is that relationships are like growing plants. They need constant care and nourishment to grow.

Why am I high on giving relationship advice today?

Because I feel that product management is somewhat similar. People fall in love with the idea of the product, they validate it, and when they have the data to prove that the idea would work, they start building the product.

But when the product evolves, they don’t understand what to do with it. A product, like a person, changes over time. If you commit to build something, you can never be sure what it’s going to look like in five years, ten years, and so on.

And that’s why nurturing a product with continuous improvements is the only way to build a successful product.

The phrase ‘continuous improvements’ might give you an impression of delivering solutions. That could be one of the interpretations but I want you to take a step back and think about the first step of product development.

Discovery.

Discovery is often the first step to building a product. You gather around to validate your ideas, discover pain points and test your assumptions before jumping to build solutions. But a lot of PMs treat it just as a stepping stone — forgetting that decisions in product development evolve as you move ahead in your journey. Most often, the discovery period is like a short burst of energy where product’s stakeholders brainstorm what they’re going to build. Once they have established the ‘why’ and ‘what’, they fasten their belts to gear up for the delivery.

Isn’t it ironic that most PMs follow incremental development and deliver in every sprint but do product discovery just once? How does one ensure that every new feature is aligned with the product’s vision and growth? How does one ensure that every change request is paired with customer interviews and usability testing?

In a world where customer behaviors and priorities keep shifting, the market keeps fluctuating, buying behaviors keep changing, continuous product discovery is the only way to build a product that matches with customer’s needs.

I learnt about the flaw in doing just ‘discovery’ from Teresa Torres. Before that, I had only heard faint murmurs about adopting continuous discovery. Teresa, who shares her thoughts and experiences on Product Talk says — “Delivery eats time for discovery. So, fix delivery to make time for discovery.”

I know what you would be thinking- PMs don’t have the luxury to do continuous discovery. They are constantly grappling with delivery timelines.

I agree.

And that’s what we need to change. We need to change the mindset that puts ‘discovery’ on a pedestal. So what could be the first step towards making discovery a part of the process?

Imbibing empathy for end users. Without empathy for people who are going to use the product, the discovery phase is worthless. We need to spend time understanding their needs, what they want from the product, what problems they face in the real world, what solutions they wish for and what goals they want to accomplish. Discovery, whether continuous or not, would only prove to be effective if we let go of our assumptions and spend time in activities that allow us to explore divergent ideas to solve users’ problems. A good discovery helps in understanding users’ pain points and getting in-context information.

The next step is to include continuous discovery in delivery timelines. Obsess about discovery as much as you do for a sprint’s outcomes. Talk to your end users after every release. Ask them to share their feedback on the features you’ve rolled out. Ask questions and hold your ideas for critique — are we chasing the right features? Does this help our users? What else would make their life easier?

I know it sounds too much to do for a PM- especially when PMs have their hands full. In small teams, they are responsible for delivery, pricing and revenue modeling, road map planning, doing market research, conducting customer interviews, and the list is endless. That’s why my suggestion is to train every individual on the team to do continuous discovery.

Let me share an example of how we do continuous product discovery at Quovantis.

One of our healthcare partners wanted to build a conversational AI assistant to augment their services. In the first phase of product discovery, we used various user research methods to understand our end users. With this acquired knowledge, we first focused on building a simple assistant that could handle the happy path quite well along with some common deviations from the happy path.

Then we gave our conversational AI assistant to real users. We collected and analyzed the kind of conversations people did with the chatbot. By following the process of conversation-driven development, we listened to our users and used those insights to improve our AI assistant. The conversations that users generated while talking to our assistant was the best training data that we gathered. We discovered opportunities to serve our users in a better way, and were able to build features and solutions that had the most impact. By using a combination of user feedback and onboarding analytics, we were able to make wise decisions for our product.

Continuous product discovery is possible when the entire team is aligned with the idea of it and understands why it’s necessary. So, whenever possible, indulge with your team to communicate the why behind this process. When you train your team to do continuous discovery, you give them a chance to think beyond their daily deliverable and look at the bigger picture.

At Quovantis, continuous discovery is a part of our product development process. Our engineers and designers actively take part in conversations to understand the product and its vision. If you’re yet to implement it in your organization, start with small steps and be mindful of the process.

I wrote this blog for our Medium Publication- Unboxing Product Management. The publication is a weekly column by people of Quovantis to share their learning.