Hacker News Reader

Comment by nadam | Hacker News Reader

Agile, MVP, Iterative development: these are common knowledge by now. But I think there are problem spaces where this does not really work becasue even an MVP must be huge, otherwise users will simply ignore the product. You cannot write a small MVP of a browser, an operating system, a search engine, a game engine, a 3D modeling suite, etc... I think markets in problem spaces where you can start with a very small MVP become oversaturated, because everyone wants to start a product with a 1 month MVP development. So you will have a competitive advantage if you are able to design products in problem spaces where even the MVP is relatively big, so you can attack not-so-oversaturated markets. I think the ability to design complex products becomes an important skill.

View on HN

> You cannot write a small MVP of a browser, an operating system, a search engine, a game engine, a 3D modeling suite, etc

I don't think that's true at all. You absolutely can and should build an MVP of all these things. You certainly could release an MVP search engine (or even a browser-based game). You probably can't hope to gain traction at large with an MVP browser or operating system, but you can start using these things internally and dogfooding them.

IMO, iterative development isn't necessarily about releasing something fast to the public, it's about rapidly building a working version that you can interact with, test properly as a whole working system and show people, so you can quickly figure out what are the most obvious issues to address and improvements to make. You can test this software internally, show it to your friends, have a small private beta or even hire testers depending on your project and budget.

This is in contrast to a more traditional/naive development model where the team isn't even trying to have a working/testable version, and instead focuses on spending weeks/months building components separately, which they hope will come together into some grand vision at the end. This approach is terrible because things likely won't come together seamlessly. The different components can fit together poorly, effort is wasted on features that weren't actually good ideas in hindsight, etc. Software projects developed this way are often late, overly complex and poorly designed.

Completely agree with this. Previously I was a PM at a rather large (valued >1bn) sales software organization. I was tasked with building a completely new product to replace the original product. We built an MVP and had our internal sales team use it. It wasn't easy, it took some motivation to get them to use it over the large, steady, enterprise solution they were used to. But, they used it enough that we received considerable feedback that we rolled into the public beta, which was much bigger than an MVP.

I agree. If you look at the book The Lean Startup, it’s pretty hilarious how hacks like skipping player movement animations led to a “teleport” effect for the imvu product that users loved. That’s a great example of mvp working - they didn’t know what the customer wanted, and the customer actually preferred the hacky shortcut.

right. the house example is plain wrong.

What I think the author should have used is a car. First, we design and test the suspension, then the wheels, then the brakes, etc until we have a working car from the ground up. Then we sell a lot of them.

The OS / game engine /car example is frightening because you have no intermediate value until the whole thing comes together. hiccups propegate.

However, an iterative approach would create a minumum feature version first.

A car with no suspension, 25 HP, and one seat. An OS with virtually no drivers, targetting single arch, bad scheduler, single filesystem, and single user.

These are, in aerospace analogies, testbeds in which you validate your long term vision while producing real things that can be sold, hyped, or used to look for improvements and bad assumptioms before the final product is produced.

I completely agree with your statement that markets become saturated with Min Viable Products ... but that is what forces iteration. I agree with the author (and this isn't new knowledge) that iteratively buidling a better thing by expanding a pre existing thing helps you capture and scale.

My opinion is this probably gets hard once that thing gets big, and starts to feel clunky, and thats where the big companaies do a "re-engineering" with a waterfall-like model. They can afford to take time to design soup-to-nuts because they are still selling the iterative MVP mutant that got them to dominance. Different strokes for different folks.

Don't forget - the product is also the factory - it is the factory that Musk has been iterating towards - they built the car very manually to start with.

> You cannot write a small MVP of a browser, an operating system, a search engine, a game engine, a 3D modeling suite

"MVP" tends to wind up meaning vastly different things to different people

who says you can't leverage what's out there to build any of these complex things? An MVP of a new browser might start out as a chrome extension, or a fork from chromium. An MVP of a new search engine can leverage google, and bolt on some custom thing to the end of it

Tesla for example built the Roadster starting with leveraging a https://en.wikipedia.org/wiki/Lotus_Elise frame

Amidst the Lean startup and agile craze, the concept of a set of ‘Minimal Marketable Features’ seemed to have been lost.

‘Minimum Viable Product’ is not the same as a product that is ready to capture real market share, just a validation checkpoint(ideally one of many).

I want to +1 this but also add to it.

I worked on a safety critical system (among many others, but this one in particular) that was developed in an iterative fashion. The "MVP" was not sufficient for fielding the aircraft, it was sufficient for testing the aircraft. Each successive iteration was meant to be closer to what was needed for later testing stages, and finally a release that was good enough (not feature-complete, but complete enough) to allow for carrying passengers.

Most of the later additions were "nice-to-haves". They provided better reporting and recording of issues, better BITs (built-in-tests) which reduced maintenance effort, etc. Nothing essential for safety, but useful for improving overall quality-of-life issues for the operators and maintainers.

Each stage also ensured that we were building what was actually needed (reporting the right kind of things, reporting it in the correct way, etc.) before we spent millions of dollars and years of effort on the wrong thing.

Being a "minimum viable product", it may actually be quite big and take a long time to reach. To me, the goal of properly defining an MVP is that you do everything needed but nothing more.

And getting stakeholders, or users, in the loop and validating at each iteration is still worthwhile to make sure you actually build the right thing.

Reply on news.ycombinator.com