This piece was originally published on Amy Mitchell’s newsletter Product Management IRL. I’ve had the pleasure of collaborating with Amy on several things and always appreciate her grounded approach to her work and writing. I love that she explores and experiments, it’s that kind of curiosity and openness that keeps people at the top of their game. If you haven’t checked out her newsletter: subscribe - it’s worth your time.
I’m sharing this slightly adapted version because I keep coming back to it myself. It’s the clearest breakdown of the specific asks that actually make a difference between engineering and product. Not vague advice, but language you can hand to a PM directly.
If you’ve ever struggled to explain what you need from product without it sounding like a complaint, this is the shorthand.
Most engineering teams have lived through the same moment:
Product managers write requirements. Work gets planned. Everyone nods and starts building. And then weeks later, the team discovers they built slightly different interpretations of the same idea.
That drift often happens because collaboration between product and engineering defaults to handoffs instead of shared engagement with the problem.
The good news is that this gap is surprisingly easy to shrink. In my experience, a few simple habits from product managers can dramatically change how engineers engage with the work.
Here are five things you can ask your PM to try this week, small requests that make engineering’s life easier and lead to better products.
One of the fastest ways to improve collaboration with engineers is simple: bring something tangible.
A written spec describes what you want. A prototype shows it. These are not the same thing, and the difference shows up immediately in how engineering engages.
When a PM hands over a spec, engineers interpret it. Everyone builds a slightly different picture in their head, and nobody discovers the gaps until something gets built that doesn’t match what the PM imagined.
When a PM shows up with something tangible (even rough, even imperfect) engineers react to it. They say:
This part works
This part doesn’t
And what if we did it this way instead?
That’s a completely different conversation. The collaboration becomes concrete.
The PM I’ve worked most closely with over the years started with napkin wireframes: rough sketches of how something should work. Then came simple interactive prototypes. Each step made the handoff sharper. Each step changed the conversation.
It’s worth noting that sometimes you may encounter resistance. Designers don’t always love a PM who sketches. Engineers don’t always love a PM who codes.
Those reactions are often about ownership boundaries rather than product quality.
But engineers who are genuinely curious about the product – who want to understand the idea, not just execute it – light up when they’re shown them something tangible.
The point isn’t that PMs should code the feature themselves. The point is to make the thinking visible early enough that engineers can react to it.
Ask your PM to sketch the flow on paper or in a simple tool like Excalidraw before your next handoff. Even three boxes and some arrows changes the conversation
Suggest they hand the sketch to an AI tool and ask for a basic mockup
Ask them to open the next handoff with: “Here’s what I’m imagining, tell me where I’m wrong.”
When work isn’t decomposed well, engineering effort stretches without clear progress. Work drags on, feedback comes late, and teams lose visibility into whether they’re solving the right problem.
In software development, this is particularly tricky because of what we call the cone of uncertainty. Early in a project, we don’t really know how complex something will be. Until engineers start working on it, the real challenges are hidden.
That’s why breaking work into small pieces is so important.
Each piece of work should be small enough to validate or invalidate something about what users actually need. In our team, if we’re not confident something can ship in a sprint, the slice is too big.
A good unit of work should:
be small enough to build quickly
produce something users can see or interact with
validate or invalidate an assumption about the product
Large features might look efficient on paper. But they delay the most important thing: learning whether you’re solving the right problem.
That’s why strong teams favor iteration. Not because it’s faster to build, but because it’s faster to learn.
PMs often push for that learning loop. But engineers are in the best position to shape it – they’re the ones who understand what can realistically be built and surfaced quickly.
Small, visible pieces let the team test assumptions earlier, adjust direction, and avoid investing heavily in something users don’t actually need.
Before sprint planning, ask your PM what the smallest shippable piece would be, something a user would actually notice
For each piece, ask them to write one line: what will we learn from shipping this? If they can’t answer it, the slice is probably too big
If the answer takes more than a sentence, push back and ask them to decompose further
Another place where PMs can make engineers’ lives easier is by clearly stating constraints, especially what you are not optimizing for.
Engineers care deeply about their craft, which means they naturally optimize for quality and completeness.
Imagine going to a tailor and asking for sweatpants. Instead, they deliver an exquisitely tailored ballgown with sophisticated stitching and complex design. Technically impressive, but completely wrong for the occasion.
The same happens in software.
This isn’t a character flaw. In the absence of clear constraints, engineers naturally default to good engineering: optimising for scalability, elegance, and completeness.
Those are all sensible instincts. But without clarity on what matters right now, they can lead to solutions that are technically strong but misaligned with the immediate problem.
The fix is simple: engineers need to know what doesn’t matter right now:
Long-term scalability? Not this sprint.
Perfect edge case handling? Not yet.
And there needs to be a time box put on it.
In our team we use appetites from Basecamp’s Shape Up methodology. Instead of estimating how long a piece of work will take, we decide upfront how much time it’s worth spending on it. It’s an explicit time box agreement that this feature gets one day, three days, five days, or whatever the work warrants.
For example:
“We have two days for this feature.”
Now engineers know the constraint immediately.
If the work turns out to be more complex, they’ll come back and say:
“Within two days we can deliver this simplified version. If we want the full solution, it will take longer.”
At that point the product manager can decide:
Do we extend the appetite?
Or do we simplify the solution?
The key is that the decision becomes explicit rather than hidden inside engineering assumptions.
Ask your PM to add a “not doing” section to the next brief: three bullet points on what to explicitly deprioritize
Ask them to name an appetite: “Is this a two-day problem, or bigger?”
If they push back on the time box, treat that as the conversation you needed before work started, not a problem to manage
Without signal, an engineering team flies blind.
I describe it like driving in fog. You’re still moving forward. But visibility is terrible and every turn feels risky.
This problem becomes especially true for teams building internal software, where the feedback loop is weakest and the silence can go on for months before anyone realizes the product has drifted somewhere nobody wanted.
One of the most valuable things a PM can bring back to engineering is clarity.
Clarity about:
What matters
What doesn’t
And what has changed
With that clarity, engineers know what to protect and what to let go. They can make better decisions at every level: about architecture, tradeoffs, and where to spend their time.
Without it, teams are left to infer priorities themselves, and that’s where things start to drift.
Great PMs keep that signal flowing. Not as a formal update, but as a steady habit of bringing the outside world back in.
After their next stakeholder conversation, ask your PM to send a short update: what they learned, what changed, what the team can stop worrying about
Ask them to close every external conversation with: is there anything engineering needs to know?
Even “nothing changed, we’re still on track” counts, ask them to say it anyway
Not every engineer has time to dig through the full context behind a feature request.
But the engineers who do understand the why will almost always build a better solution.
Most requests describe what to build. Very few explain why it matters. That gap is smaller than it looks and more expensive than most people realize.
When engineers understand the reason behind a request – the user problem, the business context, what success actually looks like – something shifts.
They stop executing and start contributing. They spot the edge case you didn’t think of. They push back on an approach that would technically work but misses the point. They make a hundred small decisions a day that are slightly better aligned with what users actually need.
In teams where the why is shared consistently, engineers start behaving like stakeholders in the outcome. They ask better questions before starting work. They come back with alternatives rather than just flagging blockers. They care whether it ships well, not just whether it ships.
That kind of thinking doesn’t emerge from a single brief. It builds over time, in teams where the why is consistently shared, where the reasoning behind decisions is treated as part of the work, not an afterthought.
The why doesn’t need to be long. It just needs to be there, every time.
Ask your PM to add one sentence to the next ticket: “We’re doing this because...”
For bigger work, ask for a second line: “The user we’re solving for is someone who...”
If a ticket just says “do X,” ask why: it takes thirty seconds and changes what gets built
The common thread across all five of these tips is perspective.
Engineers make dozens of small decisions every day while building a product. Most of those decisions happen without the PM in the room.
When engineers understand the user, the constraints, and the reason the work matters, those decisions get better. PMs who provide that context don’t just get better output, they help create the conditions for engineers to make confident product decisions on their own.
In that environment, engineers don’t wait to be told what to do. They question assumptions, simplify where it matters, and push back when something doesn’t make sense.
The best part is, none of this takes long. Most of it happens in a sentence, a sketch, or a quick conversation. But used consistently, it changes how decisions get made: from reactive implementation to shared ownership of the outcome.
This week's guest, Alyssa Fu Ward, PhD built an open source project called Open Room to teach people with no technical background how to build with AI. She ran her 70-year-old mother and her 8-year-old daughter through it. Both of them built their own room. New episode of the
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.