Sunday 19 May 2019

When a rocket ship is dragging your firm into orbit it all fits

 

The tweet spot: Twitter’s‘Fail Whale’ page was a demonstration of product-market fit.
The tweet spot: Twitter’s‘Fail Whale’ page was a demonstration of product-market fit.

Richard Rodger

Our big goal for 2019 as a startup is to achieve a product-market fit. You'll be able to follow this diary each week to see how we're doing on that big goal, and in particular, how our product development decisions work out.

Product-market fit is a term coined by the venture capitalist Marc Andreessen. It's one of those business terms that has come to mean everything and nothing. The common-place definition is that your product has seen some good sales numbers and you've got credible proof that some people want or need what you're offering. Now all you need to do is find a way to grow demand.

This is not what Andreessen meant at all. Product-market fit is one of those things that, to misquote US Supreme Court Justice Potter Steward, you know you have, when you have it.

It's not good sales numbers or a credible market. It's a rocket ship dragging your company into orbit whether the airlocks are sealed or not. It's what happens when you hit a deep market need and your customers are angry with you all the time because you can't build features fast enough and everything keeps breaking.

If you're old enough to remember the early days of Twitter, when the site kept crashing with a 'Fail Whale' page, that's product-market fit.

I've been lucky enough to have experienced both a lack of product-market fit and a relatively close analogue of actual fit.

My first startup (15 years ago) was a solution in search of problem. With huge amounts of marketing effort, I was able to create a lifestyle business.

But I was always pushing uphill - the product (a software component suite) had to be "sold". It's always a bad sign when you have to expend real energy to sell your product.

My last company, a consultancy, caught the wave of an emerging enterprise technology (Node.js).

While not a product company, we did experience rapid growth (doubling each year) and customers 'pulling' us to market.

This was product-market fit - you know it when you see it.

You have it when you literally can't keep up with demand and the entire company is breaking all the time.

Much ink has been spilled about Tesla Motors and Elon Musk in the past year and it certainly seems as though both he and his company have gone through hell. But they've finally reached their production goals of 5,000 cars a week. Product-market fit is sleeping on your factory floor because you have 50,000 customers who want your product yesterday, and you just can't build it fast enough (or at all).

How is my current startup, voxgig, an event management platform, going to achieve product-market fit?

In the best tradition of this diary, let's document our strategic and tactical decisions and see how things play out.

We are soft-launching public access to the system from January 29th.

It's a busy month as we put everything in place to make it possible for you to actually register and use our system.

Up to now we've focused on private trial clients, so there hasn't been a need for a user registration system.

Following the lean startup approach, we just didn't build it. As with our 'minimum viable product' launch in March last year, this is a soft launch. We expect to spend most of February ironing out the kinks.

The first public version will definitely be embarrassing - as it should be.

Strategically, we are trying build things only as they are needed. This makes us 'capital efficient'.

We try not to waste money building software that no-one wants (I've been burned by that one too many times). That means we deliberately end up missing big obvious things (like user registration). We're always going to be behind in some way.

Once we achieve product-market fit, this will only get worse. This strategy maximises our runway (the time until our money runs out) and optimises the product for people who actually use it.

It does present an engineering challenge. We can't build well-designed features. Every feature that we build will probably have to be updated and modified many times.

And we need to keep adding new features, all the time.

If you try to build software without taking this into account, you'll flounder. It's easy to get a first version live, and it remains easy to add new features, for a while. But then most startup software systems start to collapse under the weight of all those changes. This is a particularly dangerous thing for software startups.

You can easily end up in a situation where you don't have product-market fit, but think you can get there by adding new features.

The big warning sign is that you are the one deciding which features to build, not your angry dissatisfied customers.

Building features is expensive and burns up your investor's money more quickly. This never ends well.

But far worse is when you do have product-market fit, and you can't execute fast enough to grab the dominant market position.

The engineering tactics used by a software startup need to support the business strategy.

Our engineering approach is to break our application into lots of small 'apps' (not mobile per-se, we've just re-used the term). Each app delivers a small set of functionality and is completely standalone. Everything is built around this concept.

When a customer asks for a new feature, it's almost always a new app. We can build each app very quickly.

This lets us deliver new features easily, but now worry too much about getting them right.

What about fixing old features that need to be changed? In most cases, we throw away the app and start again. They're small enough to do this, and our supporting software architecture makes this easier over time.

By making our apps disposable, we avoid the build-up of complexity that makes software harder to change over time. (If you're technical, we build each app from a set of microservices, and some of those may survive, so it's not total destruction).

Things won't always be like this, but the early days are so volatile, and product-market fit so demanding, that you need to sacrifice everything for flexibility.

Eventually the engineering process converts to a more conservative project management approach - but only after each line of code has proven it can make money.

Be wary of hiring software developers into your startup that don't understand this - startups die easily, often with beautiful code.

Speaking of such things, you might be wondering how our funding process turned out. We hit our goals for 2018 and we're all set for 2019. And that's about as much as I can say.

Much as I'd like to go fully transparent like buffer.com (and they publish everything, including sales numbers and salaries), we operate in a very different ecosystem.

As Ludwig Wittgenstein, the oddball (aren't they all?) Austrian philosopher was fond of saying: "whereof one cannot speak, thereof one must be silent". Or as one of his friends put it: "What we can't say, we can't say and we can't whistle it either."

Marketing update: the holiday season didn't see much change in our numbers, but there's no surprise there.

The speaker's newsletter is at 5,388 subscribers, and has an open rate of 14pc.

The podcast is now at 51 downloads per week.

I'll have new numbers for the new Event Professionals (EventProfs) newsletter next week once we complete the mini-relaunch.

 

Richard Rodger is the founder of Voxgig. He is a former co-founder of Nearform, a technology consultancy firm based in Waterford

Indo Business

Also in Business