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:
- You’re promising to provide value (share some insights)
- You want to help them grow their business
- You’re not selling anything
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”).
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.
Glad you enjoyed, Chris. And good suggestion re: the live chat button. Appreciate it!
Pingback: andré nosalsky » Why only fools write code first
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.
Awesome to hear, Paul!
Pingback: How to get customers before you start writing code : Kareem Mayan's Blog
Pingback: How much money will your idea make you? : Kareem Mayan's Blog
Pingback: Software Marketing Tweetables 27 August 2012 | Smart Software Marketing
Wrote something similar this morning! MVP is about not wasting your life – great parallel here, thanks for writing this! http://istommydrunk.svbtle.com/mvp-is-about-not-wasting-your-life
Pingback: Why only fools write code first | Rocketboom
Great post, Kareem.
Thanks Andrew.
Pingback: Why only fools write code first | Enjoying The Moment
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
Great article. If you had an email list signup at the end of it, I would have used it.
Inspiring post. Nice one.
I’m working on one more, easy way of finding and interviewing potential customers clientcrowd.com
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.
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.
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.
Pingback: Building Stuff That People Want: The Lean Startup Approach
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.
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!
Great advice that I just followed to the letter. Cheers.
Pingback: Sell it before you code it | Wello !
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…
Fantastic post! Wish we had of seen this when we first began our Customer Development. Really helpful questions and examples. Thank you!
You bet, thanks for reading!
Pingback: Tech News Weekend Reading 11/2/13 | Tech News Condensed
Excellent point. But no matter how many times you repeat it; most of the funded startups today are still product or code-driven, not market-driven. The bubble continues to grow…
Pingback: Sólo los tontos se ponen a escribir código lo primero de todo | Luis García de la Fuente
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.
Glad our experience was able to help you recall what you already knew works =)
Pingback: ege rambles here
Good Article !
Pingback: Vu sur internet : Why only fools write code first | sashock blog
Pingback: 10 examples of fabulously flawed product-first thinking : CloudAve
Kareem, great post. We met a long time ago through Dowds. Your post reminded me of my latest project 20Skaters keep up the good work, if you’re ever close to Toronto let me know?? We’re talking the same talk in our coworking space here at ThreeFortyNine
If only Jack Dorsey read this article first!
Pingback: Software Marketing Tweetables – 18 November 2013 | Smart Software Marketing
Pingback: BobbyVoicu.com :: [ToRead] Why only fools write code first | Kareem Mayan's Blog » BobbyVoicu.com ::
Pingback: Biz dev first, code second | Burato.net
Pingback: Mobil Uygulamalar İle Para Kazanmak - "50.000 kişi 1$ verse..." | Koddit
Pingback: Empastillados I - Startups Lawyer - Recursos y Reflexiones Legales-Corporativas para Inversores y Emprendedores Exigentes.
Pingback: 2 razones por las que tu idea podría ser un obstáculo para crear un gran negocio.
Pingback: Why only fools write code first | Good Reads