Lean Offering Workshop
Some hypotheses can only be tested when you allow 100 % reality. This means you have to start building your lean offering in order to test your hypotheses. A Lean Offering Workshop helps your team to align on the minimal set of features and to plan the implementation process step by step.
Before building your Lean Offering(s), the team and you may need another deep-dive to align your mental models, define specific features and plan your next steps towards implementation. This workshop is optional and highly depends on the progress during the Design and Validate Workshop, as well as on your research agenda. You may bring your pre-filled Lean Offering(s) template with user stories helping to understand the basic idea of what "value" and "waste" is, but you know there is more detailed work necessary to start implementation.
In the first part of this workshop, the team gives a recap on the uncertainties and assumptions about the success of their business model (see Business Model, Hypotheses & Experiments). They focus on hypotheses which can only be tested by building and launching their lean offering(s). The main part of this workshop is then used to define the minimum set of features of their lean offering(s). Within this session the team collects user stories. A user story is an informal description of a feature:
As a <user>, I want to ..., [because ...].
After the definition and subsequent selection of the feature set for the lean offering(s), the team can start to clarify certain features by building prototypes (like scribbling screens, storyboards / service processes, or product designs per se with the help of a designer or prototyping expert). After prototyping, it is time to discuss the “minimum viable business”. Which elements of the underlying business model are absolutely essential to create and deliver the lean offering(s) to the market? The team defines this lean version of their business model and then plans the implementation process including all roles and responsibilities.
1 full day + preparation and documentation
Agenda defined, participants invited
Room booked or organised
External experts invited (e.g. Designer)
All tools & materials prepared and printed
We usually don't send the agenda to the participants prior to the workshop. We only tell them when we start and end and what preparation is required from their side.
5. Signs of Success
We consider the Lean Offerings Workshop as a success...
...if we have specified a feature set of our lean offering(s) which can be called minimal on the one hand, but represents the DNA of the Business Model and on the other hand helps to answer all open hypotheses and questions.
...if we have aligned our mental models by the help of prototypes and clarified what can be seen on every relevant screen, what happens in our service process or how our first product should look like.
...if the team is proud of the level of concreteness of the output.
...if the project team cannot wait to show their lean offering(s) to the sponsor.
6. Tools & Materials
1x Flip chart with paper
1x Time Timer
Optional: 2-3 Prototyping notepads (tablet / mobile) depending on project and team size
Optional: Service Blueprint
Optional: Further prototyping materials (see Tools for Prototyping & Building)
Optional: 1x Anti-Bullshit Spray
All templates (e.g. Business Model, Hypotheses & Experiments, Lean Offerings, Development Board, Action Plan etc.) are digitised in the Project Workspace; photos of the templates are uploaded to the Project Workspace
Tasks are documented in the Action Plan
Optional: The Development Taskboard or any other sprint board can be used to plan the lean offering(s) feature set in sprints and increments
8. Q & A
What if we have a feature set that is too big for our lean offering(s)? The two axes (ease of implementation and DNA fit) of the Lean Offerings help you to prioritise your user stories. Be honest to yourself!
What is technically the difference between building lean offerings compared to building a final product? The focus and therefore the trade-offs are different. For the final product you are building to scale (low uncertainty), for your lean offering you are building to learn (high uncertainty).
What about features which users don't see but which are necessary for my system to work (e.g. admin area to manage users)? Don't develop any features which you can do manually too. For example: You don't need to have an user management backend system when you can easily enter the users manually into the database. Most of the time, a good database management tool is enough and no backend system is needed.
9. Example Agenda
08:30 - 09:00
Arrival and "Good Morning Coffee"
09:00 - 09:30
Pitch of the Business Model & status quo of the project
09:30 - 10:00
Quick recap and refinement of hypotheses to be tested by launching lean offerings
D / T
10:00 - 12:00
Refinement of Lean Offerings template
12:00 - 13:00
13:00 - 15:00
Scribbles and prototyping of the minimal set of user stories
15:00 - 16:00
Discussion of the minimum viable business / lean version of the Business Model to create and deliver the lean offering to the market
16:00 - 16:30
16:30 - 17:00
* P = Presentation | D = Discussion | B = Break | T = Teamwork