Lean and Agile thinking are transforming the landscape for the development of new products and business concepts. Business plans are being replaced by hypotheses. Failure is expected, uncertainty embraced. Speed underpins everything as it allows hypotheses to be validated early and minimises risk (and waste).
Just as these new mindsets are replacing traditional ideas and approaches, so are new tools replacing established favourites of product management. Why? Because quite simply:
“traditional business documents — business cases, business plans, MRDs, PRDs — take too long to write, are seldom updated, and are almost never read by others. But documenting, sharing and getting feedback on your product vision is critical.” – Shardul Mehta
‘Canvases’ have become particularly popular as they are single-page by definition and provide a quick overview of the nature and proposed benefits of any suggested product development. They also neatly allude to the limits of what can be credibly known at the inception of any new idea and don’t waste time or space with fabricated facts that imply certainty.
The Canvas approach to problem/solution definition fits well with Lean and Agile thinking and has been adapted in various ways to cover all elements of product development. All of them are characterised by an emphasis on solving customer problems and delivering value, rather than achieving business goals and revenues.
The new toolset includes:
Product Vision Board
- Use in place of: Business case / Market Requirements Definition (MRD)
- Use in place of: Product Requirements Definition (PRD)
- Use in place of: Business plan for startup
- Use in place of: No real precedent, functions as a learning log for testing hypotheses
Goal-oriented or theme-based product roadmap
- Use in place of: traditional delivery focussed Roadmap
- Use in place of: traditional Roadmap
The Canvas was popularised by Alex Osterwalder and Yves Pigneur (with design by Alan Smith) who introduced theBusiness Model Canvas in their book Business Model Generation in 2010. It was designed to present a simple overview of how an organisation creates, delivers and captures value in 9 clear segments.
Since then, there have been at least 2 Product Canvases. The first, by Shardul Mehta, follows the basic structure of Osterwalder’s closely and starts with the customer problem and the benefits of the solution. The purpose of the Canvas is 2-fold: to ensure the proposed product development has been sufficiently thought through by the Product Team (eg. the basic objective can be easily articulated) and to succinctly communicate the benefits of the proposed development to stakeholders.
The second Product Canvas was developed by Roman Pichler, who trains organisations on Agile Product Management in Europe. He breaks Mehta’s Canvas out into 2 separate canvases.
The first (called the Product Vision Board) focuses on who the customer is (ie the target segment) and what problem the proposed product (or product development) hopes to solve before moving onto the expected value it aims to deliver.
The second (the Product Canvas) starts with the overall Product Goal and the Target Group and includes sections for detailed designs, user stories and epics and iteration (ie evolution) details.
Pichler suggests the Vision Board is more relevant to the upstream initiation of product development, whereas the Product Canvas should be applied to the definition of executional tactics further downstream. For brand new products, he advocates use of the Business Model Canvas in its original form.
Ash Maurya, entrepreneur and founder of The Lean Academy has developed the Lean Canvas, which orients the Business Model Canvas specifically to new business concepts and startups.
Maurya’s main objective with the Lean Canvas was to make it “as actionable as possible while staying entrepreneur-focused. The metaphor I had in mind was that of a grounds-up tactical plan or blueprint that guides the entrepreneur as they navigate their way from ideation to building a successful startup.”
Once assumptions about the customer, problem, solution and expected value have been captured on any one of the canvases, the next step is to identify the most obvious risks and then prioritise their validation via experimentation.
The learnings from these experiments are documented via a Validation Board. Mehta’s version resembles a Kanban board, with risks grouped initially in the Assumptions column on the far left and then progressively moved across the board one at a time as each one’s falsifiable hypothesis is put to the test.
The Lean Startup Machine, a training organisation that runs Lean Startup training courses around the world has developed a similar Validation Board for new business ideas. It emphasises the degree to which ALL elements of the business (customer segment, problem and solution) are hypotheses at the outset and insists that each assumption must be validated by the team ‘Getting out of the Building’ and getting feedback from their target customers.
Why (most) Roadmaps are useless
“The more detailed your plan, the more likely it is to be wrong.” – Liz Rice
Most Executives LOVE roadmaps and, partly for this reason, roadmaps are (still) the bane of most Product Manager’s lives. They exemplify the stark differences between a ‘project’ and a ‘product’ mentality. The project mind yearns for a Gantt-esque roadmap, broken down by month and extending usually across a 12-18month horizon with every single delivery date clearly marked and the features / benefits each will deliver. Whatsmore, the project mind still labours under the impression that such a document may actually represent some version of reality and is quick to misinform the Executive (and Sales) about what they can expect each month for the next 18… The net outcome is usually a furious Product and Engineering Team who feel they have been set up to fail in the eyes of the business.
The product mind, on the other hand, knows that uncertainty is more or less a given beyond a 3 month horizon at best and prefers to work with documents which acknowledge this reality in place of delivery-based Roadmaps (which do not).
Marty Cagan, the Godfather of product management, talks of ‘two inconvenient truths about product’: (first) our initial solutions to customers’ problems may simply not work and (second) our first attempt at delivering even the right solution probably won’t nail it; it will take several attempts to really get it right for customers. The product mind understands this and prefers documents that emphasise strategic priorities over committed dates.
It should be implicit in any Product Manager’s communication that little can be accurately known beyond next quarter and that dates can only be firmed up as the test and learn cycle of engineering iterations validates assumptions and removes uncertainty.
He emphasises that a Roadmap’s main purpose should be to communicate how each product is implementing the company strategy rather than simply listing out features that will be delivered.
Another option (probably too radical for most executives) is to replace the traditional linear roadmap with a Master Backlog, or strategic level representation of your product priorities for the next 12-18months. After all, Agile teams work to backlogs so the Product Manager is continually reconciling the ‘stacked’ backlog view of product priorities with the linear view of the roadmap when communicating outward. In more progressive environments, where uncertainty is accepted, the discussion centres around prioritisation rather than timing and, for this reason, a Master Backlog can provide the most accurate (and useful) representation of a product’s future.
The Master Backlog can still show indicative dates but is mainly a representation of the business priorities, which can be easily rearranged (or changed) as events unfold during the year.
Steve Blank wrote in May that ‘the Lean Startup is changing everything.’ He meant that the principles of Lean thinking extend well beyond startups and may, in fact, be most relevant to established corporations who need to adapt to theAge of Speed and Uncertainty which digital technologies have brought about. These new tools, by their concise and fluid nature, are better suited (and far less onerous) than the misleading financial projections and delivery plans of yesteryear.