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.
Fat startup: Learn the lessons of my failed Lean Startup
11–20 of 72 posts
Re: Fat startup: Learn the lessons of my failed Lean Startup
#12Sorry, 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…
Exactly, viable = vendible. If there are no customers, than you didn't make your homework right and built something that nobody wants. I'm affraid that this misassumtion about mobile app can be caused by the feedback from customer interviews. You shouldn't rely too much on what people say, ask them to pay for your product instead.
Re: Fat startup: Learn the lessons of my failed Lean Startup
#13Ironically, 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.
Re: Fat startup: Learn the lessons of my failed Lean Startup
#14Many 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... - metrics in early stage http://www.slideshare.net/andreasklinger/metrics-for-early-s... - 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...
Re: Fat startup: Learn the lessons of my failed Lean Startup
#15Sorry, 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…
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
> the minimum viable product [...] has limited practical
> use. Customers aren’t interested in funding your “learning.”
Re: Fat startup: Learn the lessons of my failed Lean Startup
#16Many 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…
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.
Re: Fat startup: Learn the lessons of my failed Lean Startup
#17> 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…
What is it about the word "viable" that seems to make everyone read right past it?
Re: Fat startup: Learn the lessons of my failed Lean Startup
#18Many 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…
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.
You are completely right. Sorry i just wrote it in one go.
I tried to restructure it. Hope it is now a bit clearer.
Re: Fat startup: Learn the lessons of my failed Lean Startup
#19Sorry, 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…
"The purpose of your first release (and every other release) is to give your customer immediate value."
Exactly. That's a MVP, not a crappy product which doesn't even work.
Re: Fat startup: Learn the lessons of my failed Lean Startup
#20Critical 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.