A novel approach to utilizing Lean Canvas within Epics in an Agile methodology
Most of us in product / engineering organizations within software companies evolved into Agile development life-cycles over the past ten to fifteen years. Most of us started out pretty straightforward applying the basic Agile Manifesto probably combined with a Scrum foundation. Of course, many offshoots and variations emerged and even still younger compliments to Agile continue to emerge, such as Lean Canvas, Lean MVP and others.
I’ve been finding reasons to apply Lean Canvas and MVP approaches for the past five years and have had some interesting successes and failures. This blog post presents one recent success using Lean Canvas, but in what might be a unique and helpful variation for your organization.
At Envysion, Inc., we were exploring the Lean Canvas, er, canvases approach, as well as following advice from the Silicon Valley Product Group. This meant we were filling out canvases for specific product lines or new product feature groups. We found Lean Canvas and Lean MVP are designed for smaller software projects and are ideal for the first generation (MVP) of a product. For a more mature product company (Envysion is a 100-person company with over a hundred enterprise clients and tens-of-thousands of enterprise end-users), the approach can be somewhat lacking.
Then one of our thoughtful and innovative product managers had an interesting idea: Use the Lean Canvas structure essentially as the “body” of Epics (and/or Initiatives). Here’s how it worked…
Within our Agile methodology, we adhere to the approach that Themes beget one or more Initiatives which beget one or more Epics beget one or more Stories beget one or more Activities. There is always more work than we can possibly address within a quarter (our planning extends out six quarters at the moment). If we apply the Lean Canvas approach to feature groups, we’d be writing a lot of Lean Canvases. That’s not necessarily a bad thing, really, but combined with the fact we also have to write a lot of Initiatives and Epics, it adds up to a lot of time we don’t have.
When writing Initiatives and Epics, we were following the general approach that you might learn from an Agile coach or through your own experience of writing requirements and Stories and such over the years (As a… , I need… so that). We were consistently providing context and background, a description of what the problem is, how we might want to solve it and what benefit our customers might gain from the result. One of our product managers realized this approach encompassed most of the aspects of a Lean Canvas. In an effort keep our Initiatives/Epics short-and-sweet, we decided to migrate to the Lean Canvas approach, but still provide a consistent structure of information to the reader.
We now simply apply the Lean Canvas structure to every Initiative and Epic. There are a few slight variations of the Lean Canvas format out there (and no real standard, yet) but the one we adopted looks like this, which each of these bullets representing a section that is no more than one or two sentences or a short bullet list…
- Existing Alternatives
- Key Metrics (of successful Solution)
- Unique Value Proposition (of our Solution)
- Unfair Advantage (of our Solution)
- Channels to Market
- Customer Segments (including Early Adopters identified)
- Cost Structure / Considerations (which we measure in Points or “Organizational Dollars”)
- Revenue Model / Potential
The results have been pretty impressive, substantive and immediate:
- These turns out to be very fast to write, once you get the hang of it. It takes a little training, which you can find online in a few blogs easily one good resource from starlit.rs is here: LeanCanvas), your product managers will get it quickly.
- Engineering and marketing seem to love it as well, so much so we’ve seen other organizations start to use the basic canvas template for their own department’s work.
- It also seems to help the scoping of the child Stories within those Epics quite a lot, which Engineering also loves.
- The learning curve of new product managers and engineers is shortened, and the transition time is shortened if we move a product manager to a different product.