I am rescuing a dialog on customer development and channel development I had with Ash Maurya from the comments to his “Lessons Learned in 2010” blog post. I am still at work on the “system of simultaneous equations” model and I think his new thinking on the “Customer Factory” is moving closer to iterating against multiple constraints simultaneously. I know with Theory of Constraints you should focus on the rate limiting constraint but after a few iterations everything can start to pinch.
I continue to work with the Okaloa team on Discovery Kanban and think that it also allows for the integration of option management into the next set of actions you are considering. This is still a work in progress and I welcome comments or suggestions for improvement.
Fallacy of Customer Development: It’s a Scalable Way To Reach Customers
Ash Maurya: The fallacy of customer development is that unless you are building a business (like Enterprise software) where the primary channel to customers is through direct sales, customer development is NOT a scalable way to reach customers. Instead, Customer Development is a form of qualitative learning and while it’s the fastest way to learn from customers, that alone may not be enough. The biggest challenge most web applications face is building a significant path to customers. Rather than going through customer discovery, customer validation, and then tackle customer creation, which can take months, I find it critical to start building and testing “significant enough” paths to customers much sooner.
Customer Development Is Not a Way to Scale Your Sales Effort
Sean Murphy: Even for B2B startups Customer Development is not a way to scale your sales effort, but it is very useful for market exploration, finding early customers, and validating your niche selection with early revenue. I think you are conflating targeting and niche selection with scaling sales. Customer development normally only works for finding a few customers at a time, but attempting to scale too early with a poor map of your target prospect/market normally does not work at all.
Initial Focus Needs to Be Learning Not Optimization
Ash: agree that the initial focus needs to be learning and not optimization.
Let me restate my position this way: if you are a B2B startup that intends to use direct sales, the learning from customer development can more easily be translated into a repeatable, scalable sales process.
If you are a B2B/B2C startup that intends to sell through your site, the learning from customer development is harder to translate into a repeatable, scalable sales process. Even though you might actually sign up early customers during customer validation, selling face to face is very different from selling through a website. Even here, I am not advocating expending effort optimizing user acquisition but rather testing your potential channels of choice so that they can at least drive enough traffic to support ongoing learning.
Customer Development Solves A System of Simultaneous Equations
Sean: I agree with you that the founders’ understanding of how to reach viable prospects is a crucial component to success that many startups overlook, or at least defer engineering in favor of product development. And to your point it’s not just message but media that can deliver a reliable audience or lead stream for your budget.
I think B2B and B2c overlap quite a bit: a B2B startup has to debug messaging and media to the extent that they can either initiate or respond to inquiries.
Your list for 2010 is a very useful summary of some of the key dynamics that founding teams need to balance.
- The best way to validate hypotheses is in two phases: first qualitatively, then quantitatively.
- Content marketing works
- Speed, learning, and focus (without focus you risk premature optimization)
- Document your Plan A
- Having more passion for the solution is a problem: binding yourself early to a solution limits your flexibility.
- Customers hold the key to success and sometimes all you need is just one customer.
My sense is that both Osterwald’s Business Model Canvas and your Lean Canvas elaboration of it are useful for understanding how a successful startup works, but neither really capture the “system of simultaneous equations” that a startup team must solve to find a viable location in a market space. I don’t say this because I have anything better to suggest, just that of everything you have outlined it seems like it has the farthest to go to be actionable.
Business Model Canvas Useful as a Balance Sheet
Ash: Sure – point taken… I think the quest for a “system of simultaneous equations” that govern startups is like finding a “grand unified theory” for entrepreneurship. A lot of progress has been made but it’s still early.
In defense of Lean Canvas/Business Model Canvas, yes by itself it’s pretty bare, but in combination with dashboards and metrics I believe it can potentially parallel the function balance sheets/income statements serve for more establish companies. We’ll have to see if that hypothesis holds up over time.
But Doesn’t Represent The Connectedness of Key Decision
Sean: I am less interested in a “Grand Unified Theory” and more interested in representing the connectedness of the decisions: target customer, key benefits, key features, etc… I don’t get that from the Canvas models.
I think your analogy to balance sheets and income statements is apt. Benefits for a target customer are a result of functionality or features. How you describe the benefits is a function of the target customer, both their needs and how they would describe the problem you solve for them.
Related Blog Posts and Articles
- Three Equations Three Unknowns: Customers, Features, Message this was my start on a system of simultaneous equations. If I could give advice that didn’t sound like an graduate course in mathematics or optimization theory I could probably write a book. I guess it comes from working primarily with engineers and scientists.
- Silicon Valley Entrepreneur interview on “Getting to Plan B“
- MIT/SMR “A Business Plan? Or a Journey to Plan B?” (in particular see worksheet examples)
- Patrick Vlaskovits: The Fallacy of Literal Interpretation a rebuttal to Ash’s “Fallacy of Customer Development.”
- Jeffrey L. Taylor: Hypothesis Driven Development
- Barry O’Reilly How to Implement Hypothesis Driven Development