Continuous Discovery Habits - Book Highlights

I loved Teresa Toress’ new book Continuous Discovery Habits.

244 pages that go by fast. Paused to highlight often. Can't recommend it enough. Should be mandatory reading for every product manager.

A lot of product books and blog posts I read stay high level. With some, you feel like you've read a content marketing piece that's meant to sell a workshop. This book feels like it IS the workshop. Teresa doesn't hold back.

If you are a fan of her Opportunity Solution Tree then this book goes deep and across. I feel like I want this book embedded in my brain Neo-style so that I can easily access Continuous Discovery Kong Fu. Guess I'll have to embed the content by finding opportunities to practice her methods as I go. Continuously.

When I was done reading, I read through my highlights. Wrote my thoughts for 21 of them. Specified why they resonated with me. Then tried to make that consumable for my future self and others :)

Here they are in no particular order.

1/

Every time we mix up the team or change the outcome, we take a learning tax as the team gets up to speed.

If you are changing what you are building then you may be implicitly changing the team’s outcome goal. Do it frequently and the team will never have the opportunity to rack up enough learning to build trust and autonomy. This is often why it’s hard to escape the feature factory.

2/

The more diverse your interviewing team, the more value you will get from each interview. What we hear in an interview will be influenced by our prior knowledge and experience. A product manager will hear things that an engineer might not pick up on, and vice versa.

I’m ashamed to say that in my 10-year product career I’ve <f-strikethrough>rarely<f-strikethrough> never pushed for an engineer to run a customer interview.

Surely, I have read about the value of it in different articles. But Teresa made me think about it in a way I haven’t until now. Big part of it is that I wasn’t interviewing continuously. So getting dev buy-in for joining a call became content-oriented instead of process-oriented.

3/

Nigel Cross, Emeritus Professor of Design Studies at the Open University in the United Kingdom, compared the knowledge, skills, and abilities of expert designers to novice designers (across a variety of disciplines) and found that the best designers evolve the problem space and the solution space together. As they explore potential solutions, they learn more about the problem, and, as they learn more about the problem, new solutions become possible. These two activities are intrinsically intertwined. The problem space and the solution space evolve together.

I like to think of discovery as 2 google docs (semi-metaphorically).
One for problem discovery.
One for solution discovery.

Doesn't matter which doc you start with. You simultaneously populate and edit both as they feed off each other while you raise their maturity.

4/

Research shows that while we are better at generating ideas individually, we are better at evaluating ideas as a group.

Teresa recommends giving people time to ideate alone before sharing with the group. Do this both within meetings and between meetings.

I remember an instance where the best idea came between meetings and as a result of the meetings. The lead designer, lead developer, and I had many brainstorm sessions about drag & drop logic for complex scenarios. No good solution arose from those. After one of the more frustrating sessions where I didn’t feel comfortable driving for a decision in the meeting, my design lead took the train home. He was still consumed by the meeting and had time to think. While on the train he left me an audio WhatsApp message with the most elegant solution to the problem.

Your job as a PM is to get the best idea out of the room. Even if that means ideas outside of the room 😊

‍
5/

Instead of jumping straight to why an idea won’t work, use your discovery framework to help the stakeholder see where their idea does fit. For example, is the stakeholder focused on a different outcome from you? If yes, then don’t shoot down their idea. Even if you don’t like the idea (remember, our preferences don’t matter), you can remind your stakeholder that, while their idea might be a good fit for their outcome, it doesn’t support your outcome right now. You can follow this same strategy if their solution addresses a different opportunity. You can always say something like, “That idea has promise. We’ll consider it when we address that opportunity.” You can even capture it on your tree or in your idea backlog (not your development backlog) so that you remember to return to it later.

If you can see that it is based on a faulty assumption, don’t just call that out. Help your stakeholder reach that conclusion on their own. You can do this by story mapping their idea together. Generate assumptions together. When your stakeholder sees what assumptions their idea is based upon, you can now share what you’ve learned about those assumptions in your past assumption tests. This helps your stakeholder reach their own conclusions about their own ideas.

I’ve had an exec come to me with an idea saying if we built feature X it will help with churn. But really what they wanted was a better demo. They wanted to get new logos as they were short-term-revenue oriented. By the time I realized this, the feature was already delivered.

Nothing wrong with short-term revenue and developing features for getting new logos. But if I knew that the intent was a better demo for prospects, then I would’ve made different nuanced decisions within the feature. E.g. I would’ve covered fewer edge cases.

It’s important to understand the outcome that drives the stakeholder. Especially if it’s unsaid.

‍
6/

Because product managers, designers, and software engineers typically report up, to their respective departments, it’s not uncommon for a product trio to get pulled in three different directions, with each member tasked with a different goal. Perhaps the product manager is tasked with a business outcome, the designer is tasked with a usability outcome, and the engineer is tasked with a technical-performance outcome. This is most common at companies that tie outcomes to compensation. However, it has a detrimental effect. The goal is for the product trio to collaborate to achieve product outcomes that drive business outcomes. This isn’t possible if each member is focused on their own goal. Instead of setting individual outcomes, set team outcomes.

I’ve had an R&D exec ask me “how do you measure your product managers?”. Said he knows how to measure his developers so can’t see why I wouldn’t. I was stumped. I didn’t know how to answer in a way that doesn’t perpetuate the throw-it-over-the-wall culture. Wish I would’ve thought to suggest setting team outcomes, instead of playing the individual outcome game.

‍
7/

Most companies have teams who are on the phone with customers day in and day out. This includes sales teams, account managers, customer-success teams, and customer-support teams. You can work with these teams to help you recruit interview participants. The easiest place to start is to ask a customer-facing colleague if you can join one of their existing meetings. Start by asking for five minutes at the end of a call. You want to make it as easy as possible for both your colleague and your customer to say “Yes.” Use the last few minutes of an existing call to collect a specific story about the customer. Once your customer-facing teams are comfortable with you joining their meetings, ask your customer-facing colleagues to help you schedule an interview with one of their customers. To make this work, you’ll want to define triggers to help your customer-facing colleagues identify who to reach out to. Triggers might include: If a customer calls to cancel their subscription, schedule an interview. If a customer has a question about feature x, schedule an interview. If a customer requests a customization, schedule an interview.

Build trust with your customer-facing team gradually so that they feel comfortable having you on a call with their clients. Then make them active agents to recruit clients for interviews.

Talk to enough clients and you’ll flesh out a shortlist of your favorite design partners. I.e. clients whose context best represents your target audience AND have high communication skills.

‍
8/

In the opening quote of this chapter, Marty Cagan, author of INSPIRED, highlights that the best product teams complete a dozen or more discovery iterations every week. This pace is possible only when we step away from the concept of testing ideas and instead focus on testing the assumptions that need to be true in order for our ideas to succeed.

...The biggest barrier to testing assumptions is becoming aware of the assumptions we are making.

...It’s common for ideas to share assumptions. It’s one of the reasons why assumption testing is faster than idea testing. Assumption tests don’t merely give us a go/no-go decision for an individual idea; they help us evaluate sets of ideas.

Fleshing out assumptions about why something will succeed or fail is the core of product work. Testing the riskier assumptions is where good product work happens. There is value in "testing" them by just discussing with experts within the company. With no mockup or dev effort. This is one of the best tips in the book. Teresa expands on how to go about it.

‍
9/

The key to bringing stakeholders along is to show your work. You want to summarize what you are learning in a way that is easy to understand, that highlights your key decision points and the options that you considered, and creates space for them to give constructive feedback.

...when it’s your turn to share, don’t advocate [for your idea]. Simply share your point of view, answer questions, and clarify your thinking.

...When you frame the conversation in the solution space, you are framing the conversation to be about your opinion about what to build versus your stakeholders’ opinion about what to build. If your stakeholders are more senior to you, odds are their opinion is going to win. This is why we have the dreaded HiPPO acronym (the Highest Paid Person’s Opinions) and the saying “The HiPPO always wins.” Many product trios [PM, design lead & dev lead] complain about the HiPPO but miss the role they play in creating this situation. When we present our conclusions, we aren’t sharing the journey we took to reach those conclusions. Instead, we are inviting our stakeholders to an opinion battle— a battle we have no chance of winning.

...Ask your stakeholders to add to your assumption lists. This is where their unique knowledge and expertise can be invaluable for helping us catch our own blind spots.

...a good product trio knows to continuously manage stakeholders. Share your work along the way, rather than all at the end. Be thoughtful about when and how to share your work. Some stakeholders will want all the details week over week; others might want the highlights monthly. Adapt to what your stakeholders need. But even if they ask for outputs, take the time to show the work that helped you conclude those were the right outputs.

...Give them space to follow your logic, and, most importantly, give them time to reach the same conclusion.

Stakeholder communication should be like an engaging documentary. Don’t advocate. Simulate for them the experience you went through that made you reach your conclusions.

Decide the best level of granularity when showing. Tailor it to the specific stakeholder. Don’t be afraid to show them more granularity than what they asked for.

Don’t make the mistake of one-off sharing right before point of decision. Share continuously.
Bring them along for the ride.

10/

If you are reading this book and feel like these methods won’t work at your company, here’s what I’ll tell you: I rarely had the support of senior leadership to do product discovery well.

...I knew that I could impact how I did my own work. I didn’t worry about what other people were doing. I didn’t try to change the way these companies worked. I simply did my work my way, and I got results— so much so that, by the age of 32, I was the CEO of someone else’s company. I don’t share that to brag; I share that to show that you have more agency than you think you do.

Some people, instead of adopting a “That will never work here” mindset, swing the pendulum too far in the other direction. They want to work using the “one right way” to do discovery. I have news for you. There is no “one right way” to do discovery. All of the habits in this book can and should be adopted to match your team’s preferences and needs. This book isn’t designed to be recipes that should be followed to the T, but rather templates that should help you get started.

Don’t wait to get buy-in to do discovery work. Show how good looks like and build trust while not hurting delivery.

Move your work one notch at a time towards more discovery. Acknowledge where you and the company are now. Don’t go for a one-off 180 change.

“You have more agency than you think you do”. So true.

‍
11/

You might be tempted to score each opportunity based on the different factors (e.g., 2 out of 3 for sizing, 1 out of 3 for market factors, and so on) and then stack- rank your opportunities, much like you might do with features. Don’t do this. This is a messy, subjective decision, and you want to keep it that way. Remember, you aren’t making absolute judgments. You are making relative judgments by comparing and contrasting sibling opportunities against each other. You don’t need to score each opportunity. This will take a lot of work, will be rife with assumptions, and won’t lead to a better decision. Instead, make a data-informed, subjective comparison for each set of factors.

There may not be a clear winner, and that’s okay. One opportunity might look like the winner based on sizing, and another might look like the winner based on company factors. Yet another might look like the winner based on customer factors. Your job as a team is to have a healthy debate. Consider the different dimensions, and make the best decision that you can for this moment in time. Think about each set of criteria as a different lens through which to view impact. Use the lenses to fuel your conversation.

When we turn a subjective, messy decision into a quantitative math formula, we are treating an ill-structured problem as if it were a well-structured problem. The problem with this strategy is that it will lead us to believe that there is one true, right answer. And there isn’t. Once we mathematize this process, we’ll stop thinking and go strictly by the numbers. We don’t want to do this. Instead, we want to leave room for doubt. As Karl Weick, an educational psychologist at the University of Michigan, advises in the second opening quote, wisdom is finding the right balance between having confidence in what you know and leaving enough room for doubt in case you are wrong. That’s the balance we are looking for here. When we treat this like the messy, subjective decision that it is, we are leaving room for doubt, so that, down the road, if we learn we are addressing the wrong opportunity, we will be far more likely to course- correct.

Prioritization frameworks like RICE are subjective. Don’t try to automate any part of the decision-making process with a spreadsheet and a sort button.

There is no issue with spreadsheets as long as they are not the goal. The goal should be the conversation that the spreadsheet facilitates.

‍
12/

You’ll want to do the best you can to capture the value the participant is willing to share, but don’t force it. You always want to respect what the participant cares about most. Remember, with continuous interviewing, you’ll be interviewing another customer soon enough. When we rarely interview, a disappointing interview can feel painful. When we interview continuously, a disappointing interview is easily forgotten.

...We don’t want to think about interviewing as a step in a linear process. Instead, our goal is to interview continuously.

I am guilty of this. Forcing my agenda because:

• I finally have a customer on the line
• I was going about the process in a linear way

13/

You start by prioritizing your business need— creating value for your business is what ensures that your team can serve your customer over time. Next, the team should explore the customer needs, pain points, and desires that, if addressed, would drive that outcome.

...As you build a history of driving a product outcome, you need to remember to evaluate if driving the product outcome is, in turn, driving the business outcome.

I sometimes get obsessed about existing customers’ pain points to a point where I forget the business aspect.

E.g. if getting new clients is the company’s bigger challenge (as opposed to retention/expansion of existing clients), then acting on the most frequent support tickets may not be first priority now.

This doesn't necessarily mean trying to estimate the ROI of a feature. Just means picking the business parameter that is in line with the company strategy. And using it as a guide.

Tami Reiss has the most useful table I've seen for business parameters vs. product strategy. She wrote an article and shared a presentation about it here. It has a tighter table. But I prefer the one below.
‍

‍
14/

When a customer expresses emotion in an interview, it’s usually a strong signal that an opportunity is lurking nearby. However, don’t capture the feeling itself as the opportunity. Instead, look for the cause of the feeling. When we capture opportunities like “I’m frustrated” or “I’m overwhelmed,” we limit how we can help. We can’t fix feelings. But if we capture the cause of those feelings we can often identify solutions that address the underlying cause.

I used to stop when someone expressed emotion. The unconscious fear was that questioning the emotion would come off as judgment. I’ve learned to see it as an opportunity. I now approach it with curiosity and empathy. I do this both in my personal life and with clients & colleagues.

When a client expresses emotion try to get them to talk about the end-to-end effect. Go beyond the product. Especially relevant in B2B, where the “job to be done” is sometimes a job that was handed over to be done.

‍
15/

A product trio should share what they are learning with the rest of their team, their product peers, and with key stakeholders. However, when we share pages of notes that make sense only to us and/ or a video of the full interview, we are expecting our colleagues to put as much effort into our discovery work as we do. This isn’t feasible. They have their own jobs to do. Instead, use your interview snapshots to share what you are learning with the rest of the organization.

I remember an instance where a design lead sent the product team a link to a 1-hour customer interview saying:

“I just had the best customer interview ever. The client identified all of our product’s flaws and communicated them with a crazy amount of insight. I won’t do it justice if I tried to summarize. It's a must-listen!”

I had it on my to-do list. I really intended to listen to it. Never did.

Share the learning in a consumable way. Assume no one will consume the full raw artifact.

16/

I believe continuous interviewing is a keystone habit for continuous discovery. Of all the habits in this book, if you are looking for one place to get started, this is it.

I don’t believe I’ve met a PM that truly believed they are talking to enough clients.

I do believe that in B2B there is a lot of value in talking to customer-facing teams. They talk to more clients in a week than you’ll be able to talk to in 3 months. But you’re still getting someone’s interpretation of a conversation. Gives a false sense of checking the customer interview box.

I’m always “not getting to it” because of delivery tasks. I’m going to shoot for finding a way to continuously interview without hurting delivery.

‍
17/

Company factors help us evaluate the strategic impact of each opportunity for our company, business group, or team. Each organizational context is unique. Google might choose to address an opportunity that Apple would never touch. We need to consider our organizational context when assessing and prioritizing opportunities. We want to prioritize opportunities that support our company vision, mission, and strategic objectives over opportunities that don’t. We want to de-prioritize opportunities that conflict with our company values. We also want to consider the company’s political climate. We might need to spend a lot of political capital to gain support for a more controversial opportunity. If we aren’t willing to do that, we’ll want to choose another opportunity. Company factors also apply at the business-group and team level. A business group might be your business unit, your department, your tribe, or even your product line. Your business group’s vision, mission, and strategic objectives might add additional constraints on what you may or may not choose. These same factors might apply at your team or squad level as well.

Company factors are rarely talked about as explicit input for prioritizing opportunities. Political climate was definitely a factor in the companies I’ve worked at (200-1000 employees).

If your team or the company won't have the appetite to set up the initiative for success, then work to increase that appetite. Or if you don’t have the appetite to do that then choose another initiative.

‍
18/

When you get stuck, start with your competition. But then look wider. Ask yourself: What other industries have solved similar problems? They don’t need to be similar or even be in an adjacent industry. You are looking for similarities in the target opportunity. For example, if you work for a job board and you are helping recruiters evaluate job candidates, you can look at other job boards, but you can also look at how online shopping sites help shoppers evaluate products, you can look at how travel aggregators help travelers choose hotels, and you can look at how insurance companies present different policies. These industries are unrelated to each other, but they are each solving analogous problems. Additionally, when you are stuck, you can start to consider what your extreme users might need. What would a power user want? What does the first- time user need? What about people with different disabilities? How about people who live in remote locations or bustling cities? Young people? Senior citizens? Your extreme users will vary by product, but thinking about the needs of different types of users as they relate to your target opportunity can help you generate more ideas that may work for everyone. And finally, don’t be afraid to consider wild ideas. Some people don’t like this suggestion, because wild ideas are rarely pursued. But wild ideas can improve more feasible ideas. This is where the power of mixing and matching different solutions to identify even-better ideas comes into play. So, when ideating, pretend you have a magic wand— anything is possible.

Great tips for how to jump-start creative thinking. Examples from my experience:

• Similar problems - When I was a PM of an editor for building walkthroughs on digital products, I took UX and functionality “inspiration” from editors of email marketing products. They had an editor for building no-code flows.
• Extreme buyer stakeholder - When I created our security roadmap I thought of the strictest security person in mind. A person that would have the most objections about embedding our product into their internal systems. It differentiated us from the competition for enterprise deals.

‍
19/

Product teams often have to do some discovery work to identify the connections between product outcomes (the metrics they can influence) and business outcomes (the metrics that drive the business).

...S.M.A.R.T. goals play a role and are common for trios that have experience with their product outcomes. But it’s not one-size-fits-all. It’s perfectly fine to start with a learning goal and work your way toward a S.M.A.R.T. performance goal.

I like the idea of setting non-measurable “learning goals”. You can’t just sit in a room and figure out how your OKRs/KPIs cascade. Discovery work is often needed to flesh out performance goals.

20/

It’s important that we frame our discovery decisions as two-way door, reversible decisions. Lottie Bullens and colleagues, social psychologists at the University of Amsterdam, found in a series of studies that, when people viewed a decision as reversible, they continued to critically evaluate their decision after making it.

This innocent text is the toughest environment to create.

As an individual contributor PM I’ve always felt pressure to make “send and forget” decisions. Pressure comes from leadership implicitly. Revisiting a decision is perceived as “pausing” or “going backward”.

Very hard to create a reversible decision environment as an IC PM. Leadership should drive this attitude via leading by example. Make your PMs revisit past decisions. Make it part of the process. Do this once or twice outside of an emergency to jumpstart the habit.

The alternative creates a culture where PMs are afraid to move forward without high certainty. Decision cadence slows down as the fallback is “death by committee”. Then delivery time stretches out. And that feeds the cycle of pressure to not "pause and revisit".

‍
21/

While many teams work top-down, starting by defining a clear desired outcome, then mapping out the opportunity space, then considering solutions, and finally running assumption tests to evaluate those solutions, the best teams also work bottom-up. They use their assumption tests to help them evaluate their solutions and evolve the opportunity space. As they learn more about the opportunity space, their understanding of how they might reach their outcome (and how to best measure that outcome) will evolve. These teams work continuously, evolving the entire tree at once.

They interview week over week, continuing to explore the opportunity space, even after they’ve selected a target opportunity.

Bottom-up discovery is a good place to start fleshing out the middle and top. If you’re part of a HIPPO/feature factory culture, start fleshing out the assumptions of what you were asked to build. Start building ammo for future autonomy.

‍Below is a Tweet thread version of this post. Let’s continue the discussion there 😊
‍

‍