Skip to content

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

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, 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 wastes money building “ok” or poor performing products.

  1. Obsess and value outputs instead of learnings and outcomes

  2. Accept a cadence of product development activities that is too slow

  3. 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 cythlical or iterative, 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 of measure 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, 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 product market fit. Remember product market fit is the goal, not an random deadline.

We should frame product development as continuous experimentation to validate a product to deliver user value as we create it.