Lean Offerings
The Lean Offerings template helps you define your first offering based on your hypotheses and Business DNA. Get familiar with the key elements, follow the instructions, and download the tool for your team.
Content
1. Overview
The Lean Offerings template helps you decide which minimum, "must have" features should be part of your first offerings – allowing you to charge customers and test hypotheses that need 100% reality. You should also think about non-functional requirements (e.g. ease of use, scalability, performance) and benchmark your offerings against the competition. We usually distinguish between:
Basic requirements (FR / nFR)
Excitement / performance requirements (FR+ / nFR+)
Describe functional requirements as “user stories” (without pre-defining a solution): <role> <action> [<outcome>]
As an administrator, I want to add new users to the database, so I can save time and serve users much quicker.
Think twice about what features should make it into your initial market offerings. More features don't always mean more value for your target groups. Features matter when you want users to switch from competitive offerings to yours – they're part of a user's decision to give it a try. Otherwise, simplicity usually matters more than a long feature list for greenfield users. Even Lean Offerings should include "factors of excitement" that match the DNA of the underlying Business Model.
Lean Offerings are always the starting point for a “minimum viable business”. Which elements of your underlying Business Model are absolutely essential to create and deliver your offerings to the market?
Be aware that Business Design defines a Lean Offering differently from an MVP (= minimum viable product), as described in Eric Ries's book "The Lean Startup". For us, a Lean Offering is the first product or service version on the market with a minimal set of features (user stories) that fulfils the following requirements:
Are your (remaining) hypotheses covered?
Can you charge your customers?
Is your DNA of your Business Model embedded?
Does your mother like it?
If all of these four questions can be answered with YES, your Lean Offerings are ready to be launched. And that's why we charge customers – it gives you as much reality as possible to validate the remaining hypotheses.
In Business Design, we also distinguish between prototypes and Lean Offerings. A prototype is built before market launch, either as an interaction tool or a thinking tool (see Prototyping) – a Lean Offering, on the other hand, is built for launch or after it.
2. Layout & Download
3. Key Elements
Element | Question | Comments |
DNA | See Business Model | The DNA carries over directly from the Business Model template. It's shown here so you can cross-check that your Lean Offerings correlate with the DNA of the Business Model. |
Focus of Lean Offerings | What is the minimal set of user stories customers and users expect, so we can deliver the core value of our offerings? | Include as few user stories as possible here. They will all have to be implemented, so keep complexity low. |
Functional requirements | What do different stakeholders want to do with our offerings? | Define user stories using this structure: "As a..., I want to..., in order to...". We always distinguish between "technically required" requirements – the ones you need to get the Lean Offerings to work – and "additional" requirements, which we evaluate on the dimensions "Ease of Implementation" and "DNA fit". Use "User Story Cards" (see below) if you need more space to describe your user stories. |
Hypotheses | Which hypotheses can only be tested by building and launching Lean Offerings? | You should have already defined these hypotheses, among others, in the Hypotheses & Experiments template: "We believe that...". |
Non-functional requirements | What non-functional requirements should be embedded in our product and/or service? | Non-functional requirements come on top of the basic functional requirements. An app with a basic function might do its job, but an ergonomic UI (a non-functional requirement) makes it more usable. |
Stakeholders | Who will be using our Lean Offerings? | Think about everyone who has functional and non-functional requirements for the Lean Offerings (e.g. users, customers, back office, sales agents). |
4. Prototypes vs. Lean Offerings
We already touched on the differences between prototypes and Lean Offerings. Let's dive a bit deeper and break them down into some key parameters. These parameters matter a lot, because each one has major implications for what you build – and how you build it.
Prototype | Lean Offering(s) | |
|---|---|---|
Test Focus | First customer feedback | Payment Models Engagement Value Proposition Features |
Feedback | More Qualitative | More Quantitative |
Scope | Lower | Higher |
Level of reality | Lower | Higher |
Functionality | Lower | Higher |
Adaptability | Higher | Lower |
Lifecycle | Shorter | Longer |
Customer Investment | Lower | Higher |
5. User Story Cards
User Story Cards help you plan and prioritise functional requirements. They are the "natural" extension of the Lean Offerings template, letting you describe every user story in a simple structure.
6. Usage Scenarios
Preparing to validate hypotheses that can only be tested by having customers actually use a lean version of the service/product
First step in defining a Lean Offering
Differentiating between functional and non-functional requirements of an offering
7. Instructions for Coaches
Think carefully about whether it's a real option to jump straight into implementing a Lean Offering without any pre-launch tests. Getting to 100% reality quickly is almost always better than spending time on pre-launch experiments. The decision still depends on the complexity of the Business Model and the investment(s) needed to realise it.
Initiate a Lean Offerings Workshop if some experiments need real conditions, and you realise more work and detail are needed before implementation can start.
When your team defines its Lean Offering, make sure it includes a minimum set of user stories they can charge customers for. Also cross-check that their Business DNA is embedded. The team should really be able to test their open hypotheses by launching their Lean Offering. Make sure it fits their overall research design, and that they continue their research after launch.
Don’t forget to define a lean version of the Business Model that creates and delivers the Lean Offering. Teams tend to think too big and lose sight of steps that can easily be done manually.
Gather all functional user stories without sorting them yet, e.g. "As a user, I want to select music by titles". Then sort them by "Ease of Implementation" and "DNA fit".
Only a minimal set of the identified user stories belongs in the upper right corner – the focus. Always ask: what is the very basic, minimal set of requirements to do the job? The Ease of Implementation often decides whether a user story makes it into the focus.
Cross-check that the user stories in your test focus still correlate with the DNA of the Business Model.
8. Q & A
What if all user stories are placed in the focus in the upper right corner? This might make realising the offerings too complex. Try to reduce the focus to the most basic user stories. Here, it's not about delivering a perfect product – it's about learning whether the customer accepts the very core of the Business Model.
What if I am unsure whether a requirement is functional or non-functional? Ask whether it serves the primary purpose or whether it makes the primary function work better.
What if the selected user stories in the focus do not seem to represent what our Business Model stands for? Based on our hypotheses, search for other user stories that match the core of our Business Model better.
What if some user stories do not fit on a single post-it and the Lean Offerings template is way too small? Use the "User Story Cards" (see above) and span a vector space with the dimensions "DNA fit" and "Ease of Implementation" on a large wall.