In the fast-paced world of startups, continuous discovery is a game-changer for product development. It ditches the traditional, one-time research approach in favor of ongoing customer feedback and insight gathering. This iterative process allows startups to constantly learn and adapt their products to better meet evolving customer needs.

But what is Product Continuous Discovery?

Imagine a never-ending loop of exploration and validation. Teams define a desired product outcome, gather customer feedback through interviews or surveys, prioritize areas for improvement, and then test potential solutions with real users. Based on the results, they refine their approach and repeat the cycle. This continuous learning loop ensures startups build products that resonate with their target audience, ultimately leading to increased product success.

Ref: Lissna.com

Why your product team should starting using this process?

Let me tell you some benefits of the Continuous Discovery process.

  • Enhanced Customer Alignment: Regular feedback ensures products are developed in line with customer needs.
  • Increased Agility: Enables quick pivots based on real-time user insights.
  • Risk Mitigation: Reduces the chances of investing in features that don’t resonate with users.
  • Informed Decision Making: Empirical data guides strategic choices and prioritization.
  • Continuous Learning: Fosters a culture of experimentation and ongoing improvement.
  • Improved Product-Market Fit: Ensures that the product continuously evolves to meet market demands.
  • Efficient Resource Allocation: Helps in focusing time and money on features that add the most value.

Ok, so how can I implement this with my product team?

The perfect process flow doesn’t exists, you can take some references from Teresa Torres book, you can check this blog post, but, at the end, you will need to approach your own custom process that fir with your team, budget, etc.

I’m gonna share the experience I had implementing the Continuous discovery in my last job.

Getting ready, set some rules

The continuous discovery process in the startup was a proposal made by my product manager pal Mariana Salazar and me. The hardest part was to get bought by the management team, so we offered:

“to enrich the upcoming roadmap initiatives with real user findings.”

This was the loop diagram to present the plan to the stakeholders.

A key factor to the preparation was to propose a good timeline, with a bi-weekly entire loop that looked not to overwhelm the people meanwhile its run besides our daily tasks.

We distributed the workload to not interrupt our daily job too much.

The execution

The users.

We had two types of people to interact with: Beta testers users and potential customers. Both of them had the opportunity to go through the product and get some tasks done.

The task

To control the activity we created some tasks, so all the users had the same goal when we ran the tests or interviews. The tasks were a bit complex because they involved an entire flow (Create a Budget vs Actual calculation based on some imported data). We named the tasks as Missions (Mariana’s idea).

Our way of work

We defined a by-weekly entire process that covered:

  1. Collect feedback.
  2. Organize feedback.
  3. Prioritize findings.
  4. Distribute to the different backlogs.
  5. Execute and start again.
Collect feedback
Talking with users
Mode 1

The users received the missions by email and tried to do it. Some days later we got an interview to know where they got struggled, where they feel a better process compared with alternatives.

Mode 2

Our sales and customer success team runs interviews with potential customers to demo the product using the same mission, after a brief introduction the user starts running the demo and sharing the screen. We recorded the sessions and the product team reviewed them week by week.

Organize feedback
Blurry covering product details (NDA)

The team members check affinity paths between findings, they can show in different user records, or getting an interesting frequency, or share a root cause.

This process is async, but we open a 30 mins session every week to discuss the decisions.

Prioritize

Our prioritization. was based in 3 factors:

  1. How critical was the task and the problem: is the user able to continue despite the problem?
  2. Is the problem in a flow we have planned to work on in a roadmap?
  3. Do we have enough information to find a solution?

In conclusion every problem could:

  1. Were assigned back to a different mission.
  2. Been allocated an upcoming roadmap project.
  3. Been part of a batch of 5 short-term solution tickets.
Where are the solutions?

This is important: until this point we ran the process only with the product team, from now is important to invite other teams people to get diversity in the solutions approach.

With a classified problems batch, we set initial hypothesis for possible solutions, in meeting with at least one development team member (we recommend inviting a technical and a customer service team member at least). So the solutions discussed covered possible feasibility problems, which means that we already had an idea about the cost of every possible solution.

Distribute

Depending on the solution cost and category, every problem/solution can follow 3 possible paths:

  1. Long-term roadmap (upcoming projects).
  2. insider tickets (3 days max. solutions).
  3. Customer issues (BUGS) – Immediate attention.
Execution

Here you can embed your designing process, however your team is already comfortable: by design sprints, brainstorming sessions, etc.

Remember the main goal of continuous discovery is not to solve all your problems, but to get constant feedback about your entire solution to discover new improvement opportunities and enrich your initiatives or roadmap.