Product management = continuous learning
Despite many linear product processes, the fact is product management is not a linear process. Product management is a twisted, turning, sometimes reversing process to discover the product market fit and deliver true value to the customer and business. It is this nature that makes the role so fascinatingly exciting and for other people terrifying.
Many product managers, especially in larger companies will embrace a popularised product process for example double diamond, dual track, discover deliver, etc. Many of the product processes suffer the same fault, they are implemented in a linear fashion.
Linear obsession is everywhere in business from annual budget plans (based on historic performance — not very innovative focused), ‘fictional’ gant charts (to give management a warm and fuzzy feeling), to linear product processes (disguising big design up front). The false comfort from linear product design and development is predictability, it feels safe being left to right — Here’s the kicker, the creative process including product development is outcome first, it is right to left..
This does not mean these well-versed paradigms don’t have value, the misdirection is when they are taken literally. When consulting and coaching product managers I hear phrases like “We can’t change that feature spec, we have finished discovery” — scary, this means the product manager is making the conscious decision “let’s build the wrong thing”.
There are three key mistakes far too many organisations make that waste money building “okay” or poor-performing products.
Obsess and value outputs instead of learnings and outcomes
Accept a cadence of product development activities that is too slow
Commit too far ahead without evidence or even known assumptions
So how do we improve the situation and improve the outcome of the product function?
We believe the product process is cyclical or iterative, this has been shared by those embracing lean.
The build measure learn cycle popularised by Eric Reis is iterative. Unfortunately, we are really good at enforcing literal meaning on everything.
The build is not meant to refer to only code, it gets misinterpreted. Build refers to executing an experiment which may involve a code release or it may not. It depends on the experiment design. Every release, user test, prototype, etc. should be considered an experiment.
Learning is pointless if it does not inform a decision. In an attempt to learn lots of measures can be overcooked, we need to measure the key information required to inform the decision.
To improve the situation we need to double down on lean, using the mantra Experiment, Evidence, Decide.
A challenge in adopting lean is forgetting the cycle needs to be fast and iterative. Lean cycles cannot be executed on traditional enterprise timescales. We cannot iterate based on months or quarters. Experiments can take hours to execute, and more complex experiments may take an engineering iteration/sprint. If it’s taking longer it’s not lean, it’s not agile and it’s high risk of missing product market fit. Remember product market fit is the goal, not a random deadline.
We should frame product development as continuous experimentation to validate a product to deliver user value as we create it.
