A Lesson Learned as a Technical Founder: Sell First, Build Later | Hacker News Reader

A Lesson Learned as a Technical Founder: Sell First, Build Later

blog.framebase.io

107 pointsvu0tran41 comments

I think as a Startup you should spend 90% of your time on refining and validating the Problem Definition. Do as much as you can of that activity without even creating a single line of code. Since most probably you are solving a human problem, you should interact with as many humans as possible.

Lets be honest, unless you are creating a rocket or some really cool new technology, most Web Services/Apps can be implemented by anyone. YOUR job as Startup is not to reinvent the wheel for the solutions but live and breath the problem definition. After all it will be much cheaper and faster to fail if you have not built the product yet.

This is great.

This _sounds_ like great advice, and "I want to believe" too, but this article is not convincing. The way it's written, I just see some principles flatly stated and not even backed up with anecdote--it's not even a data point. The HN title "A Learned Learned..." contains the most indication that the OP is speaking from experience and not off the top of his head.

Forgive me for not knowing the OP, his experience/reputation, or his company and its product. I expected a bit more explanation for his position. Also, I'm a bit skeptical of the "refundable credit" for a non-existing service or product. I'd like to hear more about how that's possible.

While I agree that you should validate your ideas before spending copious amounts of time programming, I don't think that you should sell people on an imaginary product. Unless you already have an established reputation, it's highly doubtful that people will pre-order something on mere talk alone.

I think that it's a better idea to stick with the MVP (minimum viable product) model and iterate rather than try to figure out revenue and customers right off the bat.

A minimum viable product is one users will pay for. Otherwise it's not viable.

There's a difference between a minimum viable product and a minimum viable idea. It sounds like the OP wants to sell the latter before building the former. Or, as the saying goes, put the cart before the horse.

Nice distinction.

Could be that an MVI is any idea that can be used to secure funding, in which case it would put the concept in league with a rather unsavory brotherhood.

You can do a cheap prototype, mockup or wireframe.

If you can code, just code something simple you can test with minimal features.

Most failed sites and apps have way too many features that no one except technical founders and their 37 friends want.

True, but viable means slightly more than that. It's viable when the average cost of acquiring a customer is below the lifetime value of a customer.

I don't think you've been watching the discussions surrounding Kickstarter over the past year or two.

Talk itself (that is, marketing) can be a "minimum viable product". Enough to make sales. But I think that's more valuable in the Kickstarter world of making things you can kick. In software, the standard is usually (not always) higher. As a consumer myself, I'm a lot more willing to pay for the promise of a physical product, than to pay for the promise of software.

Uh. A lot of Kickstarter projects are for things that are intangible. Like software.

That totally depends on your market. I understand that many programmers are uncomfortable with selling stuff that doesn't exist yet, because to them it feels fraudulent. But there are a lot of ways you can get around that feeling and leave customers feeling happy.

A good example is Kickstarter. People sell imaginary products on there all the time. And this has gone on in the software business for a long time. Microsoft, for example, got their start selling a product that didn't exist:

http://en.wikipedia.org/wiki/Microsoft#1972.E2.80.9383:_Foun...

I think that approach was a little dubious (although it's hard to argue with the results), but I'm perfectly happy with Kickstarter. For me, the difference is that with Kickstarter they're being honest.

There are also things you can do that are in between. For example, the landing page that talks about a "coming soon" product is fine by me. As is a guerrilla user test where you have people look at several things, some of which are products that don't exist yet. Or getting your clients to sign a letter saying, "If you build X, we will pay you Y for it."

And honestly, people do order things on talk alone. A lot of enterprise software starts out that way. It seems crazy from a programmer perspective, but if you're running a business you frequently make small bets on new suppliers to see whether they can deliver. And sometimes large bets if they have something you really want.

I was writing about just this tension recently... http://www.baqbeat.com/2013/04/27/the-product-is-the-marketi...

This is great advice, does anyone have some resources on how to pre-sell or pre-validate a product without much to show? I mean, I've always tried but if you describe something to someone and say "do you want this? Will you pay $20 for this?" they always say, "cool! sure!" and then don't answer when you come collecting product in hand.

patio11 has a good description on his site kalzumeus.com of how he market tested Appointment Reminder before he sold it to his customers. Sorry, don't have the link on me, but his whole site is pretty chock-full of good advice on selling software. Going through his lifecycle email course now, learning a lot.

IIRC he has stated that he misjudged the demand for Appointment Reminder and ended up selling less than he had hoped.

Here's the meat of it, reposted from an HN comment since it is my most succinct account of the story:

A spiritually similar example: Appointment Reminder didn't actually exist in summer 2010, but I had a two-page demo of it set up. I got $400 out of an ATM when I went home to Chicago to visit, and just wandered around the Gold Coast/Magnificent Mile region of the city looking for every hair salon and massage therapy practice I could find. I asked them all if I they took walk-ins and, if so, could I have 30 minutes of the owner's time for whatever the rate was ($30 or so). In lieu of the shoulder massage/etc, I said "I'm interested in the massage therapy industry. Would you mind if we just chatted for half an hour about it?" And I asked about how they handled scheduling, appointments, no-shows, etc etc. I also did a demo of my two-page AR mini-app on the iPad and asked if they would be interested in buying it when it was ready. I think only one person actually accepted my money for the interviews. I got five-ish "Please tell me when that is ready" out of a dozen or so conversations. No Bay Area or signup form required. (I put their emails in a paper notebook. And lost it prior to launch. Whoopsie.) This was mostly successful for me: it confirmed that there was a market willing to pay for AR without me needing to actually build it to demonstrate that. (My sampling technique, which found only massage therapists/hair salons, did sort of lead me off the rails as to who I'd eventually end up targeting for most of the business. D'oh.)

The basic premise is you set up a landing page that sells your product or service, and after someone clicks "buy" "add to cart" or "sign up" you count that as a conversion.

Drive initial traffic to test via PPC in order to avoid social bias.

Sure, but what are they buying at that point except an empty promise?

Or are you just getting them to click buy, only to arrive at a "Not yet open for business" shopping cart?

You could do the "not yet open for business". That's a little rude.

The polite thing to do is say, "Great! That product isn't ready yet. We'll contact you when it is. What's your email?"

Or you could say, "Hey, we're still working on this. Could we contact you to find out what's most important to you about this product?"

Another option is just to flash an error message and redirect them back to Facebook or Google or wherever they came from. They will pretty much instantly forget about you: things are broken all the time on the web. That's kinda lame, though, so I'd generally lean for something that invites further engagement.

Another option is the concierge delivery method. This works for some ideas better than others. Eric Ries (and many others) go into greater details. Basically, you manually deliver the service. So, if you were a grocery delivery service, maybe you would find some potential customers and have them submit a Wufoo form with their grocery order and then you would fulfill it. Skillshare did this (http://www.mikekarnj.com/blog/2011/08/01/how-to-launch-your-...).

A corollary for today's frothy times:

  1. Put together team
  2. Sell: get acquihired
  3. No need to build anything later

we definitely experienced this at matchist, and it has made us waste valuable months. now, we don't build ANYTHING unless at least 3 customers request it and unless it will affect the bottom line (no fancy feature upgrades)

If you, like a lot of the startups outthere , are going ot make another better shopping, better video sharing, or better... whatever service/product then by all means, do that. But I bet you nobody who ever did anything original did that first. Because by definition if you want to come up with something new and different, people will invariably say No until they can actually touch it and feel it. After that they may or may not say yes, but definitely not before.

Does advice like this apply in some way to personal/career development?

I would like to break in to a particular technical field. I believe that to work in that field, I'll need to demonstrate some measure of experience in that field. To that end, I'll need to build. This feels like a 'build first, sell later' kind of approach.

Or should I tip the scale toward 'selling' myself on the basis of my other useful experience, and build my expertise on the job?

IMO - you have to always sell first in everything you do... yes we want to build first to prove first... but convincing someone else you are capable is the first thing to be done... assuming you can really do it - if you don't sell first no one will give you the chance...

Before even delving into development beyond the internal spikes, put together your business model! You should have a pretty good idea who (and how numerous) your customers are, how much they're willing to pay, and how to reach them. Once you have those, you have some revenue numbers. From there, you can extrapolate at least a rough outline of a business plan.

If you can't figure out who the customers are or what they'll pay or how to get them to pay, then maybe you're sitting on a nice open source project instead. Lack of a business objective doesn't mean you shouldn't do it, but maybe it means you shouldn't try to make a living from it.

After our first failed startup due to a lack of costumer interest we didn't even touch a text editor until 120 customer interviews. We wanted to be damn sure the problem we were attempting to solve was an actual problem.

During this search process we built out our business model canvas making the necessary changes along the way. Each week we focused on a certain section of the canvas and challenged those assumptions against what our customers were saying.

This is at its core tremendous advice... But let me temper it: don't sell, validate. In many applications sale risk is cheap enough (customers forgiving enough) that sales-as-validation is ok. Sometimes it sets up really bad expectations, though.

It's easy enough to validate without selling: just don't take people's money. It's less valuable than sales since you can't be sure people are making accurate financial decisions until you have their money, but it's both dramatically better than sitting in isolation coding and carries very low social risk.

I really think its worth re-reading Venkatesh Rao's "Entrepreneurs are the new Labour" and his dissing of the Lean Startup movement (tldr - it's a great way for in estors to have control / viaibility over many more compliant startups than if entreprenuers really had peer power.)

Yes, go validate your assptions, get out of the building. But decide where your exit is, where your talents lie and how much is the opportunity cost.

Excellent advice. Quite often when technical founders aren't quite sure how to go about the validation process, we tend to double-down on development. Instead the exact opposite is what seems to work best; get out there and talk to people you think need your painkillers.

It also helps to be your own customer (or in that demographic). I'd suggest that you should have some kind of validation metric for knowing when to continue with the project as well, otherwise a project can drag on for much longer than it should.

So true, we had to read Steve Blank to figure out this one. Our previous mindset was: let's build an 'MVP'(more like alpha/beta) and see how it goes.

Don't code an half-baked product to test the market when you can build demos and talk to real people.

Fantastic advice. I first learned about this fantastic advice from a blog post by Dan Martell that I read a year or two ago.

Unfortunately, I can't find it on his blog or searching Google or I'd post it. :\

Do folks have experiences to share on validating the idea without giving it away? Isn't there a risk that the if you tell people one of them will take your idea and run with it?

You test your idea on actual customers, you don't tell your idea to HackerNews. And even awesome companies like Facebook screw up when they test by running bad tests. Example: Home. Facebook tested Home on employees who usually use iPhones. Oops. If any of them read Robert Scoble or talked to a single Android fanboy, they'd realize Android is about customization. If a Nexus fanboy likes the Sulia widget or whatever you call it, said fanboy is not going to want to use Home when Home displaces Sulia.

"Don't worry about people stealing an idea. If it's original, you will have to ram it down their throats." -- Howard H. Aiken

I think it's a legitimate worry, but a small one. Novice entrepreneurs overvalue ideas. The majority of startups make major changes along the way. E.g., PayPal was, what, Levchin and Thiel's fifth product?

And the real magic to PayPal wasn't money transfer; it was the loss prevention that kept the business viable. The thing that distinguishes successful entrepreneurs isn't that they all had one good idea 5 years ago. It's that they kept having new ideas, and had the drive to push their ideas out into the world so that they could learn enough to spark the new ideas.

Practically, there may be a very small number of people who a) are smart and experienced enough to appreciate your idea, b) have more resources to execute, and c) aren't busy doing something they like better. Try not to let those people understand the secret sauce. But those people are hopefully not your customers, who are the main ones you should be validating your idea with.

Replace all: "technical founder" to "founder".

Otherwise perfect. A+.

tl;dr: market research + presales.

Reply on news.ycombinator.com