7 ms·
I've been re-reading "The Inmates are Running the Asylum" and am no longer convinced that "2. Launch fast" is true. Launching and iterating a product quickly c
by 10dpd 10y ago
I've been re-reading "The Inmates are Running the Asylum" and am no longer convinced that "2. Launch fast" is true.
Launching and iterating a product quickly can easily lead to false negatives, where an early unpolished product that does not quite meet the needs of the end user might turn off users and harm the brand for good, but by involving user research before launch, product fit for users can be evaluated and iterated on without annoying potential future customers.
- deleted 10y ago[deleted]
- junko 10y agoI think it also depends on the type of startup you have, and how confident and knowledgeable you are of your target market. I'm currently reaching the end of the ideation phase, and although I'm familiar enough with my target users, I plan to spend a few months in Asia (where they are) to test my assumptions - hidden and conscious - and see if I'm missing out anything else. No matter how careful and smart your assessments are, ultimately it's all in your head! So yes you're right, we need to be wary of false positives and make sure that we really understand our users. But launching fast is a pretty valid idea too; personally it would be a wasted opportunity if I go on the trip without anything to show! A simple prototype can be more powerful and a much better conversation starter, plus the further advantage of lighting the fire under your bum. That would close the catch 22 loop, I hope.
- andrewstuart 10y agoI agree with this. The obsession with building something fast means that the market is flooded with shallow products that are little more than a website plus a months worth of coding. Hey a new food delivery startup! Hey a new messaging startup! Hey a new job website! No wonder they are all the same. I've been building something for 18 months now and whilst I could be proven completely wrong, I feel like I'm working on something people will want and I feel like getting it built right is the correct thing to do. The thing I am building needs alot of bits and pieces to be in place and working in order to realise the original concept. The MVP and "release fast" line of thinking says "too long, get it out there", but this would result only in releasing software that doesn't do what I envisioned it doing - what would be the point of that? I really think the opportunity going forward is to build products that are hard to build and require lots of work to implement the actual vision, but ultimately to come out with a product with deep value. I like the idea of building something deep and technical and functional. We shall know soon enough if I am right or wrong as I plan to release soon....
- aytekin 10y agoYou can start with a shallow product and slowly build it up with user feedback to create a defensible and deep product. The key is to continuously improve it.
- marcosdumay 10y agoNo, you often can't. If you could, it would be already done by one of those shallow initiatives the GP is talking about. I'd be very interested on any ideas about how to make deep innovation less risky. For shallow ones is "launch fast", but what to do when this one is not available?
- coldtea 10y ago>No, you often can't. If you could, it would be already done by one of those shallow initiatives the GP is talking about. Well, a lot of them have. Besides "you often can't" is not very helpful. The question is whether it's more difficult because you started as shallow or not -- not whether it's not a 100% surefire way to make it.
- rogerdpack 10y agoMaybe you can start with "just one feature" and then work forward... [?]
- BatFastard 10y ago>I like the idea of building something deep and technical and functional. Here here! However its easy to get lost in such products. That why there is still a lot to be said for knowing your MVP. I fight this battle everyday.
- matrix 10y agoI totally get where you are coming from. I really do. Some software is just complex, and it feels impossible to ship anything without all those parts in place. Regardless. You must find a way to ship early and often. You will go under if you do not. It helps to make a mental shift, and understand that the problem you are trying to solve is not related to features. You're trying to prove whether enough people want what you are building, and if so, what exactly it is they want (you will get it wrong the first time, and probably the second time too... this is why iterating fast with as many customers as possible is key). Will the product be sort of crappy and missing all sorts of "essentials"? You bet. But, crappy code that does what people want and they will pay money for always, always beats an untested fully-engineered solution.
- jomamaxx 10y agoAgreed. I think this is a circumstantial point. I suggest that if you have a much more intimate understanding of your customers - AND - enough self-awareness to be objective in determining what they need vs. what is nice-to-have ... then you can go further. Maybe the rule should be: launch as soon as you have something that will provide value to someone, i.e. MVP in the technical sense of the term.
- ptero 10y agoI agree in general -- one should have utility for users to launch. But I suspect PG is seeing (many) more startups that do not release when they could ("we will do one more iteration" to mean "we do not need to deal with users, ops, etc.") than those that release too early.
- rrecuero 10y agoI agree with this. Lean Startup got really popular in the last years and it is a great tool but it only works if you are in the ballpark. Peter Thiel said that it is a way to reach a local maximum. If you are not in the area, you won't get enough feedback to iterate, you'll need to pivot and play again. It's like a game of bocce ball in that sense