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

Use Case as a Black Box

Consider the following use case: Purchase Items Actor: Purchaser Precondition: Purchaser types at least thirty words per minute and has a web navigation efficiency rating of at least 40. Postcondition: For the average Purchaser acting at full efficiency, the number of seconds elapsed is no more than 30 + 20 * n, where n is the number of items purchased. The name of the use case represents a functional requirement. What does the product do, or enable the user to do? Purchase items. What are we to make of the preconditions and postconditions? What relationship do they have to the requirements for the product? Answer: the preconditions and postconditions are the nonfunctional requirements attached to the functional requirement . Another way of expressing the nonfunctional requirement would be as an attribute and associated constraint: Usability: For a Purchaser who types at least thirty words per minute and has a web navigation efficiency rating of at least 40, it shall take no

Henry Ford's "Faster Horse" Quote

You may have heard the ( apocryphal ) Henry Ford quote: If I'd asked customers what they wanted, they would have said "a faster horse". Over at the On Product Management blog , Saeed gives his take on this infamous quote. He "hates" it, and gives some compelling reasons. Saeed is spot on in his explanations. Personally, I think the quote is great, but it's a matter of interpretation. The valid point of the quote is not that it's a bad idea to facilitate a conversation with your market to better understand it. The valid points are: You must ask the right questions to get valuable answers. You must interpret the answers thoughtfully - often outside their direct meaning - to glean reliable information. Asking questions is not always the best way to "listen" to your market. (E.g., sometimes pure observational studies are more reliable.) Nonetheless, I find the quote is helpful to combat "armchair product management" in the