You are viewing an old version of this page. View the current version.
Building Lean Offerings in the Business Design process is an essential part when validating new business models. The process of implementing Lean Offerings in Business Design is fundamentally different from other software implementation processes.
The goal of lean offerings is to validate remaining hypotheses in our Business Model with a minimal set of features in a very short time frame (maximum of 3-4 weeks). This approach has some major implications on the structure of the development process (phases), people (roles), technologies, key activities and trade-offs we need to make. The outcome of this process are (in-)validated hypotheses and valuable insights, which reduce uncertainties before implementing a scalable and market-ready solution.
To start implementing lean offerings, it's important that the following preconditions are met:
- Business Model developed and reviewed with project's sponsor
- Hypotheses & Experiments are clear and target the biggest uncertainties
- Lean Offerings are defined with functional and non-functional requirements
Yes, we build lean offerings for your experiments.
Contact us: email@example.com.
Instructions for Coaches
- Make sure the whole team doesn't lose focus: Building lean offerings is about testing hypotheses
- Make sure the team involves stakeholders at an early stage (sponsor, legal, marketing, external agencies...)
- Make sure your lean offerings reflect the DNA of your business model
- Make sure the team stays within the given time frame (maximum of 3-4 weeks): Reduce the scope if necessary, but never extend the time frame
Q & A
- What is the difference between a prototyping expert and a software engineer? Prototyping experts always think in business models, hypotheses & experiments, DNA-fit etc. They have the skills to build Lean Offerings for the purpose of learning (and earning). This includes design, frontend, backend, infrastructure and a distinct business sense.
- Why don't you have roles like designers, frontend-/ backend developers, dev-ops etc.? This is because we only have 3-4 weeks to implement Lean Offerings. More people means more communication, more coordination and more meetings (therefore more time). We also don't need this highly specialized know-how because we build Lean Offerings and not highly scalable, market-ready products.
- What do you mean with DNA-fit of a Lean Offerings? The core of a Business Model is the DNA. It's critical that the DNA is embodied in the Lean Offerings.
- What is the difference between an MVP and a Lean Offerings? A MVP (= minimum viable product) is not clearly defined yet. It is almost anything from a video, landing page to a prototype. A Lean Offerings are more than that: Lean Offerings are the first version of product, service or software, which allows to charge customers under real conditions to test remaining hypotheses that can't be tested with simple means.
- What's the difference between Lean Offerings and a product? The focus is totally different: Lean Offerings are about validation and learning and therefore we take different trade-offs in our decisions regarding robustness, security, scalability, tests etc.
- We work closely with agencies when developing software. Can the agency build our Lean Offerings? In our experience, outsourcing the development of Lean Offerings is difficult because software agencies often don't have the same mindset and speak the same language (thinking in Business Models, DNA-fit, Hypotheses, & Experiments, Validation etc.). They often have a lot of talented software engineers, but not prototyping experts (see Question 1 what that means).
Usually we need the following phases to build a Lean Offering:
The purpose of the setup phase is to define everything which is necessary to start implementing literally the next day. This includes refining the Lean Offering and the corresponding hypotheses & experiments with KPIs, defining roles & responsibilities and building out rough visual drafts (scribbles)
The purpose of the Implement phase is to turn prioritised user stories into tangible out (e.g. source code) ion short 1-week sprints. Each sprint starts and ends with a "release call", where progress is reviewed and new use stores will be selected
In this phase, we are running our experiments and closely look at their KPIs on a dashboard. We refine what we measure und review the KPIs we need to (in-)validate our Hypotheses
Usually we need the following roles to build a Lean Offering:
|Lean Offering Master||The Lean Offering Master is the person who sits between the prototyping experts and the project team. He consolidates feedback from the project team, prioritizes user stories and coordinates all stakeholders|
|Prototyping Expert||Prototyping Experts are responsible for the implementation of the lean offering (design, frontend-/ backend development, DevOps etc.) as well as running and analyzing the experiments|
|Business Design Coach|
The Business Design Coach makes sure that the team works methodically correct and looks for everything regarding The Tip of the Iceberg
Building Lean Offerings vs. Building Software Products
We often get asked what the differences are in building Lean Offerings in a Business Design process and building software products outside of a Business Design Process. There are some key differences:
|Building Lean Offerings||Building software products|
Small Team with Lean Offerings Master, Prototyping Expert and Coach
Large team with designer (UI), architect, frontend engineer, backend engineer, Scrum Master, DevOps engineer, tester
Tools & Materials
- No labels