I created the Lean Canvas back in 2009 as a way to more effectively document my most critical business model assumptions for my products which were predominantly SaaS software products at the time.
Lean Canvas is now taught at over 200 universities (including high schools), close to 100 startup accelerators, and used at hundreds of businesses (including large enterprises). We just crossed the 125K users, and 175K canvases mark with our online Lean Canvas tool.
I’m not sharing these numbers to show off our vanity metrics but rather to acknowledge that both the scope of usage and audience has broadened well beyond my prototypical early adopter. Just the other day, I got a Lean Canvas question from a salmon fisher in Chile!
But with expansion comes the challenge.
In this case, one of adapting and refining the framework beyond its original reference model. I’ve mostly been addressing these challenges in my private workshops and boot camps and noticed that I hadn’t posted any of this publicly.
This was brought to a head for me recently after reading a post by Benjamin Kampmann titled: The Lean Canvas: Wrong Tool for the Job where he recounts several issues he faced when modeling his tech ventures with the canvas.
First, I’d like to thank Ben for posting his experiences publicly. I’ll attempt to address his concerns along with others I’ve collected along the way in this post and follow-on posts.
The core issue Ben raised stemmed from a characterization that the Lean Canvas was too focused on profit as the main goal of any venture. He further argues that this profit-seeking focus derails ventures that fall outside the direct (user = customer) references business models, such as multi-sided models and not-for-profit models.
While I don’t like to think of money solely as the goal of a business, I liken money to oxygen.
We don’t live for oxygen, but we need oxygen to live.
That said, there is a difference between money and profit. And I don’t consider profit the universal goal of every business or product.
The Universal Goal of Any Business
The universal goal of every business is to make happy customers.
Happy customers get you paid, and doing this repeatedly and sustainably is the goal of every business.
This is true whether you are building a product business or a services business, software or hardware, low tech or high tech, and even if you are building a for-profit or a non-profit business.
This is also the central theme of my next book, titled: “The Customer Factory.”
I am not going to dive into the details of the Customer Factory in this post, but rather use this central idea to show you how you can use it to model any business with the Lean Canvas.
I guess that this profit-seeking characterization is rooted in the presence of a prominent Revenue Streams box on the canvas, which poses problems when thinking about some of these non-direct models.
What to Put Under Revenue Streams?
First, the happy customer goal isn’t a cop-out for not being specific on your revenue streams which is a problem I generally see across all canvases I review — even direct, for-profit models.
“There is no business in your business model without revenue streams.”
Therefore, I want to start with the simplest (not necessarily easiest) direct, for-profit business model and then build up from there in subsequent posts.
Specifically, I don’t just mean citing your revenue stream sources but getting down to actual pricing and projected lifetime numbers.
For example, $50/mo with 2 yr lifetime.
You need these numbers to ballpark the opportunity or “problem worth solving” both for yourself and your external stakeholders. If you don’t have a “big enough” problem worth solving (that’s not even plausible on paper) then why expend any effort on it?
I’ll cover the simple math for ballparking your business model next time.
The biggest objections I hear against being this specific are:
a. How do I price a product when my solution is still uncertain?
Customers care about their problems and not your solution.
So you should price against their problems (using value based pricing) and not what it’s going to cost you to build and deliver your solution (that’s a Cost Structure concern). You do this by anchoring against their Existing Alternatives where you should ideally be able to point to some evidence of monetizable pain.
The best evidence of monetizable pain is a check being written but there are other proxies.
b. How do I estimate my customer lifetime?
This one is a bit harder to model, but it’s still an important input assumption to document. While we would all like to keep our customers forever, every business has non-zero churn or some finite customer lifetime — sometimes because they hate your product so much that they leave, and sometimes because they love your product so much that they use it to solve their problem and then move on.
One way to guess the customer's lifetime is through the nature of the problem you are solving. Is it a single occurrence problem or something recurring? If recurring, how frequently would the user need to solve the problem, and for how long? From there, you might be able to guess when they would outgrow your solution.
Studying other analogs in your vertical or domain can also be an effective way to estimate your average customer lifetime. If all else fails, pick a conservative estimate for now. You’ll get an opportunity to understand the impact of this number in the ballparking exercise that I’ll cover next time.
c. What if I have multiple customer segments?
Keeping your pricing model as simple as possible, especially at the earlier stages, not only helps with ballparking but also with faster validation of your business model.
I recommend starting with a single price modeled after your early adopters. Your early adopters represent your best first customers and should also represent a “significant enough” initial beachhead of customers. The thinking here is that if you can’t get these guys to accept your pricing model, what chance do you have with your other segments?
If you are further along or still insist on pursuing multiple customer segments, then come up with an average price per customer using some simple customer segment distribution model.
d. What if I’m giving away my product for free?
There is no business model in free. I have a whole chapter in my book, Running Lean, on why I consider Freemium to be a bad starting model.
Instead, start with the premium part of freemium and then use free as a marketing tactic to fill up your customer acquisition pipeline.
Delaying price testing delays testing one of the riskier parts of your business model. Plus, your pricing model does much more for your product than just putting money in your pocket. It can change the perception of your product and the customers you attract.
Ok, so you’re probably thinking all this still applies to direct business models.
How does this help with the other models?
Let's start with a definition of a business model that I particularly like:
“A business model is a story about how an organization creates, delivers, and captures value.”
- Saul Kaplan, The Business Model Innovation Factory
You create value for your users through your Unique Value Proposition which you deliver through your Solution. When you capture some of this value back through your Revenue Streams, you MAKE customers.
It’s simpler to tell this story with the direct business model because it’s a 1-Actor model where your users become your customers.
The other models are multi-actor models, which complicate the storytelling part a bit, but every business needs to be able to tell this story.
After my next post on ballparking your business model, we’ll pick up with multi-sided business models and then move on to not-for-profit business models from there.
(preferred by thousands of entrepreneurs)