The heart of the Lean Startup movement is the Build->Measure->Learn feedback loop.
The Lean Startup loop
Each loop defines the leap of faith assumption, the hypothesis and experiments to test the hypothesis. Perfect. Let us look at what I call as scattered learning versus progressive learning.
When the vision is clear and the leap of faith assumptions and hypothesis are tuned towards the vision, we have a progressive learning that takes you closer to the vision.
When the experiments are made without the vision in mind, then even if leap-of-faith assumptions and measurements are absolutely fine in isolation, you do not get closer to the vision. Even worse, if there is no vision and the loops are executed to derive the vision, the scatter looks all the more worse. Sometimes the vision is clear but the results of the experiments yield whatever has been learnt already – which may not be really useful or good use of money and time you have.
Conclusion: Each Build->Measure->Learn loop must align to the larger goal if your lean startup needs to succeed. A Product Manager’s cognizance is required to ensure this.
Loop image courtesy: http://www.ekito.fr/people/?p=2021
When a new game changing feature is introduced, a Product
Manager Owner – true to one’s role, does not draw lines limiting responsibilities, owns all the aspects of the feature from operations to user experience to go-to-market. The Owner comes up with the metrics that needs to be measured, works closely with all the departments like the master of an orchestra to ensure that the feature delights the customer and meets business objectives. This will usually take several iterations, pivots based on learning from experiments and sometimes operational changes for the product to gather critical mass and reach a cruising altitude. What happens next usually is that this Product Owner sub-consciously transitions into Product Manager – continuing to manage every nitty-gritty of the feature in a typical run-the-business sort of operation; nothing wrong – perfectly fine. This sub-conscious operation leads to most often playing the roles of Program Manager or an Engineering Manager or an Operations Manager. Organizations can often fail to take cognizance of such a situation and any such protracted scenario can lead to:
- Professional staffing ignored: Product Manager operating in roles which require specialized skill-set to maximize efficiency can reduce overall efficiency. For example a skilled project manager brings his expertise in efficient resource utilization and a product manager really may not be able to concentrate on that aspect they way it should be done.
- Reduced strategic thinking: The Product Manager is bogged down by issues that needs to be solved to run the business that he stops thinking strategically from a product’s road map perspective. A product stagnates. Crossing the chasm after a long period gets tougher and interventions become painful.
- A rock-star Product Manager does not remain one
What should be done ideally?
- A product manager (ideally the director of product management) should identify when the product’s/feature’s gestation period ends and requires product management not to hang-on to things which are not typically functions of product management. This requires structural changes in the organization and establishment of matrix structures to function effectively
- The product manager should define process and the corresponding operational metrics required for healthy functioning of the feature and help in setting up specialized teams for the purpose before abdicating some roles which he used to play
There is another school of thought that Product Managers have to be jack of all trades. Definitely, yes. It is needed during gestation period and perhaps during formative years of the product.