I've seen this pattern play out more times than I can count. A client or potential client wants to modernize something. The subject matter experts want a better way of getting their work done. The platform team thinks you're a fit. Architecture seems ok with it, and sometimes even champions it. Everyone who looks at it technically thinks it's the right move. So ,you move forward with the deal…or at least you think you do.
Then someone from transformation or program management raises their hand and says "wait, we're not sure about this”, which throws a huge wrench in the gears of progress. Or if you’re a little lucky, it moves forward but with resistance that never fully resolves.
Looking back on those situations, I don't think transformation teams were objecting to the solution at all. More often, they were likely reacting to a conversation they hadn't fully been a part of. We had alignment among the teams evaluating the technology, but not among the teams responsible for changing the organization. Product wanted to modernize, platform wanted consistency, operations wanted to reduce risk. Those are all reasonable goals. The problem was that nobody had stopped to ask what success looked like across all of them before the technical decision was made.
What I’ve learned over the years is that product and platform models create something most organizations underestimate, which is that they now have multiple centers of decision making. That’s not a flaw in the model itself…in many ways it’s the whole point. They want teams to be empowered to make decisions quickly within their respective domains rather than waiting for centralized approval. The challenge is that autonomy only works when everyone is aligned on the outcome they’re trying to achieve together. Otherwise, each team can make smart decisions locally that aren’t best for the organization as a whole. It's like a football team where every player executes their assignment perfectly, but half the offense thinks it’s a run up the middle and the other half thinks it's a pass play. Great execution can't overcome a team that's running different plays.
What's interesting is that none of these perspectives are wrong. In fact, they're all quite necessary. The problem that emerges here is when those priorities become substitutes for a shared objective. Teams start building for their own definition of success because nobody has articulated a collective one. That's usually the moment where I’ve seen momentum begin to fade. Conversations become harder, decisions take longer or never happen at all. Resistance starts appearing in places that didn't seem concerned earlier. The root cause often isn't disagreement about technology, it's usually a lack of agreement about what the organization is ultimately trying to accomplish.
That's where a Solution Designer has to step in and do something different. We can't let anything move forward if everyone in the room isn't clear on what winning looks like. Not just for their team, but for the whole organization. We need to bring everyone to the table…business, operations, IT, SMEs, the program management, architecture, delivery…especially delivery. Because if delivery doesn't understand what success looks like, they're going to be in a reactive mode the entire implementation.
Eventually I stopped asking "What do you need the product to do?" That part’s easy. Instead, we should be asking "When this is done, what does success actually look like? Is everyone solving for the same thing?" Most of the time, the answer is no. They're not solving for the same thing… that's the moment where there’s choice for us Solution Designers. We can ignore it and move forward, or we can stop and say "We're not ready yet."
When this happened to me in times past, I wish I would have gone higher quicker. I would have escalated to leadership and said "We have great technical alignment, but transformation isn't fully engaged. We can't design a solution until we understand what success means to all of these groups."
You may be sitting there wondering why this matters specifically in product and platform models. If so, great question, and thank you for still reading. In a centralized organization, you might have fewer stakeholders. There's clearer hierarchy. Someone at the top can force alignment if needed. But in this product and platform world, you have autonomous teams making independent decisions. Each one of those is rational in their own areas. But when those decisions cascade across teams without coordination, you end up with fragmentation, redundant spend, siloed thinking.
The problem here is that teams don't realize they're unintentionally creating fragmentation. They're heads down trying to hit their goals. Nobody's asking “Is everyone solving for the same outcome?" Without that question getting answered upfront, the autonomous nature of the model guarantees misalignment or even failure.
The Solution Designer creates the most value right there. Not rushing toward the solution, but by slowing the conversation down long enough to create clarity. Before we spend time on architecture diagrams, implementation plans, delivery estimates, we need to align on what success looks like. If the stakeholders are leaving the room with different visions of the finish line, the quality of the solution is going to become irrelevant. Eventually those differences will become impossible to ignore. Our role is to expose them early, facilitate the conversation that resolves them, and help to create a shared understanding that everyone can rally around.