Which product risk comes first?
I’m a firm believer that one of the primary roles of a cross-functional team, and in particular a product manager, is to reduce risk.
There’s no better way of framing product risk than the way SVPG do (see 'The Four Big Risks' for more info), which we leaned into when illustrating the typical responsibilities of our product management, design, and engineering practitioners here at Hyperact.
Someone recently asked me a question which really got me thinking: is one risk more important than the others?
This was a relatively easy question to answer in my opinion: yes. Value is most important. Without value, the others are irrelevant.
But the importance of the other three? That was much less obvious. I pondered on this for a while, and it all got a bit chicken and egg, or whatever the equivalent is for when you’ve got a three-way causality paradox.
And then I started to question my first answer 🫠
I came back to this after a while and decided to write down the typical sequencing of derisking that I’ve seen in cross-functional teams, and it goes something like this:
- Value - Is there an underlying problem to be solved? A need to be met?
- Business viability - Will meeting this need move us towards the overall goals of our organisation?
- Usability - Can we meet this need in a way that works for users?
- Feasibility - Can we create the proposed solution with the people and technology available to us?
- Business viability - (again). Will our organisation be able to support the proposed solution?
- Business viability - (once again). Will we be able to deliver the solution within the constraints of our organisational landscape i.e. time and cost?
- Business viability - (one last hurrah). Are there any reasons why we cannot or should not go forward with the proposed solution e.g. ethical, legal, regulatory, reputational?
And then once we’ve got something through this pipeline, we’d likely get signals on all of these risks through usage data, research, system observability, and stakeholder feedback, and then iterate as necessary.
So… I thought I’d try and draw this up. Here goes:
But I was kidding myself a little here - the reality is that it’s rarely this sequential. And you probably make many micro-decisions around the four risks throughout the discovery and delivery of a capability or product. And you probably do a lot in parallel. So maybe it could be like this instead:
What’s interesting (to me, anyway) is that there have been times when I’ve done this much more sequentially and at the end have kicked myself for not doing it in parallel, and there have been times when I’ve done loads of this in parallel, only then to have to redo it all as we throw one solution out of the window and pivot to the other.
I’m not sure there is a right way here. Either way, I found drawing this up a useful exercise that made me be much more intentional about risk as I workshopped through a problem and potential solutions the following day.
Next, I wondered if anyone else had mulled this over and written or drawn about it.
Reforge kinda have. They have split it out into four distinct phases:
- Opportunity validation
- Design
- Development
- Launch and iteration
But you’d be hard pressed to say which risks are tackled at which point.
Most of the literature I’ve found is about describing the risks, usually mocking blockbuster examples of when that risk has come back to bite the team in the arse in one way or another.
Ant Murphy has gone a bit deeper with a few articles. He calls out the techniques that can be used to tackle each of the risks, which gives some clue:
And he also riffs on the messy middle in The Messy Nature of Product Development.
Jeff Patton alludes to it with his Continuous Product Improvement Cycle, which breaks it down to:
- Sense
- Focus
- Discover
- Deliver
And he writes “This is not a linear flow. An organization and a product team will be working in all areas at the same time,” which I think is telling.
Which is all to say that I can’t find any articles that specifically describe the ins and outs of how teams derisk from initial identification of a potential user problem or need, all the way through to value realisation. Nor an illustration.
How do you tackle risk in your cross-functional teams?
Have you seen this picked apart in any articles, talks, or models?
Let me know @ Dave Baines.
