Why only fools write code first

Who this is for: developers who have an idea.

Why you should read it: so you don’t waste your life by building something nobody wants.

I have a confession to make: I’m 35, and until last year, I started building companies by creating a product.

Last year, when starting SocialWOD, my biz partner Ryan refused to write code without first talking to 20+ customers and getting commitments to pay us money for a solution to a well-defined problem of theirs.

Having gone down the “build first” path enough without significant success, I was up for trying a new approach. Conceptually it seemed to make sense that we’d be able to better solve our customers’ problems if we understood their problems better.

To boot, we decided not to build until we had verbal financial commitments from customers for our proposed solution.

The result? We were able to charge money from day one for a two-screen CRUD app. We were able to do so because we had honed in on a specific problem worth paying for, and we had financial commitments before we wrote a single line of app code.

Read on for some of the hard-earned lessons that’ll help you grow your biz.

Don’t build first

Building first puts you at a disadvantage. Here’s why:

Your job as an entrepreneur is to increase the odds that your business will succeed. Put another way, your job is to reduce the risks that prevent your venture from succeeding.

There are several types of risk that can kill your company.

Big ones include (but aren’t limited to):

– Team (are we the right people to execute) – Market (do people want to buy it) ← usually the biggest risk – Technology (can we build it) ← most hackers start here. Oops.

I’m gonna talk about why most hackers start reducing the technology risk (by building a product) when they should start by reducing the market risk.

And I’m going to give you a script you can use in interviews to learn more about the market side of your biz.

Why people start with code

If you’re a developer, writing code is the fun part. Code can be bent to your will to do what you want it to do. You know when it works, and when it doesn’t. It’s clean.

People have an innate desire for control, and code can be controlled.

Code is your comfort zone, so it’s what you (and I!) fall back on.

But since you can build almost certainly build the solution, it’s almost always the wrong place to start.

Where you should start

“A hacker who has learned what to make, and not just how to make, is extraordinarily powerful.” – Paul Graham

You should start by understanding your market.

This is vague. More precisely, you should understand:

• who your customers are
• the specific problem your potential customers have
• why this is a problem for them
• how painful this problem is for them
• what happens when the problem is not solved
• how they are currently solving this problem, and what else they’ve tried
• how much this problem, when solved, is worth to them
• how they find out about solutions to this problem
• the words your customers to describe this problem

The best way to do this is by talking to real live people: picking up the phone, going out to coffee, etc, asking good questions, and listening.

For most hackers, talking to customers to figure out their unmet needs is scary, and always messier than code. It’s out of your comfort zone.

The rational response is “Righty-o! Talk to customers first – that makes sense.”

The emotional response is “Oh shit. Who should I talk to? What should I say? Won’t I just be better off building this feature?”

The way I overcome this emotional trauma is to think about the insights I’ve gleaned from talking to customers in the past, and more importantly: how much time and frustration these conversations have saved me. Hackers hate working on stuff nobody uses.

Really, it’s simple: the fastest way to build something people want is to understand their problems. And the fastest way to understand their problems is to listen to what they have to say.

OK, how can I go about talking to customers?

Find some potential customers.

I may go into this in a future article, but finding a few individual customers in your market should be easy.

What should I say?

Here’s an template of an email we used at SocialWOD when referred to potential customers (we make software for CrossFit Gyms)

Hi First_name,

I spoke to referrer_full_name at referring_gym_name recently.

He said you might be interested in sharing some insights about problem_we’re_solving, and hearing about what we’ve learned talking to your peers.

I’m not trying to sell anything – just looking to learn about your business’s problems so I can build something that helps you grow your business.

Cheers,

your_name

The keys to this email are:

• You’re promising to provide value (share some insights)
• You want to help them grow their business
• You’re not selling anything

Smart Fast Startup has a great cold-calling method to validate whether your idea solves a problem that people want to pay for.

This should get you a few meetings.

What to say in your meetings

Your goal with these meetings should be to hone in on answers for each of these:

• who your customers are
• the specific problem your potential customers have
• why this is a problem for them
• how painful this problem is for them
• what happens when the problem is not solved
• how they are currently solving this problem, and what else they’ve tried
• how much this problem, when solved, is worth to them
• how they find out about solutions to this problem
• the words your customers to describe this problem

Let’s say you had an idea about product for movie theater owners that would pipe buttered popcorn (and other) smells into theaters to help drive concession sales.

Here’s the sort of questions I would ask a theater owner:

Q: Tell me about your business. What are your biggest problems? What keeps you up at night? Why?

Trying to learn: What are the big problems they have in their biz? Why are they problems? What happens when those problems aren’t solved?

Q: What are the key metrics that drive your business? Trying to learn: What are the key levers in their biz – concession dollars per ticket sold? Straight up ticket sales? etc. Is your solution potentially a must-have or a nice to have?

Q: (if they don’t mention concessions) What impact do concessions have on your business? Trying to learn: Is your solution even potentially valuable to them? How much, or why not? (Make sure you understand this. Keep unpeeling the onion; make sure you understand this fully. Try not to make assumptions here.)

Q: Have you looked at anything to help you with this problem? How have they worked for you? Where did you find them? Trying to learn: Learning what else is out there? Are those solutions working, or not? What distribution channels might you need to be in?

Q: I have some ideas about products that might be useful. Can I give you a 1-liner description and you tell me if we’re crazy or may be on to something? Trying to learn: This is to get a sense of whether your idea may even be valuable to them… you don’t want to get into specifics really, just tease them and get high-level feedback.

Also ask:

• Is it ok if I follow up as we develop our ideas? (I’ve never had anybody say no to this)
• Is there anybody else who you think we should speak to who have the same kinds of problems you do? (these are the people you call next)

The goal with these interviews is to listen and learn, not to sell. Learn where you’re right, where you’re wrong, what words your customers use, what big problems they have, and how you can adapt your solution to solve those problems.

After a couple interviews you’ll be able to provide insight and become valuable to the people you’re speaking with, which makes you even more trusted (“oh we just spoke to person XYZ at ABC corp… he was feeling the same pain, you’re not alone!” OR BETTER “just spoke to XYZ at ABC… he solved the problem you’re facing by doing 123”.)

And after 10-20 of these you’ll know a crap ton more about your market, and whether this is a problem even worth your time.

This process isn’t easy. But recurring themes will emerge that will help you hone in on a problem worth solving without writing a single line of code. The reason you do this first is because you need to do this whether you write code. You might as well do this before you spend a few months writing code, so you can figure out what to build.

Now that you better understand the problem and market, the next post will cover what you can do with that information (hint: it’s not “build the product”).