Product Owner car crash story

A few weeks ago I was in Sweden with clients and heard a horrific Product Owner story today – one I can hardly believe… maybe I shouldn’t, this was told to me second hand but I think it serves as an useful warning.

Reportedly a local car company has told its Product Owners to split their time three ways: 25% of their time is to be spent doing product owner work, the next 25% is to be spent in line management and the rest of the time, half their time is to be spent keeping deep technical knowledge by coding and other hands on activities.

To be clear: this is a bad idea, a bad idea, a bad idea.

Let’s start with 25% product owner work: not only is the Product Owner role the most difficult role to fill it is also the most time constrained role. 100% a product owners time is not enough to fill the role properly.

Next, line management and product ownership should never mix: product owners take their authority from being experts on what is needed rather than a position on an organizational diagram.

Product Owner – even when called Product Managers – are peers of software engineers. They are both professional with specialist skills, they need to respect each other and have constructive discussions even when they don’t agree with one another. The Product Owner is the expert in what customers want, the engineers are experts in solution building, they represent the analysis-synthesis split.

Product Owners need to be able to represent what the customers want to the engineers and engage in meaningful debate between peers. This is not going to be possible is the Product Owner is also the line manager for the engineers with the power to refuse holiday, promotion and mark staff down in reviews if they don’t get their way.

Besides, when do they have the time to do line management?

Then the massive 50% of the time spent coding or other technical work. Again this conflicts with being a true product owner (representing the customer) and holding meaningful discussions with engineers. As they only spent 50% of their time on engineering issues the PO will be the least prepared engineer on the team but the one with most authority. (I’ve written before about the mistake of making a platform engineer the product owner.)

And where is the product owner to get time for all the other miscellany that lands on a Product Owner’s plate? Reporting, statistics, testing, negotiation, etc. etc.

This company has fundamentally misunderstood the Product Owner role. They are seeing the role as an old fashioned Development Manager who was expected to be the technical authority, the team manager/leader and the one to nominate what should be worked on. (Even if they never meet a customer.)

The three things the company is asking the product owner to do are not just three different things, they are three things that should be separated. Line management is an issue agile folk struggle with because in purest terms it shouldn’t exist but in the vast majority of organization that nirvana is so far off it needs. So far at moment we are still in search of a generic model and until we get it we need to keep line management outside the team if possible.

50% hands-on is the give away here, the car company really want a technical authority, call then a senior engineer, a dev lead, or even an architect. This is a legitimate ask and should be recognised as full role. In fact, I would encourage the role holder to put a lot of time into mentoring less experienced engineers. In some engineering fields such senior engineers work as a type of tester to reviewing the work of other staff.

Finally the Product Owner role is a full, legitimate role in its own right. I suspect what is happening at the car company is they have lots of teams working on small technical aspects of the car. They feel only a few people need actual customer knowledge and contact.

It might be that the company could use the strategic product owner/tactical product owner model. Sometimes the TPO role crosses over with the Tester role and it can make sense to have an experienced engineer in the role. Still, you need someone to represent the customer point of view and another person to represent the technical side so the two can have constructive disagreement.

Very occasionally, once in a while I come across a situation where is makes sense to a very technical person drive product ownership from a purely technical point of view. Such occasions are few and far between, but the majority of engineer and managers think their case is one of those exceptions. Maybe this is one such case, but why add-in in line management? and why reduce Product Ownership to a part-time role?

In short: don’t do this.

Subscribe to my blog newsletter and download Continuous Digital for free

Leave a Reply

%d bloggers like this: