How People Cope
Some products exist in strategy decks but cannot be located in the codebase. The “buffer class” of product managers absorbs the incoherence these fake products produce, growing larger as the gap between narrative and system widens.
The product review is held monthly. Each product owner presents to the CPO and a panel of senior stakeholders. It is meant to be a moment of accountability.
Mark, 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. The team has delivered twelve features this quarter.
Eventually, Peter, an enterprise architect, raises a structural question, asking precisely which services currently comprise the Customer Engagement domain.
The room shifts. Mark begins to answer, then pauses. Customer Engagement, it turns out, is a label applied to a collection of features spanning four different services rather than a system, maintained by three different teams, two of which report into a different product area. The notification service is shared with Operations. The recommendation engine sits inside a legacy monolith that is nominally owned by Transactions. The analytics pipeline runs on infrastructure maintained by a platform team that was recently reorganised.
The question requires a forty-five-minute sidebar. By the end of it, no one in the room, including Mark, can draw a coherent boundary around the thing called Customer Engagement. It has a P&L. It has a headcount allocation. It has 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 Mark to “work with architecture to clarify the technical landscape.” It will be deprioritised within two weeks.
Customer Engagement continues to exist as a product. The question Peter asked is not raised again. One of the most damaging consequences of separating “the business” from engineering is the creation of products that do not exist.
These products have names. They have roadmaps. They have owners. They have funding. They appear in strategy decks and portfolio views. They are discussed as if they were real entities with behaviour, boundaries, and agency.
...
Continue reading in the interactive reader
Read this chapterSee also: Full contents · Preview chapters · Illusions in the Boardroom