For the last few years I’ve been concentrating on “getting good at getting fast”.
Finding ways to improve how quickly I can develop an idea into a tiny hack and see if it’s any good.
There’s a step before that, and it’s something that we’re tackling at Makeshift.
Our early stages of idea development can very roughly be summed up like this:
- Look around for ideas to work on - the “Open” phase
- Pitch the ideas to ourselves
- Iterate on ones that meet our aims and principles
- Pick the right idea to do now, and keep the rest on hold
- Work out the bare minimum that we could make to test an idea out
- Build a hack quickly - roughly a week - the “Hack” phase
- Evaluate the hack by trying it out with real people - the “Strike-up” phase
- Gather and listen to feedback from the right people
- Make short-term improvements to things that are “broken”, so you can’t test properly
- Stop - don’t do any more work beyond what you agreed to do at the beginning
- Evaluate where we are, probably in comparison to the other hacks in development
- Kill it or decide to follow through
- Plan the “Make” phase - who, what, why, when, how much
At each point in that flow there are different mixes of skills required, and different issues to consider.
Right at the beginning you need to be thinking about how to find good ideas, so it’s “Horizon Scanning”, having “Yes, and…” conversations (as opposed to “No, but”), reading, looking at the pain points that you and others have, and generally putting yourself in a position of being open to new ideas, wherever they come from, including things that initially sound like jokes - they’re often the best ones. It’s not “there are no bad ideas” - you’ll throw away a ton of ideas, but it is about allowing people around you to have a bad idea and responding with “you know what you could do on top of that…”
At Makeshift we have the beginnings of a small process where we pitch things to ourselves. We have a peculiar setup in that we build what we come up with, rather than having to pitch a client or an investor, so we’ve put this in to give ourselves some kind of structure. Each idea that we think is a contender for something we could do needs to be turned into a one-page document. We’re borrowing from Rapid Idea Improvement here - “What’s the problem?”, “What’s the proposed solution?”, “What’s the market opportunity?”.
Ideally we’d really go in for a full Rapid Idea Improvement model continuing the “yes and” model, and not allowing ourselves to be the “bad guy”. That sometimes creeps in, and RII gives you a meeting format that can stop good ideas being shot down.
Often the idea that’s in that document isn’t the thing that we go for. For instance, with Help Me Write, this came out of a collaborative writing game idea that Paul had. I thought the interesting bit was about suggesting things to unblock bloggers (a problem that I have myself), and pointed at how I currently had some of this behaviour - I post the titles of draft blog posts on Sketching with Code, usually because I have too many things to write and not enough time. Nick picked up some of those things, added his own spin on it, wireframed it, worked with Paul, and the idea that came out of those conversations then went back into “Pitch”.
You only have so much time, so it’s crucial to spend it wisely, and we have a variety of criteria for choosing ideas. These are going to be specific to whatever you’re working on. Here’s a few:
- Does it give a leg up to the little guy? This is what Makeshift is all about
- Is there a decent market size?
- Can we build a hack of the idea quickly?
- Does it have a way of making money?
- Does it solve a problem that we have ourselves, or do we know the people it helps?
Then the ideas fight it out and we go to “hack”.
We give ourselves a week. Ideally. And the idea is to design, build and deploy a “hack” that demonstrates the core value of the idea. For Help Me Write, this is quite easy. For Bitsy, which is a more complex product, involving payments, PCI compliance, privacy, legislation, etc. we had to take a little longer.
We’ve built a network of hackers, and the good thing here is that we can bring someone in who’s not part of the core team (yet!) to do this, because it’s so loosely coupled from everything we’re doing.
I’m doing some work on how to ensure that we’re all working on a similar stack on our hacks, but so far they’re pretty varied, using whatever language / stack is appropriate.
The purpose of the hack is to test out the idea with real people. We might put out our hacks at a demo day (so we have our own deadline), or we might do it a little more quietly, or we might just say (like we did with Help Me Write) “hey Twitter buddies - have a look at this”. Using tools like Intercom we then try to “strike up” a conversation with the people that we think will benefit from the idea, so that we can learn what we’re supposed to be doing with the hack. Is it the right thing? Is it useful? Would people pay for it? And so on.
I’m going to write about this in a lot more detail (vote it up if you want me to write it).
And then you stop. You can’t go on supporting every idea without really thinking it through. You have to take a cold, calculated look at how well the hack is doing, whether there really is a market opportunity, whether it’s just too early to tell, and whether any of your assumptions have been validated.
That’s best done when you’ve already given yourself an opportunity to not be stuck in on the thing you’re building, and by stepping away, taking a break, doing something else, you can decide if it really is worth investing more in the idea or not.
Kill or invest
And then you have a tough conversation with the rest of the team - we’ve had one of these around Bitsy, and in that case we made the decision to invest three months of solid development time into the product, to bring in some additional team members to do specific work on it, and to re-evaluate in three three months. The opposite can happen though, and it’s important that you’re able to say “okay, experiment over, maybe it’s not this one”. If you don’t allow yourself to kill an idea, you’ll block yourself and incur big opportunity costs. I know this from experience spending far, far too long following through on ideas that weren’t working, but where I’d made promises and felt so professionally embarrassed that I had to just keep on battling on. With the “it’s just a hack” approach, it doesn’t matter. You can walk away, and it’s just part of the process, and that’s one of the most important things I’ve learnt about “getting good at getting fast”.
And then you’re onto the first step of a classic startup story - the part where you’re focussing on a longer term period of productive, joyful making where the team is making all of the crucial early decisions and building a product together. But that’s too big to cover in this blog post…