
Fat startup: Learn the lessons of my failed Lean Startup  - casca
http://wordsting.com/copywriter-blog/fat-startup-learn-the-lessons-of-my-failed-lean-startup
======
thesash
I'd like to suggest that all the lessons learned here are _precisely_ what
Lean Startup teaches-- with techniques that are meant to prevent you from
spending two years in a death spiral.

Segue to edit of my standard rant on this subject: (originally posted on:
<http://news.ycombinator.com/item?id=3429906>)

MVP != half assed, cheap, shitty product. It is exactly what it says: a
minimum viable product, key word being viable. An MVP for a mission critical
application or a cutting edge piece of research isn't going to be cheap or
easy, because it needs to be viable.

Because of the name, many people make the assumption that doing a Lean Startup
means not taking the time or money necessary to execute properly, this is not
the case. Lean means conserving capital by focusing on iteration until you
each product market fit, and only then ramping up sales or marketing, but
again, if you're cracking a new market, untested technology, or going up
against mature competition, even that phase of conserving capital and focusing
in product may require a lot of capital.

Your product, when released to customers, needs to be usable, and needs to
scratch an itch for them, otherwise it is inherently not viable. That's why
customer development is so essential, it prevents you from making the worst
mistake possible-- building a robust product no one wants. Even if you have
the best product idea in the world, the only way to know if the features you
add are having a positive impact is to measure the behavior of real, live,
human users.

That being said, it's still your responsibility to stay relentlessly focused
in your core value proposition. You can't build every feature you're customers
ask for, _only the ones that make sense for your product_.

What we're seeing now is the lean startup backlash where people use the terms
but don't really take the time to understand what they mean,.

The Lean startup movement is a powerful set of lessons that can empower
entrepreneurs and save us from wasting our time and effort building the wrong
things and chasing the wrong metrics, but I guess some of the lessons just
have to be learned painfully through experience (it was certainly true for
me).

~~~
wpietri
Yes, yes, yes.

There are so many things they did that are obviously wrong from the Lean
Startup perspective. And then he goes and blames the Lean Startup material,
rather than their understanding of it.

For example, his notion that product management is supposed to be casual and
erratic is not what the Lean Startup approach suggests. The essence of the
approach is in _proving_ that customers really need something before you
invest in it. It's a disciplined, data-driven approach. But he says they built
half-assed features that nobody needed, and somehow blames that on the Lean
Startup stuff.

Also, he preaches about controlling expense. The word "Lean" in "Lean Startup"
comes from Lean Manufacturing, the heart of which is relentlessly discovering
and eliminating waste. How in the world did he get from that to being free-
spending and wasteful?

And then this makes me crazy: "By this stage, Lean Startup theory told us we
should be scaling up." No. No, no, no, no, no. No! The Lean Startup theory is
that you start scaling if and only if you have achieved product-market fit and
have a sustainable way to deliver. He described nothing to suggest they were
close to product-market fit. Indeed he says they were limping.

Or his sudden too-late realization that software quality is important. The
Lean Startup stuff is basically Extreme Programming plus Customer Development
plus some Lean philosophy. Extreme Programming is one of the most quality-
focused methods. At my Lean Startup, we had high unit test coverage, strong
acceptance tests, lots of code review, and very high quality. 18 months ago I
gave a talk on how quality practices were vital when using the Lean Startup
approach:

<http://vimeo.com/24843552>

And it's not like I was the first, or even the 10th person to talk about this.
Rather than blaming the Lean Startup approach, he should blame his poor
understanding, and his cargo-cult adoption of various rituals he apparently
couldn't fathom.

~~~
nashequilibrium
The problem I have is that everyone can rap the lean startup principles but
when you ask who has successfully implemented lean startup, nobody says yes.
How many people do you guys personally know that have successfully implemented
lean startup?

~~~
bjansn
By what measure do you want to define if startups have implemented it
successfully?

~~~
lelandbatey
I'm not the parent poster, but I'd basically say: are there any examples at
all? Even if we're really loose with what qualifies as "lean startup" are
there any examples anyone would be willing to share?

I don't mean to imply that there aren't any, but I just haven't heard of any.

~~~
j4ustin
If you read The Lean Startup there are examples in there. I mentioned above
WPEngine did it, but also look at Food on the Table. These stories show the
lean startup done right. The story above is so riddled with holes. It's like
the guys heard some buzzwords, read a wikipedia page, and ran with their
limited understanding of it.

------
RyanZAG
It's difficult to work out if the author is saying that his startup ended up
'fat', or that it would have been better if the startup had been 'fatter'.

I'd argue the problem was the former. It sounds like they spent a large part
of the runway on things that were not part of the MVP (patents, funnel, extra
employees, etc). This is exactly what the concept of 'lean startup' is
designed to avoid - 'lean startup' and 'mvp' means you throw out everything
that isn't targeting on creating a product that people will buy. You don't
throw out parts of the product itself to be lean, you throw out everything
that isn't required for the core offering. By the sound of it, the author
threw out the core offering and focused on the 'fat'.

EDIT: The 'viable' in MVP is a very specific word that is straight out of the
dictionary definition. As from Google dictionary:

    
    
      vi·a·ble  
      /ˈvīəbəl/
      Adjective
      Capable of working successfully; feasible: 
      "the proposed investment was economically viable".
    

Very clear. The MVP for humans going to space is a billion dollar ecosystem
including runways, safety checks, logistics, long range communications, etc.
An MVP can still cost a billion dollars - MVP does not mean cheap.

------
dia80
Sorry, this doesn't add up. Lean doesn't mean your product breaks or is pushed
out functionally incomplete. If no one wants it it's not viable.

The article says give your customers what they want. Unfortunately they
thought the customers wanted a mobile app... but they didn't! Wait, what
startup methodology could have prevented this...

The article is honest about their mistakes and that must have been hard to do
and props for trying but don't try and pass the failure buck to a methodology
you didn't even do right.

~~~
j_s
Agreed (edit: though I thing the title of the post indicates awareness of not
doing it right). Jumping from:

    
    
      > Our inaugural customer couldn’t access the software
    

to claim:

    
    
      > the minimum viable product [...] has limited practical 
      > use. Customers aren’t interested in funding your “learning.”
    

and blaming the MVP concept instead of the broken software?

------
gline
There seem to be two schools of thought here, both interesting to me. The
author seems to think that his failure has something to do with problems
associated with the "lean startup" model and other commenters (lean startup
adherents, apparently) seem to hink his failure has something to do with
failing to properly follow the tenets of the philosophy.

I suspect actually that the author adhered about as closely to "lean startup"
as many self-identified "lean startups" who have succeeded in the past, and
made a pretty average number of mistakes in the process. I don't think of
'lean startup' as a way to guarantee success, I think of it as a way to fail
gracefully if you don't succeed. The author came pretty close to this,
actually - it doesn't sound like they burned through enormous piles of venture
capital money, it seems like they learned a lot in the process, it seems like
they didn't spectacularly fail to make payroll causing half a dozen family-
bound engineers to suddenly lose their livelihoods. The only less-than-
graceful element of their failure was that it took two years, which is
probably a little (though not a lot) on the long side. Frankly late in the
process they came pretty close to scoring what sounds like it would have been
a pivotal investor, and that combined with lessons learned could have produced
a true MVP, product market fit, and a viable startup...

So, I think the author successfully followed a good chunk of lean software
advice, made some mistakes, got unlucky, and failed. This is what most
startups do - even most lean startups - and there should be no shame in it.
Paul Graham himself has remarked he wishes he were able to bring himself to
invest in more likely-to-fail black swans because that's the way you get to
own enough vol to have a real winner in your portfolio - we all should be more
comfortable with the risk of failure.

------
SoftwareMaven

      * Development costs too much to afford iterating.
      * Mobile app that customers didn't ask for.
      * Language customers didn't understand.
      * MVP not actually being viable.
    

I'm sure there are more, but my take-away is that this was not a lean startup.

If your development costs are such that you can't iterate on new ideas, you
might not have a lean startup.

If you are presenting features that your customers aren't asking for, you
might not have a lean startup.

If your customers can't understand what you are showing them and you aren't
immediately changing it, you might not have a lean startup.

If you are trying to target big and little customers at the same time (or
don't know who your customer is), you might not have a lean startup.

If your minimum viable product isn't viable, you...well, you don't have a
minimum _viable_ product. The point of the MVP is to provide enough value that
customers see more value in using it than it costs. Anything less than that is
just some features thrown together.

In the end, I'm not sure if OP agrees with me or not, but this sounds like a
focus problem: trying to do to much instead of focusing in on the pain that
gets you in the door.

Another note on MVP: It changes over time. Initially, an MVP may just be some
powerpoint slides that show your idea. That may be enough to get you some
conversations. Later, when targeting your initial customers, it may be a
feature or two that helps them solve their immediate needs. Later still, when
you want to start mass-marketing, it needs to be something more.

A key takeaway: Just because Lean is simple doesn't mean it is easy. It takes
a lot of discipline to keep from putting the cart ahead of the horse.

------
Uchikoma
What I've learned from my failed startup during 2000/2001 [1]: With enterprise
software the MVP is a power point deck with mockup screen shots. You first
need to validate the idea, words, concepts before you start developing. This
also helps with the deep decision pipelines that enterprises usually have to
buy your enterprise software.

Next time I'd start immediately going around with a powerpoint deck of mockup
screenshots instead of developing software first (which we did and failed).

[1] [http://codemonkeyism.com/6-reasons-why-my-vc-funded-
startup-...](http://codemonkeyism.com/6-reasons-why-my-vc-funded-startup-did-
fail/)

------
DanielBMarkham
I'm voting this up. It has so many problems that everybody should know and
talk about them.

"...First, the minimum viable product preached by Lean Startup has limited
practical use. Customers aren’t interested in funding your “learning.” They
want reliable software that delivers value consistently. You must build the
minimum desirable product, and if you don’t have a good understanding of
what’s desirable before you start, then, don’t...."

What value and growth hypotheses are you testing? Seriously, nobody is
expecting your customers to put up with crappy development. What we're saying
is that you must clearly explain what you are trying to learn before each rev.
Just coding up some minimalist POS and irritating a potential customer with it
doesn't take you anywhere down the learning road. Pro tip: irritating people
will not give you good results in your quest for learning.

Lean startup stuff says everything you do should be geared towards proving a
value or growth hypothesis. You should have a disciplined way of testing, and
numbers that mean success or failure -- ahead of time. Yes, you do it in
loops. Yes, there's all kinds of other stuff. Yes, you're always focusing on
eliminating waste. But I think this guy missed the point completely. The MVP
is where two proven hypotheses are deployed in tandem to a target market.

I could go on, but I don't want to be mean. We learn much more from watching
people misunderstand things than we do watching successes. Thanks to casca for
posting it.

------
happywolf
I have seen a lot of people who pointed out how wrong the OP had done and the
OP should have done X, followed by Y, yadi yada. What I can't find is maybe a
bit of sympathy, or encouragement.

Fine. It would be very useful if those smart people can share what and how
they have applied the Lean Startup theory, and how successful their
products/companies are. I will give most of them benefit of doubt for
_reading_ that book, but applying it? I would say around 10% of them? Applying
it and succeed? Even less, I just speculate it will be around the 1% mark. In
other words, those who talk so loud about OP didn't get the MVP right etc etc,
I will say they won't fare any better if their rubber hit the road. I am more
than happy to be proven wrong.

------
Ologn
I think "The Lean Startup" is a good book - it presents a model for creating a
successful business which diverges from older more traditional business
thinking. Some successful technology companies feel the same way. I also think
books like this should be read as guideposts, not as some orthodoxy. If a
suggestion from the book goes against particular circumstances or common
sense, you do what your common sense tells you.

Nonetheless, they seem to have missed important lessons from the book. Or re-
learned them rather. The odd thing is they then claim the book does not cover
these things, and distracted them from these problems. I don't understand why
this is said, since the book does cover these things.

The blog post says:

> Lean Startup principles distracted us from four livelihood-threatening
> fundamentals. First, you need rigorous product management. Don’t speculate.
> Build no feature unless you understand it thoroughly and have unshakeable
> evidence that multiple customers need it --urgently.

But this lesson learned _is_ one of the Lean Startup principles.

From "The Lean Startup": "For example, how many features do we really need to
include to appeal to early adopters? Every extra feature is a form of waste,
and if we delay the test for these extra features, it comes with a tremendous
potential cost in terms of learning and cycle time. The lesson of the MVP is
that any additional work beyond what was required to start learning is waste,
no matter how important it might have seemed at the time."

...I quote only one paragraph from the Lean Startup, but the idea about no
excessive features in an MVP is repeated throughout the book.

It's possible the Lean Startup approach has some holes in it, but warning
against too many features in an MVP is not one of them.

------
hluska
"Our first customer, a Canadian social services department, was led by a
Deputy Minister with a fondness for a wall chart showing the logic models
under his charge."

Several years ago, a friend and I started a non-profit that tried to work
closely with a Canadian social services department. Consequently, when I read
this sentence, I cringed. Turns out that big Canadian government departments
have these massive tomes called 'procedure manuals'. These procedure manuals
spell out every single activity that the department could possibly perform,
seemingly in the name of getting rid of ambiguity, judgement and any sort of
innovation. Consequently, trying to innovate alongside a government department
is, more often than not, an extremely frustrating experience that results in a
pissed off client and a stymied startup.

Long story short, just because someone comes at you with money, it doesn't
mean that your demand is validated. Rather, sometimes the wrong kind of
customer is worse than having no customer at all!

------
onemorepassword
Oh, so now the whole "we fucked up so let's blame the tools/methodology" has
arrived at Lean Startup?

Plus ça change...

Here's a wonderful nugget: _"too often Agile development methodologies are
used to excuse lack of process and planning"_. The irony is strong in this
one.

The next book on Lean should be a dictionary with just a single word explained
in way even a 3 year old can understand: " _viable_ "

~~~
wordsting
Viable means, strictly, able to live at birth, especially, in relation to a
foetus (but not a 3-year old?). Being born doesn't mean you will survive. So,
minimum viable product is a poor term, implying disrespect for your customers.
Minimum desirable product (from your customer's perspective) reflects the
standard required.

------
hpagey
I worked for a enterprise software company where we practiced incremental
development. The quality of software was hardly stellar but they had a great
sales team. By the time I left, they had 6000 customers, lot of them Fortune
500. It is also worth mentioning that they were completely bootstrapped until
recently.

Our customers were always ok with us informing them that features will be in
x.0, as long as we delivered on them.

Maybe, it was your market that prevented the lean startup methodology from
being applied?

------
saosebastiao
Wow. Reading these comments makes me think that the whole Lean Startup thing
is more of a religion than a methodology.

------
uladzislau
Fist of all, it might be not the right choice of methodology as government and
non profit clients are not the best audience to apply "lean". These guys are
very conservative, especially in Canada.

Second, it appears a lot of problems appeared because founders didn't know
what they are building or what they want to build and relied on "lean" as a
magic bullet to help them figure it out.

Third, it's hard to believe but I've met people who applied "lean" and other
methodologies without actually diving deep and at least reading the underlying
manifesto books thoroughly. Lean methodology is so easy, isn't it? Build an
MVP and then iterate.

To sum it up, there's nothing wrong with lean methodology. These guys first
failed at understanding it. Then no wonder that they double failed at
execution.

------
Vanke
As someone who works in the Canadian Government I'm not surprised at all that
a deputy minister would have no interest in helping you iterate your product,
at that level it's all about politics and to have a product fail in front of
them and their coworkers is a big problem it makes them look bad which could
have a negative effect on their job.

------
tbatchelli
I sympathize with the author. Lean Startup is a very good tool that should be
in your toolbox, but it's being sold and resold as "the way". It's not the
only way, and it doesn't guarantee success, not more so that knowing the
scientific method guarantees you a Nobel prize, or a published paper.

Lean methods make some implicit assumptions about the cost of finding early
adopters and building MVPs, and each entrepreneur should figure out the costs
of such activities and determine if they are worth pursuing provided the
potential benefit. In enterprise software settings, for example, an MVP might
mean 2 years of work, that means you have only one iteration if you follow the
lean methods by the book. Does that mean that you can't successfully build
enterprise software? Of course you can. You can work with a customer for 2
years, deliver this product to them, and then market it to other similar
companies, and then, only then, iterate. Is this still Lean? I don't know.

Also, I can't fail to see Lean as an optimization method, similar to gradient
descent. With gradient descent, each iteration you inch up in the direction
that seems to bring the highest reward. When using gradient descent in real
world you realize that where you start matters, and the function you are
exploring also matters, a lot. You can start iterating near a minimum, and
have a straight descent line, but you might iterate on a plain, and basically
be lost forever. Of your function might have many local minima. You have to
first explore the problem space and make sure you where you start iterating
close enough to the minimum, or that a good solution can be found by
iterationz. Where you start, or when you decide to restart, is what the
Entrepreneur's vision provides.

Gradient descent is also quite blind, and the fact that the last 20 iterations
in one direction didn't bring any success provides no insight on what is going
to happen if you iterate once more. The function you're exploring might just
have a sharp drop one iteration away, or it might continue to be flat for 100
more steps.

If your MVPs can be built quickly, or if you are close to the optima, or you
have unlimited cash and time to explore, the lean method is the way to go. For
other cases, you might have to weigh in the pros and the cons.

~~~
jacques_chester
It's slightly more than than hill climbing. More like simulated annealing.

------
tzaman
I think you guys misunderstood the purpose of MVP, since your _lessons
learned_ part explains pretty much what we can find in Lean approach books.
MVP is not a product, it's a learning process. Bugs have nothing to do with
being lean (or not), it's sloppy developers.

Not trying to be a wise-ass, but I still think your mistakes are avoidable
while still following lean principles. Good luck on your next venture!

------
bjansn
It's great you're openly talking about this! We need more people with stories
on failure, because we learn more from that than success stories.

There is a lot of stuff in the post and the comments about Lean Startup, but I
want to jump in on this the wish expressed 'The Jason Fried Fantasy'.
Specifically this:

 _We would combine simple, opinionated software with crisp software
copywriting and a low-touch online sales model._

This limits your options. I think the product was too niche to be a 37signals
'sell to the fortune 5 million' product. I'm passionate about 37signals, but
it might be difficult to apply to niche markets that require aggresive sales /
long deal flows.

Now you also point out:

 _For every customer or prospect we talked with, the risks of innovation
(failure and losing their job) far outweigh the hypothetical benefits we
proclaimed. Customers just want reasonably priced software that does its job,
not helping you launch your Lean Startup adventure._

Now assume you've already validated the problem. Probably you were getting the
wrong people in your sales funnel. Basically if people fear to lose the job,
you need to move up in the companies hierarchy. Look for the manager above him
and keep going. Or start at the top and work down if possible. But keep
talking until someone keeps calling you back to have their problem solved.
Steve Blanks Customer Development talks about this as well.

About the quality of the MVP. It's better to ship a _half_ product than a full
featured _half working_ product. From what I read in your post a lot of people
weren't feeling safe to introduce this in the organization because it was an
immature product. You solve this by narrowing down the featureset or display
'upcoming features' and involve people in developing further. But this is
different per market, B2B (as mentioned in another comment) is different than
consumers.

Edit: fixed markup.

------
pc86
> the minimum viable product preached by Lean Startup has limited practical
> use. Customers aren’t interested in funding your “learning.” They want
> reliable software that delivers value consistently. You must build the
> minimum desirable product, and if you don’t have a good understanding of
> what’s desirable before you start, then, don’t.

Oh, how I wish I could tell myself this five years ago. Maybe it's the
industry I do most of my development for, but users I interact with very
rarely want to hear "that will be in 2.0!" The ones that even let you finish
the sentence before hanging up/walking out usually respond with "That's great.
Let me know when it's done, then we can _talk_ about signing up."

MVP and incremental development is great when you're a VC-funded startup in
Mountain View, but when you're a real business you either have a working
product that people want, or you don't.

~~~
svachalek
What is it about the word "viable" that seems to make everyone read right past
it?

~~~
pc86
Unfortunately MVP has been bastardized from "the smallest thing people will
pay for" to "the smallest individual piece of the application."

------
d0m
Wow, I wasn't sure if that blog post was some sarcasm from some trolls or a
real article.

I could quote lots of parts, but here's one of the funniest ones:

>> But intelligent iteration wasn’t possible because of our obese development
costs, which left us without any funds to product iterations.

>> We wasted money democratically across developers, patents, e-mail
platforms, and a sales pipeline tool

>> Hidden inside our minimum viable product was a separate mobile application
to gather data on logic model performance.

The sad part in it is how they blame the process for their failure when they
got it all wrong.

However, one thing I've got from this article is how hard it is to create a
good mvp. The balance between Quality vs Learning vs Minimum is tricky and
highly dependent of your customer. I.e. You create MVPs to learn fast so you
can iterate faster.. but since you're still trying to validate your
hypothesis, it's hard to decide what is really _minimal_ or _valuable_.

I guess MVPs is an over-used word.. I prefer prototype: _A first or
preliminary model of something, esp. a machine, from which other forms are
developed or copied._ Basically, you _use_ prototypes to iterate really fast
and test your assumptions, and _then_ , you build a mvp from what you've
learned.

I prefer prototype because it's clear on both side that it's not the real
product. It's a temporary phase to test the ideas. But again.. way easier to
say than to do. I'm currently in that "prototype vs MVPs" phase and I'm
struggling on determining the best next step. The fact that I'm working with
health professionals with sensitive and highly important information clearly
doesn't help.

That would be amazing if a lean expert reading this would feel generous enough
with their time to help me with that "next important step" (phzbox at gmail).

Anyhow, thanks to Casca for sharing his experience.. Learning from failures is
more often than not better than trying to copy a successful strategy.

------
mfieldhouse
Right off the bat, it looks like the problem lies in 'we built a software
product that simplified how nonprofits plan and measure their social and
environmental impact.'. It just seems nothing was built that people wanted to
pay for. The product wasn't marketed to people that have the money to pay for
it and see the value in doing so. Also they got confused by thinking 'viable'
is different to 'desirable'. It's the exact same thing. MVP doesn't mean
what's the smallest piece of junk you can throw together and call it software.
It means if you strip everything out of your idea and product, what is the one
feature that customers would find useful and pay for.

------
jblok
I like the term "minimum desirable product". Minimum viable product suggests
something that barely works, while minimum desirable product alludes to
something people actually want.

~~~
dragonwriter
> I like the term "minimum desirable product". Minimum viable product suggests
> something that barely works, while minimum desirable product alludes to
> something people actually want.

I think "minimum viable product" works, and is better than "minimum desirable
product" at describing the goal, since to be viable as a product something
must not only be desired, but be desired by customers willing to pay for it
sufficiently to meet the marginal costs of delivering it.

Of course, an MVP can fail to be viable as a product and still deliver
validated learning (as I understand, the original definition of the purpose an
MVP) that progresses you toward something viable as a product, but the goal at
each iteration should be to have something valuable as a product (and this is
consistent with the more general lean methods which lean startup draws on,
where each iteration aims to do the minimum work that will produce independent
business value.)

------
ActVen
Critical Point: Viability is judged by your customer.

Developers are comfortable with dealing with some quirks in software. They
typically use some of the fastest computers and the most up to date browsers.
They live in and build the world of software.

It is very difficult for a developer to understand the mindset of a non-
technical customer and see their software from the customer's perspective and
experience-base. It's not impossible to do this. But if you don't try hard
enough your project will fail.

------
grenek
Lean Startup theory can be pain in the ass for many kind of startups. I think
it's wrong that Lean Startup doesn't encourage sales from the very beggining.
Sales are the best validation of your idea, not feedback from customers who
doesn't pay for your MVP anyways. Build a product for people who pay for it -
that's my advice. It's not universal eighter, but more than 50% of startups
can start sales before coding anything.

------
mjbellantoni
"Early adopters” and “earlyvangelists” are certainly not fictional characters.
They exist, but are rarely found working in government ministries.

------
quaffapint
Great share to hear the more realistic side of some of the MVP pieces.
Certainly one of the biggest challenges I hit almost daily with my saas is
what feature is critical to success, and which can be 2.0, especially in light
of the comment than they might not want to wait for a 2.0. Customer research
only gets you so far.

------
dkoston
It's not enough to simply survey people on whether or not they have a problem
and then go build. Building good software means building something that people
want to use. If you fail to properly dive into customer development and learn
about your customers base (what tools do they currently use, who are the early
adopters, what are the existing barriers to entry) then you will likely not
succeed.

Simply reading one book and some blogs on Lean (or any other methodology) also
does not make you an expert. You should read about many different business
strategies to understand the key parts of them and how they are similar and
different. It's a bit naive (arrogant?) to think you can just read a book and
then go conquer the world without having to constantly learn and adapt during
the process.

~~~
dkoston
Sorry to add to my rant but I get really tired of hearing the "X methodology
killed my business" story. There have been hundreds of thousands of successful
businesses created and operated by people without formal training in any
strategy so why should having read about a business strategy destroy your
business? Did it remove your ability to talk to customers and respond to their
concerns?

People often fail to address internal issues like limited domain expertise or
limited business skills. It's not enough just to see a problem and be excited
about solving it, you need some skills (either present or learned) and you
need resources.

Lean is focused around learnings. If you had focused on learning rather than
whether or not you completed a task (MVP, demo, etc), you'd realize that
you've gained a lot from the experience but it wasn't until you reflected that
you realized you failed to incorporate those learnings back into the business.

Also, failure to understand that your first customer wasn't an early-adopter
really hurt you. If someone isn't willing to jump through hoops to use your
product, it either 1) doesn't solve a big enough problem or 2) they aren't an
early-adopter.

------
WillThisFly
It may well be that your product just wasn't needed or that your focus was
wrong, for instance customers might have wanted feature y before feature x: It
is not uncommon to find it difficult to work out what customers want in
isolation.

(Shameless plug alert!)We encountered this several times in our own failed
startups where we have built the best software the world has never seen and
decided to create WillThisFly? to address these issues: It allows you to
develop your product with feedback from day one, validate ideas and features,
iterate and develop before committing time and resources to it or indeed, find
out that it's a non-starter.

Our MVP is online now at <http://willthisfly.net/projects/1/>

~~~
white_devil
But since anyone hoping to make a new product should be talking to his real
potential customers, why would he not talk to them _directly_ , instead of
say, trying to get them to use WTF?

Anyone other than his real-life potential customers giving him feedback is..
well, not going to give him the feedback he needs, no matter how well-
intentioned he is.

Then there's the issue of someone potentially stealing your idea, etc.

~~~
WillThisFly
What WTF provides is the ability to come up with an idea and get a quick gauge
as to whether it has merit (it works with projects at various stages from new
ideas to coming up with new features for existing projects and anything in-
between).

For example, you have likely heard of "Facebook killer" apps and "New way to
organize your inbox"-type ideas in the past and the general reaction is "Oh
ffs, not another <insert product here> clone" but most ideas still have some
merit even if their initial briefs are rather ambitious and somewhat tenuous.

Your Facebook killer may be too ambitious but with a bit of focus you may be
able to come up with a smaller, more niche product that benefits a particular
demographic given feedback and some direction.

This is what WTF provides: Sure, it will not give you a definite "If you build
it, they will come" answer but it might just be able to help you salvage
something that doesn't look like it is going anywhere.

In addition to helping you shape a project, it may also prevent you from
spending time and money on something that just will not work as a result of
feedback so you will know fast if it has any potential before spending time
and money on it.

AS to stealing your idea, this is rarely the case. The thing that sinks most
projects is lack of focus and aiming in the wrong direction - something WTF is
designed to help prevent.

Thanks very much for your insight... this is exactly what WTF was designed
for.

Mick

~~~
white_devil
Well, if I have a good idea, post it there and get a lot of positive feedback,
wouldn't that downright _encourage_ someone to implement the idea now that
it's (supposedly) been validated?

Don't get me wrong, I'm not hoping WTF will not succeed. It's just that as
someone who's just wasted several years of _his_ life on products that went
nowhere, I'm a bit skeptical.

"The Lean Startup" seems like the way to go, but that involves speaking
directly to your potential customers, because they're the only ones who know
what they _really_ need. Apparently it's really freaking difficult to confirm
that you've really got a product-worthy idea on your hands, even if you're
talking to potential customers.

------
robertwalsh0
I think the author hits the nail on the head with the term "minimal desirable
product" rather than "minimum viable product".

Many of the commenters here are replying with things like, "Dude, you don't
understand the meaning of the term 'viable'." I can say that I've worked with
plenty of developers who think of MVP as "the minimum amount of shit I need to
build to ship this thing" rather than "this is the minimum that needs to be
developed to make something that someone would be happy to use."

With all that said, I think changing the term to "Minimum Desirable Product"
would be something that helps get everyone involved with a software product on
the same page.

------
gregors
Not specifying what browser/versions you would be supporting - when dealing
with anything remotely government is a mistake. Having an access denied error
message right after signing up means your basic happy path wasn't working
correctly and neither were your development and QA processes. Testing features
in production is different than testing logic in production.

------
calinet6
Your blog looks like it's owned by Twitter. The twitter logo is in the usual
location of the owner's logo. I suggest you repair this. Among other things,
it's probably against their policy.

Also, I had exactly the same experience, but the difference here is the
enterprise nature of the startup. Enterprise demands power, and investment,
and capital. You can't do it lean.

------
andreasklinger
Many people i talk make the same mistake with lean and custdev.

And i have to say i did the same mistake.

We try to things the lean way and hope therefore we do it the right way. Eg.
building an MVP that should validate our business assumptions.

All of the methods around lean and custdev sound perfect in theory. But
validating that you do the right thing (apart of a super obvious strong market
pull) is extremely hard.

A common mistake i see is when people speak about 20 different hypotheses or
experiments - and usually none of them is related to a real make-or-break risk
of their company.

They try to validate that they do the right thing. Which is extremely hard.

As entrepreneurs _we_ are in charge of a strong product/customer vision. Any
method we use is only in charge to check if we are lying to ourselves.

But many of the techniques used in custdev/lean are very strong tools for
minimizing the downside.

And this is (imho) where we should use them.

Our main goal is not upside optimisation (waiting for the go) but downside
minimization (avoiding the no-go)

Or differently put: They are very good to double check if you aren't doing the
wrong thing, if we aren't lying to ourselves.

The other main mistake i see is "trying to do it the lean way":

There is no "lean" way. Lean is a reverse engineered model largely based on
survivor bias and wrong self-reflection. But that's completely ok. We must not
forget how young fast-growth oriented product-centric entrepreneurship is.
Even custdev which is more fullstack than lean is mostly academic and best
used only as a frame of thought. Not as a blueprint model. Lean will be
replaced by other models using the same or improved stack elements.

Just like me, too many people are obsessed with the theory behind lean and see
it as fullstack solution.

Instead of looking at lean as a fullstack, we should pick parts of that stack
that make sense for our business - as we do eg in software engineering or ux.

E.g. MVPs tend to be a problem with b2B relationships. Agency like concierge
code-for-hire models tend to work better. Also customer interviews work gold
for B2B - by far better than for b2c models.

Simply put: We need to pick stack elements of lean and custdev as we would
pick elements of software stacks, depending on our business's risks and
challenges.

If you are interested what i mean with stack elements, take a look at \-
customer interviews [http://www.slideshare.net/andreasklinger/actionable-
customer...](http://www.slideshare.net/andreasklinger/actionable-customer-
development) \- metrics in early stage
[http://www.slideshare.net/andreasklinger/metrics-for-
early-s...](http://www.slideshare.net/andreasklinger/metrics-for-early-stage-
startups) \- jobs to be done <http://hbswk.hbs.edu/item/6496.html> \- and
several other aspects: [http://www.hackertalks.io/robfitz/why-bother-talking-
to-cust...](http://www.hackertalks.io/robfitz/why-bother-talking-to-customers-
and-how-to-not-waste-your-time-doing-it)

~~~
j_s
Thanks for summarizing. It seems like you have a lot of useful info here and I
appreciate your contribution. However, I'm really having a hard time parsing
this; it seems like you're repeating the same thing several times. Any
additional effort you can invest in further editing your post would be greatly
appreciated!

Edit: Might look at a higher sentences-per-paragraph ratio, I think that's
what's throwing me off.

~~~
andreasklinger
You are completely right. Sorry i just wrote it in one go.

I tried to restructure it. Hope it is now a bit clearer.

------
auctiontheory
Organizationally, non-profits are a special beast, requiring very different
handling than corporate IT buyers. I don't think the Fat Startuppers grok'd
their customers at all.

Honestly, I don't think they learned very much - their "four fundamentals" are
just platitudes. There must be more to this story - I wish they could unearth
it within themselves.

------
juddlyon
I always find it interesting when a methodology XYZ is critiqued its adherents
invariably claim "that's not really XYZ."

~~~
dragonwriter
> I always find it interesting when a methodology XYZ is critiqued its
> adherents invariably claim "that's not really XYZ."

If the example given to justify the criticism isn't actually applying what XYZ
calls for, its a perfectly legitimate response. Often, the problem may still
be with the methodology, and it may just be that the methodology isn't
practical to implement because it makes unrealistic assumptions, but the
evidence needed to support that goes beyond a examples of incomplete attempts
to implement it not producing the desired results, and requires something to
show why attempts to implement it are doomed to be incomplete.

~~~
purplelobster
The problem is, you can discredit any failed startup by saying their MVP just
wasn't viable enough. Well, duh. Knowing what's viable and building it is the
difficult part, but isn't that what lean methodology is supposed to help with
to begin with? Lean methodology inadvertently makes it seem like the hard part
is the easy part, and therefore confuses people.

~~~
dragonwriter
> Knowing what's viable and building it is the difficult part, but isn't that
> what lean methodology is supposed to help with to begin with?

Lean approaches (including, but not limited to, lean startup) provide basic
rubrics about where to focus your efforts to optimize return for effort. They
aren't, however, a magic wand that substitutes for skill, judgement, and
domain expertise (well, perhaps a _little_ for the last, since inherently lean
uses the scientific method to _grow_ domain knowledge in a highly-focussed
way, but unless you've got a deep reserve of resources to fund failures that
you learn from, or get really lucky, you are still likely to fail without
domain expertise going in.)

The biggest problem with lean now is it is being treated as if it were a
formulaic, recipe-driven methodology that substitutes for specialized skill,
when lean is pretty much an anti-recipe approach that is all about everything
you do being part of a continuous hypothesis-test-review improvement cycle,
including the kind of things you might get from a book discussing practices
that _others_ developed via lean, which may provide a starting point for your
practices, but not a fixed methodology.

------
orangethirty
Ship early, ship fast, ask questions, write down answers, run tests. That's
what "lean" is all about.

------
josephturnip
Ironically, the first two of the "four livelihood-threatening fundamentals"
that the Lean Startup methods distracted them from are pretty much verbatim
parts of the Lean Startup method.

------
csmatt
What is the difference between a software startup and a small company that
writes custom software?

------
Uchikoma
What I tell a lot of people: Iterate on ideas, do not iterate on quality.

~~~
NirDremer
I agree. Once one decides that there's a problem worth working on the
iterations in early stages shall be to test different ideas how to solve the
problem.

------
starrhorne
Some markets just don't self serve.

