Earlier in the Summer someone shared their frustration with GDS’ ‘formal discovery, alpha, beta’ phases. See the original post here (Twitter). It got a lot of responses. There were two themes that stood out to me:

“Beware process ossifying into dogma”
‘Aren’t we doing discovery and delivery in parallel the whole time?’.

These were both things I’ve thought about for a few years because I lead Service Standard for my organisation as part of my role as Head of Product. Here I share some of my thinking along with how it’s influenced my approach.

“Beware process ossifying into dogma”

This is what Tom Loosemore said in the responses to the original post. It’s what I’ve held in mind since I became Head of Service Standard in 2018. For a process to be useful, we need to:

Understand the intent behind it
Understand our own goals in using it
Critically engage with it
Localise and contextualise
Be pragmatic.

I make space for this in my organisation. GDS’ ‘formal discovery, alpha, beta phases’ are the UK Government’s way of talking about the product lifecycle. I’ve found the product lifecycle to hold true for all products I’ve worked on, across all sectors. The product lifecycle has been a conceptual tool for improving product strategy for a long time. Here’s a republished article from 1965 talking about it. It’s been refined since, with people like Steve Blank going much deeper on the ‘customer development’ stage in his book ‘The Four Steps to Epiphany’. This was a core text when I tutored on the General Assembly product management course many years ago. Steve’s Blank’s thinking was an explicit influence on ‘The Lean Startup’. ‘The Lean Startup’ was published in 2011 around the same time that GDS was being spun-up. Joining the dots, it clearly influenced the shape of GDS’ thinking (directly or indirectly).

The standard product lifecycle is aimed at commercial products that measure success through sales. It requires contextualisation to work in the Civil Service where we measure success through how much we help people. ‘Amount of use’ is maybe a decent alternative for sales, where ‘use’ is defined as the number of successfully completed user journeys. In any case, it’s totally legit to tweak it. But ultimately: we’re just talking about the product lifecycle.

The product lifecycle is a core part of the product management role. We can’t do our role without it. Product strategy is fundamentally different from one stage of the product lifecycle to another. Our users and their expectations are different from one stage to another. While the boundaries are more blurred than diagrams would suggest, the stages are real. It’s so fundamental to our role that it’s one of the core skills listed in our role description on the Digital, Data, and Technology Capability Framework. You can blame me for that. I advocated for its inclusion back in 2016 when we were writing the role description. I’d noticed through interviewing, managing, and speaking with PMs that it was recognised to be important but was the most common skill that needed development. The other Heads of Product agreed and it was included.

Heading up Service Standard, I’ve held onto this. Most of our products are relatively small and so internally assessed. This means we can make additions to the standard guidance and assessments in order to (i) make their intent more clear so that (ii) we can localise and contextualise. We’re always true to the intent of the Service Standard. We never lower the bar. We never replace any existing guidance, it always remains our starting point. We add to it in order to make it work better for our context and to reflect what we’ve learned over the years. We work closely with GDS (now CDDO) and they’re totally supportive. We’re not doing our own thing. We’re just adding to the already amazing starting point that’s been provided. We were audited earlier in the year and received the highest level of assurance with no recommendations for change or improvement. It just feels like the healthy, positive thing to do.

So if you’re frustrated with GDS’ ‘formal discovery, alpha, beta’ phases I invite you to:

Revisit the intent behind it
Think about your own goals in using it
Critically engage with it
Localise and contextualise
Be pragmatic.

This could take the form of your Portfolio/Controls/Standards team pairing with your Product Management profession to lead a project to do the above with and on behalf of your organisation. And to partner and check-in with the Standards Team at GDS (now CDDO). I have never found them to be anything other than positive and supportive of our work. And the Service Standard and Manual remain the most effective mechanism for protecting a user-centred, product approach that I’ve experienced in any sector. They were a huge reason for me joining the Civil Service and have proved invaluable throughout my career here.

‘Aren’t we doing discovery and delivery in parallel the whole time?’

I think this is a red-herring. The same word can mean different things to different people. I think this has happpened with discovery.

There’s discovery, in a general sense. We discover things. We learn stuff that improves our products. This should happen throughout a product’s life. We should always learn and improve.
There’s Product Discovery, in a specific sense, within the context of the product lifecycle. A stage in which we invest a small amount of money in order to define a problem in order to gain greater confidence in figuring if and why we should build a product. We should invest the minimum amount needed to figure this out. And avoid sinking money into our imagined product until we’ve figured this out. The early stage of an opportunity is the riskiest. Not least because it’s where we know the least. But also because people talk about problems through solutions. The solution we’re all talking about right now is a metaphor for the problem. It’s easier to talk about an imagined solution than the problem we’re trying to solve because we haven’t had time to define the problem yet. Creating a list of things we don’t know about a problem is less motivating than a workshop thinking about a solution.

The product lifecycle is talking about Product Discovery in a specific sense. It’s requiring that we define our problem before committing to a solution. It’s saying that it’s not enough just to find a problem. We need a problem that’s valuable, urgent, and pervasive. If people are solving it themselves then we may already have an invisible solution. Or if someone else is working on solving it (possibly within our own organisation) then we may have a competitor. We need to know all these things before we invest further in an opportunity.

Let’s think even bigger.

We often think about the product lifecycle from the perspective of an individual product team working on an individual product. Let’s change perspective.

Let’s say we’re a large organisation. We’re looking at 50-60 digital products in varying stages of development. We know they’re all valuable. We’d love to pursue them all, and more. But we don’t have infinite people. We don’t have infinite time. We don’t have infinite money. We have to make hard decisions about where to invest tax payers’ money. From this perspective, the product lifecycle provides a series of investment decisions. Each time we’re asking: is this single opportunity worth pursuing in the context of all our other opportunities, given that constraints mean we can’t pursue them all at once? And if it is worth pursuing, can we help it connect with other opportunities where there are chances to learn and share from each other?

In UK Government, it’s a critical part of a Product Manager’s role to lead the team to these decisions. It’s the reality of the ‘product lifecycle’ essential skill. There will be Senior Product Managers and Lead Product Managers (depending on the size and maturity of an organisation) whose role it is to support with assessment of opportunities in the broader context that an individual product sits in. We should support, empower and require product teams to engage with these investment decisions at critical points of the product lifecycle. In an ideal world, assessments are just a place for teams to share these decisions and check their thinking with supportive peers.