Lean Startup Adventure, day 3: The Business Model
In the previous post of this series, François introduced "Admin-as-a-service", a business opportunity that we wanted to explore using tools from the Lean Startup method.
Today, I'll describe how Lean Startup tools can help refining this opportunity thanks to a Business Model.
Writing It Down
This initial idea is, in fact, a list of hypotheses. To document these hypotheses and make them apparent, to make it possible to discuss these hypotheses, we need to describe a business model. A business model is more detailed than the two-paragraph description given in the previous post. But it doesn't need to be a lengthy Excel spreadsheet, or an expensive slide deck. Actually, the initial vision often proves wrong, so there is no point in spending too much time to document it.
Note: What is the difference between a business model and a business plan? Actually, a business plan is a forecasting exercise to describe upfront the evolution of our business. On the other hand, the business model is "only" a description of the way we will organize our business to reach our goals. The business model is more a snapshot, an hypothesis of what could be the result of our efforts, than the way to reach them.
Ash Maurya's Running Lean book advises to summarize the business model into a one page diagram. There are two well-known models for business model diagrams: the Business Model Canvas, and the Lean Canvas. Which one should we choose?
The Business Model Canvas
The most famous model is Alex Osterwalder's Business Model Canvas. It has been widely described in a book called Business Model Generation (well worth the read). This 9-box canvas particularly fits existing businesses needing to evolve, and eases discussion on a vague business model.
The Lean Canvas
The Lean Canvas, which is an evolution of the previous one, focuses more on the relationships between the customer segments, the problems encountered, and the business value introduced by the product. Authored by Ash Maurya, it adapts the Business Model Canvas to the Lean Startup method, focusing on most risky things.
Our First Canvas
As we choose to follow the Lean Startup method, the Lean Canvas seems to be a good start to clarify our first hypotheses. So we gather with François for a workshop, and we try to rephrase the product vision as answers to the 9 boxes. Using a cardboard panel and post-its, we end up with the following canvas:
Don't worry if you can't read it, it isn't meant to be readable by anyone else at that point. It gets better once transcribed in a Powerpoint template:
It doesn't read from left to right, but in the following order:
What It Says
1. Problem: Products owners can't manipulate their business data easily without an admin backend. Think about an e-commerce business for instance: the product owner needs to update the catalog, prices, promotions, etc. To build an admin, today they need developer time. But more and more, startups spend money on *-as-a-service tools instead of hiring developers. How can they have an effective backend admin tool then? Worse, for companies using a microservice architecture, each service comes with its own admin tool. In order to achieve a given task, an admin user must therefore use several tools, one for each microservice involved.
2. Customer Segments: We're targeting small companies with a Software-as-a-Service (SaaS) culture, i.e. where the person with a credit card is willing to use it for small monthly subscriptions. Ideally, they already have their own set of REST APIS, or they have decided to build an API-centric architecture. Inside these companies, our main target is a product manager - a non-technical person who wants to avoid spending money on web development for an admin they can customize themselves. We know such companies in our own customer base - these would do perfect early adopters.
Note: We also list CTOs and IT departments as secondary customer segments, but we choose to ignore them. This is because we know that selling software to developers (B2D, a.k.a. "Business To Developers") is hard, since developers use a lot of open-source and are reluctant to pay code.
3. Unique Value Proposition: A direct interaction with the business data, live, without any import/export. To make this clearer, we try to find a high-level concept, by associating existing product names. "Online Excel" sounds nice, except it conveys the idea of an old school and not user-friendly "spreadsheet" interface. "A Kissmetrics you can edit" is closer to what we think about.
4. Solution: That's the easiest part - as engineers, it's the part we usually think about the most. "An admin builder working on top of REST APIs" speaks to developers. Will it speak to our customer segment?
In our cardboard canvas, we also determine existing alternative solutions for this problem. If it's a problem worth solving, there must be alternatives. In our case, most of the time, SMEs use phpMyAdmin or Excel import/export. When they can afford it, they develop their own admin backend, but it's very expensive. In Ash Maurya's Lean Canvas, this piece of information ends up in the "Solution" box, but we don't have enough space in the Powerpoint canvas to add it.
5. Channels: As a SaaS product, the natural path to customers is online (through paid advertising and SEO), but we think that during the early stages, we'll need to meet directly with prospects (in conferences, trade shows, or via cold calls).
6. Revenue Streams: As we are SaaS customers ourselves, this is almost a no-brainer. The service should be paid as it is used, with no commitment upfront. A Monthly subscription per user seems natural. We also think about an unlimited users plan, where the pricing would be indexed on the number of connected API endpoints. But it seems harder to explain to end users.
7. Cost Structure: We don't do any calculation at that point, just listing the costs we'll have to run the service. It's an online service, so in addition to development and hosting, we count customer support right from the start. Sales and ads are included, too - we know right from the beginning that recruiting new users is going to be costly.
How do these revenue and cost translate into actual dollars, and where is the break even point? We don't try to answers these questions now, because we have no idea how much we can charge for this service yet. We'll need to benchmark similar services to get an idea of the Average Revenue Per User (ARPU), and therefore, how much we can afford to spend building the product if we're looking for a quick break-even point (less than a year).
8. Key Metrics: How do we measure success of failure? Being a SaaS product, our revenue is directly indexed to the number of active subscription. On the other hand, the complexity of the service is related to the number of REST endpoints we connect to. There are other possible metrics (number of visitors, number of free users, etc), but at that stage we dismiss them as vanity metrics. And in the early days, we know we have to focus on customer acquisition, as this will be the hardest part for us.
9. Unfair Advantage: We've implemented a custom admin interface based on REST APIs several times in the past, using our own ng-admin. Technically, we know the job very very well. We are the maintainers of the core technology that makes admin-as-a-service possible - ng-admin. We know that this library is the only one capable of building a single interface connecting to API endpoints from several backends - which is the case in microservice architectures. Lastly, we have an existing customer base already using ng-admin, and who would love to be able to customize their admin themselves.
Note: We stop the exercise after writing only one Lean Canvas. Retrospectively, that's a mistake: we should have explored several possible business models, and rank them objectively.
Next Steps
At that point, we're very happy with our canvas. The Lean Canvas exercise really clarifies our thoughts, and it helps spotting the main risks of our business model.
Which are these risks, and how can we test them? That's what we'll describe in the following post.
Credits:
Thumbnail picture: Kitchen rainbow1, by Gary Millar
