Engineers are eager to deliver, and AI helps them turn ideas into working software faster and with less effort. This puts more pressure on the PM to decide what should be built.
A team can execute a solution well and still solve the wrong problem. It can also build something users want, but make it difficult enough that they keep using their workaround. Faster development makes those mistakes cheaper to make.
My approach is to put a prototype in front of target users before engineering grooms the change. AI makes the prototype quicker to build, and an engineering-supported coding agent gives me a first view of feasibility. That way, by the time we discuss scope, I will know whether users see a use for the solution, understand what they’re doing, and can complete the task.
Faster code still waits for answers
Writing code is only part of engineering’s working day. Meetings, grooming, changing requirements, and switching between tasks still take time. In fact, making the coding faster makes the other demands more expensive.
An unresolved product question can hold up engineers who are otherwise ready to build. Another sync means more people stopping what they’re doing to return to a decision we couldn’t make last time.
Some of that discussion is necessary. Engineers know the system and will spot constraints I haven’t considered. But questions about which behavior matters to users, what they understand, and what they can live without are part of my preparation. Domain knowledge alone may help me answer them, but watching users try the solution gives me something more specific to work with.
So I try to bring those answers and make informed decisions as early as possible.
Use AI to get a rough technical answer first
Involving engineering early makes sense: testing a concept the system can’t support wastes everyone’s time. The challenge is gathering sufficient technical input without pulling engineers into every idea before we know if users want it.
At Ship.Cars, a marketplace and transport management system for moving vehicles, our engineers built a codebase skill that business people could use for early feasibility checks and approximate estimates. A PM could explore a concept without asking an engineer to stop their work each time.
That’s a kind of coding agent you’d want engineering to supply and support. It needs enough context about the actual product to help guesstimate the size of an idea and spot likely constraints or limitations. We treated the skill’s output as an informed suggestion for what is possible with the given scope, which gave me enough direction to decide what was worth prototyping.
Let users try the solution before grooming
At Ship.Cars, most of my users rarely had time for a call, so I used smoke tests or put prototypes in their path through in-app prompts, then used session replay and a few short questions to understand their experience.
I’m looking for three things:
Does this address a real problem in their working day? The click-through rate on a smoke test is especially useful here.
Can they get through the intended workflow without me explaining each step?
Does it miss something they need?
A prototype won’t establish long-term adoption or prove the production system will perform well. But it can expose a missing step, or a confusing interaction, while I can still change it without sending engineering back through the code.
And if users don’t see the value, the concept is shelved while we have spent only a few dollars on tokens.
Use the evidence when engineering challenges the scope
The benefit shows up when engineering asks whether we can negotiate the requirements.
If a step adds significant effort, I need to understand what removing it would mean for the user. Testing helps me distinguish between a detail I happen to like and something people needed to complete the task. If engineers suggest a different interaction, I can judge it against the behavior I observed.
That gives me a better chance of making the decision during grooming. I can explain why a requirement matters, accept a simpler approach where the evidence supports it, or identify the specific question that needs another test.
Where I’d bring engineering in sooner
I use this workflow for straightforward additions and improvements where the main uncertainty is how people will use them. For complex changes, engineering belongs in the discussion from the beginning. If technical decisions determine the available workflows, a rough agent assessment won’t give me enough to test a credible solution.
The same applies when the feasibility check leaves an important constraint unresolved. I’d ask an engineer before putting a misleading prototype in front of users.
Before the next grooming session
For a small product change, I’d ask:
What user problem makes this worth building?
Has an engineering-supported feasibility check given me enough to prototype it?
What did target users actually do, and where did they struggle?
Which parts of the solution matter to completing their task, and which could change?
Can engineering find that evidence beside the requirements?
If I’m asking engineering to move faster, I owe them product decisions they can act on while the work is in front of them.
Next article