

A Lesson Learned as a Technical Founder: Sell First, Build Later - vu0tran
http://blog.framebase.io/post/50355416770/sell-first-build-later

======
31reasons
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.

~~~
tyang
This is great.

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

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

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

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

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

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

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

~~~
patio11
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.)_

------
biot
A corollary for today's frothy times:

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

------
startupstella
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)

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

------
jabbernotty
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?

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

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

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

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

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

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

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

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

------
mkoble11
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.
:\

------
noveltyaccount
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?

~~~
wpietri
"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.

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

Otherwise perfect. A+.

------
jk4930
tl;dr: market research + presales.

