How my failed startup failed due to being Flexible, not Focused

Hampus Jakobsson
Thinking about Startups
5 min readJun 5, 2016

--

My latest startup Brisk just folded. Here’s the first in a series of blog posts what we learnt. This one is about product and how we built ours. In a bad way.

Brisk wanted to make sales as precise and predictable as engineering. After a few false starts we found the problem and possible solution but the first customers had slightly different needs and ways of working. To cope with that we built an “application environment” on top of the product which allowed us to tailor the product for each customer. Suddenly we were closing deals with happy customers and users. But that’s also when things started to go wrong.

Too Customised, Too Confused

Every closed deal resulted in a way in a customised version of the product. The customizations weren’t technically challenging, but it gave rise to other problems. We had turned into a platform, with a handful of internally build applications on top.

There was the work of building and maintaining the platform itself, which didn’t directly benefit any user. This slowed us down a lot. As the users weren’t aware of the platform, so we could only charge for an application. But the main problem was that we didn’t have one user story, one persona, and one user goal. Our goal became flexibility.

Flexibility is Not a Feature

We were proud of the flexibility the product offered as every new client could essentially get a perfect, tailored experience. Sadly, that flexibility made it harder to define the main purpose of the product. The solution would have been to either become a platform or to focus. Focus meant cutting off paying users.

Flexibility is not a feature. It’s a burden and a proof of indecisiveness. The fewer killer features you have, the better.

The only time flexibility is a feature is if you are a platform and the applications you have built are merely examples. But then you have to either get others, application developers, on board or have the client build and customize things on their own.

iPhone setup experience evolution by Luke Wroblewski. Once a spear, now a platform.

No One Metric Means no Captain on the Ship

As soon as we started closing deals we started using revenue as the metric for success. Before we looked at active users, which I now understand is also a bad metric.

What we needed was a Product Metric, that showed if the product worked, not only if was used or paid for. A product metric shows that your users are successful in their task: dates created by a dating app, recommendations taken by an expert system, or interactions with data by a BI system. It is only for entertainment apps that time spent is a good thing.

When discussing features of a product, each should have an hypothesis of how it contributes to the product metric, and that hypothesis should be evaluated. If the feature doesn’t add enough value it should be removed, even if some people love it.

We had built a petri dish, but were not running scientific experiments.

VCs liked what we were doing. We got great feedback from happy users. We settled for that. Which was the second mistake and just aggravated the issues we got from being flexible.

Carrots, Sticks and indecisiveness

A problem we got into was also that we ended up with two users within a customer with different goals. Goals that weren’t completely aligned.

Before Brisk we had made a mobile version that made life really easy for the user, the salesperson. But the manager wasn’t satisfied enough by the subordinates smiles to pay us. The manager wanted salespeople to update more data in the CRM to be able to have better reports.

That led our first iteration of Brisk to be a “brownie points” version where the manager could push what needed to be updated to the correct salesperson. The problem with that was that we had low retention. Unsurprisingly.

So we ended up adding more carrots for the salesperson. Bribing them. More nice user interface, search, recommendations on what to do, etc. Which increased their usage. But it diluted both the metric of data collection, and of course the main problem: it made us ambivalent of the goal and the target user to listen to. What to measure‽

If you find you need more and more carrots, you are probably not solving a real problem with a real pain. Ideally you have one user with one pain.

How is this not only visible in hindsight?

Generally the Lean Startup methodology has this problem; navigating customers wishes and demands, and searching for patterns and data with so little input.

As long as you are searching you can’t have any legacy and be able to move quickly.

We had tried, but ended up with tricking ourselves with the platform approach. We were lean, but we didn’t start from scratch every experiment and set clear hypothesis for each feature. As we signed customers on the different variants, we also ended up having to maintain them which slowed us down.

Finding product-market fit is like peeling an onion.

Inside every PMF there is a tighter one with a slightly more focused and maybe smaller market. When is the fit multiplied by size the biggest? That I guess is only seen in hindsight.

Then again, was there ever a market for Brisk?

The mistakes I describe above definitely contributed to the failure of Brisk but the main reason may have been an even bigger problem. Those years were marked by the demise of many other sales tools. We thought we were different. In hindsight, we either tried to over-solve a problem or were not visionary enough.

Our users weren’t looking for a solution that brilliantly predicted and recommended what they should do, but merely a better user interface for a product they already used: the CRM. But that wouldn’t have been big enough. It wouldn’t have been “VC-worthy”.

On the other hand, there was a visionary objective we could have pursued: automating sales entirely. We could have made a car for users who were asking for faster horses. Mentally that was too visionary for us in the beginning.

So what should we have done?

We should have solved something that was a problem already being solved but in a flawed way (with “pen and paper”) or we should have done a moonshot idea. Our product should have had a very narrow use case and user. We should have figured out what the product metric would have been when that user was successful. Finally we should have stared at that problem, that user, and that metric alone, and ignored every other customer and killed features that didn’t live up to improving the metric.

Next blog posts will treat passion and what failure actually is.

--

--

Vegetarian, stoic, founder & investor. Father of three. Malmö/Sweden. Twitter @hajak.