Product Management Handbook
A white label product management handbook for government digital services
View the Project on GitHub scottcolfer/product-management-handbook
Simplicity - the art of maximising the amount of work not done - is essential
The point of validated learning, rapid build-measure-learn feedback loops, and accountability is to help us spend the least time and money possible to meet the needs of our users through a compelling product or service. The aim of every increment of our product/service is to create the minimum, viable product/service.
Minimum viable product
The concept of ‘minimum viable product’ has been used and abused over the last few years, so let’s return to source and see what it originally meant. The Lean Startup helped to make the concept popular:
The Minimum Viable Product is that version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time.
We talked about an increment in our guidance for Associate Product Managers - it is the work done during a sprint which takes your product/service one step toward a vision. Our goal as product managers is to use validated learning and accountability within a rapid build-measure-learn feedback loop (e.g. a sprint) to prioritise the least work needed in order to meet our sprint goal. Our continual challenge is for each increment to produce the minimum, viable product/service needed to meet our sprint goal. What is acceptable for minimum and viable will change during the lifetime of the product/service as it grows in maturity and number of users.
Continuous Delivery and DevOps
‘Continuous delivery’ describes a software development culture that get changes (experiments, features, bug fixes) into production or in the hands of users safely and quickly in a sustainable way. This requires closer working between development and web operations, which has since been labelled ‘devops’. Continuous integration is a critical aspect of continuous delivery, which means working in small batches and using automated tests to detect and reject changes that introduce regression.
‘The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win‘ introduces ‘The Three Ways’, a description of the values and philosophies that guide DevOps processes and practices.
‘The First Way is about the left-to-right flow of work from Development to IT Operations to the customer. In order to maximise flow, we need small batch sizes and intervals of work, never passing defects to downstream work centres, and to constantly optimise for the global goals (as opposed to local goals such as Dev feature completion rates, Test find/fix ratios, or Ops availability measures). The necessary practices include continuous build, integration, and deployment, creating environments on demand, limiting work in process, and building safe systems and organisations that are safe to change.’
‘The Second Way is about the constant flow of fast feedback from right-to-left at all stages of the value stream, amplifying it to ensure that we can prevent problems from happening again or enable faster detection and recovery. By doing this, we create quality at source, creating or embedding knowledge where we need it. The necessary practices include ‘stopping the production line’ when our builds and tests fail in deployment pipeline; constantly elevating the improvement of daily work; creating fast automated test suites to ensure that code is always in a potentially deployable state; creating shared goals and shared pain between Development and IT Operations; and creating pervasive production telemetry so that everyone can see whether code and environments are operating as designed and that customer goals are being met.’
‘The Third Way is about creating a culture that fosters two things: continual experimentation (which requires taking risks and learning from success and failure), and understanding that repetition and practice is the prerequisite to mastery. Experimentation and risk taking are what enable us to relentlessly improve our system of work, which often requires us to do things very differently than how we’ve done it for decades. And when things go wrong, our constant repetition and daily practice is what allows us to have the skills and habits that enable us to retreat back to a place of safety and resume normal operations. The necessary practices include creating a culture of innovation and risk taking (as opposed to fear or mindless order taking) and high trust (as opposed to low trust, command-and-control), allocating at least twenty percent of Development and IT Operations cycles towards non-functional requirements, and constant reinforcement that improvements are encouraged and celebrated.’
Reading: