Monthly Archives: March 2012

How to get paying customers before you start writing code

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 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.

How to use Stripe when running a Canadian Company

If you don’t know Stripe, you should. They’re the easiest way to bill customers with your web app.

Ryan and I run SocialWOD out of Vancouver, Canada, but Stripe’s not available in Canada yet.

So we use Paypal.

And we hate Paypal.

I’ll spare you the play-by-play. But we’ve been rejected twice for Website Payments Pro with no explanation, getting our Paypal account connected to a bank account has been a nightmare, and to add insult to injury, the Paypal sales team continues to send us email to buy their products.

Things got so bad with Paypal that Ryan forwarded Stripe one of our email chains with Paypal as comic relief, exhorting them to get to Canada soon.

We didn’t want to get set up with another Canadian payment processor as we’d just switch to Stripe when they launched in Canada, so we decided to see if we could get set up with them today.

Turns out we can, even though we have a corp registered in Canada, not the US.

There’s one caveat though: you need a Social Security Number. So if you haven’t worked in the US, I think you’re out of luck.

Here’s how to do it (the usual caveats apply – I am neither a lawyer nor an accountant, so please get your own advice):

1. Get an Employer Identification Number from the IRS.
You can do this over the phone (phone number at link above) and the actual process takes 5-10 minutes. They’ll give you your EIN over the phone, but they also mail you a paper copy of your EIN which will take a couple weeks to get to you. (Also, to avoid paying US taxes, you’ll need to file a W8-BEN form. But you can do that later.)

2. Apply for a US bank account.
You can do this over the web at Harris Bank, a subsidiary of Bank of Montreal. A lot of US banks make this difficult – you have to go to a physical branch to open the account – but Harris lets you do it over the web. Plus, they’re used to dealing with Canadians who want to open US accounts.

You’ll need:

  • Articles of Incorporation
  • EIN (paper copy) <-- This takes a couple weeks to get to you from the IRS
  • Valid form of ID for each signer (driver’s license, passport, etc.)
  • Proof of personal address for each signer (utility bill, bank statement) issued within past 90 days
  • Proof of business address (utility bill, bank statement) issued within past 90 days
  • Verification of deposit (signed by a signer and banker) <-- Harris will send you this form
  • Mother’s maiden name for each signer
  • Home phone for each signer
  • Social insurance or social security number for each signer

2a. If you don’t have a US mailing address, get one.
You’ll need one for the next step.

3. Sign up for Stripe.
This is where you’ll use your US address and Social Security Number.

4. Be ecstatic about working with a company that cares about its customers and is easy to use.

I ran this by Stripe and John Collison (one of Stripe’s founders), replied:

Yeah, with this you meet all the requirements to set up an account
with Stripe, so we’d love to have you aboard!

Hope this is helpful – we’re waiting for our EIN to arrive so we can SAY GOODBYE TO PAYPAL!

Why only fools write code first

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.



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:

QuestionTrying 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”).

The most valuable lesson I learned from a VC

In 2008, I left FOX Interactive Media to join up with Jon Bischke to start eduFire.

It was the first foray into running a venture-backed startup for both of us, and we made a lot of mistakes (I’ll talk about some in another post.)

In the course of raising a $500k angel round, and laying the groundwork for an institutional round (which ended up being ~$1.2M, led by Battery Ventures), we spoke to a crap ton of angels and institutional investors in LA (where we were based) and the Valley.

Four years later, one meeting in particular stands out.

It was with Mike Maples, who despite being fairly new to investing in the Valley, had invested in companies like Twitter and Digg.

He was a nice, humble, and smart guy. It was one of the most valuable meetings we had, for a lot of reasons. You’ll see the biggest reason in a moment.

We pitched Mike on our idea: eduFire was an education marketplace, where you could find teachers of any subject you wanted to learn. Students would be able to learn from experts, and teachers would be able to earn a lot more than they currently did.

“Education,” we said, “is a $1T market. Yes: trillion.”

The most common response we got from investors was “that sounds interesting, but I don’t know much about education…” (Turns out we were early – education is so hot right now, but it wasn’t in 2008.)

Mike gave a similar response.

But then he said something interesting.

Something like:

“You know, I heard about a really interesting company the other day. They’ve approached building their business in a really cool way. They started by identifying the riskiest parts of their business. Then they tested their theories about how to reduce those risks in the real world. They’ve been at it for a short while, are learning a ton, and have removed all kinds of risk from their business. It’s based on a book called Four Steps to the Epiphany. Have you guys heard of Steve Blank…?”

The company was IMVU, co-founded by Eric Ries. Ries has gone on to write a book and lead the Lean Startup movement, based on his experiences growing IMVU.

After the meeting, Jon and I briefly discussed this crazy new risk-reduction approach. We never acted on it, other than trying to get through the dense and academic Four Steps to the Epiphany. Continuing to build was a much more fun and comfortable route to take. (And I’m still not sure why we didn’t ask Mike for an intro to Steve or the IMVU guys – Jon and I both like meeting, learning from, and helping smart folks. Life might have taken an even more interesting turn had we made one of those connections.)

Mike passed on eduFire, we closed our angel round, and continued on the path of building our vision.

I left eduFire in 2009, and after raising their round from Battery, it was sold in 2010 to a company that wanted the tech.

That meeting with Mike stayed with me, though. It took a few years – and a few more “let’s build the vision” approaches and ensuing failures – before the lesson that you should identify and reduce a new venture’s biggest risks FIRST was driven home.

This is one of the valuable lessons about building a business that I’ve learned along the way, but there are many more. (It’s also where this blog’s tagline comes from: “I’d rather learn I’m wrong than waste my life.”)

It’s almost like when I started eduFire, I had a heavily pixellated mental map of how to grow a successful business. It looked something like this:

It’s gotten sharper over the years, and it’s my hope that by continuing to run a business (SocialWOD), help others run theirs, talk to people smarter than I, and share the lessons I’ve learned, my – and your – map will come to look more like this: