An Overview On Teresa Torres’s Continuous Discovery Framework

If you’ve read Teresa Torres’s book, Continuous Discovery Habits, you’re probably familiar with her continuous discovery framework for building better products that are actually guided by user feedback.

You should read this article if you’re looking for a quick recap.

If you haven’t read the book… well, you are definitely missing out.

So here’s an overview (watch the video below or continue reading- whichever works best for you).

Ready? Let’s get started!

What is continuous discovery?

Continuous discovery is the process of conducting small research activities through weekly touchpoints with customers, by the team who’s building the product.

In other words, it’s a mindset of developing a cadence of having conversations with your customers and getting regular feedback from them.

What is actually the “product role” in a startup?

In recent years, many SaaS companies have started to rethink their growth tactics and think more about the product-led approach.

The product-led approach is a go-to-market strategy that puts the product at the forefront of the business and relies on it as the main driver of attracting, activating, and retaining customers.

If used effectively, it can significantly reduce the money spent on marketing and sales activities.

What are the benefits of using a continuous discovery framework?

As product managers, we’re constantly trying to improve the product thus making product design decisions every day.

Build features that matter

Some of them are more strategic decisions, like “what outcomes should we pursue”, “what opportunities we should go after”. Others are pedestrian decisions, like “how to label a button”, etc.

Regardless of the type, these decisions all matter.

And if we usually conduct thorough research before every big strategic decision why do we often forget to include customer inputs as well?

Well, it’s something that is often neglected by product teams but in reality, we should get user feedback on these big decisions too as they are the product users, after all.

What if we don’t talk with our customers regularly?

Nobody wants to work on features that are useless or confusing for the users. This can be easily prevented by adopting a continuous discovery mindset.

By continuously engaging with our customers and discovering their needs we are more likely to build features that drive value to our users than just relying on the validation mindset and end up creating something that doesn’t make an impact for them.

Avoiding the curse of knowledge

As product people, we are the experts of our own product knowing every detail of each functionality supported and of how it works.

But it’s not the same with customers.

They are not experts and don’t know the ins and outs of our product. This leads to the curse of knowledge and we start suffering from bias.

With that being said, we forget what it’s like to not have that expert knowledge thus we make decisions that don’t work for users as we’re making them from the expert point of view.

We can avoid the curse of knowledge by just engaging with our customers on a regular basis and trying to get feedback earlier in the process where it’s less expensive to make changes.

That way, we also avoid two other biases:

1. Escalation of commitment – we fall in love with the idea, and the more time we invest in something, the more we identify with it, the more we commit to it (even when it’s a bad one!).
2. Confirmation bias – we’re more likely to find evidence that supports the idea, and we’re going to completely miss the evidence that our idea is flawed.

The whole point of the confirmation bias is that you’re more likely not to notice the negative feedback because your brain is filtering it out and not that you’re ignoring them.

Using a continuous discovery framework will help avoid biases and build better products.

Validation mindset vs Continuous Discovery mindset

Engaging with customers using the continuous discovery framework, not only helps us eliminate the curse of knowledge but also aids us in validation activities.

A validation mindset is where we do all the design work up front and when we’re done we validate through usability testing to see if we get it right.

For this, we should develop the so-called “co-creation mindset” where a customer is actively involved in the product creation process.

“If I had asked customers what they wanted they would have said a faster horse”. – Henry Ford

Customer feedback is important but we don’t have to take every customer input or random idea into consideration.

This is where Henry Ford’s famous quote resonates more than ever as a co-creation mindset is not about letting customers make technology decisions but listening to their pain points and desires from their perspectives and getting feedback as soon as possible.

The sooner you get feedback the cheaper it is to make changes on half-baked ideas on “paper sketches”.

Let’s assume we’re interacting with our customers monthly.

In this case, we can gradually increase the frequency of the meetings to reach that weekly cadence but at the same time, we shouldn’t overwhelm them.

How to build a continuous discovery team?

Discovery should be led by people who are actually building the product. In most SaaS companies this is the product team trio:

• the Product Manager
• the Design Lead
• the Tech Lead

The typical product trio is comprised of a product manager, design lead, and tech lead who are working together from the very beginning and making decisions about what to build.

So this should be the team to engage with customers on a weekly basis.

While the trio is the main team, it’s not the only team that should be involved in the discovery. The thing is the more people involved in the decision, the slower you’ll go.

On the other hand, the decision will be better if you have the right people in the room. Depending on the type of decision you’re trying to make you can grow or shrink your team.

For example, if you’re building a machine learning API, it’s logical to include a data scientist in the team. If your company is committed to user research then you probably want to have a user researcher embedded on the team.

As you see every organization is unique and so are its needs.

What needs to change in your company to allow Continuous Discovery?

SaaS is a business model, so we should be looking for business and financial metrics that can help us increase our revenue, for example, customer retention.

That’s logical.

But apart from aiming for generating more revenue, good product teams should focus on customers and listen to their feedback.

That means you should shift your mindset from generating revenue which usually puts the focus on fast delivery and doesn’t care about quality or customer feedback that much towards generating value and becoming customer-centric.

Teresa Torres Continuous Discovery Framework

Start with setting an outcome

Good product discovery starts with a clear outcome specified with a metric.

A product outcome (OKR) measures how well the product supports a given business outcome and whether it creates business value.

Map opportunities

Once the product outcome is selected, the next step is to define and map opportunities.

What are opportunities?

They represent the customer needs, pain points, which in turn, create the business value driving your outcome (once your product solves them).

In other words- what could you build that could potentially bring value to your customers?

Map solutions for each opportunity

Now that we uncover what our customers need, we can also develop solutions for them.

In other words- what could you build that could potentially bring value to your customers?

Let’s look at an example to get a better understanding of this.

Most of us are familiar with Netflix which relies on a subscription business model. The key metric they should focus on is subscriber retention. We can translate this business metric into more behavioral data – e.g. watch time > engagement > retention.

So the product team can look for ways to drive this product outcomes. This could be the way the feed is displaying available movies, how it’s sorting recommendations etc.

I think you get.

Which solutions should I build?

Here is when conducting user interviews comes in. And don’t get me wrong, this is not a one-time thing, you should be running these on a regular basis (weekly works best).

The biggest barrier to interviewing every week is recruiting as it’s hard to find people to talk with you.

You can make it simpler by just automating the recruiting process.

1. Use your product to recruit your end-users. For example, offer gift card incentives for customer feedback in return
2. Use your customer-facing teams to recruit your buyers. Ask your customer support team to book a meeting directly on the calendar when being on the phone with the customer.

Should you work on 3 solutions at a time?

Working on three solutions at the time is critical but it’s not something that happens often.

Why? The answer is simple.

We don’t have enough research teams to use the traditional research methods and focus on three solutions for the same target group simultaneously.

That’s why we need to change our research methods to more continuous research methods.

We need to rapidly test our assumptions.

We don’t need to wireframe the whole product and we should only mock up the critical part of the assumptions.

Take the 3 solutions and break them down into underlying assumptions. This idea is not new. Eric Ries wrote about it in “Lean Startup” 10 years ago. But we’re still not doing it as it’s hard to see our own assumptions.

Validating assumptions

Assumptions can be validated through these actionable tactics. Originally there are three types of assumptions thus tactics but we’ll add two more:

• Viability – Should we build it? Why is it good for our business?
• Desirability – Does anyone want it? Why will the customer want our solution?
• Feasibility – Can we build it? Why do we think it’s possible to build this.
• And 2 more from us:
• Usability – Can anyone use it? Will our users be able to do what we need them to do
• Ethical – Is there any potential harm? What data do we need to build that solution? Are customers comfortable giving us that data?

Knowing these 5 categories will help you generate assumptions. But it’s not enough.

Here are 4 more validating strategies to not be blind to your assumptions.

1. Prototype a specific moment in the assumption using story mapping as it helps your team align around specific solutions.
2. Ask a 1-question survey to evaluate past behavior, e.g did they make a specific action over a given time?
3. Make sure your customers are already exhibiting the behavior you want to see. Have your customers shown interest in the solution you’re going to create?
4. Evaluate feasibility with research spikes. Collect specific data about specific tasks and then doing comparing/contrasting techniques you can evaluate the assumption, the feasibility of the solution, also improve delivery estimates.

Keep in mind that these assumptions can shape the prototype of a specific moment, not the whole solution.

Conclusion

Here is a brief recap of what we learned from the continuous product discovery framework.

First, we should define the clear outcome that represents a business value. Then we should do research activities on a weekly basis. We can do that by interviewing our customers to make sure we create customer value.

Once we choose a target opportunity we start developing a solution. The next step is to do rapid assumption testing so that we can compare our solutions with each other.

In this way, we can evaluate which solution is most likely to address our target opportunity creating customer value in a way that would drive our outcome creating business value. That’s it.

Want to start collecting feedback in-product from the right users and enhance your interview data? Get a Userpilot demo and see how you can automate feedback collection in-app.

[/vc_column_text][/vc_column][/vc_row][/vc_section]