A couple of days ago on the AppGarage blog we wrote a blog about “How to build when you can’t”. Today we’re going to write about almost the opposite: How to build when you shouldn’t.

As someone who can build (engineers, developers, programmers etc) building things are associated with great joy and a feeling of accomplishment. At the same time building makes us feel comfortable and in control. We’re good at it. We know exactly how to optimize Java heap space, how to program an FPGA, how to build bacteria(? granted we’re not a bio engineers at AppGarage.. yet) — you get the idea. We know how to do it, we know why we do it. So we just do it.

The danger of being able to build

So when I as a builder get a business idea — what’s the first thing that I’m going to do? Fire up Sublime Text/Eclipse/Xcode/IDE-of-choice and start building. Why? Because I like it, because I love to bring new stuff into this world. It motivates me, it makes me feel powerful, it makes me work all-nighters with absolutely no need for sleep. And depending on the idea and my motivation in everything from 1 week to 6 months down the road I have a built “Something v1.0”.

Let’s examine that something that I’ve built from a market perspective:

What’s the market size of “Something v1.0”? 1 person, myself.
What’s the value proposition? “Something v1.0” satisfies need “x” which I have confirmed that 1 person (myself) has.
How many users does “Something v1.0” have? 1.
How many users have the need that “Something v1.0" solves? No clue.

See the danger? There’s a high risk that you’ve built something which only you or a very select few will ever buy/use.

So should you stop building altogether and kill your dream of realizing “Something v1.0"? Heck no. You should just build in a slightly different and more scientific way.

Lean Startup for builders

As a builder we like data. We like to look at data and tell ourselves — yes we were right about that, just as we thought we were. We use data all the time when we build stuff: If the execution time of our “draw_giraffe” function is representing 80% of the execution time of our program then we know exactly where to optimize, where to make it better. When we think about it we probably also knew that using that nested for-loop to draw the dots on the giraffe would wouldn’t be good for the performance of our Zoo simulator. We excel at analyzing data and optimizing products based on it.

Fortunately, there’s a method with which to build startups, which is just as scientific as analyzing your c-program with gprof and it’s called Lean Startup. If there’s one book that all builders have to read (regardless if you like startups or not) it’s Lean Startup by Eric Ries.

Lean Startup is built on one simple feedback loop, which is taught in every single technical university around the world on the first day of the first semester (but obviously introduced to the world of business as something new and revolutionary): Build -> Measure -> Learn.

“Ah — so I should build ‘Something v1.0' before doing anything else? Bye bye blog — I’m going to go build!” Hold it! That’s not what it says exactly. I’m going to go through each step from a builders point-of-view.

Build.

Build is about designing an experiment to test a hypothesis that you have about the problem that you’re going to solve. And the first hypothesis you should formulate is known as the value hypothesis (it may in fact be many hypotheses). The value hypothesis is about formulating what you think the is that your idea provides to a customer. With “value” I mean what would make a customer pay for your “Something v1.0". Imagine you’re going to the supermarket to buy meat. What value does the meat bring you? Satisfy hunger is probably the first. So why do you choose the meat that you do? Maybe you’re focused on it being organic, maybe it’s fat content. Different features of the meat might appeal to different people in different ways.

Same for products that you as a builder can build. Let’s take an example more fitted IT engineers. One of my good friend’s recently launched Timebird — an app that let’s you schedule anything with anyone without the hassle of e-mailing back and forth.

Let’s define a value hypothesis for Timebird. It could be:

People are annoyed with having to send e-mails back and forth in order to schedule an appointment.

Now the “Build” part of this is how can we build an experiment with the fewest amount of resources to verify this hypothesis? Several things could be done:

1. Make and send-out a questionaire
2. Make a sign-up page e.g. using launchrock.co and ask exactly that question and see if you can get people to sign-up.

We could also build the whole product. But that would take us a lot of time and if we then find out that only a few people wanted to use it — well then it might have been better to spend an hour to setup a launchrock site. Each of these suggestions above require no code but by executing the experiment you learn a lot. But only if you measure right.

Measure.

Let’s say that because you’re a developer you think questionnaires are boring and you want to play with launchrock.co. So you built a launchrock.co page and you shared it on all social networks, you got your friends to share it and so on. How do you measure if your hypothesis is true? This is about defining a metric that will truthfully give you a picture of whether or not your hypothesis is true. At the launchrock insights panel you get access to all sorts of stats about the people that visit your site. And one important metric that you get is the conversion rate i.e. how many people who viewed your site also signed-up.

The conversion rate could be a good metric. The important thing when selecting a metric is to evaluate it and really try to shoot it down. Is the conversion rate a good metric? What if we used number of visits instead? Would that be good? You could argue that clicking a link is not that tough and everybody click on everything all the time, so theoretically your number of visits has to increase over time. But the conversion rate shows you how many actually take their time to read your message and type in their e-mail. This might be good enough for now because then you verify “what percentage of people care enough about being saved spending time sending e-mails back and forth to schedule a meeting” — and that’s close enough to the original hypothesis: “People are annoyed with having to send e-mails back and forth in order to schedule an appointment”.

Learn.

So is 6.29% a good conversion rate? Depends — did you just spam out your link to everyone or did you specifically target people who you would be absolutely sure would be in the target group. If you targeted only really busy people who you know would have to book a ton of meetings then you would expect a very high conversion rate. But if you sent it to the pupils of an elementary school then 6.29% is probably pretty good. The key thing in the learning step is to figure out if you have validated the hypothesis or not. This requires you to upfront set a goal for your metric. If you sent it only to busy people who you think is right in the target group, then you should probably set it to 50%+. If you don’t hit the target, you should re-evaluate what could have gone wrong. Why are people happily spending hours on writing e-mails back and forth to find a time to meet? Maybe the problem is just not as big as you think? Maybe people have concerns about you looking in their calendars with your app?

If you hit the target you’re ready to proceed in the next step in the feedback loop: Produce a new set of hypotheses and start all over again. Or maybe validating this value hypothesis is good enough to start actually building the product?