Recently, I was working with a client, designing an application for them. We worked for a few months, from concepts, to sketches, to high-fidelity wireframes, which were then transformed into detailed requirements documents, to hand off to an internal development team. The process (for a relatively simple application) took about 6 months, 2.5 of which were design, the rest, translation into formal requirements.
Safe process, right? Ensure you’ve got all the Ts crossed, and Is dotted, making sure you can accurately estimate development resources, and plan accordingly, so you can sync other functions of the business (marketing, support) with the plan.
Until it doesn’t.
This formal process of prepping high-fidelity documentation for product development is generally the go-to approach for enterprise teams. But it has problems. For all the safety in this extensive documentation comes some real risk for the product:
Products Aren’t Snapshots
Putting together formal documentation and requirements for a product takes a long time. Months, sometimes close to a year. In that time, so many things change. You learn the market better, the market changes, your strategy changes. With that documentation so meticulously prepared, you end up locked into a strategy that made sense months ago, but is now less relevant.
Formality Squelches Creativity
Your product team are your greatest source of creative solutions when building your product (duh). Your designers, developers, marketers, salespeople and all the others working around the product are the engine that drive things, and their collaboration can create huge leaps in the product experience.
Formally documented products remove this creativity. A carefully documented screen or interaction becomes a tightly scoped instruction to a developer, who might see a more interesting way of solving the problem, but is hamstrung by the process.
That powerful creative force that you’ve got in your product team is effectively neutered, likely replaced by rounds of compromise by committee. The product ends up being safe and mediocre, not innovating and game-changing. Not what you set out to create, was it?
The Sunk Cost Fallacy Kills
When you spend months documenting a product, meticulously designing every detail, you’re investing scads of time into that process. Every minute you invest becomes a sunk cost - time invested that you don’t want to waste. As a result, ideas that are invalidated later in the design (or even development) process are harder and harder to revise. Sure, that feature looks less important now, but we spent so much time designing it, we can’t just drop it.
This is the sunk cost fallacy, and it sinks a lot of products (pun definitely intended). When you invest a lot of time or money into something, it becomes harder emotionally to kick it to the curb. You want to ride it out as long as possible, even against your best judgement. You launch, it fails, and the blame game starts.
When you build products, you have to be willing to get rid of stuff mercilessly. Else, you end up with a Frankenproduct that no one loves.
Low Fidelity To The Rescue
While it’s not always appropriate, taking a lower fidelity approach is often faster, lower risk, and helps to engage more creative resources on your team. An idea for a new features isn’t meticulously detailed, it’s drawn out roughly on a whiteboard in 30 minutes, in collaboration with design and dev (and marketing? and support?), and then each party is sent off to apply their interpretation and magic to it. If you are hiring the right people, this allows them more creativity to make magic when actually building it, taking the solution far past that design-by-committee approach that is too often used.
Designing informally like this also eliminates (or at least vastly reduces) the sunk cost fallacy effect. You spend 30 minutes before lunch whiteboarding and brainstorming, and by the end of the week, that feature is out in the world. Didn’t work well? Kill it or revise it. Because less time was invested in detailing it out, there’s less attachment to that particular solution, allowing you the freedom to get to the correct solution faster.
The point is, when you build products, you almost always build them wrong. Everyone does. The only way to get to the right product is through cycles and cycles of iteration. You can either make quick mistakes, or make long mistakes. At the end of the day, it’s about the money and time you’re burning. Dollars per mistake (as a function of time) is a good metric for seeing how efficient you are at getting to the right solution.
Next time you need to build something, stop and take it to a whiteboard, and see if that’s enough. I bet you’ll be surprised.