Who this is for: hackers who have an in-depth understanding of the important problems their customers have. (If you’re not sure about this, read Why only fools write code first.)

Why you should read it: so you can figure out what to build, and have customers commit to pay you money before you write a line of code.

Once you understand the specific problem you’re solving, have a sense of why prospective customers want their problem solved and how much it’s worth to them, it’s time to validate your idea by finding the smallest solution possible that your customers would pay for.

This does not mean you should start writing code.

Remember: your goal is to NOT WASTE YOUR LIFE. There are faster ways to figure out how to validate your solution is worth paying for than writing code.

I’ll briefly touch on some of the downsides and upsides of delaying writing code, since changing the way you do things is rarely easy.

Then I’ll talk about how we validated our solution at SocialWOD, and got commitments from customers to pay us before we wrote a line of code… and how YOU CAN TOO.

The Hard Part About Delaying Writing Code

The downside of talking to customers first is that it’s out of your comfort zone, and sometimes it’s just a pain in the butt. Scheduling, missed appointments, etc take time. It can be tough to paint a complete picture of what customers want with qualitative data. In some respects, it’s the opposite of code: messy and uncontrollable. It can seem like you’re not making progress, because you’re used to progress meaning new features.

During this process we were tempted to say “screw it” and hit up Textmate to start banging out code, but we resisted that temptation, having gone down that road in the past only to waste our lives building something few people wanted.

Dealing with the downsides takes practice, discipline, and emotional energy. It’ll feel painful at first, but once you’ve gone though it once, it’ll feel a lot more comfortable.

The Upside Of Delaying Writing Code

You only build stuff people want, ergo, you don’t waste the most scarce resource you have: your time and attention. You have commitments to pay you money before you launch. You push your comfort zone and become a more powerful hacker than you once were. You come closer to controlling your own financial destiny.

If you’re not in this to learn more, build something people use, and / or make more money, what are you in this for?

Figure out Problems, and Then Find a Solution

The whole time you’ve been speaking with customers, you should be hearing recurring themes about problems they have. Until you truly understand their problems, you don’t truly understand the key parts of a solution that will solve their problem.

When we were building SocialWOD, we talked to 20-30 gym owners about the key problems they have with their business before we knew enough to build the smallest solution that could possibly be useful (i.e. worth paying for).

Once you understand your prospective customers’ problems is when you use your 1337 hax0r skills to figure out how you can solve their problems in an elegant way using technology.

A solution for our customers

At SocialWOD, we kept hearing that gym owners biggest problems are classic ones that almost every small business has:

1. Getting more customers
2. Keeping existing customers
3. Saving time

When we combined that with our CrossFit industry knowledge, we figured out that we could build a workout-tracking tool that would help gym owners with *all* of their problems (this is one thing I’ll change about my next business – our app is less attractive than one where the value prop has one clear benefit, i.e. “Use this and you’ll get N new customers a month”, or “Use this and you’ll cut down churn by 25%”).

A brief digression on how CrossFit works so you’ll grok our solution: every CrossFit gym around the world has a whiteboard. When you go into a gym, the workout of the day (or WOD), is written on the board. You do the WOD, and then write your name and score up on the board. Since you can’t see progress without tracking, athletes track their scores using – gasp – a paper training log kept at the gym, or a web or mobile app. We learned 10-20% of athletes care enough to use a web or mobile app – the data geeks and hard-core athletes.

With some secret sauce on our end, we figured out how a gym owner could snap a photo of their whiteboard at the end of the day, email it to us, and we’d put every athlete’s data online for them to use.

By having every athlete’s data tracked, SocialWOD could do things like:

1. Show *every* athlete AND gym owners an athlete’s training log and progress, without them having to do *any* work (other than, you know, the workout 🙂 ). Athletes get to see charts and graphs detailing their progress, and gym owners can help people along and congratulate them when they make big gains. (or, “Keep existing customers”)
2. Alert the gym owner know when an athlete hadn’t been to class in 30 days (if their name isn’t on the whiteboard they didn’t attend class). He can give the athlete a call to make them less likely to churn out (the LTV of an athlete to a gym owner is, depending on the monthly price an athlete pays, $1500-2500. So it’s worth it to make those phone calls).
3. Boost word of mouth marketing by posting athletes’ scores to Facebook for them (which CrossFit athletes already do anyways – we’re just making it easier by doing it for them)
4. Automatically post a gym’s scores to their Facebook page and blog, creating a stronger center of gravity around the gym’s communities outside of the gym (community is a HUGE part of CrossFit)

So! That was the big vision.

The Smallest Solution Worth Paying For

But instead of building that, we wireframed the core of app, along with parts of the bigger vision that we thought would be valuable to gym owners.

We hypothesized that the smallest thing that could possibly work was these two screens:

One we had these wireframes, we set up Skype calls with the folks that had shown strong interest to see if we were right.

In those calls, we:

• Validated their problems to make sure we were on the right track (“we found that most gym owners were looking to get more customers, keep existing ones happy, and do it while saving time. Does that sound right?”)
• Showed them the two key wireframes, and the other ones that would come “at some point down the road” (use Adobe Connect or join.me for dead-simple and free screen-sharing)
• Asked if “they could imagine using something like this at their gym” (or if they obviated the need for that question and asked us about pricing right after the wireframes, implying that this was something they’d use), we tested out pricing and asked for a commitment: “Pricing will be based on how many athletes you have at your gym. It’ll likely start at $50/month for 1-50 athletes and go up from there. We’re offering discounted pricing of $30/month to those who commit early, and we’ll start building once we get a certain number of commitments.”

We had decided not to start building until we got five commitments to pay – this was the validation we needed that we had solved a valuable problem. We ended up getting closer to 10.

Five was good enough for us to start building, but it might not be for you: choose a number that gives you a sense of whether you’re accurately validated your problem & solution.

These customers (“earlyvangelists” in the Lean Startup nomenclature) bought into the large vision, but decided that a two screen SocialWOD was worth paying for. Since we launched in late July 2011, we’ve regularly added features to fulfill the product vision, making it attractive to customers who need more features for them to try it.

Aside: keep in mind you may not get a positive response to your solution. In this case, you can integrate the feedback and iterate on your solution, and/or go back and better understand the problems your customers have.

A friend mentioned to me “I’d feel guilty building a two-screen CRUD app and charging people money for it!” I know what he meant, but also realized that as developers, we sometimes get caught up in the code and lose sight about what a business is supposed to do: solve a problem valuable enough that people pay you for it.

What Next

Even though you know what to build, there’s a couple more things you should do before you start writing code:

1. get a sense of the financial mechanics and potential upside of your business
2. figure out how you’ll acquire customers

I’ll cover these subjects in the next two posts.