Takeaways from Continuous Discovery Habits - Teresa Torres

Photo by Austin Distel on Unsplash

Off topic pre-amble

I’ve decided to try something new and start writing posts summarising my personal takeaways from non-fiction books I read. Whilst the primary driver is that I hope spending the time to reflect and summarise what I’ve learnt from the book will help me better absorb what I’ve learnt (as opposed to just taking copious notes for future reference, which is what I’ve done up until now), and hopefully it might be interesting to someone that might come across this.

The takeaways here are personal in nature and are weighted towards things that resonated with me or that I would have benefited from the most, as such it may or may not include the most important aspects of the book.

Getting back on topic of the book…

Teresa Torres’s book Continuous discovery habits (* affiliate link - commissions earned) has been on my backlog of books to read for a while and I wish I’d put it a lot higher on the list as I learnt a lot from it. It is a quality book that not only goes into the theory on tools and habits product teams can adopt to increase the chances of building great products that helps the business meets it’s goals, but provides specific examples using case studies which was my favourite part of the book.

In the book Continuous discovery is defined as:

At a minimum, weekly touchpoints with customers, By the team building the product, Where they conduct small research activities, In pursuit of a desired outcome.

The opportunity solution tree is a tool that helps product teams during continuous discovery to be more outcome focussed by helping them visualise what they’ve learnt in a way that clearly links the desired outcome (of the business) with identified opportunities (customer needs, pain points), solutions, and assumption tests. 

Here are my five key takeaways….

Start small and iterate (in ways of working)

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.  [Chapter 14]

Whilst starting small and iterating is an advice often used when building products, it equally applies when adopting a different way of working. It is very tempting to seek an environment where “everyone” is working a certain way and perhaps be discouraged when this is not the case.

One of the best advice I took away from this book was to remember that we have agency to make an impact in the way we do our own work irrespective of how the whole organisation works.

Applied to the continuous discovery process this means:

• Product team collaboration - start by finding your product trio willing to partner with you and consult them on key decisions and iterate from there
• Talking to customers - if you are not able to talk to your own customers, talk to someone who is similar to your customer and ask them for an introduction for another person to talk to
• Working backwards - where your team is assigned a solution to deliver (as opposed to outcomes to solve) work backwards by asking the two questions:
• “If our customers had this solution, what would it do for them”
• “If we shipped this feature, what value would it create for our business” (refine the answer until there is a clear metric, which is the desired outcome)

Identifying hidden assumptions

I often generate 20-30 assumptions for even a simple idea. (Identifying as many gotchas a you can increase the chance that you generate the riskiest ones)  [Chapter 9]

Assumptions testing is highlighted in the book as an effective way to minimise risk (or at least it is cheaper to learn during discovery) e.g. that what we are proposing is desirable, viable, usable, feasible…. As part of this the product trio will need to identify hidden assumptions.

Reflecting back on past initiatives I have worked on at work, this is one thing that I wished I had spent more time on in facilitating shared alignment around assumptions held by everyone. In one case it was an assumption I had an assumption that was not directly related to what we were trying to achieve and therefore believed it wouldn’t impact us, but this assumption ended up being false and impacting us post release. In hindsight I believe spending time as a cross functional team aligning on each of our own assumptions could potentially have resulted in a different outcome as there would have been an opportunity from different team members to highlight it as an assumption worth testing/validating.

Chapter 9 of the book goes on to share some techniques on identifying assumptions, one of which is to use story maps to surface underlying assumptions by putting ourselves in the shoes of our users to surface assumptions through each major steps they take in using our product.

Running assumption tests

As we test assumptions, we want to start small and iterate our way to bigger, more reliable, more sound tests, only after each previous round provides an indicator that continuing to invest is worth our effort. We stop testing when we’ve removed enough risk and/or the effort to run the next test is so great that it makes more sense to simply build the idea. [Chapter 10]

There are two tools that should be in every product team's toolbox- unmoderated user testing and one-question surveys. [Chapter 10]

Chapter 10 of the book talks through running assumption tests once your product “trio” has identified and more importantly prioritised key assumptions to test. This highlights the value in bringing the iterative mindset to discovery as well, and as a result of that the tools that can be used to test assumptions.

Prior to reading this book, one of the tools I’ve read/heard about for testing assumptions about demand is the fake door test (or a similar test called landing page test) where we show users an option that has not yet been built in order to measure interest. However this will usually still require some form of development to be done.

The book talks through two ways to more rapidly test assumptions to get some early signals.

• Unmoderated testing - unmoderated user testing services allows you to post a prototype and define tasks/questions for participants to complete without the presence of a moderator. Whilst normally intended for usability testing, this could be used to test assumptions in a similar way one might do with a fake door test but without requiring development.
• One question surveys - Similarly one question surveys that pop up in product could be used to test some assumptions (however it is important to ask about past behaviour and specific examples and not what they might do in the future as this could result in unreliable data)

Continuous interviewing

The hardest part about continuous interviews is finding people to talk to. In order to make continuous interviewing sustainable, we need to automate the recruiting process. Your goal is to wake up Monday morning with a weekly interview scheduled without you having to do anything. [Chapter 5]

Whilst there are some great user research tips in chapter (I’ve got a book called “The Mom Test” that delves a lot more on this topic near the top of my list which I hope to write a summary about in the near future), perhaps the most interesting and unique part is the tips on addressing one of the frictions/pain points of finding customers to interview, and “automating” this process such that talking to customers regularly becomes easy.

One of the tools suggested is to recruit them whilst they are using your product by way of a one question survey “Do you have 20 minutes to talk with us about your experience…”, and potentially in combination with a scheduling software to reduce the back and forth needed for them to select an appropriate time.

Prioritising opportunities

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.

Perhaps my most interesting take away from this chapter was the advice not to “score and stack rank” the opportunities especially as many prioritisation frameworks I’ve seen so far does this. However the rationale does make sense in this instance as doing so will lead us to believe that there is one right answer (the highest score).

The recommendation instead is for the team to have a healthy debate, considering different dimensions and make the best decision at that point in time. In relation to decision making it also refers to the level 1 vs. level 2 decision concept from Jeff Bezos in which he argues that we should be slow and cautious when making decisions that are hard to reverse (level 1) but move fast and not wait for perfect data when making decisions that are easy to reverse (level 2).

Closing

There are so much to take away from reading this book that my top takeaways hasn’t even touched the surface of the continuous discovery process and opportunity solution tree.

If you find yourself interested in what was discussed here, the book Continuous discovery habits (* affiliate link - commissions earned) is a top read.

* As an Amazon Associate I earn from qualifying purchases. This page contains affiliate links, meaning I get a commission if you decide to make a purchase through my links, at no cost to you.