I walked into one of my first product meetings as a PM with a fully formed solution. The problem had been described in a Slack thread the day before, and by the time I sat down, I had already sketched the architecture, thought through the edge cases, and was ready to pitch it. I was proud of how quickly I had turned it around.
The meeting did not go the way I expected.
My manager listened patiently, nodded, and then asked a question that stopped me cold: “That is a great solution. But can you walk me through the problem first?”
I froze. Not because I did not understand the problem. I did, or at least I thought I did. I froze because I realized I had skipped the most important part of the conversation entirely. I had jumped straight from symptom to prescription without ever really diagnosing.
That moment was the beginning of the most difficult unlearning process of my career.
The Engineer’s Superpower (and the PM’s First Trap)
For the first decade of my career, being fast at solutions was the thing that made me good at my job. As a Field Systems Engineer, I configured DR solutions and clustered environments. When something broke, you fixed it. When a customer had a requirement, you designed for it. Speed and accuracy were everything.
As a Solution Architect, the job was literally in the title. Customers came to me with problems, and I responded with solutions. I wrote technical offers, responded to RFPs, designed high-level and low-level architectures. The faster and more elegant the solution, the more valuable I was.
When I moved to Pure Storage as a Cloud Solutions Engineer, the pattern continued. I was the technical authority for Cloud Block Store across AWS and Azure. Customers needed hybrid cloud architectures? I designed them. Partners needed enablement? I built the training programs. Integration patterns between CBS and native cloud services? I pioneered them.
Every role I held before PM rewarded the same behavior: hear the problem, solve the problem, move on.
And then I became a Product Manager, where that exact instinct became my biggest liability.
The Problem with Solving Too Fast
Here is what I did not understand at first: in Product Management, the problem is the product. Not the solution. The problem.
When you solve too fast, you make a series of subtle but dangerous mistakes:
- You anchor on the first framing of the problem, which is rarely the right one.
- You optimize for what is technically feasible rather than what is actually valuable.
- You close the conversation before your team, your customers, and your data have had a chance to shape it.
- You miss the context that separates a feature that gets shipped from a feature that gets used.
In my previous roles, solving fast was rewarded because the problem space was well-defined. A customer needs a DR solution between two datacenters. The constraints are known. The options are finite. You pick the best one and execute.
In PM, the problem space is ambiguous by definition. You are not responding to a clear requirement. You are trying to figure out what the requirement should be. And that requires a completely different muscle.
From “I Know the Answer” to “What Is the Right Question?”
The mental model shift did not happen overnight. It happened through a series of uncomfortable moments where I had to catch myself mid-sentence and course-correct.
One pattern that helped me was learning to separate discovery from delivery in my own thinking. In my engineering days, these two phases were often collapsed into one. Someone describes a need, you figure out how to meet it, and you build it. In PM, discovery is its own discipline. It means spending time with customers not to validate your idea, but to understand their world. It means looking at data not to confirm your hypothesis, but to challenge it. It means asking “why” five times before you ever ask “how.”
I started keeping a simple rule for myself in meetings: do not propose a solution in the same conversation where the problem is first introduced. Force a gap. Let the problem breathe. Talk to more people. Look at the data. Sleep on it.
It felt slow. It felt unproductive. It felt like the opposite of what made me valuable.
But it worked.
What Actually Helped Me Break the Pattern
Three things made the difference in rewiring my instincts:
1. Customers who told me I was wrong.
Some of the most valuable conversations I have had were at VMware Explore, in hallway chats and coffee meetups, where customers told me that the thing I thought was the problem was actually just a symptom of something deeper. When you are in a technical role, you tend to hear customer feedback through the lens of “what can I build to fix this.” When you are in PM, you learn to hear it through the lens of “what is really going on here.” The same conversation, completely different listening mode.
2. A mentor who refused to let me skip the “why.”
Early in my PM career, I had a mentor who would not let me present a solution without first articulating the problem statement, the customer segment, the business impact, and the alternatives we had considered. It was frustrating at first. I would come in with a crisp recommendation and they would send me back to do more discovery. But over time, that discipline became second nature. The quality of my solutions improved dramatically, not because I got smarter, but because I got better at understanding the problem.
3. Writing things down.
My blog tagline has always been “figuring out how to integrate X with Y, to achieve Z. And most importantly, writing the solution down.” What I discovered in PM is that writing is not just about documenting solutions. It is about thinking clearly. When you write a problem statement and it does not make sense on paper, it means you do not understand the problem well enough yet. Writing became my forcing function for rigor.
The Tension Never Fully Goes Away
I want to be honest about something: the instinct to jump to solutions never fully disappears. It is not supposed to. The engineering mindset is not a bug to be fixed. It is a feature to be managed.
There are moments in PM where speed matters enormously. When the Broadcom acquisition of VMware created sudden market upheaval, I did not have the luxury of months of discovery. I had to move fast, identify the gap in VMware cost visibility, and push the Virtualization Assessment from concept to production in three months. The engineering instinct to solve quickly was exactly what the moment required.
The skill is not in eliminating the instinct. It is in knowing when to deploy it and when to hold it back. Early in the process, hold it back. Sit with the problem. Let it get uncomfortable. Late in the process, let it loose. Move with conviction. Ship the thing.
The best PMs I have worked with are not the ones who have the most frameworks or the most data. They are the ones who have learned to be comfortable in the ambiguity between the problem and the solution. Who can resist the pull of their own expertise long enough to let the right answer emerge.
What I Would Tell My Past Self
If I could go back to that first meeting where I showed up with a solution no one asked for, I would tell myself this:
Your ability to solve problems is not going away. It is what got you here, and it will continue to serve you. But the job has changed. You are no longer the person who builds the bridge. You are the person who decides where the bridge should go. And that decision requires you to spend more time on the riverbank, understanding the terrain, before you ever pick up a blueprint.
Stop being the solution guy. Start being the problem guy. The solutions will follow, and they will be better for the wait.
Next up: My First PRD!
comments powered by Disqus