In the previous post in this series, Yann explained how running an online demo helped us to learn a lot about our initial assumptions with minimal investment. Based on objective metrics gathered during that demo, we clearly highlighted the flaws in the original business model. Let’s try and design another business model, not for end users, but for developers this time. In other words, let's pivot.
Eric Ries first coined the term pivot in the Lean Startup book. A pivot is simply a major change in the business model. A startup decides to test another set of assumptions, which translates into major updates to one or several boxes in the Business Model Canvas. It often comes after getting negative feedback from the market, either in the early stages (before public launch), or after an initial run.
In his book, Eric Ries describes 10 types of pivot. Let's try to summarize them here:
Making a pivot is not easy: it requires the courage to accept that the initial solution was wrong. It requires the energy to start again, test the new assumptions using the tools we've already covered (customer interviews, demos), and possibly disappoint some of the early adopters.
But making a pivot is better than going further and further in a direction that leads to a dead end. A pivot is a drastic procedure following a partial failure, in order to avoid a complete failure. If you can't pivot, you can't learn from your mistakes, and sooner or later the product-market fit will change and you'll be doomed.
The Lean Startup is all about experimenting, and iterating after a failure to converge faster towards a plan that works. But experimenting properly is hard, so experiments may fail not only because they rely on wrong assumptions, but because the experiment is flawed. And it's very easy to fail the execution of an experiment.
That means that in many cases, the outcome of a Lean Startup experiment is negative, to a certain extent. The temptation is high to blame the assumptions, rather than the execution. That leads to an early pivot.
But if you're not able to execute an experiment, chances are you won't be able to build a complete product either. So a pivot won't change the outcome: you will fail.
That means that, before deciding to pivot, a startup must carefully inspect the experiment that failed, trying to find the execution flaws first. It is much easier to re-run an experiment after fixing execution problems than it is to go back the an empty Business Model canvas.
In our case, our experimentation clearly had flaws: we should have used the demo on customer interviews first, to make sure the wording could fit; we didn't know how to use the customer acquisition tools properly; we had a very small number of visits to base our conclusions upon.
Nonetheless, we are quite sure that iterating on the same set of assumptions will lead to more failure. Many clues show us that our initial assumptions are wrong, so we decide to pivot. Based on what we learned, we know we need to update the business model by changing the customer segment.
A pivot translates into a new business model. This time, instead of the Lean Canvas, we’re using the Business Model Canvas, invented by Alex Osterwalder and Yves Pigneur. I decided to try this new canvas after attending a talk by Yves Pigneur, where I found the canvas very effective, and the speaker very smart. And it definitely works for Lean Startup products:
The Value Proposal reads “Provide a customized workspace for each admin user, immediately available, without spending developer time”. Still quite close to our original approach, despite the fact that the main customer segment changed. We dig deeper into this value proposal using Alex and Yves’ Value Proposition canvas, here is what it gives:
Now the value proposal says “SaaS Backend administration configurator based on a REST API”.
As a comparison, here our original Lean Canvas (from day 3):
While doing this exercise, we identify API generators and SaaS services offering an API as core partners. Then it strikes us: if someone can package both an admin generator and an API generator (together with the storage) into a single tool, they would produce a very appealing offering for frontend and mobile developers. An entire application backend, managed and hosted, allows to start frontend developement right away. This is interesting because the web developer job is currently shifting from backend to frontend, as most of the business logic gets implemented on the frontend side (using frameworks likes Reacts.js and Angular.js), while the backend is more and more reduced to a dumb storage (thus, a REST API).
A good example of that shift is the CMS landscape. CMS backends are often a huge cost for dev teams. If you happen to use an open-source CMS as your framework, then everything not content-related becomes very expensive to build. If you happen to use a general purpose framework, then you have to reinvent the core CMS features (publication workflow, versioning, site structure, media library, etc). Instead of facing this alternative (build up on a CMS or a framework), you can think out of the box and build the content-driven sectino of your app on top of a SaaS CMS service like prismic.io. It provides a document storage, a REST API, and an admin interface for editors. The rest (implementing the frontend apps based on the REST API) is the frontend dev's job.
So there is another business model to explore, complementary to our Admin-as-a-Service idea? It could be named “backend as a service” (BaaS). Guess what? It's already beed developed for years. By googling the term, we find that there are already half a dozen backend-as-a-service services, ranging from the “early preview” to the “complete solution”. Before working on yet another business model canvas, we decide to take time to benchmark existing solutions, and see what each of them can offer.
Then the very next day, Amazon publishes Amazon API Gateway, a fully managed backend-as-a-service solution. This is huge news, for several reasons:
So building a BaaS offer ourselves is out of the question, but there is definitely a place for an admin-as-a-service offer based on AWS’s API Gateway, and other BaaS providers!
After a pivot, you have to start again. Problem interviews, benchmarking, brainstorming the solution, building a demo, measuring customers appetite for the solution. Rince and repeat, until it works.
Our next post will focus on what happens when the demo is conclusive. Once you're confident that you have found a problem worth solving AND a good solution for that problem, then it's time to build a Minimum Viable Product.
Thumbnail picture: Windmill, by Adam Simmons