Hacker News new | past | comments | ask | show | jobs | submit login
Sell it before you build it (venturehacks.com)
91 points by dcurtis on March 28, 2009 | hide | past | favorite | 32 comments



I think if you have good sales (or sales oriented) people on the team, you probably already are selling before you build, regardless on what stage the company is in.

As developers, we'd often complain about sales people selling features we haven't yet created. Only after learning about Steve Blank's Customer Development approach I realized that's how it's supposed to be. Sales people are the ones in contact with the client, and incoming revenue is the signal the real world is giving you on the value of your product.


To be fair, developers complain about salespeople selling features that don't exist yet and promising delivery by a certain date without consulting us. That kind of thing makes our lives hell and makes us write terrible crap that undermines all of the company's software assets.

Selling features that don't exist is ok, just check with the guys that have to deliver on your promises first.


I know what you mean, I've been the developer in this scenario more than once :)

In the end it's a matter of balance between sales and development. Unlike the common "10 things you must do" stories on HN, there aren't really any well-defined rules for this. You just hope to have smart sales people and developers, good communication between them, and have neither side controlling the company.


This is a really interesting idea, but I'd like to see more examples with some actual data. For example, how many people check the box? Of those, how many actually sign up when the service is available?


This is pretty standard advice actually. The reason you don't hear more about it on HN is because most of the case studies are B2B startups, and HN seems to be less interested in those. The obvious example that comes to mind is DOS.

Another good example is a guy I met who started a business putting pro sports logos on car seats. First he went to the national retail chains and got them to order a hundred thousand units. Then once he made the sale he used it to get the rights from the sports leagues to use their logos. Only then did he go out and find a manufacturer, and by then he was already guaranteed to make money on the deal. So his only startup costs were a couple weeks making phone calls, and he made a ton of money.


'Sell before you build' is an old saw, but the 'coming soon/contact' landing page metric I had not heard before, and its great because its a very simply algorithm for developers to follow to arrive at a successful product.


We're currently doing this for EtherPad. We added a "pricing" tab to our homepage, but we don't have any prices yet, just a sign up form. So far (2 weeks in), about 100 companies have signed up to hear more about our for-sale version.


As someone who has been interested in paying for a SaaS or Hosted version of Etherpad since January it's been annoying.

Because I plan to use it with my customers I knew I wanted to pay for a supported SaaS/hosted version. I have been surprised that we have been unable to have any meaningful discussion about it. I know that one interested user doesn't constitute a market, but I was dismayed with the lack of meaningful engagement beyond we will notify you when it's ready.

I think the part that's was left out of the Venture Hacks article was when someone tells you they want to buy it, have a conversation with them to understand how they plan to use it and how they value it (what are the alternatives that they are comparing it against).


This is very common in the apparel industry. You make a few samples and a catalog, then see which stuff in the catalog gets the most interest before having it manufactured.


This happens a lot with chips: you will generate a set of "preliminary" data sheets for potential products and see which get interest. It allows you to have a conversation with a potential buyer that's more useful (or at least as useful as) starting from a blank sheet of paper and asking them what they want.


Take-home message:

Step 1) Build a brief, branded landing page describing the product, with a 'contact me when you ship' form.

Step 2) Gauge interest based on form responses. Only build if interest is strong.

Step 3) Edit product and reiterate.

Brilliant!


This was the first Cambrian House business model.

I saw two problems. First, you didn't know what to do with your metrics -- if changing a button from green to blue caused signups to go from 20/day to 25/day, which number indicates how much customer demand exists? Second, as pg pointed out, startups rarely get very far before figuring out there's actually a much better product for them to build that's about 70% different from their current one. At best, the site no longer is evidence of interest in the new product, you have to start it over. If you've taken pre-orders (the only way to reliably gauge interest) you may be committed to building what you sold.


There's another important step:

Drive customers to the site AND make sure they are the real market your targeting before taking their feedback.


Good points. I've "expressed interest" in a bazillion things, but I'm loath to part with money. I sign up for information announcements and beta sites because I'm simply curious about stuff, but I may not be a good customer when you get to the bottom line.


This is an old trick out of the direct marketing handbook, BTW. Direct marketers would send out mailers for lots of different products, asking people to respond if they were interested.

They then gauged market demand by the response rate.

I think this technique might actually be illegal when done over snail mail nowadays.


In B2B sales there's also a significant gap between "interest" and "purchase". You have to be able to tell how much one implies the other.


I think that in general, these sort of tests need to be seen as early probes, not absolute measures. They might be better in a relative test:

"Should I build this or this?" rather then "Should I build this?"


To take this to an extreme, you could simply ask people - off or online - "Do you ever have problem x?" implicitly asking about the problem your product will solve. The more responses you get, the more you'll know you're on to something.


I loved this article. We're doing exactly that with our B2B product for NewsCred. Just getting it out to and seeing who's willing to pay for it, what people think of current features, but also to prioritize the medium term feature roadmap.

This all fits quite nicely with Steve Blank's Customer Development methodology/framework.


That looks like give it away before you ask for money for it. The checkbox is interesting though.


If nothing else, you've got a list of hot sales leads. And if you've got halfway decent analytics, you could figure out that, say, people who come to the site through a google ad are more likely to check the box than those from TechCrunch (or whatever).


Additionally they can display different combinations of features for the bullet points and prices each time the page is looked at and see what generates the most interest.


This was one of the steps mentioned in 4 hour workweek, although this example is a little different. I don't like the book in general, but you can cherry pick some of the cool strategies like this one.


I sort of find this idea quite weird. In this case it is interesting to note they already have a product, all they are doing is pre-selling a pro version. But when you try to apply this strategy to a new product being created, your focus often gets diluted. And if you are asking what customers want, you risk to get overwhelmed by their requests. So, it is better to sell after you have a actual (no matter how minimal) product. Frankly, I don't see a point in pre-selling, do you?


The question is what is the simplest or most basic product that people want to buy. If you don't merge all of the feature requests, but pick the smallest subset that prospects tell you that they will pay for, you are less likely to get overwhelmed/diluted. Once you know what the minimum feature set is you are more likely to be able to develop it, and if you have pre-sold it there is much less risk than you have developed something that you love that no one wants.

"Frankly, I don't see a point in pre-selling, do you?" If you have ever developed something that no one (or too few) people wanted to pay for you may get more cautious about developing something without assessing customer buying interest first.


Yes. You'll build the wrong thing. Something nobody wants.


Or you would never build the right thing, because all your time is consumed in selling the thing that is never made.


You aren't just selling, you are learning.

You are very unlikely to get it right based on a hunch without multiple iterations with real customers. That means that you will end up iterating whether you build it or not. So its best to first iterate without building: you get more iterations and less wasted development that way.

As the interview explores, that doesn't mean building nothing, but it does mean validating an idea first and foremost.

I understand that this can be frustrating for a developer. We tend to think, 'if we build it, they will come' and we don't like sales. But personally I've wasted too much time building elegant software... nobody much wanted, to build new stuff without validating it first.

If you "don't get" this interview, I would suggest a second listen. It contains a critical lesson.


Worst case is you realize you don't have time to finish it quickly, so you buy it from someone else and sell the customers that to keep them happy while you work on the 'real' product.

I realize this approach will probably be hated on by the HN community, but for a certain set of products, it makes perfect sense.

I'll add one more thing:if you guys were selling hardware, you'd have a much greater appreciation for this technique!


Build for long term growth.


Go fliggo!





Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: