Effective Product Development

One question that has been preoccupying me in recent weeks is:

“What makes for effective product development?”

Having pondered on this question for a while, my own answer is presently quite simple:

“Meeting the needs of the stakeholders.”

Note I don’t say “Meeting the needs of the customers“ or “delivering value”. I do not single out any particular constituency of stakeholders, nor any particular kind of need.

So what does this statement mean? Let’s deconstruct it:

“Meeting…”

Not exceeding. Not falling short. Exactly meeting. Not that we’ll ever be able to meet the stakeholders’ needs exactly, for we will never be able to understand them or define them exactly.

“You cannot define being exactly on time.“

~ W. Edwards Deming

But it’s a consummation to which we can aspire, at least. And one to approach asymptotically.

“…the needs..”

Needs. Not wants. Not “requirements”. Not what folks say they need. What they actually need. At a specific point in time. To the extent that we have a product which meets folks’ needs, then we have a successful product. And we might do well to remember that rarely are needs of different stakeholder in harmony, congruent, compatible. We have to balance the various needs as best we can. We have to resolve conflicts. And no, I don’t mean compromise. Sometimes, balancing the various needs is just not going to be possible. So sometimes we’re onto a loser as far as coming up with a completely successful product goes. And needs can change. Over time. In different circumstances and contexts. A man in the desert might need water rather more than a man in a lake. So a successful product today, or in one context, may not be so successful tomorrow, or in another context. So we may have to produce difference variants, and change the product over time, to keep it in the “sweet spot” of the stakeholders’ collective needs.

“…of the stakeholders.”

All the stakeholders. Not just customers. Nor just the producing organisation. Nor just its managers and executives. Nor just the employees – developers and suchlike. Some years ago I coined the term “covalent” to describe this.

[Update January 2022: I have for some time been using the term “The Folks That Matter™️” in preference to “stakeholders”.]

Few product development or software development folks seem to make an effort to explicitly list their stakeholders. Whether specific (people) or generic (constituencies). And fewer still seem to attend to understanding their respective needs, in any deliberate or organised way.

“Corporations should be maximizing stakeholder, not shareholder, value to employees, customers, and shareholders.”

~ Russell L. Ackoff

To sum up then. A product development organisation – or a product development effort – is effective to the extent the it meets the needs of its stakeholders. Simple as.

Having happy customers but dispirited employees is not so effective. Having happy employees but disappointed managers and executives is not so effective. Having happy executives but high costs or impacts on society at large is not so effective. You get the picture.

All the multitude of opinions, ideas, methodologies, etc. that speak to how to go about being effective at product development seem incidental compared to this basic definition of effectiveness.

– Bob

Afterword

One thing has been bugging me about this post. My thanks to Sami Honkonen for bringing it up, which in turn has motivated me to pen this afterword.

He tweeted “This is a local optimum. What about the system? Are you trolling?”

And while I was not trolling, I did fail to mention the systems implications of the answer “Meeting the needs of the stakeholders.”

It was not my intention to imply that effective product development is the sole responsibility of some “product development group” or function. In siloed organisations (the norm), there may be a product development silo. Although that in itself is rather unusual – piecemeal product development and product enhancement being much more common, with the work sliced up and stuffed into the existing silos of marketing, sales, IT, finance, etc.

To get to highly effective product development, the whole organisation must be involved. And ultimately, that means breaking down the silos, liberating the specialists locked inside each, and bringing them together to evolve new “whole products”. Cf. Prod•gnosis.

Meeting the needs of all one’s stakeholders is always a challenge. Doing so effectively within a siloed organisation – focused on local optima – is even more of a challenge. Maybe being highly effective under those conditions is just not possible. I believe that attempting to move to a place of highly effective product development has profound implications for the organisation as a whole. And not least for the mindset that underpins the siloed model – i.e. the Analytic mindset.

Further Reading

Principles of Software Engineering Management ~ Tom Gilb
Competitive Engineering ~ Tom Gilb
Nonviolent Communication ~ Marshall B. Rosenberg