The Real Problem Is Never in the Brief

The brief said “converge content management systems into a single platform.” Clean problem. Clear solution. Except thirty systems had thirty owners, and every one of those owners had spent years building their piece. Nobody was going to hand over control. Not to me, not to each other, not to anyone.

That wasn’t in the brief. It never is.

Why Problem Briefs Are Almost Always Wrong

Every brief I’ve worked from was written by smart people who understood their business. But the stated problem is almost always the one people feel safe discussing. “We need a unified platform.” “We need better data governance.” “We need product management practices.” These are symptoms that sound like solutions.

The real problem is underneath — and it’s usually political, structural, or both. The stated problem is always the one people feel safe discussing. The real one requires someone to give something up. Listening first is how you surface it. Territory. Control. A headcount line. A reporting structure they built. That’s the part that doesn’t make it into the brief.

What I Walked Into at Ford

The brief said “roll out product management practices.” Leadership had gotten wind of how the tech industry operated and wanted that for their teams. Reasonable enough.

But as I started talking to people across the organization, the real picture emerged. Teams were building technology for technology’s sake — projects that checked boxes but didn’t delight customers. Scope was creeping everywhere. Priorities shifted constantly because there was no framework for making trade-offs. Starting a dozen things and finishing none of them had become normal.

The problem wasn’t that Ford needed “product management practices.” The problem was that nobody had a way to work backward from customers and deliver with predictability. What we actually needed were tools and habits for making trade-offs visible, managing leadership expectations honestly, and ensuring teams delivered value instead of just output. “Roll out PM practices” was a label someone put on a problem they hadn’t fully diagnosed yet.

When Organizational Politics Shape the Product Solution

Back on that content management convergence — once I understood that thirty leaders weren’t going to consolidate into a single system, I had a choice. Push the original brief and fight a political battle I’d lose, or find the actual problem the brief was trying to solve.

The problem wasn’t that there were too many systems. The problem was that nobody could find anything, nobody could trust what they found, and every AI initiative downstream was building on a foundation nobody believed in. Those problems didn’t require convergence. They required connection.

That’s where the knowledge catalog came from — not replacing the existing systems, but building an intelligent layer on top of all of them. An index of every knowledge asset across every system, discoverable by people and machines. The leaders kept their systems. The organization got a unified knowledge supply chain. The solution that actually shipped looked nothing like the one in the brief.

When Politics Constrain the Product Solution

Even after we shipped, one leader felt strong ownership over a specific use case — intake and scoping — and wouldn’t bring it into the unified experience. We disagreed and committed. The result was a fragmented customer journey that we had to engineer around through interoperability between systems. It works. It’s not what I would have built if the org chart were different.

That’s the honest part of finding the real problem: sometimes you find it and still can’t solve it completely, because the politics that hid it are the same politics that constrain the solution. You design around it and ship something real anyway. We did — and it still bothers me that the customer experience isn’t what it could be.