Lean Startup Adventure, day 15: Learn

After building a demo and gathering key product metrics, it's time to learn. As explained in the previous post in this series about the Lean Startup, we spent more than a hundred dollars in ad campaigns in order to test our ability to acquire customers. The result wasn't good. So it becomes clear that our business model is wrong. what can we change to make it better?

Customer acquisition

Our most fragile hypothesis is proven wrong. We thought we could acquire leads about a general purpose tool through online ads. We never managed to prove this would be possible. We haven't discovered the right words to describe the admin-as-a-service product, or at least no word that would trigger curiosity. And when people corresponding to our customer segments arrive to our landing page, they simply don't understand what it is about. Transformation rates are dangerously close to zero. We are not able to get in touch with our future customers.

What we have learned:

• Ad based customer acquisition must rely upon a set of words which represents a concept with an existing, shared understanding. You can't simply showcase a "tool to help you in your day-to-day task" and expect people to imagine what it could be for them
• Driving an ad campaign requires highly specialized skills. You can't open a Google Ads account and expect to count clicks in the following hour. The related expertise is costly and rare.
• LinkedIn Ads result in an abysmal click-through rate. Don't use them.
• On a landing page, a video showing the product isn't enough. You must publish a video showing a real problem solved with the product.

Other customer acquisition strategies (most notably through sales) involve a high investment to get started, and are far from sure. At that point, we are not ready to invest more on our first idea because we know our acquisition failure reveals a deeper error.

Solving A Problem That Doesn't Exist

The problem interviews were eye openers. When we managed to find people coping with the problems we target, it took a very long time to explain our vision of the solution. Most people wouldn't believe it could be possible. They would only accept to pay for it if we could prove that it solved one of their more specific problems beforehand. The tool they'd have bought would have to be packed with a ton of features. A general purpose tool wouldn't do the job.

We have learned a lot in the process:

• When targeting Marketing people, general purpose tools simply don't work. One must provide a specialized service already matching an existing process, not the bricks to build that tool.
• Many sources of data in the enterprise (invoicing, CRM, internal tools) don't expose an API.
• There is no such job description as a "data entry manager". No "Micro-Enterprise Resource Planning user" either, no "admin user". It's all about tasks. But you can't target the "people who fulfill tasks" in general. You must focus on one particular task - and for that, you need domain knowledge.
• Every collaborator in the companies we met use several softwares, some of these are connected, some of these not. The time they spend switching between these tools isn't counted, the loss of time caused by the switch isn't estimated. Moreover, if a task has to be repeated often, the cost of switching between multiple tools becomes marginal thanks to training. Productivity and usability gains are impossible to estimate.
• People who do have the problems we expected solve it by investing on developing a home made admin tool. These are the same people who invest in home made software, in which the admin part represents about 30% of the cost.

Simply put, it seems we are trying to solve a problem that none has - like 95% of startups out there. We are glad to discover that before actually developing the product!

There Must Be Another Way...

In the sad landscape of our dead-before-start product, we see a path to a maybe viable product. Every developer we talked to was enthusiastic about the solution. Every manager we talked to saw the potential savings a modern admin generator could bring. We know that ng-admin fills a need because it is already used by many developers across the world. Maybe we could focus on helping people spend less instead of helping to solve a problem that doesn't exist?

Could it be that, by switching from a B2B (business to business) to a B2D (business to developer) strategy, we could monetize our solution? Our experience and intuition tell us to be careful, because developers seldom pay for software nowadays. We can count many failed attempts at providing SaaS tools to developers (including some we've worked on like SensioLabs Insight), and only a handful of successful ones (GitHub, Travis CI, BrowserStack). But the rapid expansion of the user community tells us there is still something to explore.

Time to change the business model, time for a pivot! We'll explain how to do that in the next post in this series.

Credits:

Thumbnail picture: Fire Juggling, by Daniel X. O'Neil