Four
3 things learned from 50+ Discoveries, Notes from 'Continuous Discovery Habits', and Product Tarot Cards
Thanks for reading. Each newsletter pulls together three topics - the only thing they have in common is that I enjoy them and want to share them.
I’m joining Herd as Director of Product in the New Year. Herd’s currently a specialist business analysis consultancy & delivery partner, I’m joining to create and lead the product management arm. More info here. Shout if you’d like to talk about working together in 2024.
That being said - in newsletter four we’ve got how to invest in the right opportunities by doing Discovery right, notes from ‘Continuous Discovery Habits’ by Teresa Torres, and adventures in Product Tarot. Enjoy!
Scott Colfer, November 2023
Do the right thing: invest in the right opportunities by doing Discovery right
The science of saying ‘no’ to the wrong things
I used to work with nonprofits, charities, and social enterprises. We had to pitch for funding from investors. Most investors wanted a well-defined solution to invest in. But it takes time to understand a problem, and it takes understanding of a problem to design a useful solution. We’d play the game of pitching an idea in order to get funding. We’d then start the thing, learn more and try and retrofit the original bid to actually be useful. This made me sad. Money is precious and we were working with people who deserved better. Me and my CEO wanted to get closer to investing in a problem without specifying the exact solution. So we pitched and won funding from Esmee Fairbairn to do something about this.
We had a central fund that covered the costs of making time to understand problems for our service users before deciding if and how to apply for a grant. We called this ‘Lean Discovery’ and it was powerful. We explored 5 grants over 6-months. Normally we’d apply for a modest amount from all 5 but this time we discounted ourselves from 3 of them. We didn’t have the understanding of the end users or the capability needed to serve them well so backed away. We were extremely confident about 2 of them based on our Lean Discovery and applied for ambitious funding in both. We asked for way more funding than normal because of our confidence that we could genuinely help people. We were successful in both. We won more money in those two than we would’ve done if we’d won all 5 at our normal bid amount. This allowed us to focus our efforts rather than spread them. And most importantly, I can honestly say that we made a difference for the better for people. Saying ‘no’ to the wrong opportunities helped win the right opportunities, and win big.
That was over a decade ago in 2012-13. Since then I’ve led loads of Discoveries and reviewed even more. And learned this challenge is the same in the commercial and public sector. Everyone needs to find the need that hasn’t been met before they make a decision to design something to meet that need. Otherwise we create a solution in search of a problem.
Discovery: making a decision to kill or continue with an opportunity
We must be ruthless with ideas and opportunities, testing their likelihood of success before spending time designing and building them. If it’s going to fail, fail fast. We can make this decision by asking three questions:
Does anyone want it? Is it desirable?
Should we build it? Is it viable?
Can we build it? Is it feasible?
This is straight from ‘Continuous Discovery Habits’ by Teresa Torres, a book that’s become the go-to for Discovery. I won’t summarise it here and pass it off as my own. I will summarise my take on the book below. And suggest you read it for yourself :) Prior to the popularity of ‘Continuous Discovery Habits’, I used five questions to figure out if we should kill or continue with an opportunity:
Is there a problem?
Is it valuable to solve?
Is it feasible to solve?
Is it urgent?
Is it pervasive?
Are users solving it themselves?
Are we the right people to solve this problem?
Teresa’s approach simplifies these into three powerful questions so I’ve happily upgraded to hers. I share this for two reasons. Firstly: perfect is the enemy of good. If you’re asking any decent questions that improve the opportunities you’re choosing, that’s success. Secondly, we learn and improve. Simplicity is hard. It’s worth continuously learning from others and reviewing and retrospecting on what we’ve learned so we can improve.
3 reasons why Discoveries (should) end
So far so textbook. You could learn all of the above from a few web searches and a bit of reading. I got to see behind the scenes of 50+ Discoveries over a few years, leading and reviewing them for a Central Government Department in the UK. Prior to that I ran a cross-Government review and retro of Discovery. Here are 3 reasons why Discoveries (should) end.
1. It never should’ve started
There’s a lot of performative Disco. out there e.g.
The solution has been decided but a team is asked to do a Discovery ‘cuz reasons’
The team work hard but if they genuinely challenge the problem it’s unwelcome.
Colleagues are tired of this ‘Discovery thing’ that seems to take ages and go nowhere
A programme tries to define its whole self through a single Discovery but that doesn’t work because it’s too big in scope. The team wonder how on earth to make this work. Colleagues are tired of this Discovery thing that seems to take ages and go nowhere.
The conditions are right for a genuine Discovery . . . and then the team falls in love with a single problem/unmet need and doesn’t explore its value, viability or feasibility. A splurge of user needs later and the team is happy, colleagues are happy . . . and then the thing gets lost in Alpha and Beta because it’s not valuable, viable or feasible.
Everyone loses in these real examples. Being honest about the context we find ourselves in and giving it the right name can avoid a lot of wasted time and effort. Pragmatism is important. If it’s really a project then call it a project and run a project initiation. If it’s a Programme then run something lightweight and flexible like an Exploration.
2. We forgot that context is key
The biggest reason for problems in the Discoveries I reviewed was nothing to do with the users or their unmet needs. It was to do with a limited understanding of our own organisation. For example: I reviewed multiple opportunities that relied on developing their products with the same internal partners. And they had no idea about this. Each team was unwittingly competing for the same route to (internal) market. Each opportunity was desirable in isolation but they had a hierarchy of desirability in relation to each other. And this bottleneck on the same partners meant that, until these teams together, they weren’t individually viable or feasible.
There’s a crucial leadership role here, to understand and generously share context. Having teams try and figure it out through trial and error, relying on goodwill and good luck, will burn money, time and trust. There’s also a crucial role here in teams accepting this context and working with it. A crusade to get the problem or unmet need we’re most invested in will just burn everyone out.
3. It doesn’t matter
Discovery’s done. Everyone looks at each other, shrugs, and ploughs on with designing the product. There’s no decision to kill or continue. At best we’ve learned a bit more. At worst it was a waste of time.
This was true in my organisation until I worked with colleagues to set clear expectations around successful Discovery, support to ask and the right questions, and space to review the opportunity: making a kill or continue decision. So now Discovery mattered . . .
. . . except not really. There was still no simple question about value. So I worked with colleagues to define how we measure the outcomes of our work and asked teams to name who they were going to help, what unmet need was being addressed, to measure what this looked like now, and to set a minimum target for improvement that justified the investment of time and money being requested. This was then used in the future to assess if the product had hit product-market-fit (aka return on investment, aka benefits realisation). And so Discovery started to matter. See a public summary of the approach here.
There’s a science to saying ‘no’ to the wrong things. It’s partly about the opportunity itself. And partly about the context the opportunity sits in. There’s success in being honest that conditions are imperfect and we’re not really doing a Discovery. Pragmatism is powerful. There’s success to saying ‘no’ to the wrong things as early as possible so we don’t waste our time and money. And every opportunity we pause or close down leaves the landscape simpler, making the right opportunities easier to spot.
What’s your experience of finding opportunities? Have you carried out a useful Discovery? Is there anything else you’d like me to share about Discovery (this just scratched the surface)?
Reader’s Digest: ‘Continuous Discovery Habits’ by Teresa Torres
‘Continuous Discovery Habits’ has become the go-to book for finding the right opportunities to improve the value of your products. Opportunity solution trees have become the shorthand for this great book but what else does it share, and what is it missing? Here are the bits that stand out to me.
Continuous Discovery in a nutshell
Teresa’s looking to change a certain kind of organisational mindset where people fall in love with a single idea and become fixated with building it. Where this ‘solution’ is measured through lots of metrics, lots of outputs to deliver, lots of goals. There is a lot of reporting and a lot of big reports. And leaders who’ve never seen good product teams up close so they can’t coach and develop their people. Teresa would like to change from that to a mindset that is:
Outcome oriented. The goal is impact for users (not the amount of code shipped)
User-centric. Our goal is to serve our users, don’t forget that
Collaborative. We reject silos and have multidisciplinary teams
Visual. We externalise our thinking in creative ways, going beyond just the spoken and written word
Experimental. We take a scientific approach, testing hypotheses.
The aim is to find opportunities in the form of unmet user needs, pain points, and desires. At its simplest and as a minimum, this involves weekly touchpoints with users by the team building the product where they conduct small research activities in pursuit of a desired outcome. Ideally, outcomes come from a two-way negotiation between leaders and the team doing the Discovery. Here’s a challenge for leaders: research suggests that setting a learning goal (e.g. discover a strategy that might work, and do your best) could be more effective than challenging performance goals in a SMART format. Teresa suggests ways for teams to sensitively challenge leaders who don’t provide the necessary information on initiatives, or who give specific outputs without clear outcomes.
Anti-patterns
Pursuing too many outcomes. Impact is increased when we focus on one outcome rather than spreading focus across many.
Ping-ponging from one outcome to another. Reactive organisations always ‘fight fires’ and so outcomes often switch. This wastes time we’ve spent learning how to achieve one outcome as we quickly move to another.
Setting individual outcomes rather than team outcomes. Separate outcomes for individuals will pull the team in opposite directions.
Choosing an output as an outcome. An example is ‘launch software x by date y’. So what if you achieve that? What’s the value in it?
Focusing on one outcome to the detriment of all else. Yes, we need a primary outcome. But we also need to monitor other signals to get a full picture of team health.
Start with an experience map
Each team member thinks about the outcome to be achieved (e.g. increase new users) and has a question that sets a scope (e.g. what’s stopping a new user from completing their application in one go). Then co-create a shared experience map. Start by turning the individual maps into nodes (a moment in time, action or event) and links (which show movement between the nodes. Bring all the nodes and links together, conflate and simplify. Next, add more detail on links, including movement between nodes due to something not working, or frustration. Finally, add more context to each step: what are users thinking, feeling and doing? Don’t get bogged down in endless debate. If needed, highlight differences in perspective between the team, don’t debate them. Differing perspectives are the point of multidisciplinary teams.
Go learn
The experience map is a jumping off point, a set of assumptions to test. Now go out there and learn, speaking with users. Separate what you are trying to learn (your research questions) from what you ask during an interview (your interview questions). Focus your research. Do little and often. Don’t generate huge interview scripts. Keep it as conversational as possible and leave space to excavate the story. Do ask about real and specific experiences. Don’t ask hypothetical questions. One format you can use to summarise an interview is a memorable quote, quick facts, insights, and opportunities. Do generate actionable insights. Don’t share copious notes.
Find, map and prioritise opportunities (not solutions)
This is where the now famous opportunity solution tree rests. This has been described loads. Rather than me offering another description go watch this instead. Focus on one opportunity at a time and test your assumptions:
Desirability assumptions. Fundamentally, does anyone want it?
Viability assumptions. Should we build it? Just because it works for our users doesn’t mean it’ll work for our organisation.
Feasibility. Can we actually build it?
Consider hard opportunities. Don’t draw conclusions from shallow learning. And be ready to switch opportunities, don’t overcommit to them.
What’s missing?
Let’s say you’re a product leader in a large, messy organisation. You’ve got loads of teams. They’re doing Discovery pretty well. One of the biggest reasons an opportunity won’t lead to anything will be your organisation itself. For example, I saw multiple examples of a single team missing out on crucial internal context, such as a critical contract expiry, or users not having the headspace for even more change. This context can be hard to draw out through user research interviews. The ‘product trio’ at the heart of this book (product manager, designer, and developer) will implicitly require someone to provide the broader organisational context. There’s an argument to be made that this is the role of leadership: to lead through context. But I don’t think that’s explicitly clear in this book.
I feel harsh typing this. It’s unfair to say that ‘understanding wider organisational context’ is missing from this book. The book achieves what it sets out to do, which is for Teresa to share her exceptionally well-designed approach to continuous discovery. I wish this book existed when I started out in product management. It gives an effective approach to finding opportunities to improve our products for our users.
Have you read ‘Continuous Discovery Habits’? Did anything else stand out to you? Do you disagree with any of my take?
Product Tarot
The Devil is in the detail
I love the Devil card in Tarot because it’s not what you think. Look past the huge, hulking Devil at the two people in chains. Now look at those chains. The chains around their necks are loose, they could remove them any time they choose. The Devil represents the things they’ve allowed to become big, monstrous, looming. The Devil is of their own making. For me, the card doesn’t represent something to be scared of. It represents making things less scary.
Have you allowed something to become big and scary at work, made a chain around your neck? Can you take back control, throw-off the chain you’ve created and lose that looming monster? What would that look like? What would it mean to care less and have more fun?
Tarot cards, really?
So yeah, I’ve been playing around with Tarot Cards. It’s thanks to my wife that I'm writing about it. She kept telling people about what I’m doing with Tarot and when I asked why that was she said simply ‘it’s really interesting to people’.
I first became aware of Tarot Cards as a teenager reading the ‘Arkham Asylum’ comic, a psychological re-imagining of Batman. A couple of decades later I bumped into Tarot again whilst taking Alan Moore’s writing course on BBC Maestro. Alan uses the suits of the Tarot to represent the elements of good writing. Alan’s comic series ‘Prometheus’ heavily features the Tarot, which I’ve read too. It makes sense that comic creators are interested in the Tarot because it’s a form of visual storytelling much like comics. Each tarot card is like a comic pane, pulling a few of them allows us to create our own story. I bought my own deck to help me when writing. Then one day I decided to pull one for real, for myself.
I don’t view the Tarot Cards as magical. I don’t think they predict the future. I don’t think they’re mystical. I think they’re cards with pictures on them. And I think they’re great tools for personal reflection, for making some time to see that thing in our blindspot that makes our lives that little bit better. I started pulling a card in the morning to start the day with a bit of personal reflection, rather than doom-scrolling on my smartphone. The Devil is one of the first cards in this way and it genuinely helped me to realise that I’d blown something out of proportion and that it didn’t really matter. I love starting the day with a little personal story-telling. It’s not serious for me, it’s enjoyable.
Checking your blindspot
I recently went for my first and only Tarot Reading. It felt silly and weird and embarrassing but it shouldn’t. So I pushed myself outside of my comfort zone, booked it without overthinking it and went. I chose a reading from Lucy Porter at She’s Lost Control. Lucy’s profile talked about fun, which is what I wanted it to be. Lucy was was gracious with a n00b like me. I confessed I didn’t really know what to ask or expect, then downloaded loads of ideas before saying ‘sorry, this is really random’ to which she replied ‘don’t worry, it’s always fucking random’ :) We did a short reading and Lucy was ace at being intuitive and interpretive, working with me to build a story that was useful for me. What I was starting to realise was that, for me, Tarot is a fun way of holding a mirror up to myself and finding what’s in my blindspot. It’s often something I wouldn’t have guessed.
Finding Justice
‘Justice’ was the card that we decided best described me. It’s about giving everyone a voice. Finding bias and countering it with a new perspective. And this links with my job, product management. It’s all about finding value in the sweet spot where different perspectives align. The problems I encounter always boil down to bias: one perspective dominating and/or one perspective missing. Finding that bias and countering it by amplifying a missing voice is most of the job. I’d already been thinking there could be a cool version of Tarot for the professional world and this sealed the deal. Side note: I pulled the ‘Justice’ card at home the following morning.
product-tarot.com
I’m low-key working on a way to use the Tarot in a professional setting, particularly in product teams. It helps to reflect on how we’re working for our blindspots then making tweaks to improve. It cuts through the ennui of professional development, as though another session on OKRs is really going to make the world a better place. Most problems are personal, to us or those around us. Tarot’s an example of something that asks powerful questions and assumes we’re smart enough to figure out the answers. And it’s fun. I’ve seen friends and colleagues respond with humour and enthusiasm. I like that this is the opposite of a ‘tech-bro’ approach to product, it’s a people-first counterpoint.
Because I’m a product manager I’ve broken this down in to small, testable experiments:
been testing the idea with small number of people I trust, positive response
learning and practising Tarot reading at Treadwells to improve my storytelling and to test that people enjoy it
this post to test if the ideas make sense and to gauge interest
meetup with Maryem to brainstorm some ideas for 1 or 2 Product Tarot card designs to see if we can come up with something interesting that fits
. . . and if it’s heading in a good direction, I’ll start writing and testing some product-specific meanings and questions for some of the Tarot cards.
And I’ve obviously got a domain name: https://product-tarot.com - nothing there yet but will be soon.
Afterword
I was clear in the above that, for me, Tarot isn’t mystical and doesn’t predict the future. This is baggage that people often have when I first mention the idea. Now, zoom back up to the pieces above about Discovery. And think about what we do at work with planning and promising for the future. We believe in mystical properties of visions, business cases, project plans and because they’re cloaked in over-confident corporate symbols we often accept it. We believe in their mystical power to predict the future. But if you don’t believe that Tarot can predict the future, ask yourself why you accept the ability to predict the future at work? Because the truth is, we can’t :) The best we can do is regularly find and check our blindspot and improve what we’re doing a little at a time.
Do you fancy having a Product Tarot Reading in 2024? :)
What’s next?
I’ll share three things at a time. And keep each thing simple and brief. I’ll publish a newsletter when I’ve got something interesting to share and stay quiet when I don’t. Newsletter five might include guidance on investing in the right people, leading through context, and adventures in creative non-fiction.