I am always skeptical when I hear someone describe their start-up and it sounds really complicated (especially if they haven't launched yet).
I suppose it is possible to deliver complex systems that work for users, but it's extremely hard. And it's already very hard to deliver even simple systems that work for users, so if you like to change your 1% odds into 0.01% odds, either you have money/time to burn, or you're making a bad gamble.
Echo that sentiment. When I hear an overly complex solution or idea, I think that person either doesn't know what they are talking about or that the solution is for a hyper-niche situation. Usually, asking a few "Heilmeier-type" questions will lead to classifying the person in the former group.
And I admit to being a member of the former group myself, too often, I'm afraid.
George Heilmeier was a former DARPA director, for whom the Heilmeier Cathechism is used by DARPA PMs to judge projects. These simple questions are excellent for understanding other projects, and I use them to keep my own projects on track. I also use them as the basic outline for presentations.
I'm the author of the blogpost and I feel I didn't write enough about how I differentiate simple and complex. Here's a good but very software-specific example that might illustrate that. Imagine you told a programmer (or team of) to create a Digg clone. How many of them would build the entire system with all the features (submissions, comments, friends, profiles, media types, categories, etc.)? I'll wager that most people will attempt to do so. As a result, they'll probably fail. That entire Digg "system" is what I would call complex. On the other hand, when given such an assignment, you should try to write something simpler which would at once also be useful. In this case, write something like Hacker News (but take out comment threading, karma and a few other things)! Once you're done building that, you can slowly add profiles, categories or whatever would benefit the community the most. That's the meaning of "start simple, use a lot and evolve"
Another thing, it's important to remember that what was complex yesterday is simple today as we move to a higher-level of abstraction.
In the academic/applied research setting, I find sensor networks are the canonical example of this phenomenon. People jump off into "secure energy-efficient self-organizing" sensor network architectures, that they lose the ability to even articulate the problem they are ultimately trying to solve.
A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system. this isn't always true.
Basically you can do two kinds of products: evolutionary and revolutionary. Evolutionary products can start as something simple and evolve into something more complex. They are the ones we usually talk about because they are easy to do, and make up the bulk of all digital products.
Revolutionary products are the ones that can't evolve from something simpler but have to be complex from the start to serve a meaningful purpose. The Apollo space program is a good example: It probably wouldn't have worked very well if they "launched early and launched often" and fixed problems as they went. It would also require too many suicidal astronauts ;-) It had to be perfect the first time. It's basically the same issue as irreducible complexity in evolution: All the intermediate steps have to be useful, or you won't ever get to the finished product. Incidentally this is also why you don't see moving parts such as wheels in biological organisms: The steps leading up to it are no good. Aeroplane manufacturing is the same thing: Either it works or it doesn't.
The areticles advice pertains only to evolutionary products and startups.
I'm not so sure you're interpreting that quote correctly. The Apollo space program didn't really start out with the declaration that "we're going to put a man on the moon", it started out with a bunch of rocket scientists in Germany trying to lob bombs onto London. And before that, of course, there were even simpler attempts to build rocket-like devices.
Then, looking at the Apollo program itself, they didn't send someone straight to the moon. There were many simpler missions before they finally culminated in the moon landings.
The point of that quote is that even something so monumentally complex as the Apollo space program started with something simpler that worked, and evolved up from there.
I would suggest that revolutionary start-ups are precisely the ones that need to start simple, because it's not quite clear where they're going, so they need to figure out the simplest thing that works before making it more complex. Evolutionary start-ups, on the other hand, can probably afford to stand on the shoulders of previous attempts and start with something a little more complex, because they already know what works - but even that is risky.
No, the Apllo program didn't start with rocks and sticks and built from there: If you go back far enough you can probably assert that everything derives from fire. but I think that's kind of missing the point.
Of course they did tests. Of course they fired small rockets in the Mohave desert. But they did it all with one simple goal in mind: Putting a man on the moon. They knew exactly where they were going, and everything they did was just preparations for that. They knew that their final, and only, test would come the day they launched. The difference between evolution and revolution as I described it above lies primarily in whether you know the goal.
It's definitely possible to take the evolution route (I don't quite agree that there's a clear dichotomy between revolution and evolution) and have a goal in mind. I'm sure Steve Jobs had already envisioned the App Store when he was working on iPhone 1.0. The difference between complex and simple lies in focus. The reason it's not possible to build complex systems from scratch is that you just can't focus on so many different parts/components and integrate them together as well. Apple builds successful products because they focus on a few things rather than do everything all at once.
As for your other point, I believe Gall's law (your quoted bit) holds true for all cases but the other rule I added about each intermediate step being useful might only be true for some cases (perhaps, more for user-facing products).
You're right that the blogpost might only pertain to "evolutionary products and startups". I wrote it with software in mind but my guess is that it's also mostly true for other kinds of things. I need to think further about them.
The Apollo space program is a good example: It probably wouldn't have worked very well if they "launched early and launched often"
Actually, they did iterate and take small steps. They started with unmanned suborbital launches, went to manned suborbital launch, then manned orbital launch. And that was just the Mercury program. Next, they went to launching 2-man capsules, spacewalks, and on-orbit rendevous in the Gemini program.
It would also require too many suicidal astronauts ;-)
You have an implicit assumption that rapid iteration means poor quality control. It doesn't have to. I've met people with formal methods tools who say they are capable of rapid iteration. (And yes, these are marketed to the aerospace industry.) Also, if you manage a project from the start with automated testing, low defect rate is very doable.
Aeroplane manufacturing is the same thing: Either it works or it doesn't.
Uh, no. There are lots of examples of planes that kinda worked. This is why test pilots have to be so good. You have to be very good to get a kinda-working plane back on the ground in one piece, or sometimes even to just manage to eject from it.
Your point may be good, but it suffers from drawing from examples which you don't have very good knowledge about.
"You have an implicit assumption that rapid iteration means poor quality control. It doesn't have to."
I would actually go a step farther and assert that strong quality control facilitates rapid iteration. My 15 years of experience in software bears this out -- the (extremely rare) projects with quality control were far smoother than the ones without. In ones without solid QA, the software become so convoluted and messy that rapid iterations became entirely infeasible. There was no way to change the software without re-writing large chunks of it, or putting in a large collection of hacks that broke as much as they fixed.
Maybe we have different interpetations of "revolutionary." I see something like the transistor a revolutionary discovery/invention. It rests on some pretty complex physics, but is a small and fairly straightforward concept to explain. Yet it has changed electronics and the way we live forever.
The same could be told of the discovery of DNA's structure. Everyone can imagine the double helix, but it has spawned an entire industy in bio-engineering.
"Basically you can do two kinds of products: evolutionary and revolutionary. Evolutionary products can start as something simple and evolve into something more complex. They are the ones we usually talk about because they are easy to do, and make up the bulk of all digital products."
That's not true at all. Complexity has absolutely nothing to do with whether or not a product is revolutionary or evolutionary, that's just from the idea(s) behind it.
The Apollo program DID launch early and often. In reality, the R&D behind it began long before we decided to send people to the moon.
