Why only fools write code first

45 Replies

Who this is for: hackers 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

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:

  1. You’re promising to provide value (share some insights)
  2. You want to help them grow their business
  3. 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:

Question Trying to learn
Tell me about your business. What are your biggest problems? What keeps you up at night? Why? What are the big problems they have in their biz?
Why are they problems?
What happens when those problems aren’t solved?
What are the key metrics that drive your business? 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?
(if they don’t mention concessions) What impact do concessions have on your business? 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.)
Have you looked at anything to help you with this problem? How have they worked for you? Where did you find them? Learning what else is out there? Are those solutions working, or not? What distribution channels might you need to be in?
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? 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”).

Get more actionable tactics to grow your business

       

45 thoughts on “Why only fools write code first”

  1. Chris

    Hey great article and I’ll be using some of these outlines when researching my next idea. I checkout out your website, socialwod.com, and had a suggestion to move the Live Chat button down 40 pixels or so, so that it doesn’t overlap your logo. Site looks great, best of luck with it.

    Reply ↓

  2. Pingback: andré nosalsky » Why only fools write code first

  3. Paul DeJoe

    We got this advice from Kareem personally about 6 months ago. I can tell you, it was some of the most valuable advice we’ve ever received and we followed it to a product that had customers waiting for it. One thing I’d add to why this is a great strategy is that you’ll be able to see the body language and personal frustration with the problem you are trying to solve when you talk to potential customers. You’ll soon see if your message is off, your product is off or if it’s the huge market you thought it was.

    Reply ↓

  4. Pingback: How to get customers before you start writing code : Kareem Mayan's Blog

  5. Pingback: How much money will your idea make you? : Kareem Mayan's Blog

  6. Pingback: Software Marketing Tweetables 27 August 2012 | Smart Software Marketing

  8. Pingback: Why only fools write code first | Rocketboom

  10. Pingback: Why only fools write code first | Enjoying The Moment

  11. Gokhan Arik

    Great article! This article explains very well why most of startups fail. I am impressed how you reached customers(actually potential customers) and asked their opinion. I will use that technique in my career. Thanks again and good luck in your future projects

    Reply ↓
  14. Andrew Thompson

    Love the honest and practical post Kareem. Its amazing how easy it is for the default to be “write code” first instead of figuring out if you’re anywhere near product/market fit.

    Reply ↓
  15. Seth Eheart

    First of all, thanks for sharing your thoughts and knowledge. While I generally do agree with parts of your post, I would argue that the opposite still holds true. Sometimes its better just to get your product out into the wild and let users drive its evolution. You have a lot of great advice for people seeking to refine their strategy pre-development, but I think about all the time and resources this would take in relation to just hacking something together and see how people actually use it. I think a constant within the start-up world is that people don’t know what they want, rarely can ever accurately express what they want and don’t know their true need. Again, just my thoughts, but I believe it’s really dependent on the space.

    Reply ↓
    1. kareem Post author

      Thanks for the comment. In my experience if you’re trying to optimize for success before you run out of money, building first rarely makes sense. You end up trying to find a market for an existing product, which is a lot harder in my experience than finding a market for a product that doesn’t exist. The cost of changing your software when it’s a few sketches is zero, and it increases to a lot more than zero once it’s live.

      Reply ↓

  16. Pingback: Building Stuff That People Want: The Lean Startup Approach

  17. Nick

    Can you give examples of when this approach worked, or when building the product first failed? Or statistics on the general cause for failures?

    Almost all of the successful startups I know of built a product first, simply because the founder wanted. Apple, Microsoft, Google, Dropbox — some of these are famous even today for never doing user surveys.

    Your advice sounds reasonable, but so does the opposite. I’d want to see some evidence before I buy into them too much.

    Reply ↓
    1. kareem Post author

      Hi Nick, thanks for the comment.

      Couple points:

      First, Microsoft sold DOS to IBM before building it:
      http://inventors.about.com/od/computersoftware/a/Putting-Microsoft-On-The-Map.htm

      Second, other examples: Kickstarter.

      Third, history is littered with failed ideas driven by a “visionary” founder building out his or her idea. Apple, MS, Google, and Dropbox got as big as they did partially because of timing and luck. It’s dangerous to think of those companies as the canonical examples of success, because the odds you’re going to build one are infinitesimally small – it’s catching lightning in a bottle. The odds of building a 7 or 8 figure company are a lot better and have more to do with problem selection than timing / luck (though there’s still a lot of those involved).

      Fourth, user surveys aren’t really what I’m talking about; it’s more about getting a thorough understanding of the problem space as your customer sees it, so you can provide a solution based on facts, not assumptions. Apple, Google, MS (and probably Dropbox) are famous for doing customer research.

      Finally, if you don’t believe me, I encourage you to try both approaches yourself. Some say it’s a lesson one has to learn the hard way – I certainly did!

      Reply ↓

  19. Pingback: Sell it before you code it | Wello !

  20. brice

    Great article, I might use some of your insights to get to the bottom of the buz problems we are finding over here in my homeplace…

    Reply ↓

  22. Pingback: Tech News Weekend Reading 11/2/13 | Tech News Condensed

  24. Pingback: Sólo los tontos se ponen a escribir código lo primero de todo | Luis García de la Fuente

  25. Guy

    This is gold. Thank for sharing!

    I’m starting a business and have been struggling with this. My initial approach was to barge into a potential client’s store and start pitching the idea. They immediately went on the defensive which made me nervous and give a terrible pitch. I didn’t get very good feedback and I left the store feeling I should stick with my day job. Starting with the potential customer’s problem makes perfect sense.

    I honestly had a head slap moment when reading your article, because I already knew this approach works. I’ve sold knifes door-to-door in my teenage years, and I was most effective when the customer told me what their problems were, rather than when I would try to convince them of problems they didn’t have. And yes, a referred prospect is much more open to meet you than a complete stranger.

    Reply ↓

  26. Pingback: ege rambles here

  28. Pingback: Vu sur internet : Why only fools write code first | sashock blog

  29. Pingback: 10 examples of fabulously flawed product-first thinking : CloudAve

  32. Pingback: Software Marketing Tweetables – 18 November 2013 | Smart Software Marketing

  33. Pingback: BobbyVoicu.com :: [ToRead] Why only fools write code first | Kareem Mayan's Blog » BobbyVoicu.com ::

  34. Pingback: Biz dev first, code second | Burato.net

  35. Pingback: Mobil Uygulamalar İle Para Kazanmak - "50.000 kişi 1$ verse..." | Koddit

  36. Pingback: Empastillados I - Startups Lawyer - Recursos y Reflexiones Legales-Corporativas para Inversores y Emprendedores Exigentes.

  37. Pingback: 2 razones por las que tu idea podría ser un obstáculo para crear un gran negocio.

  38. Pingback: Why only fools write code first | Good Reads