Lean Startup Adventure, day 16: Pivot

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.

What Is A 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:

• Zoom-In and Zoom-Out: A pivot where one of the features becomes the product, or the product becomes a feature of a bigger product,
• Customer Segment: The product we designed answers to a real problem, but the customer segment we focused on does not experience this problem,
• Customer Need: when the problem we were working on appears to be not very important to them, compared to an another problem,
• Platform: a need for change from an application to a platform, or vice-versa,
• Business Architecture: globally moving from Business-to-Business (BtoB) to mass-market (BtoC), or vice-versa,
• Value Capture: as capturing value is a core element of the product, changing the way to capture value deeply changes the product design,
• Engine Of Growth: the three engines of growth described by Eric Ries in his book are Viral, Sticky and Paid Growth. A pivot on this domain is to switch from one to another,
• Channel: changing the distribution channel hypothesis often affects the price and the features of the product,
• Technology: sometimes building the solution with another technology can provide more performance or cost less and then increase revenue.

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 Dangers Of Early Pivot

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.

Misocell Pivot

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):

A Pivot Can Offer New Opportunities

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:

• If Amazon publishes that service, it's a proof they already use it internally, and that the architectural model behind it is relevant
• They probably came up with the same business model design we are about to do, and have come to the conclusion that this is a viable product. A great validation of one of our assumptions... without even needing to build an experiment.
• If Amazon publishes that service, and for a cheap price ($3.50 per million API calls received, plus the cost of data transfer out), building a competing offer becomes out of the scope. We could never build a better product ourselves.
• AWS’s service provides the core infrastructure (storage, monitoring, and API) but NOT the backend interface. There is a place for a complementary offer.

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!

Next Steps

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.

Credits:

Thumbnail picture: Windmill, by Adam Simmons