The What and Why of Continuous Discovery in Product Management

Welcome and Housekeeping

Robyn Brooks | 00:00:00–00:03:00 Okay, let’s go ahead and get started.

Hello everyone, welcome and good morning. My name is Robyn Brooks and I am a Strategic Advisor and trainer here at Productside. Thank you so much for joining us this morning.

Today we’re discussing The What and Why of Continuous Discovery.

I am excited to introduce Teresa Torres with Product Talk. Teresa, please tell our listeners a little bit about yourself and why you’re so passionate about this topic.

Introducing Teresa and Today’s Topic

Teresa Torres | 00:03:00–00:05:00 Yeah, first of all, thanks for having me. I’m really excited for this conversation.

I work as a product discovery coach. I’ve been doing that for about the last 10 years, and I’ve been really fortunate to work with teams all over the world — all different sizes and in a lot of different industries.

What’s fun for me is that I get to collect and refine practices that work in a lot of different contexts, and then help other teams find their continuous cadence to discovery. What’s really fun about that for me is helping teams unlock better products so they can better serve their customers.

About Productside and Webinar Logistics

Robyn Brooks | 00:05:00–00:08:00 Wonderful. As I mentioned, my name is Robyn Brooks and I’m a Strategic Advisor here at Productside. My background is in product management, particularly in the education technology space.

We have a lot of synergy between Productside and Teresa, and we’re really excited to have her here today to talk about this important topic.

Let’s go over just a couple of housekeeping items for the webinar.

After the webinar, you can continue to stay engaged with the product management community. Being in an online community can really help you feel connected, so join your peers by joining our LinkedIn group. Use it as a forum to chat about best practices and tips. We’ll paste the URL into the chat shortly, and you’ll also see a short link on the slide.

During the webinar, please ask questions — our team is standing by to help. At Productside we really love interacting with you. We encourage you to ask questions or give feedback. You can use the questions box on the right of your screen to type in questions or comments at any time.

We will leave time for Q&A at the end of the webinar, so if we don’t get to your question as we’re going, we’ll try to answer as many as we can at the end.

And our most popular question is: “Can I watch this webinar later?”
The answer is: yes. All attendees will receive a link to view the webinar recording after it has ended.

With that, let’s talk briefly about Productside.

Our mission is to empower product professionals with the knowledge and tools to build products that matter. We’re so excited to have you here today to talk through this. Unlike other companies, we’re focused just on the needs of product professionals. Whether you need help as an individual growing your knowledge and skills or you’re working towards improving your team’s effectiveness, we have the experience and services you need.

Check us out at Productside.com.

And now let’s get on to the meat of the webinar. Take it away, Teresa.

Discovery vs. Delivery and the Project Mindset

Teresa Torres | 00:08:00–00:11:30 All right, excellent. Thank you, Robyn.

Like Robyn mentioned, we’re going to talk about the what and why of continuous discovery. I already gave a little bit of background, so what I want to touch on here is just highlighting that the framework, tools, and tactics we’re going to talk about have been tested in a lot of different environments.

I know what it’s like to sit in an audience and think: “Oh, this is only going to work at the Amazons and the Netflixes and the Googles of the world.” What I want to encourage you to do is flip that a little bit and think: “Odds are this has worked in an environment like mine,” because I’ve probably worked with a company like yours.

See if you can start to look at: how might you bring some of these ideas to your own workplace?

Let’s level set: what do we mean by discovery?

It’s this simple: discovery is the work we do to make good decisions about what to build.

We often contrast that with delivery, which is the work we do to build, ship, and maintain a production-quality product.

These definitions are becoming much more prevalent in our industry because we see a lot of companies putting a huge emphasis on delivery and under-emphasizing discovery. Thankfully, that’s starting to change.

However, what I see is a lot of teams adopting a project mindset to discovery, and that’s because most of us grew up in a project world. What we’re now seeing is a shift toward a continuous mindset.

Today we’re going to talk about what continuous discovery looks like. I’m going to give you a clear definition of that, and we’ll walk through it over the course of the talk.

But before we dive into that, we’re going to start with a quick poll, which Robyn is going to walk us through.

Poll 1: Your Current Experience with Continuous Discovery

Robyn Brooks | 00:11:30–00:13:30 Yes, so this is a poll to determine: how much do you know about continuous discovery today?

Your options are:
– Nothing at all
– A little bit but I want to learn more
– Trying to implement it
– We’re doing it but want to get better

As you’re thinking about your options, there are no wrong answers. All of us are on a continuous improvement journey. In fact, what we’re going to talk about today is really about giving you a benchmark to aspire to.

Absolutely. I think no matter how much we’ve done this, there’s always room to get better because it’s always changing. I know that from following Teresa’s work over the last few years — we learn, we grow, and that’s what it’s all about. We’re continuously discovering, right?

Poll Results and Learning Mindset

Teresa Torres & Robyn Brooks | 00:13:30–00:15:00 Teresa: Exactly. We don’t just continuously discover our products, we also continuously discover our methods, which is a lot of fun.

Robyn:
Absolutely. Okay, so we have our responses in. Thank you to everyone who responded.

The biggest group — almost 50% — said, “I’ve heard a little bit but I want to learn more.” I think that’s pretty typical.

Teresa:
Yeah, that’s not surprising. It looks like the next big chunk is “trying to implement it.” For those of you that said “nothing at all,” you’re going to get a pretty good foundation today. We’ll level set you pretty quickly.

For those of you that said “we’re doing it but want to get better,” we’re also going to get into some details. I often hear people say, “Wow, I’ve been doing this for a long time and I still got some really good takeaways.”

So regardless of where you fall on this poll, hopefully there is something you’ll be able to take away from today’s talk.

From Project-Based Discovery to Continuous Discovery

Teresa Torres | 00:15:00–00:19:00 Great, so let’s get into it.

We talked about the rise of discovery versus delivery, and how a lot of us start with a project mindset. What we really want to talk about is: how do we get to a continuous mindset?

Let’s start with what I mean by a project mindset.

Most of us work in a world where we pick up a project or an initiative. If we’re lucky, we start with some user research: we do customer interviews, we create a research deck, and we rely on that as we make decisions throughout the project.

Then, maybe at the end of the project, we do validation research:
– We validate: “Did we get the design right?” with usability testing.
– We validate: “Did we get the delivery right?” with A/B testing.

There’s nothing wrong with project-based research. Especially if you’re involving your customer, that’s better than no research.

But what we’re seeing is that the best teams are adopting a more continuous cadence, because we’re starting to recognize that we could benefit from having the customer involved throughout the entire process.

I’m going to give you a definition of continuous discovery from my book Continuous Discovery Habits:

Continuous discovery is weekly touchpoints with customers, by the team that’s building the product, where they’re conducting small research activities in pursuit of a desired product outcome.

It’s a mouthful, so we’re going to break it down line by line as we go.

Weekly Touchpoints and the Curse of Knowledge

Teresa Torres | 00:19:00–00:24:00 Let’s start with the first part: **“weekly touchpoints with customers.”**

Why is this cadence so important?

As product people, we’re making decisions every day. Some of them are big strategic decisions:
– Which customers should we serve?
– What opportunities should we go after?
– What are the big rocks that go on our roadmap?

Others are smaller, daily or weekly decisions:
– What do we label this button?
– How do we expose this feature in the interface?
– How should this workflow work?
– How should the underlying data model work?

Most of us know that big strategic decisions need customer input — that’s usually where our project research shows up. But all those daily and weekly questions can also benefit from customer input.

Think about your phone. If you scroll through all your apps, you probably have dozens of apps you were excited about, installed, tried, and then abandoned. They fell short of your expectations.

That could be for many reasons:
– Missing a key feature
– Doesn’t match your mental model
– Just not good enough

Often what happens is a team gets a key idea right, but they don’t follow through. They don’t infuse those daily decisions with customer feedback.

Product teams also suffer from the curse of knowledge — a bias where, as we develop expertise in our product, we forget what it’s like not to have that knowledge. We make decisions from our expert point of view, which means those decisions often don’t work for our customers, who don’t have that expert knowledge.

One of the easiest ways to overcome this is to increase the frequency with which we talk to customers and to engage with them every week.

Now, this weekly cadence is a benchmark to aspire to.
If you’ve never talked to a customer, just focus on talking to your first customer.
If you’re talking to customers quarterly, try to get to monthly.
If you’re at monthly, try to get to every other week.

Don’t treat “weekly or bust” as success vs. failure. Take a continuous improvement mindset: can next month look a little better than last month?

By increasing the frequency, we increase the number of opportunities to see the gap between how we think about the product and how our customers think about the product.

This also starts to unlock what I call a co-creation mindset.

Co-Creating with Customers (But Not Asking “What Do You Want?”)

Teresa Torres | 00:24:00–00:28:00 We already talked about a **validation mindset**: – Validating design with usability testing – Validating delivery with A/B testing

A co-creation mindset allows us to get feedback much earlier in the process. Customers can:
– Give input on what problems we should be solving
– React to early sketches and low-fidelity prototypes
– Help us adjust direction when it’s still cheap to change

This can feel magical, because we can iterate quickly when we get frequent feedback.

Now, whenever I talk about co-creation, somebody thinks about the Steve Jobs quote: “People don’t know what they want until you show it to them.” Or the Henry Ford quote: “If I had asked customers what they wanted, they would have said a faster horse.”

So I want to be really clear: we’re not going to ask customers, “What do you want?” That’s the wrong question.

When we talk about co-creating with customers, the goal is to combine:
– Our knowledge of the product, the technology, and what’s possible
– Their knowledge of their world, their context, and their needs

We’re synthesizing these two knowledge bases to get better products.

So that’s why we’re aiming for a weekly cadence:
– To close the gap between how we think about the product and how customers think about it
– To unlock co-creation instead of just late-stage validation

But it’s really critical that it’s the team that’s building the product that is engaging with customers on this cadence.

The Product Trio: PM, Design, and Engineering Together

Teresa Torres | 00:28:00–00:33:00 Let’s talk about who I mean by “the team that’s building the product.”

This is what I call a product trio:
– A Product Manager
– A Designer
– A Software Engineer

These three are jointly responsible and are collaborating from the beginning on discovery decisions — the decisions about what to build.

That’s different from what we’ve historically done, where:
– The Product Manager writes requirements
– Hands them to the Designer for design work
– Then both are handed to Engineering to build

When we do these stage-gate handoffs, we see a lot of rework:
– Requirements get to design; design runs into constraints; we have to rewrite requirements
– Design and requirements go to engineering; engineering runs into feasibility issues or huge estimates; we go back to adjust everything

This is exactly why projects end up over budget, under-scoped, and late. It’s also why companies are moving away from big waterfall processes.

The problem is that even in Agile environments, many of us are still doing “mini-waterfall”: smaller batches, but still sequential handoffs.

The trio is meant to break that. We want these three roles:
– Collaborating from the beginning
– Jointly making decisions about what to build
– Jointly engaging with customers on a weekly basis

Because they’re the ones making decisions about what to build, they’re the ones who need firsthand exposure to customers. That’s how we overcome the curse of knowledge as a team.

Beyond the Trio: Including the Rest of the Team

Teresa Torres & Robyn Brooks | 00:33:00–00:37:00 Most of us have more than three people on our team. So what about everyone else?

You might have:
– Additional engineers
– QA
– Data analysts
– User researchers
– Customer success
– Sales engineers
– Product marketing

The idea is not to exclude anyone. The trio is the minimum cross-functional set of roles responsible for discovery. The concept is flexible.

For example:
– If you have a full-time embedded user researcher, your trio might become a “quad.”
– If you’re working on go-to-market strategy, you might pull in your Product Marketer for those decisions.

The point is to balance:
– Speed of decision-making (fewer people move faster)
– Quality of decisions (the right cross-functional perspectives)

Instead of handoffs, we ask: how do we get a cross-functional group together to make a better decision from the start?

Robyn also adds the value of having UX and engineering leads talk directly with customers. When they hear real stories, it shifts their assumptions, reduces bias, and leads to better, more meaningful products.

From Big Projects to Small, Continuous Research Activities

Teresa Torres | 00:37:00–00:41:00 So far we’ve tackled the first half of the definition: – Weekly touchpoints – With customers – By the product trio

Now let’s move to the second half:

“…where they’re conducting small research activities in pursuit of a desired product outcome.”

We can’t just take our big project-based research and cram it into a weekly cadence. It’s not sustainable.

Instead, we want to do small research activities that are sustainable week over week.

And we’re not doing research for research’s sake. We’re doing research to drive a desired outcome.

To organize this, I like to use a visual called an Opportunity Solution Tree — a way to chart the best path to your desired outcome.

Outcomes vs. Outputs and the Opportunity Solution Tree

Teresa Torres | 00:41:00–00:46:00 Historically, we’ve managed product teams by **outputs**: – We give them a roadmap and say, “Go build these features.”

That assumes we know upfront the right things to build. It assumes we can predict the future. If the last few years have taught us anything, it’s that the world is much more uncertain than we thought.

With an outcome focus, we say:

“We’re not sure what the right outputs are, but this is the outcome we need you to drive.”

In my model, the outcome should measure business value. It’s how your business leaders say: “This is where you can create value for the company.”

Example: Netflix.
If I’m a business leader at Netflix, I care about:
– Customer acquisition
– Subscriber retention
– Lifetime value

I might give a product team the outcome: increase subscriber retention.

The product trio then translates this business outcome into a product outcome — a metric that reflects behavior in the product.

For Netflix, that might be: increase viewing engagement. We have a theory that if people watch more, they’ll stay longer.

Once that outcome is in place, we use weekly interviews to discover opportunities — customer needs, pain points, and desires that, if we address them, will drive the outcome.

We’re then:
– Mapping opportunities under the outcome
– Generating solutions under those opportunities
– Using small tests to identify which solutions best address customer opportunities and drive the business outcome

That’s the Opportunity Solution Tree:
– Outcome at the top
– Opportunities in the middle
– Solutions at the bottom

And all of it is informed by continuous discovery.

Poll 2: What’s Your Biggest Barrier?

Robyn Brooks & Teresa Torres | 00:46:00–00:49:00 Robyn: We’re going to pause for another quick poll.

This poll is about what you think the biggest barrier is to getting continuous discovery going:

– Assembling the team you need
– Putting the right processes in place
– Recruiting customers to talk to (including internal barriers)
– Understanding the results of your customer interviews

For many of you, it might be multiple, but pick the biggest barrier.

Okay, looks like we have a majority of folks who’ve weighed in, so let’s see the results.

It looks pretty close between “putting the right processes in place” and “recruiting customers,” with quite a few who also feel that assembling the team and understanding the results are barriers.

What are your thoughts about this, Teresa?

Teresa:
This is really common. We’re going to get into the recruiting barrier in just a second. I see all of these on a regular basis:
– Many of us aren’t working in stable trios yet
– Many don’t know where to start from a process standpoint
– Many struggle to interpret interview data

The methods I’ll walk you through today are designed to help you with all of those.

Automating Customer Recruiting for Weekly Interviews

Teresa Torres | 00:49:00–00:54:30 The biggest barrier to weekly interviewing is usually **recruiting**. If you’re hustling every week to find someone to talk to, you won’t sustain it.

The key to unlocking a continuous cadence is to automate your recruiting process.

Ideally, I want you to wake up on Monday, look at your calendar, and there’s already a customer interview scheduled — and you didn’t have to do anything to get it there.

We’re going to combine:
– A way to recruit people
– With scheduling software to automate the back-and-forth

Here are three strategies:

Recruit people while they’re using your product or service.
– Great for B2C and B2B end users
– You can use in-product prompts, pop-ups, banners, or links in newsletters
– “Would you be willing to chat with our product team?” → scheduling link

Think about it like a product funnel — you’ll need to experiment and optimize, but most teams I work with use this method.

Use your customer-facing teams.
– Sales, account management, customer success, support
– They’re already talking to customers all day
– Define triggers: “If a customer mentions X, invite them to talk to the product team.”
– Then send them to your scheduling link

This works especially well in B2B contexts where you might need buyers or key stakeholders.

Advisory boards for tiny markets or extremely busy customers.
– For very small total addressable markets (e.g., 6 major studios)
– Or extremely time-constrained customers (Fortune 500 CEOs, ICU physicians during peak crisis)

Here you build long-term relationships with a small set of customers. Invite them to commit to, say, a monthly interview. If you have three product teams, you might invite 12 customers so each team gets a weekly interview.

For almost everyone, one or more of these strategies will work. Most teams mix and match.

Interviewing for Opportunities (Not for Solutions)

Teresa Torres | 00:54:30–01:00:00 Once we have customers in the room, the next question is: **what do we ask?**

Our goal is to avoid speculation.

A lot of our default questions are things like:
– “What do you want?”
– “What features do you need?”
– “How would you like this to work?”

Even when we ask about behavior, we might ask generically:
– “What do you like to watch on Netflix?”
– “How do you usually pick what to watch?”

Those still invite speculative answers and are influenced by cognitive biases. People will often answer with:
– What they aspire to do
– What they remember most recently
– What makes them look good

Instead, we want to ground interviews in specific stories from the past.

So instead of:

“Tell me about your experience with Netflix.”

We ask:

“Tell me about the last time you watched Netflix.”
“Tell me about the last time you chose a new show.”
“Tell me about the last time you watched on your phone.”

When we ground people in a specific moment:
– Their answers better reflect actual behavior
– Needs, pain points, and desires (opportunities) emerge naturally from those stories
– We get the nuance and context that help us design better solutions

So in your weekly interviews, your primary goal is to discover opportunities, not to evaluate your solution.

From Opportunities to Multiple Solutions (Avoiding Idea Bias)

Teresa Torres | 01:00:00–01:05:00 Once we’ve interviewed and mapped out the opportunity space, we choose a **target opportunity** to focus on.

Then we:
– Generate multiple solutions for that opportunity
– Set ourselves up for a compare and contrast decision

This is important because most teams:
– Hear a customer need
– Jump to the first solution
– Ask: “Is this a good idea or not?”

That “yes/no” framing triggers:
– Escalation of commitment (the more we invest in an idea, the more we love it)
– Confirmation bias (we look for evidence that supports our idea and ignore evidence that doesn’t)

The easiest way to avoid those biases is to always work with a set of ideas and ask:

“Which of these looks most promising?”

Think about Usain Bolt. If I ask, “Is he fast?” the answer is: “Compared to what?”
Compared to a cheetah? No.
Compared to other humans? Yes.

You want a field of options so you can identify a clear front runner.

But we can’t run full-blown project-based research for three big ideas at once. We don’t have time. That’s why we shift from solution tests to assumption tests.

Assumptions, Story Mapping, and Fast Tests

Teresa Torres | 01:05:00–01:12:00 Instead of treating each solution as a big monolith, we **break solutions into their underlying assumptions** and test those.

Assumptions fall into categories:
– Desirability – Does anyone want this? Will they do what we need them to do?
– Viability – Will this create business value? Will it drive our outcome?
– Feasibility – Can we build this? Is it technically possible?
– Usability – Can customers find it, understand it, and use it?
– Ethical – Are we collecting and using data responsibly? Are we creating harm or replicating inequities?

We’re often blind to our own assumptions, so we use story mapping to surface them.

Example: Netflix idea — integrate local TV channels so subscribers can watch sports.

We imagine the solution already exists and ask:

“What does our subscriber have to do to get value from this solution?”

Story map steps:

Decide to watch a game

Choose a streaming service

Open Netflix

Choose the local channel

Watch the game

Then, for each step, we ask:

“What needs to be true for this step to succeed?”

We uncover assumptions like:
– The subscriber is a sports fan
– They want to watch sports on Netflix (not somewhere else)
– They know what channel the game is on
– Netflix can partner with that channel
– The game isn’t blocked by regional blackouts
– Netflix can reliably stream live sports (with all the technical complexity that implies)

Some assumptions are shared across multiple solution ideas. If those fail, entire sets of solutions fall away.

Other assumptions differentiate solutions. Those are the ones we test to compare options and find a front runner.

Assumption tests can often be run in a few hours to a couple of days, unlike solution tests that can take weeks.

This is how we:
– Keep discovery continuous
– Move quickly
– Make better bets about what belongs in the backlog

Recap: The Continuous Discovery Loop

Teresa Torres | 01:12:00–01:16:00 We’ve covered a lot, so let’s recap the continuous discovery loop:

Start with an outcome.
– Translate a business outcome into a product outcome you can measure in the product.

Interview customers weekly.
– The trio engages in weekly interviews.
– Focus on specific past stories to discover opportunities (needs, pain points, desires).

Map the opportunity space.
– Use an Opportunity Solution Tree to break big, fuzzy problems into smaller, concrete opportunities.

Generate multiple solutions.
– Don’t fall in love with the first idea.
– Set up a compare-and-contrast decision.

Break solutions into assumptions.
– Use story mapping and the five assumption categories: desirability, viability, feasibility, usability, ethical.

Run fast assumption tests.
– Small, quick tests to collect evidence.
– Use that evidence to identify a clear front runner.

Deliver in small batches.
– Ship the best ideas into your backlog once risk is reduced enough.
– Measure impact on your outcome.

Then repeat. Discovery isn’t a phase — it’s a continuous habit.

If you want more detail, this is what my book Continuous Discovery Habits is all about. It’s meant to be a hands-on guide for teams.

Q&A: Making Time for Discovery and Changing Culture

Robyn Brooks & Teresa Torres | 01:16:00–01:26:30

Robyn:
Let’s move into Q&A. I’ll start with a question we got ahead of time.

As Product Managers, we all have so much to do. What do you recommend we do less of or de-prioritize in order to make time for weekly customer touchpoints?

Teresa:
This is a great question. Time is often the biggest barrier.

The advantage of continuous discovery is that if you have 30 minutes a week, you can start. You might need to invest a bit up front to automate recruiting, but once that’s in place, 30 minutes is enough to keep the habit going.

If you truly don’t have 30 minutes, you need to ruthlessly evaluate where your time is going. Most Product Managers are double-booked in meetings all day. Many of those meetings:
– You don’t need to be in
– Nothing bad would happen if you didn’t attend

We also get invited to everything because it feeds our ego to be included.

But if you want to do your job well, you need firsthand exposure to customers. So start by dropping the meetings that don’t truly require you.

And when you put that weekly interview on the calendar, don’t schedule over it. If you’ve automated recruiting and there’s a customer waiting, you’re far less likely to cancel.

Robyn:
Another question: is continuous delivery a prerequisite for continuous discovery, or the other way around?

Teresa:
They go hand in hand, and ideally you push on both at the same time.

– If delivery is faster than discovery, you’ll feel like you’re always scrambling for what to build next.
– If discovery is much faster than delivery, you end up with a huge backlog of ideas you’ve already vetted but can’t ship yet.

Most companies aren’t perfectly aligned on both, and that’s okay. Work to:
– Shorten delivery cycle times
– At the same time, build your continuous discovery habits

Robyn:
We also got this one: how do we break through org silos where engineering is seen as strictly back-end and “shouldn’t” talk to customers?

Teresa:
This is hard, and it’s very common. It’s the old IT mindset: “Just build what we tell you.”

If you’re a Product Manager in that environment, don’t start by trying to win the ideological war. Don’t go in preaching that “we must change everything.”

Instead:
– Look for small opportunities to invite engineers into customer conversations
– Start with a single interview or session
– Let them experience the value firsthand

In parallel, start exposing gaps:
– When you’re given a project, write down the expected impact
– After you ship, measure the actual impact

Over time, this makes it easier to argue for doing more learning before building.

Q&A: Big Projects, Results, and Leadership Expectations

Robyn Brooks & Teresa Torres | 01:26:30–01:33:00

Robyn:
Another great question: how do big, hairy projects — things that might require 3–6 months — fit into continuous discovery?

Teresa:
This is where opportunity mapping really shines.

Big opportunities like “It’s hard to find something to watch” at Netflix are evergreen. You’ll never “finish” that. But you can break that into smaller opportunities:
– “I can’t decide if a show is good.”
– “I can’t remember which service it’s on.”
– “I can’t find the specific movie I want.”

Then you break those into even smaller opportunities. For “I can’t decide if a show is good,” you might discover:
– “I want to know who’s in it.”
– “I want to know if my friends liked it.”
– “I want to know if it’s similar to something I’ve liked before.”

Those smaller opportunities can often be solved in weeks, not months. Each small solution chips away at the bigger, long-term opportunity.

So instead of a 6-month mega-project, you’re doing a series of smaller, outcome-driven bets.

Robyn:
And finally, how long does it take to see results from continuous discovery, and how should we set expectations with leadership?

Teresa:
When you’re new to this, there is a learning tax. You’re:
– Learning a new process
– Building infrastructure (recruiting, testing tools, etc.)
– Changing habits

The first time you go through the process, it will feel heavy and slow.
The second time, it will feel faster.
By the third or fourth time, teams often say:

“I can’t imagine working any other way.”

In terms of timelines:
– You can start interviewing weekly almost immediately, once recruiting is set up
– You can often start mapping opportunities and running assumption tests within a few weeks

Success looks like:
– You’re starting from an outcome
– You can quickly articulate your current target opportunity
– You have multiple solutions in play
– You’re running small tests weekly
– You’re making more confident bets about what goes into the backlog

Over a few months, you should start to see:
– Better product decisions
– Less rework
– Clearer link between discovery work and outcomes

Closing and Next Steps

Robyn Brooks | 01:33:00–01:37:00 Thank you so much, Teresa. This has been a really informative webinar.

To close us out:

If you want to learn more about the discovery techniques Teresa talked about, definitely pick up her book Continuous Discovery Habits — I’ll give an extra plug for that. It’s a phenomenal, practical guide.

If you need help implementing these practices and shifting from a project to a product mindset, that’s where Productside can help.

We have two flagship courses:
– Optimal Product Management – a comprehensive framework for product management practice
– Digital Product Management – focused more on cultural transformation and moving from project to product thinking

Together with Teresa’s book, these can really help you implement continuous discovery in your organization.

Thank you so much for coming today, and we hope to see you again soon.

Teresa Torres | 01:37:00–01:38:00
Thank you, everybody.