Product Owner

Product Owners, engineering decisions, and 'technical debt'

When you’ve got a software product, it is composed solely of items like the code, static assets, supporting architecture and infrastructure (hereafter referred to as 'the tech'). These items are often thought of as being a necessary part of the product, but really they are the product and trying to separate them is a logical fallacy similar to trying to separate the food from a meal.

I think it's worth pausing and thinking about that for a second because it is an important concept to understand and embrace: in a software product the "tech" is the "product", and vice versa.

Things that are truly good for the tech are ultimately good for the product, and for the product to succeed the tech must itself succeed.

So why then, do team continue to treat the two as entities that are somehow distinct? Even the notion of things like 'tech debt' shouldn't exist. Let's explore that…

Of course code, architecture, infrastructure, etc. matter but not for the sake of themselves; none of these things can stand alone. If things are unstable, unscalable, or difficult/slow to update, that directly impacts the product value that can be delivered. ‘Technical debt' therefore, is more accurately labelled as ‘product debt', or even just 'debt'. Technical issues that have no impact over the product (or the future development of the Product) are completely irrelevant. There are surely no exceptions to this.

If a codebase requires refactoring because making changes is error prone and therefore slow, this has direct influence over the product value that can be delivered. If issues such as this go unaddressed, the rate of product value that can be delivered will decrease (probably exponentially) over time. If product value cannot be delivered, that's a product concern first and foremost.

It’s probably not for the Product Owner to specify specific implementation details, but they do have a very significant stake and interest in how their product is built since the decisions made can have significant influence over the success and possible speed of iteration.

A common over-simplification is that the Product Owner has responsibility over “what” and the Development Team have responsibility over “how”, and while this may be true at a very high level, The Scrum Guide reminds us that "The Product Owner is responsible for maximising the value of the product and the work of the Development Team". If architectural and 'debt' style tradeoffs will influence the delivery of value, the Product Owner should be part of such decisions. They may or may not have the technical knowledge (or the interest) to know whether a Product should be written in Python or C#, but they may care about the advantages of each. They may also care whether a new feature is implemented in a generic way, or hard-coded, especially if there is a big difference in implementation time.

I think that many of these issues have roots in legacy ways of working where there was a more distinct divide between Product Management and Engineering disciplines, and where product changes were captured in lengthy and detailed specification documents. In the agile world, where we’ve come to value things like valuable working software, and individuals and interactions we can do a lot better than handoffs of specifications. We can communicate, collaborate and negotiate with honesty about different solutions and the pros and cons that they bring because we’re now one team with one goal.

We must never lose sight of the importance of good technical practices, but only in so far that they can support the product. "Being agile" is never an excuse for cutting corners, but it does challenge our long-held beliefs about how teams can work together to satisfy our users and customers through early and continuous delivery of valuable software.

Who is the Product Owner?

Throughout my career, at some point or another every company that I have had dealings with has struggled with the role of the Product Owner.

I think each Scrum role is confusing for a lot of teams, companies and individuals, but arguably the Product Owner is the simplest one to understand, but one of the hardest to accept.

In simple terms, the Product Owner is responsible for ensuring that the team delivers something valuable. They are not responsible for how work is completed, or necessarily deciding every last detail themselves but they are ultimately the ones that set the direction, manage expectations and generally steers the Development Team in the right direction.

What I have observed as being challenging for businesses isn’t the concept, but rather accepting that this is the best thing to do, and/or actually giving the Product Owner the responsibility and trust that they require to be successful in their role. The Product Owner is one person, not a committee, as the Scrum Guide says — and yet to a greater or lesser degree almost every person I speak to in the agile community tells tales of a Product Owner being second-guessed by their superiors, team leaders, CEOs or even the development team themselves.

When you say to somebody “you’re in charge of steering this car” and then continuously reach over and grab the steering wheel, violently changing the course it’s almost inevitable that the car is going to crash sooner or later, and that in the meantime the path the vehicle takes is not going to be a smooth one.

It is when a development team, or members of a development team, don’t trust or respect the Product Owner that the greatest damage tends to be done. The unity of the team becomes damaged and the value of the work diminishes — in place of delivering value, the team easily starts doing ‘busy work’, choosing to simply do “something” rather than “something that matters” to the users of the product. When teams go down this road it can be very difficult to steer them back on course and in some circumstances it can be very difficult to even identify that this is happening.

When a team is used to doing 30 Story Points of work, getting them to accept that doing just 15 Story Points that deliver 10x the value, even if it theoretically means more down time, is actually better.

The Product Owner needs to be trusted, they need to be allowed to fall over and pick themselves back up without undue pressure or criticism: nobody will make perfect decisions every time.