Building Lean Offerings

Not every hypothesis can be validated before we hit the market. In some cases, you need to build a "Lean Offering" and start selling it to reduce your uncertainties. Learn more about how and why we build Lean Offerings during the Validate Phase.
Avatar of Sabine Schoen

Sabine Schoen

Business Design Field Researcher

1. Purpose

Some of the experiments you are planning to execute during the Validate Phase may require either a prototype or a Lean Offering. For us, Lean Offerings are the first version of your product or service being offered on the market that still serves the purpose of learning (rather than earning). Thus, we actually charge customers to allow as much reality as possible. A prototype on the other hand, is built specifically before market launch (see Prototyping).

Be aware that our definition of Lean Offerings differs from the definition of an MVP (= minimum viable product) as described in the book "The Lean Startup" from Eric Ries. For us, Lean Offerings is your first version of products, services or software 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.

We need Lean Offerings during the Validate Phase since not every hypothesis can be validated with simple prototypes or customer interviews. We need to embrace reality. In some cases you simply have to sell your first version of your product or service under real conditions to reduce specific uncertainties (please find some examples below). Obviously, it highly depends on your offerings what it takes to actually build it. Sometimes, a bit of money and some "manual" work by your team to get your lean offerings running is sufficient. Sometimes, the building process spans over 2-3 iterations of a Business Design sprint. In that case, you should start thinking about building your Lean Offerings as soon as possible to strive for 100% reality.

Next to your Lean Offerings, you should also think about a lean version of your Business Model ("minimum viable business") to create and deliver your Lean Offerings.

2. Duration

5 weeks (as part of the Validate Phase)

3. Key Activities

The following activities represent the core steps to build your Lean Offering:

  • Design your Lean Offerings & lean version of your Business Model: You probably discussed your Lean Offerings already during the Design Workshop or Validate Workshop. If you know there are more details necessary to start its implementation, get together in a Lean Offerings Workshop, define user stories, plan responsibilities and tasks.

  • Build your Lean Offerings and corresponding Business Model: Start the implementation and prepare your learning environment of corresponding experiment(s) (see Validating Hypotheses) to get ready for market launch.

  • Launch & test your Lean Offerings: Launching your Lean Offerings does not mean you finished your Business Design sprint or you are already in the Go-to-market phase. You are still on an iterative learning journey and your market launch is part of an overall research design. You launched your Lean Offerings to validate hypotheses. This means that you run your experiments carefully, and that you track and analyse the results meticulous (see Validating Hypotheses).

4. Participants

5. Tools

6. Instructions for Coaches

  1. Think thoroughly if it is a real option to jump right into the implementation of a Lean Offerings without any pre-launch tests. Allowing 100 % reality quickly is always better than wasting time with pre-launch experiments. The decision nonetheless depends on the complexity of the Business Model and the investment(s) necessary to realise it.

  2. Initiate a Lean Offerings Workshop if some experiments require real conditions and you become aware that more work and details are necessary to start the implementation.

  3. When your team is defining their Lean Offerings, take care that it includes a minimum set of user stories they can charge their customers for. Plus cross-check if their Business DNA is embedded. The team should really be able to test their open hypotheses by launching their Lean Offering. It is your job to make sure that it fits to their overall research design and that they continue their research after launch.

  4. Don’t forget the definition of a lean version of the Business Model to create and deliver the Lean Offering. Teams tend to think too big and loose sight of steps that can easily be done manually.

7. Examples

Well, all that might still be a little bit too abstract. Let’s say your biggest uncertainty is if your customers are going to pay amount X for your offerings. This is nothing you can test upfront. Of course, you can do some research and answer question like "How much money do they currently spend in that area? How much does the current workaround cost them? How much are comparable offerings? What is our minimum price tag in order to be profitable?" But we cannot really answer the initial question if they would buy it for our selected price before market launch.

However, thist is not completely true. Some (digital) Business Models allow to create "fake doors" like a paywall on a Landing Page and you can simply track how many people click "Buy now". But this always means telling them afterwards, that the product is not yet available. And, this is simply not possible with all Business Models. In these cases, we can reduce our risks by counting customer investments (see Validating Hypotheses) before market launch, but the highest level of reality kicks in when money comes into play. This can happen before market launch by preorders or deposits. And finally after launch, when you charge your customers the first time for your Lean Offerings. It is obviously the highest evidence if and when they accept your pricing.

Additionally, you are often not be able to test the relevance of certain features or aspects of your business model before you let customers use / experience your product or service. People have to use your product or experience your service under real conditions to answer these kind of questions. One example: You want to find out whether the way you provide customer support makes the difference (see "magic factors" here).

  • Ries, Erik: The Lean startup (Amazon)

  • Maurya, Ash: Running Lean (Amazon)

8. Prototypes vs. Lean Offerings

We already touched the differences between prototypes and Lean Offerings. Let us dive a little bit deeper and break down the differences to some key parameters. These parameters are very important, because each one of them has major implications on what and how to build your prototype or Lean Offerings.

Prototype

Lean Offering(s)

Test Focus

First customer feedback
Sales-Channels
Sales-Story

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

User-Investment

Lower

Higher