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 my top 3 Discovery blindspots.

1. It’s not a Discovery

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
• 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 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. Context

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. Value

Discovery’s done. Everyone looks at each other, shrugs, and ploughs on with designing and building the thing. There’s no decision to kill or continue. At best we’ve learned a bit more. At worst it was a waste of time.

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.

Discovery is the most difficult and most important phase of product development. I love it And I’m looking forward to helping a lot more people over the coming years.

---

🖊️ Authored by: Scott Colfer, Director of Product, Herd Consulting

🎧 Favourite thing listened to this year: ‘Yellowface’, a novel, by Rebecca F. Kuang

---