Engineering, hacking and faking.

One of the hardest things I’m learning as the co-founder of my startup, is where to apply effort. When you could do anything, it’s hard to prioritise where the effort should go. I’ve almost certainly not solved this completely, but I have some experiences I thought worth sharing.

A startup, by its very definition, is doing something new. The phrase “product/market fit” was coined to describe the experimental approach most startups take to trying different things until they land on something that customers will pay for.

Unless you are incredibly lucky, it’s exceedingly unlikely that you will magically hit product/market fit by sitting in a cave building something. The only practical way to achieve it — as we’re finding — is to build something, show it to potential customers, iterate based on feedback; and repeat until you discover the magic.

We’re iterating the way we describe our product, the market segment we’re going after and the particular problems we’re hoping to solve with our core technology. We might even end up iterating what the product is.

A startup sometimes blunders across a need that a customer is willing to pay good money for by accident — but probably only because they’d started a conversation of some substance. Given the often hand-to-mouth existence of most startups in their early days, when the realisation that “here’s something we can do that people will pay for” dawns, most of us are going to jump at the opportunity. That’s when we find out what the mission really is.

But there’s a difficult game to play here. Having meaningful conversations with potential customers is hard unless you’ve built something that you can show. And when you do show it, the feedback is often “well, that’s super interesting, it’s not quite what we need, but if you took things in this direction we might be interested”.

We needed to invest to make our ideas come alive. We needed to build something to capture the imagination. In particular, if you’re doing something new — like we are — then most people only really “get it” when they see it working. You need that “penny dropping” moment that only comes from seeing a great demo.

But here’s the hard part. A lot of that initial investment might end up being thrown away, because the market’s perception of what they might buy is probably a bit different to the ideas of some bright startup folks in a garage somewhere.

This means there’s some hard choices. Some aspects of your solution need to be “engineered” in order to prove your team has the ability and in order to have enough “stuff” to sustain you through the conversations, market tests and inevitable pivots.

But some aspects of your solution can be faked; hence the phrase “fake it until you make it”. And some can be built in a very low-tech way in order to be just “good enough” and not waste precious effort on features you may end up throwing away.

Having spent three months defining my startups proposition, testing the reaction and pivoting, I’ve learnt the hard way. Predicting when to engineer, when to hack and when to fake, is the hardest thing. But it’s also probably the most critical thing to focus money and effort on the things that really matter.

So I advocate asking some basic questions:

• What is the absolute minimum you need to build properly in order to approach potential customers? Hint: be hard on yourselves, it’s probably a much narrower scope than you might think. You might not need anything properly engineered at an early stage. Or you might need some core technology to build confidence. Some things you may need to engineer in order to prove your idea can work, but a lot you probably don’t. The list of things you need to engineer should be the things that are needed in order to demo and build confidence.
• What features do you think customers might need on a very small-scale in order to complete a pilot? This is your “hack” list. It’s features you suspect are needed, but have no evidence to prove it is so. You want to avoid pouring effort into features with an unproven demand, until you see stronger evidence of traction. So if you can, do something quick-and-dirty in order to move things forward and rebuild when you need to.
• What will customers expect to see, but which they probably won’t spend any time focussing on? There’s often a set of “tick list” features that people expect to see, but which aren’t actually important. Customers are often just looking for confidence that you see the need and have thought about it, but don’t actually need to see it working. This might be your “fake it” list. You might be surprised how many things are on this list; maybe even things you might at first put on your engineering or hack lists — so make sure to really challenge your assumptions. Static screen designs that show intent, but which don’t need to actually work, are often good-enough in this space.

Let me leave you with one further word of caution. You might start off with a prototype of things on your “engineering” list — something good enough in order to capture the imagination, but something you know you will throw away pretty rapidly. Because doing real engineering is hard and takes time. And you need the shortest route to validating, or refuting, your ideas. So it might be totally acceptable for the first version of your product to be entirely disposable.

Another reason for prototyping things on your engineering list is because you need to work out the right technical design. You might be considering a more exotic technology you have little experience with — if you are, you might find out that, whilst it works, it’s not quite as reliable or easy to operate as you hoped. You can only find this out by trying something out on a smaller scale. You want to avoid pouring months of effort into something, only to discover “this isn’t actually reliable-enough for our needs”. So when considering new exotic things, it’s best to explore their use on a smaller-scale before your whole product is based on them.

It’s sometimes tough to accept that much of that hard work in the early days will be discarded later on. But fear not; it is not wasted. The purpose of hacking and faking is to discover what the real need is — because your guesses are probably wrong. Discovering that need is priceless — because when you do, you’ll have achieved that elusive product/market fit.

We’re still working on it — making progress, but learning every day. We’ve engineered some things that in hindsight we probably didn’t need to — things that a static screen-shot might have sufficed for. At other points we’ve made the right decision to prototype and prove the need. Making these assessments isn’t easy, but I’m learning that it’s best to be explicit about the choices and challenge “do we actually need to build this yet?”. Doing so provides real clarity of purpose. Not doing so has the risk of provoking confusion amongst team members as they struggle to work out the priorities. And a tiny team can’t do everything — it needs to apply it’s talent to things that really matter.

One last thing; this isn’t just for startups, big corporates can benefit from a similar discipline.

In my experience, corporates tend too often to be beset with a destructive “tell me the plan and stick to it” mentality. In the worst case every line of code is counted as an asset, which makes it hard to accept mistakes and to discard work that’s served its purpose.

But good management understands that most wasted effort in IT comes from building things users don’t end up using. So spending a little money to discover the real needs is a valuable investment.

A rigorous process that accepts engineering, hacking and faking as valued disciplines would go a long way to making IT more effective. But with a caveat; it should be in the mainstream, not some innovation function that has a small, but disposable, budget for crazy schemes. For the discipline of “we need to get through the experiments and find what our purpose is” can only come from the pressure of delivery. In the same way that a startup’s fear of running out of money focuses the mind. This isn’t a game; we all need to be accountable.

So make your list; what will you engineer, hack and fake? And why will you make those choices? Write it down and challenge everything you’ve assumed.