The greatness of a product can be measured in smiles.
I truly dislike the concept of “minimum viable product” or MVP. My goal is to create great products, not to expend the least effort to get something out the door. Look at this from the perspective of a consumer: Who wants a product even the creators think is half baked?
I see so many tweets about agile, epics, scrums, story points, etc. and none of it matters. We didn’t use any of that to ship the best products years ago at Apple.
Exactly none of the most common approaches I see tweeted about all the time helped us to make the original iPhone. Oh, and we didn’t even have product managers. We never thought about it in terms of what was minimally good. We wanted it to be a great product. That was the standard we set. That outlook contributed to how the product turned out.
Do you know what worked? A clear vision. Design-led development. Weekly demos to deciders who always made the call on what to do next. Clear communication between cross functional teams. Honest feedback. Managing risk as a function of the rate of actual progress toward goals. [source, 2]
During the development phase of a product, I make as many iterations on prototypes as I can. More is better. These prototypes are almost always half baked. They’re filled with wrong stuff. That’s what they’re for. They’re part of the effort to find the right path. I’ve always looked at shipping as a moment where I take people’s time and attention into account. Would they want the thing like this? Is this the best I can do for people? Is there anything critical that’s missing? Is this product going to cause more frowns or smiles? To me, the development phase of a project is everything before beta. By time beta rolls around on my work, the design and features are complete. Beta testers can try everything out for reals. No show-stopping bugs either (at least none that are known). [source]
There is no consensus on what makes an MVP. Some say MVPs don’t ship—they’re internal prototypes. Others say MVPs go out to a limited audience as a beta. Yet others say MVPs are a way to get early-adopting paying customers to use a shipping product.
The first demo for a new project does not need to be right—it very rarely will be. However, it should be clear and express a point of view. In a happy and healthy design process, such a demo will elicit reactions and point the way to the next step: keep A, discard B, more of C, less of D, etc. No more of that” is an excellent review outcome. From the universe of possibilities, you now know one thing that isn’t the answer. Progress!
Demo a product often while building it, ideally with far more “show” than “tell”. Effective demos create a setting, run through a scene, and lead to a decision on next steps.
Setting. An in-development product doesn’t completely work, so a demo needs to creates an island of illusion around a portion of the product, focusing attention on a part that does work in a way that approaches the vision for how it will when it’s ready to ship.
Scene. Like a take in a movie, with explicit “action” and “cut” moments, show the product in character, as if it’s doing its job in the real-world setting. If everyone squints, you all can imagine the product doing this task with all the other features and aspects around it.
Next steps. Did the demo go well? Should the final product work exactly as shown? If yes, wonderful. This part can be used as a foundation to build around in future demos. If not, what specifically should change? In either case, it should be stated clearly what comes next. If you demo in this way often and repeatedly, the settings expand, the scenes become more and more like everyday usage, and eventually, the next step is to ship it. [source]