← Illusions in the Boardroom

The Illusion Was Rational

Chapter 4: Portfolio Labels That Do Not Exist in Code

“Fake products” carry all the governance artefacts of a real product but have no boundary that corresponds to anything in the system. For an audit committee chair, a fake product is a capital allocation that cannot be traced to a productive unit.

The product review is held monthly. Each product owner presents to the CPO and a panel of senior stakeholders. The product owner for “Customer Engagement” presents third. His slides show a funnel, a set of KPIs, and a roadmap with six items colour-coded by quarter. The presentation is fluent, the narrative confident. Customer Engagement is growing, retention is improving, and the team has successfully delivered twelve features this quarter.

Then an enterprise architect asks a question. “Which services comprise Customer Engagement?”

When the product owner begins to answer and then pauses, it becomes clear that Customer Engagement is not actually a system at all. Instead, it is merely a label applied to a collection of features spanning four different services, maintained by three different teams, two of which report into an entirely different product area. For instance, the notification service is shared with Operations, the recommendation engine sits inside a legacy monolith nominally owned by Transactions, and the analytics pipeline runs on infrastructure maintained by a platform team that was recently reorganised.

The question requires a forty-five-minute sidebar. A delivery lead begins drawing boxes on a whiteboard that no one will photograph. By the end of it, no one in the room, including the product owner, can draw a coherent boundary around the thing called Customer Engagement. While it has a P&L, a headcount allocation, and a roadmap, it does not have a boundary that corresponds to anything in the system.

The review continues. Nobody suggests that the product definition might be the problem. The action item is for the product owner to “work with architecture to clarify the technical landscape.” It will be deprioritised within two weeks, which is itself a form of clarification.

Customer Engagement continues to exist as a product. The architect's question is not raised again. The architect's question is diagnostic. Every software-dependent corporate has a version of this problem.

...

Continue reading in the interactive reader

Read this chapter

See also: Full contents · Preview chapters · Illusions of Work