Every prompt engineering guide says the same thing.
Be specific. Give context. Constrain the output. Tell the AI exactly what you want.
And that does work. But it’s not the only way to start.
Maybe the time to get specific is not in the beginning.
The practice
I describe the problem space, not the final answer
To be honest, every PM starts with an idea of what they think the answer might be. I do too. But I try not to get attached to the first version of the solution too early.
Great ideas still deserve exploration. Right ideas deserve pressure testing. Sometimes the direction I walked in with is right. Sometimes it only solves part of the problem. Sometimes exploring the edges of it exposes something better.
And exploring the edges helps me plan better for the future too.
Sometimes the solution I do not choose today still teaches me something about where the product could go later, where complexity may appear, what users may eventually ask for, or what operational pressure points are waiting further down the road.
That is the part AI changes for me.
It accelerates exploration.
It lets me investigate multiple directions quickly, challenge my own assumptions, and move through the problem space faster than I could on my own. What used to take days of exploration can now happen in hours.
But if you do not anchor that exploration to timelines, operational realities, user behavior, adoption risk, and constraints, you can get lost chasing possibilities instead of solving the actual problem.
That is why I keep myself in the loop.
The AI helps me expand the space. My job is deciding what survives inside the realities of the product.
Why I work this way
Curiosity matters, but curiosity alone is not enough
I work from a place of genuine curiosity.
Not because I think every idea is good, but because I think the wrong solution can look convincing when you stop exploring too early.
I have found that some of the best product conversations happen before the solution is fully formed. Before the workflow is locked. Before the implementation starts hardening around assumptions nobody challenged.
That openness matters to me.
Not forever. Just long enough to understand the real problem underneath the request.
Because there is a difference between:
- the thing someone asked for,
- the thing that removes friction,
- and the thing the product actually needs.
Those are not always the same thing.
The balance
Exploration first. Convergence second.
I think a lot of AI conversations collapse these two stages together.
The exploration phase should stay open. The execution phase should tighten.
Early on, I want competing directions, alternative framings, pressure testing, unexpected patterns, enough room to challenge my own assumptions.
But eventually the work has to converge.
That is where timelines matter. That is where operational realities matter. That is where adoption risk matters. That is where product judgment matters.
AI can expand the space quickly. The PM still has to narrow it responsibly.
A real example
Real product work is rarely that simple
A good example of this for me was when AI first started accelerating quickly.
I wanted to build with neural networks so badly.
The idea was exciting because I could already see the future potential. I could see how a product might eventually grow with an organization over time, learn patterns, adapt workflows, and become smarter alongside the people using it.
But the reality of the project in front of me was more complicated than the idea itself.
The organization was still growing. The workflows were still evolving. The operational processes were not stable yet. The data was inconsistent. The users were still adapting to basic workflows.
Starting with neural networks at that stage would have been unnecessary. Expensive. Harder to maintain. It would have added complexity before the organization had even reached the point where that complexity created meaningful value for users.
And that mattered more than my curiosity.
What I realized was that exploring an idea does not mean forcing it into the current product immediately. Sometimes exploration is about understanding what could matter later so you can build toward it responsibly over time.
The curiosity still had value.
It influenced how I thought about scalability. It shaped some architectural thinking early. It helped me think differently about long term workflow patterns. It helped me understand where the product might eventually go as the organization matured.
But product judgment was recognizing that the right long-term idea can still be the wrong short-term decision.
That is the balance I try to protect.
I never want curiosity to disappear from the work. But I also never want curiosity alone to drive the roadmap at the expense of the human beings actually using the product today.
What stays open
Human in the loop
I keep myself in the loop by refusing to delegate the choosing.
The AI surfaces possibilities. I evaluate them.
The AI helps me see more directions faster. But the responsibility for choosing still belongs to the human sitting closest to the users, the constraints, and the outcomes.
That part matters to me.
AI changed something important.
Curiosity used to be slower.
Now it is not.
And I think that changes how product discovery works when used intentionally.
Not because AI replaces judgment. Because it gives judgment more space to explore before committing.
AI is always learning.
We should too.