The Strong Pull Of Faulty Logic

Say you're a software business. How should you develop products? See if you can follow along:

Ideas

Well, obviously you need to start with an idea. Get them from customers, stakeholders, sales, or marketing.

Business Case

Now, for each idea, we'll need to assess how much value it brings us and how much it costs to build. All pretty obvious.

Roadmap

Once we've got a business case for each idea, we can rank them and put them into an ordered roadmap for the next few quarters.

Requirements

Time to flesh it out. A product manager turns the vague ideas into concrete requirements, whether in the classical form of user stories or some other sort of spec.

Design

Now it's pencil to paper. What will it look and feel like? That's where interaction and visual design come in.

Build

Now that the idea has been turned into functional requirements and a look-and-feel design, it's the engineer's turn. They write the code and build the thing.

Test

Don't forget to test! Does the thing match the requirements? Does it break in any other interesting ways? If yes, back to the engineers it goes. If no, on to the final step.

Deploy

Ship it! Send it to the servers, make it live, and reap all the benefits identified by the business case.

Sound good? Was I able to trick you? Because this is the process described in chapter six of Marty Cagan's great book, Inspired. The chapter's title is: The Root Causes of Failed Product Efforts. It's exactly the way he laments leads to so much unnecessary toil and failure.

Yet it's also still the most widely practiced approach to product delivery. Why is that? Because, reading along the list above, it's easy to fall into the trap of nodding along. If you have followed my newsletter for a while, you might already know a few failure modes I've talked about (like the build/test handoff issue).

Over the weekend, have some fun pondering the myriad ways in which the above process fails, and keep tuned for next week's newsletter to read my own take.