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.
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....
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?
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.
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.
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.
Read Four Steps to the Epiphany and apply the process described therein. You'll be able to turn your feeling into an actual conviction.
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.
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
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.