Lean Offerings
The Lean Offerings template helps you to define your first offering depending on your Hypotheses and Business DNA. Familiarise yourself with the core elements, go through further instructions and download the tool for your team.
Content
1. Overview
The Lean Offerings template gives you guidance on deciding which of the minimum set of ("must have") features should be part of your first offerings, allowing you to charge customers and test hypotheses that require 100% reality. Moreover, you should think about non-functional requirements (e.g. ease of use, scalability, performance) and seek to benchmark your offerings against the competition. We usually distinguish between...
Basic requirements (FR / nFR) and
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 do not always mean more value for your target groups. If you want users to switch from competitive offerings to your products, features are an important part of people’s decision to give it a try. In any other case, simplicity is usually much more important for greenfield users than having a lot of features. Even lean offerings should include "factors of excitement" according to the DNA of the underlying business model.
The lean offerings are always the starting point to derive 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 in Business Design a lean offering is defined differently from an MVP (= minimum viable product) as described in the book "The Lean Startup" from Eric Ries. For us, a lean offering is the first product or service version on the market. Thus, we charge customers to allow as much reality as possible to validate remaining hypotheses.
In Business Design, we also distinguish between prototypes and lean offerings. A prototype is built before market launch either as an interaction or thinking tool (see prototyping). Where as a lean offering is built for / after market launch.
2. Layout & Download
3. Key Elements
Element | Question | Comments |
DNA | The DNA is directly transferred from the Business Model template. The reason the DNA is shown in the Lean Offerings is to cross-check that the developed lean offerings do correlate with the DNA of the business model. | |
Focus of lean offerings | What is the minimal set of user stories customers and users expect to be implemented in order to deliver the core value of our offerings? | As few as possible user stories should make it up here. These user stories will have to be implemented, so keep complexity low. |
Functional requirements | What do different stakeholders want to do with our offerings? | Define user stories following this structure: "As a..., I want to...in order to...". We always distinguish between "technically required" requirements we need to implement in order to get the lean offerings to work and "additional" requirements that will be evaluated based on the dimensions "Ease of implementation" and "DNA fit". Consider using the "User Story Cards" (see below) if you need more space to describe the user stories. |
Hypotheses | Which hypotheses can only be tested by building and launching lean offerings? | Following the process these hypotheses amongst others should have been defined 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 are things that are asked for additionally to the basic functional requirements. An app with a basic function might do its job, but an ergonomic UI (non-functional requirement) would enhance the usability. |
Stakeholders | Who will be using our lean offerings? | Think about everyone having functional and non-functional requirements for the lean offerings (e.g. users, customers, backoffice, sales agents). |
4. Usage Scenarios
Preparing the validation of hypotheses which can only be validated with customers actually using a lean version of the service/product
First step in defining a lean offering / MVP
Differentiation between functional and non-functional requirements of an offering
5. Instructions for Coaches
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 should be in the upper right corner, the focus. Always ask: what is the very basic and minimal set of requirements to do the job? Often the ease of implementation decides whether a certain user story shall be in the focus or not.
Cross-check if the user stories in the test focus still correlate with the DNA of the business model.
6. Q & A
What if all user stories are placed in the focus in the upper right corner? This might make the realization of the offerings too complex. Try to reduce the focus to the very basic user stories. Here, it is not about delivering a perfect product, it is about learning whether the customer accepts the 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 of our hypotheses we then have to search for other user stories which 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 below) and span a vector space with the dimensions "DNA fit" and "Ease of implementation" on a large wall.
7. User Story Cards
User Story Cards help plan and prioritize functional requirements. They are the "natural" extension" of the Lean Offerings template allowing to describe every user story in a simple structure.
