Are you building a hack, a product, or a hackquaduct?
Bridging the Hack/Product Gap
When we started Makeshift, one of my main motivations for going for our particular business model was to build on the hacking process I’d been developing for a few years. It goes like this:
The hack-to-product process
Notice a problem that isn’t being solved
Check for gaps - are you missing something obvious?
Think of the simplest thing you could make to demonstrate the idea
Hack it together in a day or two (the time constraint is important here)
Test it out with people who might have a similar problem or be interested in the hack
I’m sure you can see the problem. What happens after the hack?
If, like me before I started Makeshift, you’re by yourself and have other things that you’re working on to bring in the money, the likelihood of one of your hacks turning into something profitable is next to zero.
After the hack
Following through after you’ve made a little hack is tough. At first you’re optimising for the joy of making, but quite quickly that can turn into maintenance, bug fixing, and the worst thing — the brutal cold shoulder of the internet. There’s only so many tweets you can send, and people are busy.
To turn a hack into a ‘product’ requires a ton of effort and, ahem, marketing. Far more likely, your hack will wither on the vine; it may continue to grow slowly but not really bring in serious revenue.
Before Makeshift I had the hacking part down and I teamed up with Nick and Paul pretty much because of one question: “How can you turn a hack into a product?"
This past first year we’ve done lots of hacks, in fact about a dozen. And through that process of trying an idea, evaluating it and making mistakes and learning, I’ve spotted a few things.
So you put out a hack and get some really good feedback.
From here, it’s tempting to attempt to chip away at it until it magically turns into a great piece of software, or indeed a business.
The trouble is, you can end up with something that’s too big to be a hack and not quite a product. It’s a hackquaduct.
A hack isn’t an MVP
With a hack I’m not trying to be “viable” in any way - hacks don’t make money. Hacks are exploratory. They’re the bit before you work out the full requirements for the thing you might make.
Don't have a big launch for your hack
If you market something that’s not ready you’ll end up with tons of “it’s broken” messages and have stressed-out weekends fixing stuff instead of learning. Not fun. And fun should be a thing you hang on to.
Hack the right thing
You can tie yourself in knots building the wrong pieces if you’re not careful. At hack days I always see people messing around with user authentication on their laptop and not getting their hacks actually onto the internet! Priorities…
Test just the right amount
Your hack doesn’t need to be amazing production code. It does need to not fall over and break.
A hack is not the place for Test Driven Development
That’s not because I don’t believe the rhetoric. I’ve done TDD. But because it’s generally slower for me, it fails the ‘make it really quickly’ test that a hack has to have. Plus, if you’re going to throw it away at some point, as long as the hack roughly works for the main flows that people will go through, you’re probably wasting time.
Don’t make too many changes after you release it
I make this mistake all the time. The hack is out there, people are playing with it and like what it does, but it would be lots better if it had x, y and z too.
If you immediately follow through with too many of these iterations, what you’ve actually got is some badly written, rushed software that will become unmaintainable. You’ll hire people, add them to the ‘project’ (you’d stop calling it a hack at some point) and you’ll end up with some difficult conversations about code quality, refactoring and being production-ready.
I’ve learnt to keep the list of amazing features in ‘feature land’ - a fantastical place where one day I might venture.
Hacks are conversation starters
Don’t be tempted to say about your hack, “Here’s my amazing new company. It’s going to be huge”; you run the risk of disappointing or really irritating people.
If you’re following the hack-first process, you’re aiming for conversations with people, not trying to impress them with the scale of your ambition. This means...
One way or another your hack will die. It might not work, so you turn it off. It might keep tinkering along, so you leave it online but do nothing to it, which is killing it through lack of attention.
The best ‘kill it’ result though, is if it works.
Wrangler is a good example here. It was a tiny little Sinatra hack that I made for Paul to run some SQL in a browser. It quickly got to the point where it needed to evolve and have more features. So we killed it, took what we’d learnt from it and Tanja built it again from scratch, properly, using test-driven methods.
The code quality is high, the app is much more maintainable and it’s had the benefit of the ‘hack, play, learn’ loop by someone on our team as the main user.
If you don’t kill it though, and keep chipping away, well, you’ve heard the horror stories of companies saying ‘no new features’ and spending a year refactoring their app. Far better to have a reset early on once you know you want to turn a hack into a product.
The Hack/Product inflection point is the thing you’re trying to find with a hack. Nowadays I’m constantly thinking, “Is this a hack or a wannabe product? Do we stop and do it properly? Do we follow through or is it a no?”
Paying attention to my own behaviour and what’s going on with a hack is my latest obsession.
For now though I’m firmly sticking to this being a tiny hack until such point as people tell me “you know, every startup could use this, have you thought about…?"
Perhaps I'll take a journey to Featureland if it happens enough.
Image credit Rick and Brenda Beerhorst.