Decoupling the Solution: How to Separate the What from the How
A few years ago, an engineering manager marched into my office, visibly frustrated. He'd spent the morning dealing with a string of urgent customer support issues, and the root of his frustration was data, or rather, the lack of it.
Whenever a customer ran into a snag, our support and engineering teams had to verify the client’s unique terms and conditions. The problem was that we didn't have a centralized contract management system. Agreements were scattered across multiple digital folders, buried in shared drives, or literally printed out and sitting in physical filing cabinets (with a sign on the door that says “beware of the leopard” (IFYYK)). Hunting down a single clause was a laborious, time-consuming scavenger hunt.
"We need to build a contract management system," he told me. "We can take all of these materials, OCR-scan the physical papers, index everything, and build a search interface. That way, any member of the staff can retrieve client-specific terms in milliseconds."
It was a great, well-intentioned idea. He'd implicitly laid out a crystal-clear What:
The Problem: It takes far too long to find accurate details on client agreements, slowing down support and frustrating customers.
Success Metrics: Within a few months, any employee can query client terms in milliseconds and get a canonically accurate answer.
The Value: Faster resolution times, happier clients, and less internal friction.
He'd defined the What beautifully. But he'd immediately married it to a highly specific How, which was: "We need to build it."
I asked him to take a step back and look at the execution. He managed a team of five engineers. He estimated the project would take them about four months. Experience has taught me to mentally adjust an optimistic four-month engineering estimate to at least six months, not to mention the indefinite tail of ongoing support, patches, and maintenance.
These were highly skilled, expensive engineers. Their core mission was to build the proprietary product we licensed to the market, which was the literal engine of our business. Pulling them off the core roadmap to build a bespoke internal document index meant a massive opportunity cost and a permanent distraction for engineering.
Because we'd decoupled the What from the How, we weren't trapped by his original proposal. We agreed that the What was absolutely worth solving. But the How shifted completely. Instead of building it ourselves, we went out and licensed a third-party tool. We got it implemented in a fraction of the time, at a fraction of the cost, and most importantly, we didn’t distract five valuable engineers from the core product innovation that drove our revenue.
Why We Default to the "How"
Almost a day doesn't go by without some variation of this happening. Someone comes into my office, connects via video, or accosts me in a corridor with: "Hey, we should do X." And like that engineering manager, their ideas almost always come from a good place.
Our teams are inherently driven to solve things. When an engineer or a product manager spots a point of friction, their brain immediately leaps to the point of creation. They visualize the architecture, the interface, or the code.
The problem is that the "How" is comfortable. It feels like progress because it's actionable. But jumping straight to the action bypasses the critical diagnostic phase. In fact, experience has shown me that the likelihood of an initial, ad-hoc "How" perfectly mapping to a rigorously defined "What" is remarkably low.
To govern this instinct and protect our team's focus, I rely on three deceptively simple questions to extract the What:
What's the problem we want to solve, or the opportunity we want to pursue?
What does success look like?
What's the value?
Only when we've got clear answers to these questions can we assess if a problem is actually worth solving. The discipline required to clearly state the What before assigning a single story or writing a single line of code can't be overstated.
The Hardest Part: Visualizing the Future
Defining "what success looks like" trips people up constantly. The knee-jerk reaction is to describe actions, like: "If we do X, we can pursue Y opportunity." But that's still a How. Those are just the actions you intend to take.
What I'm looking for is a shift in reality. After we've done something, what does the world look like? Are customers more successful? Are they happier? Have we used our resources more effectively?
During my time at Amazon, this discipline was codified into a mechanism known as Working Backwards. We didn't start with a technical architecture; we started with a Press Release dated a year into the future.
A great Press Release is written within a strict boundary. It's got to articulate success entirely in terminology that resonates with end users. There's nothing in it about the code we wrote, the data pipelines we constructed, or the models we tuned. It focuses purely on the customer outcome and the positive impact. It forces the author to live in the future they want to create before they're allowed to build it. If you can't write that press release, you don't know what you're building yet.
The AI Parallel: Training Agents vs. Pointing Humans
This discipline isn't just a management framework anymore; it's the definitive bottleneck for the future of technology.
Right now, the industry's transitioning away from "pixels and pipes", which are the traditional user interfaces and hardcoded integrations, toward autonomous AI agents and architectures like the Model Context Protocol (MCP). We're entering an era of Agentic Commerce, where digital delegates execute complex tasks on behalf of users.
Here's the brutal truth: If we can't discipline ourselves to define the "What" for our human teams, we've got absolutely no hope of defining a clear mission for autonomous AI agents.
An LLM or an autonomous agent can't guess your strategic intent. If you feed an agent a vague "How," it'll rapidly hallucinate a thousand wrong directions. The primary skill of the modern engineering leader is no longer directing the How. Instead, it's providing a flawless, unambiguous definition of the What so that both human engineers and AI delegates can build toward it effectively.
The "Desire Paths" of Innovation
Whenever you introduce a requirement like a "simple one-pager" to define the What, you'll inevitably hear a common pushback: "This is just corporate bureaucracy. It’s a rubber-stamper that slows down innovation."
I view it exactly the opposite way. Think of university campuses where paved concrete walkways are ignored in favor of the dirt tracks worn into the grass by students taking shortcuts. Landscape architects call those desire paths. They represent the natural, frictionless way people actually want to move.
A written "What" isn't a sidewalk guardrail designed to restrict your team's movement or trap them in committee reviews. It's a paving tool. By taking a brilliant, raw hallway idea and breaking it down into a clear, one-page document, the author is showing us a true organizational desire path. The document doesn't slow them down; it helps their great idea get recognized, aligned, and resourced much faster.
In the Trenches: Peer CTO Realities
When I share this framework with other technology executives, they often push back on a few predictable operational realities. Here's how we handle those challenges on the ground:
"Colin, how do you stop the 'What' process from turning into analysis paralysis? My engineers'll spend three weeks arguing over problem definitions instead of coding."
You enforce a strict constraint. Keep it to a single page. The document has to rely on clear, declarative statements backed up by real data.
Remember, the purpose of this initial draft isn't to deliver a flawless, final decree; it's to support early discussion and collaboration. Writing an effective "What" statement is incredibly hard intellectual labor. It requires practice.
If a team member is finding it difficult, don't let them spin their wheels in isolation. Guide them to get help from someone with more experience. I ensure we've got several members of the senior leadership team who excel at defining the What. This turns a tough strategic bottleneck into a high-value coaching and growth opportunity. It's a discipline that pays off time and time again by keeping development on track.
"If an idea self-filters and fades away because they can't define the 'What,' aren't you worried they'll just take it underground as a secret side-project and deploy it anyway?"
Underground engineering happens when teams feel ignored or think the process is a black hole where good ideas go to die. We prevent this by ensuring all staff know their ideas are valued and will absolutely be listened to.
We never just say a flat "no" and walk away. If we decide not to move forward with a proposal, we take the time to explicitly explain why we're hitting pause, at least for this time. When staff understand the strategic context behind a decision, they don't feel the need to hide their creativity. Once again, closing that feedback loop transforms a potential rejection into a fantastic coaching moment.
Protecting the Spark
When presented with a new idea, I'll always ask about the What. Some people can articulate it clearly right out of the gate, which is great! We're off to a flying start.
Most can't, and that's perfectly okay. Defining the What is hard intellectual labor, and it takes practice. When someone brings me a raw idea, I'll send them off to sketch out that simple, one-page document. When that happens, one of two things usually occurs:
The idea quietly fades away. The suggester starts writing the What and realizes that while the idea's technically feasible and clever, it doesn't actually solve a pressing customer problem or move a needle that needs moving. The mechanism self-filters without a manager ever having to say a word.
I receive a written one-pager. Wonderful. Now we've got something tangible, rigorous, and collaborative. It becomes a living document that we can refine together, pass around for peer feedback, or consciously cast aside for a better day.
Why insist on a written form? Because conversations evaporate, but writing scales. It allows us to build a corporate repository for future reference. Today’s What might be a bad fit for this quarter's goals, but it might be the exact breakthrough we need next month or next year. I don’t ever want to lose a potentially great idea to the ether of a brief hallway conversation.
Crucially, this process is never about bursting anyone's bubble. I love creativity. I thrive on raw ideation, and I want my team to keep accosting me in the corridors with their flashes of brilliance. By demanding a structured What, we aren't killing the spark of innovation. We're giving it the oxygen it needs to actually become a fire.