Skip to main content

Lean Startup Concepts

Now that you've had a largely buzzword-free introduction to lean startup methods, you may be interested in a bit deeper understanding of the concepts and terminology.  Lean startup methods incorporate scientific methods and principles of agile development to help practitioners learn markets quickly and reliably and deliver successful products.  But lean startup enthusiasts and practitioners throw around a lot of terminology and concepts that may seem alien or not particularly meaningful to you.

Let's examine and demystify the basic lean startup terminology with a rich and concise conceptual model. To view the model of lean startup concepts, click the image below:

Lean startup concepts fall within four different clusters: hypotheses, learning, market, and product.


Forming hypotheses is a component of lean startup methods. The business model represents the strategy driving more tactical product decisions, and it consists of a set of hypotheses. These hypotheses are rooted in the market problems the product is intended to solve. The product serves as a set of solutions to these problems.

Prospects and customers typically have existing alternatives to at least partially address or work around the same problems. The unique value proposition conveys an overarching theme of addressing the problems, and it leverages the unfair advantage the company possesses relative to any competition. A high-level concept summarizes the unique value proposition using a metaphor likely to be familiar to members of the targeted customer segments.

Metrics measure the key activities from which the company and customers derive value, such as adoption, usage, and purchases. Customer segments represent the target market for the product, and sales and marketing channels reach these customer segments. Revenue streams come from such sources as product purchases and advertising, and they offset the cost structure for the product.


Lean startup methods are first, and foremost, about efficient learning. We conduct interviews of subjects, which include prospects and existing customers, to uncover initial insightsHypotheses rest on assumptions. These assumptions entail predictions that we can test with purposeful experiments. The results of these experiments yield further insights that we use to adjust our assumptions and hypotheses.


We sell products to prospects who face problems, and those prospects become customers. Early adopters are initial customers that can be key partners in helping lean startup practitioners form, test, and refine hypotheses.


The business model outlines the strategy for a successful product. Developing a minimum viable product (MVP) enables us to minimize the amount of time needed to deliver value to customers, to determine whether prospects will pay to solve their problems, to determine whether the product satisfactorily addresses those problems, and to determine whether the product is usable.

Parting Thoughts

Most lean startup concepts aren't new. Taken as a whole, however, they incorporate and enhance the common ways that companies make product decisions in a manner that can accelerate, and improve the reliability of, learning and implementation. The scientific and agile approach fosters a greater likelihood of product success.

Is your company incorporating all or most of these concepts in the ways it makes product decisions? If so, what sorts of successes and challenges have you had? If not, why not?


Unknown said…
Roger, I think you're right on that most "lean" concepts aren't new. Good product people have practiced these techniques for years.

OTOH, many startups and skunkworks projects in larger organizations do these things badly or not at all, and end up wasting a lot of time and money delivering solutions no one will buy.

So overall I am happy to see these concepts popularized.

As I mentioned in my comment on your last post, the hardest thing is, I think, gathering real data you can use to validate or invalidate your hypothesis. I'd love to hear tips, tools, hacks or any other ideas people have on how to do that efficiently.
Roger L. Cauvin said…
Thanks, Bruce, for the comment.

While I do believe most of these concepts aren't new, I also believe that even "good product people" have generally not practiced them in a comprehensive fashion. I think you hit the nail on the head with data and measurement, though I think the shortcomings are even broader.

Questions for product managers who believe they already sufficiently leverage these concepts:

1. How many purposeful experiments have you run in the past month?
2. What falsifiable predictions did you document before running those experiments?
3. Did you work with your team to instrument your product or website to collect the needed metrics?
4. What did you learn from your experiments?
5. How did you modify your business model or tactics as a result of what you learned?

I suspect candid answers from most product managers - even some of the best ones - would reveal that they aren't applying some of the most important lean startup concepts.

In my next blog entry, I'll cover some tips and tools that product managers can use to apply these concepts in a few short hours or days.

Unknown said…
[minor edits]

Awesome thoughts here! I agree with both of you in that Lean principles seem to borrow much from good business practices in general.

I often feel like the most compelling reason to "buy in" to the ideas of lean is that we end up doing this in an unorganized organic way anyways if left to our own devices.

But being able to put a language and wording to the process as a whole makes communicating the complex layers of good business development to wider audiences so much easier.

Those questions should be written on my mirror every morning, ha! We are keeping track of many initiatives with multiple experiments in various phases of progress.

What's tough is how to start measuring operational things. For instance, there are many analog metrics that matter to my company, and potentially other companies applying lean face those problems... How do you handle that?

Being a developer, I'm considering wiring up easy interfaces like google spreadsheets or some other low-tech method of collecting analog metrics of activities and sending them into other APIs we use.

But, seems like a lot of work, and something not every entrepreneur can do.

As Bruce is speaking to, gathering real data you can use *is* hard. Most software products get the juicy metrics for free or with little effort. But I definitely find it challenging to accurately keep up with those analog events that matter to me as leadership running an operational company.

So, with that said... I'll parrot Bruce and ask again, "I'd love to hear tips, tools, hacks, or any other ideas people have on how to do that efficiently, particularly with analog data."
Roger L. Cauvin said…
Keith, Google sheets are a great low-tech way of tracking results of experiments. I've actually been using a combination of Bitly and Google sheets to track results of experiments I run when publishing new blog entries.

A future blog entry will describe how product manager can apply lean startup methods right away, without waiting on expensive tools or major investments of time from development.

Popular posts from this blog

Why Spreadsheets Suck for Prioritizing

The Goal As a company executive, you want confidence that your product team (which includes all the people, from all departments, responsible for product success) has a sound basis for deciding which items are on the product roadmap. You also want confidence the team is prioritizing the items in a smart way. What Should We Prioritize? The items the team prioritizes could be features, user stories, epics, market problems, themes, or experiments. Melissa Perri  makes an excellent case for a " problem roadmap ", and, in general, I recommend focusing on the latter types of items. However, the topic of what types of items you should prioritize - and in what situations - is interesting and important but beyond the scope of this blog entry. A Sad but Familiar Story If there is significant controversy about priorities, then almost inevitably, a product manager or other member of the team decides to put together The Spreadsheet. I've done it. Some of the mos

Interaction Design: the Neglected Skill

Your product development organization has a big, gaping hole in it. (Be prepared to feel defensive as you continue reading.) One of the most important roles in product development is the role of interaction designer. An interaction designer designs how the users will interact with the product and conceptualize the tasks they perform. He decides whether, for example, the user interface will be command driven, object oriented (clicking on objects then specifying what to do with them), or wizard based. The interaction designer decides the individual steps in the use cases. Every company has one or more people that play the interaction designer role. Usually, those people have little or no expertise in interaction design. Sadly, they typically don't even realize how unqualified they are. Let's see who typically plays the role at companies. Engineer . An engineer is an expert on building what is designed. Yes, an engineer may know how to design the internal structure of the hardware

Stop Validating and Start Falsifying

The product management and startup worlds are buzzing about the importance of "validation". In this entry, I'll explain how this idea originated and why it's leading organizations astray. Why Validate? In lean startup circles, you constantly hear about "validated learning" and "validating" product ideas: The assumption is that you have a great product idea and seek validation from customers before expending vast resources to build and bring it to market. Indeed, it makes sense to transcend conventional approaches to making product decisions . Intuition, sales anecdotes, feature requests from customers, backward industry thinking, and spreadsheets don't form the basis for sound product decisions. Incorporating lean startup concepts , and a more scientific approach to learning markets, is undoubtedly a sounder approach. Moreover, in larger organizations, sometimes further in the product life-cycle, everyone seems to have an opinio