The fine practice of product management is a tough gig. The role requires strong leadership and collaboration and ability to change direction regularly to find valid market fit.
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 manages, specially 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, even if they have been drawn in a figure of eight loop.
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 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, creative process including product development is not left to right.
This does not mean these well versed paradigms don’t have value, the misdirection is when they are taken literally. When I was consulting and coaching product managers I heard phrases like “we can’t change that feature spec, we have finished discovery” — scary, this means “let’s build the wrong thing”,
There are three key mistakes far too many organisations make that wastes money building “ok” or poor performing products.
- Focus on output instead of learnings or outcomes
- Accept cadence that’s too slow
- Commit too far ahead without evidence
So how do we improve the situation and improve the outcome of the product practice?
Personally I believe the product process is cythlical iterations, this 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.
Build is not meant to refer to only code, it gets mis-interpreted. Build refers to execute 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 is not informing a decision. In an attempt to learn lots measure can be overcooked, we need to measure what ever is required to make the decision.
To improve the situation we need to double down on lean, using the mantra Experiment, Measure, Decide.
A challenge in adopting lean is forgetting the cycle needs to be fast and iterative. Lean cycles cannot be executed on enterprise time, we cannot iterate based on months or quarters. Experiments can take hours to execute, more complex involved 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 market fit. Remember market fit is the goal not a deadline.
We should frame product development as continuous experimentation to validate a product to deliver user value as we create it.