Lean Startup Adventure, day 4: Risky Business

Previously in "Lean Startup Adventure", Yann laid out the product vision into a canvas to explore the business model. This clarifies most of the assumptions on which we intend to build the product. But some of these assumptions, if they turn to be wrong, can make the business fail miserably. These are the risks.

In this post, I'll explain how we determined and prioritized these risks.

Lean Startup Is Dealing With Risks

A lot of things could go wrong with our business plan. We could solve a problem that doesn't exist, we could fail to build a path to our customers, or we could make a great product but fail to make a business out of it because of bad pricing. There are risks of course - otherwise there wouldn't be an opportunity.

In Running Lean, Ash Maurya encourages entrepreneurs to rank business models against product risks, customer risks, and market risks. Naturally, quantifying a risk is just a matter of multiplying the probabilities of a specific outcome by the associated loss.

At this stage, we feel no need to go deep into statistical modeling of our risks. We already have a pretty good intuition about those risks and their ranking.

Admin-as-a-Service Risks

All it takes to determine the risks for the first Admin-as-a-Service Business Model is a series of discussions with a few advisors. Advisors are people external to the project who are not in the target, but whose experience is valuable. In our case, we look advisors in the marmelab staff, and in our own network of startup entrepreneurs. After meeting with about 5 people, here is what we get as a result:

1. Customers May Not Exist: There is no such job description as "data manager". We have the intuition that non-tech staff would love our product, but who are these people? Who is dealing with data management in a company, and struggling with internal IT for usable admin interfaces? We don't really know who we should contact to engage a conversation about our product. In short, even though we are pretty sure about the type of company that would want our product, we don't know our customers - and that's a hell of a risk. If nobody outside of the tech staff can be interested in our product, we don't think we can make it a business.
2. Can't Reach Customers Without a Problem Name: The terms "admin backend" or "Administration GUI" aren't very widely used. "Admin as a service" speaks mostly to developers, not to product people. How do these people talk about their current admin tool by the way? The value proposal may not have an existence in our customers' mind - it's too early. We may not be able to acquire leads based on SEO and SEM if we can't find words to target. Even passed that, a landing page using these words may see a very high bounce rate. Even if we don't need to find the right name now, there is a high risk that we can't find any good one at all.

   Note: When shaping that risk, we don't notice that we're too "online-oriented". Other customer channels, like referrals or word-of-mouth, are dismissed as not compatible with the early phases of our product. That's a mistake. We also overestimate the reach risk at that point. There is still time to find a better reach strategy, but we will only find out later.

3. Customers Won't Accept To Leave Their Business Credentials Behind Their Firewall: One of the main ideas behind Admin-as-a-service is that customer data is not stored in our servers. Users connect to their own APIs and grab data from there, without our intervention. But we can't store the API credentials on the client side, in the JavaScript code, for security reasons. That means that users must trust us with their API tokens/credentials to be stored in our servers, so that we query the APIs for them (sort of like a proxy). That may cause a no-go from the IT security teams. There is a counterexample of that risk: online dashboard and BI services, which require the same kind of credentials, have found a customer base.
4. REST Architecture Requirement Is Too High: REST-centric architectures, which are a prerequisite, may not be as common as we imagine. The market size can therefore be much smaller than expected. This risk isn't too important in our minds, because a product manager can make the API a requirement, or decide to go with our product first and ask their IT staff to work on the "details" afterwards.

   

5. The Market May Be Too Small: If this is such a good idea, why didn't anyone else build such a product before? It may be because someone tried, and failed to build a profitable business out of it. It may be because it's hard to charge $10 to $20 per user per month for an admin panel. In that case, we'll never cover our costs.
6. REST Adapters Are A Black Hole: Developing adapters for all possible REST flavors can be too expensive for the business to be profitable. That's a problem of technical feasibility, which is almost always a matter of cost. This may become problematic once we pass the early stages of the business and start to scale. We choose to put this risk aside.
7. CRUD Is Too Generic: The GUI implemented by ng-admin is mostly a combination of datagrids and forms. In short, it's a CRUD (Create, Retrieve, Update, Delete) with an up-to-date design. Even though ng-admin itself can produce much more sophisticated GUIS (using the power of Angular JS), these non-standard widgets are hard to customize without code. And we're trying to remove the need for a coder, so only the standard datagrid and forms can be included (at least at first). Will this simple interface match the complex requirements of business processes? When it won't, that will reduce our market size.
8. Can't Sell SaaS to Non-Tech Staff: Software-as-a-Service customers are mostly CTOs and CIOs - because they're supposed to know what they pay for. We know that some product people pay for dashboard services, and we hope that the same customers can look for a service that not only reads their data, but also updates it.
9. Competitors Can Do Better Faster: ng-admin is open-source, so we don't have any real technical competitive advantage. Anyone could use ng-admin to build a better Admin-as-a-service as we do. If our product is a success, there is a very high chance that this may happen. But this will be a rich people problem.
10. Browser Support In Corporate Environment is a Killer Cost: We're targeting non-cutting edge users, those who still suffer with IE8 and 9. The additional cost to support older browsers could kill our profitability.

Phew, that's a lot of possible reasons to fail! After listing all these risks, our first reaction is to stop there. There are just too many possible causes of failure to even try. But we're still almost convinced that we're addressing a problem worth solving. Motivation is key in a risky business. So let's continue, and check if we're right or wrong about that business idea.

Prioritized Risks Are An Ordered Task List

Why is it important to prioritize risks? Because in a Lean Startup business, we're not looking to build a product, but to learn - or, as Eric Ries puts it, to acquire Validated Learning. We will learn the most from the most uncertain assumptions with the worst possible outcome, the ones that can simply kill a business.

To put it otherwise, if one of the risks we've listed proves to be true, we'd better find out very soon and pivot to another business model, before we spend too much in the wrong direction. In any case, we will learn something, be it that no business is possible with that model. And that's already a competitive advantage over other companies who would go all waterfall with their product.

So we will have to tackle all these risks, one by one. How can we lift them? By building an experiment to check whether we're right or wrong. Each experiment will bring us validated learning, and allow us to tackle less risky assumptions.

So the list of prioritized risks determines an ordered list of experiments. This is our roadmaps for the early stages of the product. By working on risks, we've just found a way to do product planning efficiently, and to determine where to start.

Next Steps

There is a cheap way to get insights about our business model: by discussing our vision of the problem with possible customers. In the next blog post, we'll explain how we designed Problem Interviews.

Credits:

Thumbnail picture: Circles, by Susanne Nilsson