
The Real Product Market Fit - craigcannon
http://themacro.com/articles/2016/06/the-real-product-market-fit/
======
beat
Makes me think of something I say occasionally... you need a problem so
compelling that customers will pay for a buggy, incomplete solution, because a
buggy, incomplete solution is what you're building.

~~~
panic
And then we wonder why the world is full of buggy, incomplete solutions!

~~~
beat
It's the dream of every engineer to get to _make something that doesn 't
suck_, right? But the 80/20 rule applies. Getting through that last 20% that
is suboptimal is 80% of the work. Every hour you spend polishing your way to
perfection is an hour you _don 't_ spend adding new features or creating new
products. Every bug fix is paid for with opportunity cost - at a very high
compound interest rate, if you're in a startup.

I've come to the conclusion that if your code doesn't kinda suck, you're doing
something wrong. You're wasting effort. Actually, I came to a much harsher
conclusion than that - I've concluded that _all software sucks_. That all
software hovers near the line between "barely works" and "doesn't work". Why?
Because by the time you get to feature-complete, if it still works, it's so
riddled with compromise and bad decisions that you never want to look at that
code again. You want to start something fresh and new, and THIS time, you
won't make all those stupid mistakes! This time, it won't suck!

It always sucks, in the end.

~~~
panic
I think it's possible to write good software, but I agree that it's difficult
to do at a startup. At the very least, there are kinds of software (aerospace
and medical software for example) where hovering between "barely works" and
"doesn't work" isn't acceptable, and the people responsible found ways to
improve their software beyond that point.

~~~
beat
It's not really making software that more than barely works... it's changing
the definition of "barely works". I've spent most of my career in banking and
health care, stuff under heavy regulation. The regulations become part of the
requirements. And within those bounds, banking and health care software barely
work. Avionic software barely works. The software that keeps your pacemaker
going? Barely works.

Remember, a pacemaker that doesn't work 1% of the time doesn't work. Specs are
different.

------
programminggeek
Here's the most important lesson...

This kind of starving crowd is rare and you should expecting it to be rare.
That's why people are willing to pay you millions of dollars if you find one.

If you find a truly hot market, it can be worth billions and most any idiot
can make a lot of money in a hot market. If you are good, all the better.

But remember, it's rare and hard to find. Assume that 99.5% of all businesses
aren't in that kind of market situation.

------
lacker
I like the idea of someone hitting themselves on the head with a brick to put
out a fire, and a brick salesman getting excited

------
mwseibel
Hey folks - this is Michael from YC - happy to hear your thoughts on the post

~~~
gmarx
It's a charming ideal that I think is vanishingly rare in real life. I also
can't see how the hair on fire thing fits with any of the top startups and ex
startups I know. In fact I dare say the rapidly rising user count is a
separate story from the hair on fire story. The hair on fire tends to be a
specialty business problem and still, against all reason, tends to require a
pretty rigorous sales cycle. The problems I work on, making the medical record
discrete data is of this kind. The other kind is more like Google, Facebook,
Uber, AirBnB and those were surprises because no one's hari was on fire. We
didn;t know we wanted that stuff until we saw it and then we wanted more and
more.

In summary, I guess I disagree with the whole thing

~~~
mwseibel
I know about Airbnb personally and it started with a hair on fire problem - a
design conference where all the hotel rooms in the city where sold out. Brian
and Joe hosted attendees in their apartment on air beds. That sounds like a
hair on fire problem and a brick solution :)

~~~
gmarx
I see your point but that implies that on rare occasions hotels are sold out
at a specific time and place. I don't think that is the problem AirBnB solves

~~~
nostrademons
I'm wondering if this may dovetail with another piece of common YC advice,
"start by going narrow & deep".

I didn't start using AirBnB until 2013, and I used them because they were
remarkably polished and made the experience super-easy. They weren't at all a
"hair on fire" problem _for me_.

But I could imagine that at some point in time, there was a group of people
who were so desperate for a place to stay that they'd crash on a couple of
airbeds at a stranger's place. And that gave those strangers the idea that
maybe this was something worth looking into and investing time into
perfecting.

The importance of that initial core group of users may be _feedback_. I've had
to give up startup ideas because I launch them and then there is literally
nobody who cares. And then with no users, there are no guideposts as to which
direction to improve the product in. It's all guesswork, and random ideas
don't have a particularly high chance of success.

This may also dovetail with the known advantage that you get from solving your
own problem. If it's your own problem, then you know at least one person wants
it, and you can use yourself for feedback on improving the product. Then
hopefully once it's good enough for you, you can find some other folks that'll
find it good enough to try out, and use their feedback to evolve the product.

~~~
rrecuero
Great write up. You hear many times the advice of getting MVP out and then
"just" listen to your customers and the data. A lot of times, as you said,
there is virtually nobody that cares and few feedback. You are just treading
through a desert without nothing to guide you...

------
kevinyun
Hey Michael, awesome piece! When I started my first company [that made serious
revenue relative to other projects], I didn't spend any money until we
actually had sales. Getting to product-market fit took awhile for us, as
growing the brand and reputation just took time, but now it's an awesome
machine that churns well with some spurts of oil here and there.

I think you're spot on with the half-baked, v1, imperfect solution. Currently
trying to do the same with a new startup
([https://getbeau.com](https://getbeau.com)). Our v1 didn't do it for us, but
we listened to the recurring feedback and just relaunched our v2 and are
continuing to validate that the problem we solve for our customers is a
serious (albeit first-world) problem.

------
kinj28
Incase of enterprise tech - finding repeatable pain across set of customers is
a must. Solving one enterprises "hair on fire" problem is no guarantee of
similar pain existing else where.

My observation from being in enterprise mobility market for 10 years - while
one customer realizes hair on fire, many others are diabetic and don't feel
the pain.

------
pea
Great article. Another good way we've had this explained is: if someone is in
a burning building, you are the option of jumping out of the window.. There
may be a 95% chance they will die, but they're in so much pain that they'll
make the jump (even though they normally never would).

Do you think this is more geared for entry strategy (getting the tip of the
spear in)? In an ideal world, you could find something where building a small
quantum converges with solving this degree of pain.. though of course the
stars do not always align that easily...

------
billionsfan1
I'd like to find more resources / books (I love audio books these days) that
answer some of the questions at the bottom of Marc Andreesen's original post:

\- How exactly do you go about getting to product/market fit if you don't hit
it right out of the gate

\- How do you know when to change strategy and go after a different market or
build a different product?

Anyone have books on some of these mechanics?

