Product Development Flow

Product Development Flow

I’ve been seeing a lot of funny looks and blank faces recently. Although not unusual <wry grin>, in this case it’s been when answering the question “What’s your job title?”. My reply, for the record, has of late been “Head of Product Development Flow”.

I suspect that the terms “Product Development” and “Flow” both are causes for confusion and puzzlement. And I also suspect that the combining of them only compounds the bewilderment.

So, here’s my explanation of each term, and then of the combination, along with some minor digressions and mention of other related ideas, along the way.

Product Development

Some folks, myself included, use the term “Product Development” to describe the myriad of activities involved in taking an idea from e.g. a vague concept to a fully-formed design for a product. In other words, the elaboration (a.k.a. “development”) of an idea for a product into something that, once instantiated, is compelling enough that potential customers will be willing to pay money for it. Wikipedia happens to have an entry for “New Product development” (Caution: much misinformation there).

Personally, I regard product development as not only the elaboration of ideas for new products, but also the elaboration of new features for, or variants of, existing products.

Aside: In the world of software and software products, the continual release of updates and new features is the norm, and happens much more frequently than the introduction of completely new products.

Whole Products

Few are the organisations that approach Product Development systematically. Fewer again are those that share Toyota’s practice of explicitly ensuring all aspects of a product design are created in a joined-up way. Toyota’s TPDS has the concept of the “Big Room” or Obeya, signifying their emphasis on getting all the various specialists necessary for creating a “whole product” design (in Toyota’s case, a design for a new product line) together in close physical and temporal proximity. This approach is, in part, what allows Toyota to bring complete new car designs to market – cars rolling off the production line and onto the road – in around 18 months, compared to GM’s 36 months (source: BBC News, 2007).

Flow

Flow (n): the movement of a product or service through the process which creates it.

In the context of product development, we might choose to modify this definition slightly:

Flow (n): the movement of the designs for a product or service through the design processes which create them.

And continuous flow:

Continuous Flow (n): The progressive movement of units of design through value-adding steps within a design pipeline such that a product design or service design proceeds from conception into production without stoppages, delays, or back flows.

Operational Value Streams

There are many way of looking at a business, but the mental image I use most often in the context of Product Development is “business as a series of operational values streams” (cf. Allen Ward), where each such operational value stream’s business-as-usual consists of a bunch of people (often assisted by technology and/or machinery) adding value to some raw materials – and delivering units of product or service for consumption by the business’s customers. These operational value stream folks would use the product designs created by the “Product Development” folks to tell them how to manufacture and assemble the product(s), or in the case of a service, how to deliver the service(s).

See also: Value stream mapping, Prod•gnosis, Flow•gnosis.

Note that in most businesses, organised around silos (a.k.a. functional departments) as they are, the value streams are notional rather than actually manifest in organisational policy. And their business-as-usual rather, erm, haphazard. The day-to-day (business-as-usual) operational processes (the way the work works) are rarely designed, per se, but rather grow up, like Topsy, over time. With much management tinkering.

Prod•gnosis

I’ll just drop a mention of Prod•gnosis in here. Prod•gnosis refers to my concept of having a “Product Development Value Stream”, responsible for the instantiation of each and every operational value stream within a business.

Typically, when a business first decides to launch a new product line, the product design(s) for the product line will be developed, and then these designs will be sliced-up, and stuffed into the various functional departments of the business, alongside the slices of current products. There will likely also be large gaps in the product design, due to an absence of “whole product” thinking. Various functional departments will have to rally round and (reactively) patch these gaps as they see fit.

For example, a Marketing department may be surprised by the imminent arrival of a new product line, and then feel obliged (to jump) to develop the marketing collateral for that new product line.

With Prod•gnosis, each operational value stream is the “whole product” for that product (line). As an integral part of the “Product Development”, all the operating procedures (processes), support and admin systems, interfaces to common “shared” services – such as billing or CRM systems – etc. are part of the design for the operational value stream in question. By “instantiating” this value stream design – by, for example, adding the people and equipment needed to “run” the operational value stream – the business has the necessary means to sell and support the product line in question. This instantiation can happen once, or maybe even several times in e.g. different geographies.

Aside: You may spot some similarities here to the model often used by franchisers.

Of course, Prod•gnosis is an ideal. But one which I suggest is entirely feasible to use as a model, and to “grow into” progressively, as the product development competence of the organisation grows and matures.

And just in case you’re thinking I’m making a case for a big, up-front design of a new operational value stream – I’m well aware of the egregious dysfunctions inherent in BDUF. No, rather I’m thinking more in terms of a Lean Startup-like approach – instantiating version 0.1 of the operational value stream as early as possible, conducting experiments with its operation in delivering an MVP (even before making its 1.0 product line available to buying customers), and through e.g. kaizen by either the product development or – the few, early – operational value stream folks (or both in collaboration), incrementally modifying, augmenting and elaborating it until the point of the 1.0 launch, and beyond.

Product Development Flow

Basically, the idea of Flow – a fundamental concept in e.g. Lean Manufacturing, Lean Service, etc. – relates to the continual delivery of something of value to someone who needs it.

In Lean Manufacturing, it’s the continual delivery of product units – such as cars – to customers.

In Lean Service, it’s the continual fulfilment of service requests in response to demands from customers, a.k.a. “service users”.

And in Lean Product development it’s the continual delivery of (whole) product designs into the business, and thence – via e.g. the operational value streams of manufacturing or service delivery – of instances of those designs into the hands of the business’s customers.

So, pulling this all together: I use the term “Product Development Flow” to refer to the flow of new product designs into the business. The operational side of the business can then take these new product designs, slice them up (and patch the gaps) and stuff them into the organisation, to sell and support alongside existing products.

For businesses that embrace the idea of the “whole product”, “Product Development Flow” refers to the flow of new “whole product” designs into the business.

And for businesses that embrace the ideas of Prod•gnosis, “Product Development Flow” refers to the flow of (one or more instances of) complete new operational value streams into the business (in the case of new product lines). In the case of new features for, or variants of, existing products, it refers to the flow of updates to existing operational value streams. We can imagine we might like to do this incrementally and iteratively, in the Agile way.

Measures

We might choose to monitor the flow of each new product, whole product, or operational value stream – in terms of things like:

• Rate or speed of flow (in, say, throughput dollars/day, or function points/month)
• Lead time (time between a customer requesting e.g. a new feature and them beginning to use it)
• Cycle time (time, on average, between starting on the development of a new product or feature and the completion of that new product or feature i.e. ready for sale)

And we might also choose to monitor the flow through the product development process itself (the design of new operational value streams, or updates thereto):

• Rate or speed of flow (in, say, new operational values streams, or updates, per year)
• Lead time (time between the business requesting a new operational value stream or update, and its instantiation, ready to serve customers)
• Cycle time (time, on average, between starting on the development of a new operational value stream or update, and the completion of that new value stream or update)
• Process cycle efficiency (PCE – ratio of value-adding time to lead time)

Big Head

And as for the job title, “Head of Product Development Flow”? For me, it refers to a role with the responsibility for helping folks in the organisation move towards improved flow of new products and updates, new whole products and updates, or new operational value streams and updates, into the business.

To use an analogy, it’s a bit like the role of a master plumber: planning, installing and then overseeing the operation and maintenance of the organisation’s “concept-to-cash” pipeline. Making sure the pipework is fit for purpose, installed competently, continually adapted to changes in circumstance, and kept clear of blockages, scale and corrosion – so that “value” can flow smoothly, reliably and continuously from ideation at one end to satisfied customers at the other.

And what does “improved” mean? Ah, well, that’s a good subject for a future post.

– Bob

Further Reading

Lean Product and Process Development ~ Allen Ward
Product Development for the Lean Enterprise ~ Michael Kennedy
The Principles of Product Development Flow ~ Don Reinertsen
Lean Product Development Flow ~ Bohdan W. Oppenheim (pdf)
Sketching User Experiences ~ Bill Buxton