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.

Prod•gnosis

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