Holistic Solutions for Product Development Businesses

Several people have been in contact this week to say “It’s all very well talking about holistic solutions for software development, but who really has any notion of what that might even look like?”

Which is a fair question.

Aside: Let’s note that the phrase “holistic solution for software development” is an oxymoron of the first order. By definition, software development is but part (and generally a small part) of any solution that addresses customer or market needs. Even software “pure plays” have a lot of non-software components.

So, I thought I’d describe just one holistic solution for whole organisations that develop new products containing some software. For want of a better name, I’ll call it this example “Flow•gnosis”. With this example, I hope that maybe one or two readers might find a spark of insight or inspiration to broach the question of a True Consensus in their own organisation.

I’ll try to keep this post brief. I’d be happy to come talk with you about holistic product development solutions for organisations, in person, if you have any real interest.


Flow•gnosis is a hybrid born of FlowChain and Prod•gnosis. FlowChain is not specifically a holistic solution, focussing as it does on improving the flow of knowledge work through a development group or department whilst moving continuous improvement “in-band”. Prod•gnosis is specifically a holistic solution for effective, organisation-wide product development, but says little about how to organise the work for e.g. improved flow or continuous improvement.

Together, they serve as an exemplar of a holistic solution for knowledge-work organisations, such as software product companies, software houses, tech product companies, and organisations of every stripe with in-house product development needs.

Let’s also note that Flow•gnosis is just an example, to illuminate just a few aspects of a holistic solution. Do not under any circumstances consider copying it or cloning it. Aside from the lack of detail presented here, you’d be missing the whole point of the challenge: building a True Consensus, as a group, with your people, in your context.

What’s the Problem?

Before talking more about a solution, what’s the problem we’re trying to solve?

I’ll work through an almost universal problem facing organisations that “do” software development. A problem that some enterprising supplier or management team might choose to address with an “innovative” solution.

Understanding the Problem

Here are some typical Undesirable Effects (UDEs) I hear from many companies involved in software and product development:

UDE: Delivery is not fast enough (long time-to-market)

UDE: New products cost too much to develop (high cost to bring to market)

UDE: We struggle to keep our products at the cutting edge

UDE: We always drop balls in hand-offs of tasks (i.e. between specialists, or business functions)

UDE: Continual contention for in-demand specialists

(For the sake of brevity, I’ll skip the building and analysis of the cause and effect graph. Your analysis will be different, in any case).

Root cause: Developing new software, products and services through a byzantine labyrinth of tasks and hand-offs, between and across dozens of specialisms within the company and its network of suppliers and distributors. This approach causes many delays (waste of time), mistakes (waste of effort, money), contention of resources, etc.

Conflict: A) Specialists must work together in their own specialist groups or silos to maintain their cutting-edge skills and know-how. B) Specialists from across all specialisms must work together as a group else handoffs and queues will cause many delays and mistakes.

Conflict arrow: Specialists cannot work in their own groups advancing their specialist knowledge at the same time as they work together with other kinds of specialist on new product ideas.

Flawed assumption at the root of the conflict: Specialists must work together. What makes this so? Only the old rules of the organisation. That silos (a.k.a. business functions) “own” their clutch of specialists. What if we changed that rule? (Note: this change is one key element of Toyota’s TPDS). And if we changed that rule, what other rules would we need to change too?

A Bird’s Eye View of Flow•gnosis

Prod•gnosis looks at an organisation as a collection of parallel Operational Value Streams, each dedicated to the selling and support of one of the organisations’ (whole) product or service lines. And each with its own team or collection of people doing the daily work of that operational value stream. Further, Prod•gnosis asks “How do these operational value streams come into being?” And answers with “They are made/created/developed by a dedicated Product Development Value Stream.”

FlowChain describes a way of working where a pool of self-organising specialists draws priority work from a backlog, executes the work, and delivers both the requested work item, and posting new work items (for improving the ways the work works) into the backlog. In this way, FlowChain both improves flow of work through the system, and brings continuous improvement “in-band”

By merging Prod•gnosis and FlowChain together into Flow•gnosis, we have an organisation-wide, holistic example which improves organisational effectiveness, reifies Continuous Improvement, speeds flow of new products into the market, provides an operational (value stream based) model for the whole business, and allows specialists from many functions to work together with a minimum of hand-offs, delays, mistakes and other wastes.

The latter point is perhaps the most significant aspect of Flow•gnosis. Having customer, supplier, marketing, sales, finance, logistics, service, billing, support and technical (e.g. software, usability, emotioneering, techops, etc.) specialists all working together (cf. Toyota’s Obeya or “Big Room” concept) enables the evolution of “Mafia Products” and “Mafia Offers” which the more traditional silo-based models of business organisation just can’t address effectively.

Out With the Old Rules, In with the New

Flow•gnosis is an innovation. Irrespective of the promised benefits of Flow•gnosis, we have learnt in recent posts that adopting an innovation ONLY brings benefits when we change the rules.

Let’s apply the four questions to our Flow•gnosis innovation and see what rule changes will be necessary to truly reap the benefits.

Q1: What is the POWER of Flow•gnosis?
A1: Flow•gnosis makes it commercially feasible for a company to repeatably come to market with new “Mafia Products”.

Mafia Product: “A product (or service) so compelling that your customers can’t refuse it and your competition can’t or won’t offer the same.”

Q2: What limitation does Flow•gnosis diminish?
A2:  Serialisation of specialist work (passing things back and forth between various specialist and business functions).

Q3: What existing rules served to help us accommodate that limitation?
A3: Handoffs. Queues. Batches. Separation of command and control from the work. Process. Process conformance. Local measures. Constant expediting. Critical path planning (Gannt charts, WBS). Local optima. Functional management (discrete management of each separate business function).

Q4: What (new) rules must we use now?
A4: Flow. Value streams. SBCE. Holistic measures. Ubiquitous information radiators. Cost Of Delay prioritisation. Buffer management. Constant collaboration. Dedicated teams of generalising specialists. Self-organisation. In-band continuous improvement. Resource levelling. Limits on WIP.


This post has been a – necessarily brief – look at one holistic solution to (software) product development. Crucially, we have seen how old rules have to be replaced, and what many of the replacement new rules might look like.

I invite you to remember that Flow•gnosis is just an broad-brush example of a holistic solution. Please don’t consider copying it or cloning it. And remember the real challenge: building, as a management group, a True Consensus.

– Bob

Further Reading

Meeting Folks’ Needs At Scale – Think Different blog post

Obstacles to True Consensus – Summary

[Tl;Dr: Major improvements in the effectiveness of any organisation go begging, because the skills and experience for reaching the necessary True Consensus are almost always absent.]

This is the final post in my recent mini-series about obstacles to True Consensus.

The Big Picture

Let’s step back and try to take in the big picture for a moment.

I most often label this big picture “Organisational Effectiveness”. You might prefer to call it “improving the bottom-line”, “productivity”, or simply “success”.

Why does this big picture matter to me? Because of the impact ineffective organisations have on the people who work in them, on the people who depend on their products and services, and on society as a whole.


I’m a software engineer at heart. I have so many times worked with software engineers and other folks wanting to make a difference in the world, and being unable to do so because of the ineffectiveness of the organisations within which they work. Sooner or later, these folks simply give up on their dreams and “check out” (remaining employed but disengaged) or quit. Having been in the same boat myself on any number of occasions, I feel like I can relate. And, BTW, that’s why I now serve organisations in the role of Organisational Psychotherapist, actually doing things – albeit non-software engineering things – to “make a difference”.


I’m a customer of these organisations, too. We all are. Not out of choice, let me add. I have in mind the various organs of state, in which we have no say regarding the shoddy services and lame products they foist on us. Not that most private corporations are much better.


How do ineffective organisations impact society? Apart from the waste of public money (many are in the public sector) that could be put to better use elsewhere, the sheer number of ineffective organisations lead us all to believe that ineffectiveness is normal and unavoidable. We seem to have lost the belief that we can ever expect to see things become better.

The Key to Improved Effectiveness

It’s pretty much accepted that the ability to transcend paradigms (an organisation’s beliefs, assumptions and rules about work) is the greatest lever to improve effectiveness. And by effectiveness, I mean reducing or eliminating things that should not have been done but nevertheless were done. See my recent post: Reliability and Effectiveness for details and objective measures of this.

In other words, the prevailing paradigm, or mindset or memeplex governing an organisation determines its effectiveness. And so, it’s obvious that to improve effectiveness, we must “shift” this paradigm. This is where most organisations falter and fail. They have no experience or capability in achieving a True Consensus. Such a thing looks like an impossibility.

Aside: Agile

In case you’re wondering if there’s any relevance to tech companies and their employees and customers: All flavours of Agile are essentially forms of local optima. Local optima, in that Agile initiatives are almost always limited to one silo (the “development” or “IT” silo) in the organisation. Most people in organisations doing software development are obliged to place their faith in systems of local optima. This is because the prospect of building a True Consensus across the whole organisation seems so daunting, so impossible, so contrary to prevailing behaviours, as to never receive serious consideration or discussion. And so, systemic ineffectiveness is locked in.

True Consensus

A “True Consensus” is when ALL top managers agree on the exact SAME action plan, with each and every top manager regarding his or her components of the joint action plan as his or her own baby.

Whether in a single organisation, or society as a whole, True Consensus is a prerequisite for concerted action to make things better, to make things more effective. On the path towards effective organisations, progress will only come about if the top teams, and eventually their whole organisations, can agree on their core problems and find coherent, holistic ways forward, together. True Consensus is the necessary prerequisite for Rightshifting any organisation.

This mini-series and its precursors has described one path to arrive at such a True Consensus, including describing the obstacles we can expect to encounter along the way, and ways of overcoming those obstacles.

In brief, the described path consists of repeatedly practicing, as a group and emergent leadership team, these steps:

  • understanding the core conflict in a problem by discovering the inherent flawed assumption
  • agreeing on a direction for a solution
  • elaborating that direction into a full (holistic, company-wide) solution or plan of action
  • agreeing on how to implement that full solution
  • enacting the implementation

You can find more details in the posts of this mini-series:

Obstacles to True Consensus – The Dominant Impatient Visionary

Obstacles to True Consensus – The Smart Conservative

Obstacles to True Consensus – Extrapolating From the Past

Obstacles to True Consensus – Solutioneering

Obstacles to True Consensus – Summary (this post)

and in the four posts prior to the mini-series itself:

Organisational Psychotherapy and the Bottom Line


Innovation ALWAYS Demands We Change the Rules

Reliability and Effectiveness

And you can find even more in-depth elaboration of these ideas in e.g. Goldratt’s audiobook “Beyond The Goal”.

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)
Leverage Points: Places to Intervene in a System ~ Donella Meadows
The Asch Conformity Experiment (Video)

Organisational Psychotherapy and the Bottom Line

The core of the Rightshifting message is:

“The power of the holistic approach dwarfs the bottom line results of the Analytic approach”.

A system of local optimums is not an optimum system at all; it is a very inefficient and ineffective system.

Because of interdependence and variation, the optimum performance of a system as a whole is not the same as the sum of all the local optima. If all the components of a system [e.g. silos] are performing at their maximum levels, the system as a whole will not be performing at its best (or anywhere near its best).

And that’s why we have to do everything we can to move to a holistic (a.k.a. synergistic) approach.

But what’s the main blocker to our moving in that direction? All senior executives in a company may agree in principle that a holistic approach is desirable. And yet, so infrequently do companies actually take concerted action to make this happen. Why is this?

True Consensus

Absent a “True Consensus”, action will be unlikely. What is a “True Consensus”? A “True Consensus” is when ALL top managers agree on the exact SAME action plan, with each and every top manager regarding his or her components of the joint action plan as his or her own baby.

So, how to reach such a true consensus? It can look like an impossibility. What are the real obstacles (barriers) to a True Consensus?

For the most part, the real obstacles are the behaviours of key people. Not dysfunctional behaviours, though, but the outstanding, positive behaviours that have got the company to the successful place it occupies today.

These key people include: the Dominant Impatient Visionary (a.k.a. the engine of the company),  the Smart Conservative, and others who extrapolate from past experience.

Facilitating a True Consensus.

How, then, to bring these key people closer together in such a way that they can arrive at the necessary True Consensus? And at the shared Action Plan? And keep them on course as that Plan unfolds?

Here’s where Organisational Psychotherapy can help. Organisational Psychotherapy increases the quality and effectiveness of the dialogues between a company’s key people. Dialogues without which the building of a True Consensus will most likely fail to get off the ground, stall or dissipate.

How will you go about building the necessary True Consensus to unlock the power of the holistic approach in your company. Could you use those hugely improved bottom-line results?

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)

Reliability and Effectiveness

Many times when presenting either the Rightshifting curve:

or the Marshall Model:

I have been asked to define “Effectiveness” (i.e. the horizontal axis for both of these charts). I have never been entirely happy with my various answers. But I have recently discovered a definition for effectiveness, including a means to measure it, which I shall be using from now on. This definition is by Goldratt, as part of Theory of Constraints, and appears in his audiobook “Beyond the Goal”.


Measurements serve us in two ways:

  1. As indicators of where we are, so we know where to go. For example, the dials and gauges on a car’s dashboard.
  2. As means to induce positive behaviours.

We must always remember, though, that we are dealing with humans and human-based organisations:

“Tell you how you measure me and I’ll tell you how I behave.” ~ Goldratt

We must choose measurements to induce the parts to do what’s better for the company as a whole. If a measurement jeopardises the performance of the system as a whole, the measurement is wrong.

Companies already have one set of measurements which measure their performance as a whole: their Financial measurements: e.g. Net profit (P&L) and investment (Balance Sheet)

What about when we dive inside the company as a whole, though? We then have two areas in which we have to conduct measurements:

  1. Support for and evaluation of management decisions
  2. Oversight on execution (how well are we executing on the decisions we’ve made?)

We generally don’t have good measurements in terms of decisions, nor good measurements in terms of execution.

We have to remember we’re dealing with human beings. And as long as we’re dealing with human beings, we have to realise that by judging any person on more than five measure, we’re creating anarchy. Simply because, with more than five measurements, people can basically do whatever they like, and likely still score high on one of them. And their bosses can nail them on some measurement they fail to deliver against. More than five measurements is conceptually wrong.

Categories of Measurement

So, how to categorise thing so that human beings can grasp the situation? Can we do better than we do now? Theory of Constraints suggests we can.

What resources do we have to help us formulate measurements in each of the above two areas; management decision-making, and execution of those decisions?

  • For decision-related measurements – there are lots of resources available to help e.g. books on Throughput Accounting.
  • For execution-related measurements – there is next to nothing published anywhere.

Continuous Improvement

I’ll not make the case for continuous improvement here. But if we wish to induce people to continuously improve, where should we focus our measurements? On things that are done properly, or on things that are not done properly? Which of these two foci better drives action? Focussing on the things we’re doing properly tends not to drive improvement. So we must concentrate on things that are not done properly.

How many things are not done properly? Kaplan suggests that in most businesses, there are more than twenty categories of things that are not done properly. But for humans to grasp our measures, we have already decided we need at most five categories, categories that completely cover everything that is not done properly, with zero overlap or duplication. Finding a way to categorise things that meets our criteria here is a nontrivial challenge.

Goldratt says there are only two categories:

  1. Things that should have been done but were not.
  2. Things that should not have been done but nevertheless were done.

Just two categories, with zero overlap. Beautifully simple.

And each of the above two categories already have a word defining them:

  1. Things that should have been done but were not – unreliability.
  2. Things that should not have been done but nevertheless were done – ineffectiveness.

Let’s swap these around into positive terms: Reliability, and Effectiveness.


Reliability and Effectiveness

Can we find measures to quantify Reliability and Effectiveness? How can we put numbers on our reliability? How can we put numbers on our effectiveness? Because, without numbers, we’re not measuring.

Let’s consider what is the end result of being reliable, in terms of the system as a whole. And what is the end result of being effective, in terms of the system as a whole? Not in financial terms though, as reliability and effectiveness are not financial things. We know this intuitively.


Things that should have been done but were not.

The end result of being unreliable, in terms of the system as a whole, is that the company fails to fulfil its commitments to the external world. In other words, the company fails to ship on time. Do we already measure on-time shipment? Yes. We call it Due Date Performance. That’s a measure of how much we ship on time. “Our company Due Date Performance is 90%”. The unit of measure is almost always “percent”. What behaviour does this unit of measure trigger? Does it trigger behaviour that is good for the company? No. It encourages us to sacrifice on-time shipment of difficult, larger shipments in favour of smaller, easier shipments. So the dollar value of the sale must be part of any reliability measurement. We cannot ignore the dollar value. And neither is time is a factor in percent units. How late is each late shipment? We must include time, too. So, let’s change our “Reliability” units from “percent” to “Throughput dollar days” – the sales dollar value of each orders that is late, multiplied by the number of days it is late, summed across all late orders. The sum total is the measurement of our (un)reliability.

This is of course  a new unit of measure: Throughput-dollar-days. To infer trends, or to compare the performance of e.g. groups or companies, we will need time to train our intuition in the significance of this new unit of measure. As we begin to get to grips with this new unit of measure, it can help to present it as an indicator (a number in some fixed range, say 1-10, or as we use in Rightshifting, and the Marshall Model, 0-5) until we have adjusted to the Throughput-dollar-days measure.


Things that should not have been done but nevertheless were done.

If we do things that we should NOT have been doing, what is the end result? Inventory. Do we already measure inventory? Of course we do. But how do we presently measure inventory? Either in terms of a dollar value, for example “$6 million of finished good inventory”, or in terms of a number of days, for example “60 days of finished goods inventory”. But both dollars AND time are important. Existing units of measurement for inventory drive unhelpful local behaviours like over-production and poor flow. So, how to measure to induce helpful behaviours? For each item of inventory, let’s use the dollar value of the inventory multiplied by the number of days that we’re holding that inventory under our local authority. We’ll call this unit of measure “Inventory-dollar-days”.

And one more measure of effectiveness: local operating expense. (For example, scrap, or salaries – with a given subunit of the company).

Note: We can fold quality into these measures simply by not recognising a sale, or a reduction in inventory, until the customer accepts the items (i.e. until the items meet the customer’s quality standards).


Now we have means for defining effectiveness, (and reliability) in a way in which we can also measure it. I feel very comfortable with that.

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)

Relevance Lost: Rise and Fall of Management Accounting ~ Kaplan & Johnson

The Goal ~ Eliyahu M. Goldratt

Throughput Accounting ~ Thomas Corbett

The Balanced Scorecard: Translating Strategy into Action ~ Kaplan & Norton

Strategies, Effective and Ineffective

[Tl;Dr: The effectiveness of any organisation is a function of the alignment between folks’ collective beliefs and assumptions about business, and the realities of business.]

I’m not sure this post is going to tell you anything new, but I did hear recently someone appear to misunderstand one of the the basic premises of the Marshall Model. So, for the benefit of clarity…

The Marshall Model – Recap

The Marshall Model asserts that there are four basic collective mindsets in organisations. For ease of reference, the model labels these collective mindsets, in order of increasing effectiveness: Ad-hoc, Analytic, Synergistic and Chaordic.

These various collective mindsets – and by “collective” I mean shared, more or less, by everyone within a given organisation – dictate the strategies in use in that organisation. And by “strategies in use” I mean, when making every kind of decision, from the most senior manager to the lowliest worker, the approaches used to make or inform those decisions.

Put another way, in any organisation, a multitude of decisions come up every day:

  • Which and what kind of business opportunities to pursue.
  • Who to please (and who to ignore or disappoint).
  • Which market segments to focus on.
  • How to serve those markets.
  • How to finance the business.
  • What kinds of people to hire (and fire).
  • Which trading partners to work with (and which to compete against).
  • HR policies.
  • Management policies.
  • Sales methods.
  • Engineering approaches.
  • Budgets.
  • And on and on.

How to decide? Most always, folks will approach making these decisions within the frame of their existing beliefs and assumptions. Existing beliefs and assumptions which have become the basis for their more or less automatic responses. Kahneman calls these “fast” or “system 1” responses.

And various psychological pressures conspire to ensure any one person’s beliefs and assumptions remain “congruent” with the collective assumptions and beliefs of the organisation as a whole (for example, nobody wants to be seen as an outsider).

The Effectiveness Lever

Any organisations where people work together are by, their nature, complex adaptive systems.

The Marshall Model implies that relative organisational effectiveness is a direct function of how closely the prevailing collective mindset matches the reality of organisations. If the prevailing collective mindset enables decision-makers to choose approaches and strategies well-suited to the realities of complex adaptive systems, those decisions will be more likely to be effective. If the prevailing collective mindset constrains decision-makers to approaches less well-suited to the realities of complex adaptive systems, those decisions will be more likely to be ineffective. Both as individual decisions, and in aggregate.

So, it’s not the organisations that are Ad-hoc, Analytic (a.k.a. mechanistic), Synergistic or Chaordic systems. It’s the collective thinking of the people within those organisations that conform to one of these four labels. The organisations themselves are always complex adaptive systems. And, for the clients I work with, collaborative knowledge work systems, too.

I hope this post has served to clarify. Would you be willing to let me know whether it’s achieved that aim? And for the sake of further clarity, I’m happy to address any and all questions that this post might bring to mind.

– Bob

Further Reading

Thinking, Fast and Slow ~ Daniel Kahneman

On Espoused Theory, Theory-in-Use, and “Effective Theory” ~ Mark Federman (blog post)

The One Perfect Way to Develop Software

[Tl;Dr: Being a Master of the perfect way to develop software is more of a handicap than an asset.]

Let’s imagine you’ve received a Matrix-style download of all the knowledge and skills necessary for Mastery of the perfect way to develop software. And you’ve applied this knowledge, and honed the skills, in several or many software development endeavours. And have the results to prove it.

Then you join a new-to-you organisation, and a new-to-you team, where of course you want to share your profound, highly valuable insights, capabilities, knowledge and skills with your peers, with a view to you all basking in the sweet success of the One Perfect Way.

Setting aside secondary issues such as the probability that there is no ONE perfect way, and that software development per se is maybe not what our customers are really interested in, what could possibly go wrong?

I’ll leave this question hanging. If I receive some expressions of interest, I propose to return to it in a future post.

– Bob

Further Reading

Characterizing people as non-linear, first-order components in software development ~ Alistair Cockburn


The Future Of Software-Intensive Product Development

A little while ago I wrote a post posing some questions about what ways of working we might look to, After Agile. Fewer folks engaged with this post compared to some others I have written. So I’m assuming that few are thinking about what we might see as the natural – or even unnatural – successor to Agile.

It is, however, a topic that occupies me regularly. Not least because of the intrinsic flaws in the whole Agile idea. We can, and eventually must, do much better.

Recently, some folks have been asking me about what I see as the future for software- and software-intensive product development (SIPD). Of course, I’ve been answering this question, on and off, for at least the past few years.

In a Nutshell

To sum up my take: In a nutshell, the issues that plague SIPD seem obvious. They’re mostly the same issues that plague all forms of collaborative knowledge work. Issues compounded by the gulf between conventional or traditional work and the new world of work (i.e. the world of collaborative knowledge work) – a new world distinctly unfamiliar to most in the world of work today.

We are faced with various collections of pathogenic beliefs (management, traditional business, Agile, etc.), none of which provide us with a context for EFFECTIVELY tackling the challenges we face in the new world of work – i.e. the world of collaborative knowledge work.

I’m choosing here to list these challenges in terms of needs, and in terms of the strategies – conventional and unconventional – for meeting those needs.

Developers’ Needs

Agile came into being driven by developers attempting to see their needs better met. These include:

  • Less working time “wasted” on mindless bureaucracy and distractions, such as meetings, reports, documentation, etc..
  • More time to focus on making great software, and stuff that delights customers.
  • Improved relationships with co-workers, business folks, customers, and the like.
  • More flexibility to adapt to emerging information, to changing needs, and to things learned along the way.
  • More say in what they work on, the tools they work with, and how they do their work.
  • Approval of one’s peers (including a sense of belonging and community re: the “technical” tribe)
  • And simply, the leeway to just “do a better job” and make a positive difference in the world.

Bottom line: Many developers need to feel valued, purposeful, that they’re making progress (learning) and are recognised for their abilities.

Business Folks’ Needs

Secondarily, but still important in the Agile approach, is better outcomes for “the business”. Agilists have come to recognise the following needs (even though common forms of Agile do not address them).

  • Approval of one’s peers (including a sense of belonging and community re: the “management” tribe).
  • Empathy (meaningful connection with other human beings).
  • A positive self-image.
  • Stability (folks have families to support).
  • Acclaim/fame (folks have careers to pursue).
  • Warmth (of human relationships) – Most business folks are just normal people, too.
  • Peace (i.e. an absence of distress).
  • Purpose.

Users’ / Customers’ Needs

Businesses ultimately stand or fall on revenues. Revenues which depend on their products and services meeting the needs of their customers. These needs include:

  • Approval of one’s peers (including a sense of belonging and community re: the “brand” or “XYZ customer” tribe).
  • A positive self-image (what being a user or owner of a certain product says about you, in your own mind).
  • Stability (folks don’t like to think too hard, or continually learn new stuff for no good reason).
  • Warmth (of human relationships) – Most customers, being humans, value interactions with other human beings.
  • Low fuss (i.e. being able to get their jobs done with minimal distress).

Shareholders’ Needs

Shareholders also have needs which they seek to get met. These include:

  • Approval of one’s peers (including a sense of belonging and community re: the “investor” tribe).
  • Contribution to society (e.g. ethical investments) and communities.
  • Financial returns (investors have families and/or lifestyles to support).

In a future post I’ll be looking at the strategies that people use to get these needs met, including those strategies implicit in Agile methods – and some alternative strategies that might prove

– Bob


%d bloggers like this: