If you’re in business for anything more than a one-hit-wonder, you may have given some thought to your next product. Albeit probably not much more than a few cursory thoughts, given the attention that you current product(s) demand of you.

Product Development And Delivery Flow

Some lucky few may have moved from the idea of economies of scale, maximising utilisation, etc., to the idea of flow. Flow of products from raw materials to finished and sold goods (or services). And flow of product ideas and new features into those products and product lines.


Fewer again may have adopted something like Prod•gnosis, where ideas for each new product or service get deliberately “developed” into a new operational value stream:

(click for larger image)

(click for larger image)

With this kind of approach, people (in the green box) who specialise in creating new operational values streams can bring their talents, expertise and continuous improvements to bear on each new operational value stream (blue boxes) they “develop” for the organisation.

Aside: The Toyota Product Development System (TPDS) works much like this, with circa 100 people co-located in a Big Room, or Obeya, for the 15 months or so that it takes Toyota to transform a new product line (vehicle) idea into a new, running operational value stream (blue box).


If we consider the whole organisation, over time, then whether we use the above approach or no, there will a whole series of operational value streams (blue boxes) starting up, operating for a time, e.g. whilst profitable, and eventually shutting down:

(click for larger image)

(click for larger image)

We might like to see our blue boxes flow into the organisation (start up), with as smooth and effective a flow as possible. This is what I call metaflow: the effective flow of operational value streams “into” an organisation.

Ultimately, I guess it depends on how much you need new products and services to flow, and how much you need the benefits that can bring you.

– Bob

Further Reading

The Principles Of Product Development Flow ~ Don Reinertsen

Product Development 101


“What is Product Development?”

I’m pretty convinced that few folks – even those with product development responsibilities, working in product development organisations – could easily answer this question.

The Wikipedia entry for “New Product Development” doesn’t seem to have a useful answer. Actually, I prefer the brevity of the entry for “Whole Product”.

Tom and Mary Poppendieck refer to the “Concept to Cash pipeline” e.g. the evolving of a vague idea into a revenue-earning product. Some more technically-minded folks like to describe product development as the creation of operational value streams.

But I’m not looking for a partial, complicated or technical answer. I’m looking for an answer that my grandma could relate to. Something like:

“The life blood of businesses everywhere is revenue they earn on the products and services they sell. As times change, existing products and services can begin to lose their appeal, and so both sales revenues and profit margins can begin to fall. To remain successful and profitable, businesses find themselves having to introduce new products and services, as well as upgrading or retiring their existing products and services. From an inkling of a new product, service, or upgrade, all the way through to having something ready for folks to buy – everything that a business does in this regard we call ‘Product Development’”.

I’ve been spending time with various product development organisations recently. Or, rather, with some folks who work for organisations in which the introduction, upgrading and retirement of products and services is central to their business model. (As opposed to organisations with one or more long-lived, more or less unchanging, cash cows).

Time and again, it seems to me that rather than product development being done all wrong, it’s more like it’s not being done at all. Or at least, not in any kind of intentional, deliberate, organised way.

I see lots of software development going on (the products in question being software-intensive in nature). But precious little, if any, product development.

The Product Development Organisation

For me, an essential aspect of Product Development is the organisational perspective. Most established organisations will be introducing, upgrading and retiring products – and services – on a more or less regular basis. So

“Product development is about developing products, not just a product.”

I see few organisations indeed that are set up to do this in anything but a purely ad-hoc way.

Does It Matter?

If we accept POSIWID (the purpose of a system is what is does) then it doesn’t matter much at all. Most organisations, most executives, most managers, and most staff seem happy with – or at least, resigned to – the current state of dysfunction in their product development efforts. I’m pretty sure they don’t know – and don’t, presently, much care – what it’s costing them, personally and collectively.

And until we begin to look at product development as a pipeline, a.k.a. value stream, through which ideas flow – from concepts to revenue streams – I guess things will just have to continue in that vein.

– Bob

Product Aikido


Photo Credit: Sigurd R

I wrote a post some time about Doctrine, although in that case I was writing about business, and the potential value to an organisation in defining just what it means by the term “business”.

“I reject any doctrine that does not appeal to reason and is in conflict with morality.”

~ Mahatma Gandhi

Since then I have been working on a first draft of a exemplar of a doctrine for Product Development, which I have named “Product Aikido” (presently, a document of some seventy-seven A5 pages). My motive for this has been the belief that there is much value in (product) organisations having a shared, common understanding of what product development is, and how it is conducted.

Note: The colophon at the end of the document explains a little more about the choice of name, amongst other things.

I offer this first draft here for your kind consideration. Any feedback, questions, comments or suggestions you might have for its improvement will, as always, be most welcome.


“The essence of product development is an intense and ongoing struggle between organising intent and entropy. Organising intent is the will of the company, manifest in the actions of its product development people, bent on meeting the goals of the company through the creation and evolution of products and product features.”

– Bob

Further Reading

Product Aikido – The Exemplar Doctrine


Not in the sense of being ambitious, but in the sense of having some things in mind that I’d like to see come to pass. You might call that an agenda. Or some needs which, upon being met, might make my life more wonderful…

Whatever you choose to call it, here’s my list:

  • An implementation of FlowChain. I’ve had this model rattling round inside my brain for years now. I see little prospect of someone else taking the necessary leap of faith and implementing it – although the Reaktor folks seem to have evolved something similar, independently –  so it’s down to me.
  • An illustration of just how much like product development is software development. And an illustration of the value – and relevance – of applying decades of well-evolved product development practices to the betterment of software development and a business.
  • A systems thinking approach to a) product development and b) (more ambitious) running a business. I refer to this as “Prod•gnosis“.
  • Learning how practical all the above ideas really are, in the crucible of real life. And how much – and in what regards – they need modifying when they come into contact with the “enemy’s main strength”.

“No plan of operations extends with certainty beyond the first encounter with the enemy’s main strength.”

~ Helmut von Moltke

This is my agenda.

As I explained recently in my post “Introducing Rightshifting“, I have no desire to foist these things upon people. But (in the context of my new job) I HAVE been asked to bring my experience and insights to bear. And to “innovate”. The above list seems to be a start, at least.

And just in case you’re wondering about my motivation, it’s not all selfish. I’ve made no secret over the years about what drives my work: to see an end to the egregious waste of human potential happening in software organisations everywhere, today. I believe the above ideas, implemented, will contribute significantly to this aim.

If someone asked me what needs of theirs their participation might serve, I’d offer the following list of possibilities:

  • The opportunity to learn lots of new things.
  • A chance to master the art of software development (esteem).
  • Making a difference. Advancing the art, illuminating the possible, and inspiring others.
  • The prospect of much fellowship, positive stress, self-actualisation (cf Maslow) and  fun!

Am I an idealist? A dreamer? You may choose to make that judgement. Although such a choice (i.e. to judge) would make me feel sad.

“Observing without evaluating is the highest form of human intelligence.”

~ Jiddu Krishnamurti

So who’d like to join me on this journey? How do you feel about my agenda? What’s your agenda? What needs can we meet, together? What might make your life more wonderful? And how might we help each other?

– Bob

Further Reading

Prod•gnosis in a Nutshell – blog post

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” .

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 (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 with a design process 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

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.


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 deign 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 wants 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 idea s 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.


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

Conway’s Law Revisited

Have you ever wondered why software produced by corporates (by which, I mean Analytic-minded organisations) is often e.g. disjoint, incoherent and balkanised, with a poor user experience and high on resource (memory, cpu, io, storage) use?

Many years ago I came across Conway’s Law, and found it explained much of this phenomenon. The Law, named after computer programmer Melvin Conway, states:

“Organisations which design systems… are constrained to produce designs which are copies of the communication structures of these organisations.”

or, as restated by Eric Raymond:

“The organization of the software and the organization of the software team will be congruent.”

Since discovering this Law, I have embraced it and taken it as a given. As a given, it has seemed a valid – and comforting – observation, but, until now, rarely provided me with any actionable insight. But which I mean, It’s not provided me with any ideas on how to improve the design of software systems and products.

Organisational Structure Reflects the Collective Mindset

If we combine Conway’s Law with the tenets of Rightshifting and the Marshall Model, however, some actionable insights do come into focus.

Where does an organisation’s structure come from? Why do some organisations have little in the way of structure, some have clearly-defined silos, departments and a management hierarchy, and some have a more fluid, but still highly (self-)disciplined, flatter kind of structure?

The Marshall Model attributes these differences to differences in collective (organisational) mindset. Each of the four mindsets produce their own kind of organisational structure. e.g.:

  • Ad-hoc: Little or no recognisable structure
  • Analytic: Hierarchical, siloed, departmentalised, autocratic
  • Synergistic: Flatter, self-organising, meritocratic
  • Chaordic: Fluid, adaptive, emergent

So, if we want to be able to design products that are coherent, self-consistent and a pleasure to use, Conway’s Law tells us that we need a congruent organisational structure. Which in turn means that we need a congruent collective organisational mindset. The Marshall Model names this as the “Synergistic Mindset”.

The necessary action, then, is to transition the organisation’s collective mindset from e.g. Ad-hoc or Analytic to Synergistic. (And given the herculean nature of this prospect, maybe we’re going to be stuck with many lamely-designed products, for many years).

Would you be willing to consider what kind of product designs might emerge from organisations having a Chaordic mindset?

– Bob

Further Reading

Structuration – Wikipedia entry
Neuroscience of Rightshifting – Blog post
Mel Conway – Website
Mel Conway’s Original Paper – Introduction and link to pdf

Prod•gnosis in a Nutshell

As the regular readers of this blog (thanks folks!) may know, I believe that to make truly amazing things happen, we have to Think Different. In my posts I offer folks the opportunity to Think Different on a range of issues related to effective knowledge-work organisations. Today’s post is about product development and the product development process.

“The very aim of the product development process is to create profitable operational value streams.”

~ John Shook & Durward K Sobek II, Lean Product and Process Development, Prologue, p.xiii

Quite often too, I offer up a sacred cow or two along the way. Today’s sacred cow, for what it’s worth, is the IT department, and its bizarre role in, and stranglehold on, product development.

Whole Product

“Turns out that the CEO of Jet Blue made one critical decision on day one: He got the head of Marketing involved in product design and training as well.

Marketing is built into the product

If a company is failing it is the fault of the most senior management, and the problem is probably this: They’re running a company, not marketing a product.

If you are a marketer who doesn’t know how to invent, design, influence, adapt, and ultimately discard products, then your’re no longer a marketer. You’re a deadwood.”

~ Seth Godin, Purple Cow

This is not just true with respect to Marketing. The Whole Product concept (as practised by, amongst others, Toyota with their TPDS “Big Rooms” (Obeya)) says that businesses need to involve every area of the business in new product development.

Aside: I happen to subscribe to the view that everything, including what we call “products”, are in fact services. So when I write “products” here, I actually mean “products and/or services”.

So, is it a good idea to give IT departments the starring role in new product development? In coordinating folks across the business in one concerted effort to get each new product designed and into production? I say not. And if IT shouldn’t have that central role, why then should IT departments even have anything to do with software development (surely, these days, a core activity in most new product development)?

Aside: What is an IT department? In case the term “IT department” confuses, here’s how I’m using the term in this post: An IT department (a functional silo) generally looks after everything to do with Information Technology within the wider business. This means making sure everyone’s computers and networks remain up and running, acquiring and running the enterprise applications such as customer (CRM) databases, sale and purchase ledgers, financial reporting, and so on. In most organisations, the IT department also looks after all the software development in the organisation, both of internal software systems, and of software for use in customer-facing products and services.


I coined the term “Prod•gnosis” some years ago as a label for a different way of thinking about new product development. (It’s a portmanteau word, formed from Product, and Gnosis – meaning knowledge).

Any organisation with aspirations of longevity and growth will (sooner or later) have more than one product. In fact, we can regard an organisation as a pipeline of new products, in various stages of development, each coming to market as resources and priorities dictate. So, I suggest it benefits organisations to take a considered, disciplined approach to managing this flow of new products into the market. Indeed, to have an evolving – continually improving – capability for doing this.

I use the term Prod•gnosis primarily in the context of this evolving capability.

Where to Put Software Development

If we accept that the IT department is poorly suited to play the central role in a Prod•gnosis-oriented organisation, and that it is ill-suited to house or oversee software development (for a number of reasons), then where should software development “sit” in an organisation?

Returning to the idea of “whole product”, and inspired by the ideas of Dr Allen Ward, I suggest that we regard each “product” (or more specifically “product line”) as an operational value stream. The task of new product development then becomes the task of designing and implementing the operational value stream through which instances of that product will be manufactured, packaged, shipped, sold, and serviced. Each new product line will have its own, custom-built operational value stream, which once up and running – building and shipping product – can use its own personnel to begin its continual improvement journey. The design of the product itself is then integral to the design of the operational value stream dedicated to that product (or product line).

Aside: Each operational value stream may call upon some central, shared (organisation-wide) services, such as billing, or logistics – but that’s no more than an optimisation-led implementation detail, in this picture.

Thus, the organisational capability we spoke of earlier is the capability to create and launch these operational value streams.

I suggest the effective place for software development is in the “Product Development Value Stream” (PDVS for short) – that part of the organisation which is responsible for creating each and every operational value stream. As the PDVS “cookie-cutter” folks crank the handle, they can rapidly improve their own performance through short iterations and continual feedback. And this avoids a key dysfunction in the more conventional “project team” (one project per product) approach – the continual setting-up and tearing-down of project teams, with all the cost overheads, waste and loss of learning this entails.

Getting to Prod•gnosis

Of course, getting there from here is the real challenge. the Lean literature is replete with stories of organisations failing to move from vertical silos to horizontal values streams. The idea of Prod•gnosis also layers on the additional challenge of wresting software development from the IT crowd and creating a whole new part of the organisation to contain it.

“How will you make such a large change in your organisation?

You won’t. Change will occur when the majority of people in the organisation have learned to see things in a new way.”

~ Dr. Allen C Ward, Lean Product and Process Development, p.205

It’s this kind of systems perspective that offers the prospect of dramatic performance improvements. Another example of the power of choosing to Think Different.

What do you think?

– Bob

Further Reading

In Praise of the Purple Cow ~ Fast Company article by Seth Godin
Lean Product and Process Development ~ Dr Allen Ward

%d bloggers like this: