how a user is likely to employ the product. Focus on the important interactions, concentrate on your primary persona, and don’t be shy to update or replace the diagrams as your understanding changes and you explore new aspects of your product.
Epics are coarse-grained, big user stories that sketch the product’s functionality. Every epic must serve a persona or be required by the business model, for instance, displaying online ads. You can connect the epics to the personas by using the persona names in narrative: As <persona name>, I want to <use functionality> so that <need or problem of the persona is addressed>. It’s usually not necessary to order the epics.
Don’t make the mistake of listing all of the product functions you can possibly think of. Rather focus on the epics that are essential to address the user needs. Exposing product increments to users and customers will test your assumptions and ideas and you are likely to discover new epics. The development team should size the epics if you want to track the project progress via a burndown chart.
Design sketches communicate your design ideas. The sketches should capture the critical aspects of the product or user interface design; for instance, the design of a few important screens. I prefer to work with paper sketches, as they are usually good enough to communicate the important design aspects. They are also quick and easy to create and update.
Resist the temptation to create the entire design upfront. The design should evolve based on the feedback you receive from users, customers, and other stakeholders. This helps you design a product with a great user experience.
Constraints describe operational qualities that apply to the entire product. These include performance, interoperability, robustness, and regulatory requirements. The constraints influence the user experience, drive architecture and the technology decisions, and impact the total cost of ownership together with the product’s life expectancy. Unlike the epics and the design sketches, you should clearly describe the constraints upfront. For example, for a performance constraint, state the type of data being transferred, the number of concurrent transactions taking place, and the system configuration used.This facilitates the right architecture decisions, and it ensures testability.
Ready stories are small, detailed stories that feed the next cycle. They are derived from the epics and satisfy the sprint goal when Scrum is used. The ready stories have to be clear, feasible, and testable so that the development team can transform them into a product increment or minimal viable product (MVP).
Order the ready stories from one to n—for instance, first, second, third, and so on—to maximise the chances that you acquire the desired knowledge and to guide the development work. The team should estimate the ready stories if velocity-based iteration planning is employed or if a burndown chart is used to track the project progress.
The Business Model
The product canvas describes the target group and the product features, but not the business model including revenue sources and cost structure. While I have intentionally kept the canvas focused, I have designed it to be compatible with the Alexander Osterwalder’s and Yves Pigneur’s business model canvas. I recommend you use the two canvases together, as Figure 5 illustrates.
Figure 5. Product Canvas and Business Model Canvas
There is a small overlap between the two canvases as both consider the market and the value proposition. But I don’t find this an issue: I use the business model canvas to capture the market and value proposition at a high-level, and I state the details for one specific product on the product canvas.
If you don’t