I’ve been involved in the development of a number of product development processes—which is to say, the creation of the pipeline from idea to reality. The outcomes are always useful, and always sightly different. But there are commonalities, such as the breakdown of the process into various phases. These are usually combinations of Concept, Exploration, Elaboration, Definition, and so on. (Sometimes they include “Ideation”, a particularly unpleasant verbation of a perfectly innocent nounicle.)

The processes provide useful reminders of what people should be doing. For example, the very existence of a Concept phase, in which the purpose of the proposal is clarified, might seem too obvious to bother with, but most people who have spent a while in the industry will testify to working on too many projects where the purpose is ill-defined, and time is wasted while people try to deliver something without any agreement or verification of what success looks like. (Such projects tend to be little more than the buzzword du jour: Mobile app, Cloud, API, etc.) Detail of the Concept phase, for example, might remind product managers and execs that around here we are expecting to use a business model canvas, so demand it, and get used to understanding it.

I find that the problem with these processes, though, is that there is too much detail for those who aren’t directly involved in the product development process. The pipeline tends to look like a waterfall methodology, filled with artifacts and outcomes specified in 8 point font. More iterative approaches exist, but that’s still a lot of detail if you’re not closely involved in process. Abstracting away is difficult if it’s to be meaningful, but still carry the essence, for key stakeholders on the edge of the activity (the Cs and Is in the RACI model).

A simple abstraction for me, then, is the Z-like figure at the top of this article. It’s intended to remind everyone of the overall purpose of a product development process (e.g. for exasperated executives who cry “But I just want a mobile app; what have you been doing?”) or why we’re having yet another meeting about the same thing (e.g. developers, mystified as to why the product manager isn’t just giving them a nice, clear product spec).

Reading from left to right is a progression of time. The upper triangle, which is larger on the left, indicates the excess of ideas, proposals and options that gets thrown at the product team. Over time (moving to the right) we want to reduce this number, retaining only the most valuable ones. The lower triangle, which is gets larger as time goes on, represents the resources (time, people, money) we want to dedicate to these ideas. Overall, the purpose of our product development process is to whittle down the number of proposals in the pipeline, using more of our precious resources to progress only those that justify it. Initially there should be a low resource cost to strike out a few of the less useful ideas; we can use a bit more resource to filter out some of those that remain, given that they have at least minimal merit; then we bring in a bit more expertise and effort to reduce uncertainty around those that remain; and so on.

Any one product development process can be split into any number of phases, and we can label them however we like (cf: Woody Allen). That can be useful to set stakeholders’ expectations around their involvement, and the kind of uncertainty we’ll have flushed out after each stage. Different kinds of organisations will also end the process at different stages. Traditionally the process would end when we move into the Build phase; more progressive places will want to employ build-measure-learn, indicating that there is more uncertainty to flush out even after the work goes into Build.

But aside from those details, the overall idea here is to take a step back and explain the purpose of the product development process to those who aren’t always so closely involved. Then the Z-like figure can be embellished according to our particular requirements.