Item 18: Prototype Early and Often

When we show sketches, mockups, slide decks, bulleted lists of features, etc, what we're trying to do is get something concrete in front of stakeholders before we have a product to show them. Ideally, we'd like to show them a product, except building a product takes time, and time is money. However, what costs more time and money is when you eventually build the product, and even though you've shown your stakeholder all those sketches, mockups, slide decks, and bulleted lists of features, it turns out that they wanted something completely different. In order to avoid this:

As soon as you have an idea of the simplest possible thing you could build in order to validate that you're thinking of the product in the right way as the customer, prototype it, put it in front of them, and ask for feedback.

If you have "user stories" or "customer journeys", or are practicing the techniques mentioned in Item 7, a great way to get started prototyping is to take the most important journey and implement it as quickly as possible. Note that because it's a prototype, just focus on bare functionality, and do not focus at all on code quality. You can then put this in front of stakeholders and gather feedback.

The science here is pretty simple: all of those conceptual artifacts that are not the product are models that approximate an abstract version of the product. Like all models, "the map is not the territory" (BIBLIO: GREAT MENTAL MODELS), and like all models, they are subject to "model error" (BIBLIO: Black Swan). The problem is, as expressed in Item 1, the stakeholders might not know what they want until they see the actual product. Prototyping is a perfect way to dramatically reduce the turnaround time for demoing a product and putting it in front of the customer.

Besides, who wants to make slide decks anyway?