The Product Owner Is Not The Problem III

Episode 47 - 03 Aug 1985

In Part 1 we talked about step-changes... boundaries... discontinuities.

In Part 2 we talked about the quality of relationships. And their importance.

This time we'll zoom in on the relationships between these key players:

  • Business Owner
  • Product Owner
  • Lead Developer

And ask the question: "What can be done to improve these key relationships?"

Previously: a road sign. Another road sign.

This time: Yet another road sign.

Oh.. and we'll move on from problem to solution


In the last episode, I sprinkled road signs with stick figures.

First, I mapped the relative sizes of the "discontinuities" between the team members.

But then my brain then popped up with its "So what?" question

So I started again and mapped the relative importance of each of the relationships.

So far so interesting.

"Weighted Discontinuities"

I now have two rather crazy diagrams.

Two crazy diagrams... that are related:

The second [importances] is like a lens through which the first [discontinuitities] can be viewed.

What I'd like to do is "magnify" the DISCONTINUITIES by the relative size of the IMPORTANCES to get a WEIGHTED discontinuity .

He's the idea:

this multiplied by this gives this

this multiplied by this gives... a smaller "this"

and this multiplied by this gives ... an enormous "this"

I can now apply this "weighting" process to the discontinuities diagram:

  • these four stay about the same size.
  • These actually get smaller get smaller
  • These two get bigger
  • And this one gets MUCH bigger.

Three key players

As I said last time: my search for answers started with the Development Team, but it lead me to this gang of three:

  • the Business Owner
  • the Product Owner
  • and the Lead Developer

What am I saying?

I'm saying that in my experience, the greatest improvement in a software development organisation can come as a result of improving the interactions of these three players.

So what can be done?

I think there are two broad approaches... both of which got a mention in Part 1.

Approach 1: Impedance Matching

Remember the electronic components?

The trick was to match the impedances as closely as possible.

How do you do that with people?

Well, is to help each see the world from the other's point of view.

To "get" where the other person is coming from.

To walk a mile in their shoes.

This, dear viewer, is what "Development that Pays" tries to do.

Most of the episodes are intended to help these two [Product Onwner and Lead Developer] understand each other,

But you'll also find the odd episode designed to help the Product Onwner and Lead Developer to understand where the Business Owner is coming from

Approach 2. "Multi-coating"

The reflections on the glass lens were reduced by adding an intermediate layer.

One big step is replaced by smaller steps.

But what do we put on the step?

Not what. But whom.

What about a Scrum Master?

Or (the term I prefer) the Agile Coach?

One of the most powerful things that an Agile coach does is to bridge the gap between the product owner and the Lead Developer.

That's the immediate benefit

The longer terms benefit is that the product and the lead developer move toward each other over time.

Win win.