A team can ship a feature and still miss the business goal. A deliverable is a capability or other action the team proposes to support a desired change in behavior. Instead of starting with a fixed feature list, start with the business problem, a measurable goal, the people who can affect it, and the behavior you want to encourage. Then ask: what can we do to make that behavior easier or more likely? section 4.3 section 4.3.5
Keep the proposed deliverable connected to its purpose:
- Name the impact first: what should a customer or other actor do differently? section 4.3
- Propose a capability that supports that change. It might be a software feature, an epic, a larger initiative, or a nonsoftware activity. section 4.3.5
- Make the assumption visible and choose a metric to check whether the deliverable has the intended effect after launch. section 4.3.5
More bookings, not just more features
Suppose an airline wants frequent flyers to buy more tickets. Easier mileage redemption or the ability to use points for an upgrade at check-in are possible deliverables because they support that behavior. If the goal is more loyalty-program sign-ups, offering double points to first-time flyers who join within 24 hours is a possible nonsoftware deliverable. Each proposal is a hypothesis about behavior, not proof that the business goal will follow. section 4.3.5 section 4.3
For a broad planning view, group selected high-value deliverables as epics in an Epic Landscape. A Pirate Canvas starts with pain points and metrics, turns them into measurable goals, and links those goals through actors and impacts to potential deliverables. Keep the most valuable candidates rather than filling the landscape with every idea. section 4.4.4
Figure 4.18 A completed Pirate Canvas shows an Epic Landscape, high-level deliverables in the context of the bottlenecks they aim to eliminate.
The completed Pirate Canvas places high-level deliverables alongside the bottlenecks they are intended to eliminate. section 4.4.4
