5 Things Engineers Wish Product Managers Did More Often

How small shifts in product manager habits help teams move faster and build the right product.

Introduction

This is a perspective on how small shifts in working with engineering can lead to better product decisions.

Product managers and engineers want the same thing: a product that solves the right problem well.

But the collaboration between the two roles often defaults to handoffs instead of shared problem-solving.

I recently met Alex Ponomarev after he reshared an article I wrote about the Builder PM. That led me to his writing on engineering leadership. Many of Alex’s articles are written for engineering leaders, but I found myself thinking: product managers would benefit from hearing this perspective directly.

From an engineering leader’s perspective, here are five small habits product managers can adopt that improve how teams work together.

From Alex

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 quietly 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 any product manager could start doing this week that make engineering’s life easier and lead to better products.

1. Prototype it first

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 product manager 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 product manager imagined.

When a product manager 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 product manager 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 product manager who sketches. Engineers don’t always love a product manager 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 you show them something tangible.

The point isn’t that product managers should code the feature themselves. The point is to make the thinking visible early enough that engineers can react to it.

Try this week:

• Sketch the flow on paper or in a simple tool like Excalidraw – even three boxes and some arrows change the conversation

• Hand your sketch to an AI tool and ask for a basic mockup

• Open your next handoff with: “Here’s what I’m imagining – tell me where I’m wrong.”

2. Break work into visible pieces

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.

Product managers 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.

Try this week:

• Before sprint planning, ask engineering to identify the smallest shippable piece a user would actually notice

• For each piece, write one line: what will we learn from shipping this? If you can’t answer it, decompose further

• If the answer to the first question takes more than a sentence, the slice is probably still too big

3. Make constraints explicit

Another place where product managers 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 can happen 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: tell engineers what doesn’t matter right now:

• Long-term scalability? Not this sprint.

• Perfect edge case handling? Not yet.

And put a time box 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.

Try this week:

• Add a “not doing” section to your next brief – three bullet points on what engineering should explicitly deprioritize right now

• Try naming an appetite: “I think this is a two-day problem – does that feel right to you?”

• If engineering pushes back on the time box, treat that as the conversation you needed before work started, not a problem to manage

4. Bring back signal

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 product manager 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 product managers keep that signal flowing – not as a formal update, but as a steady habit of bringing the outside world back in.

Try this week:

• After your next stakeholder conversation, send engineering a short message: here’s what I learned, here’s what changed, here’s what we can stop worrying about

• Close every external conversation by asking yourself: is there anything here engineering needs to know?

• Even “nothing changed, we’re still on track” is useful signal – say it anyway

5. Share the “why”

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.

Try this week:

• Add one sentence to your next ticket: “We’re doing this because...”

• For bigger pieces of work, add a second: “The user we’re solving for is someone who...”

• If you catch yourself writing “just do X,” pause and add the why – it takes thirty seconds and it changes what gets built

Why this works

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 product manager in the room.

When engineers understand the user, the constraints, and the reason the work matters, those decisions get better. Product managers 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.

Thank you to Alex

My thanks to Alex for sharing this perspective from the engineering side of the table.

Many of these habits reflect a shift I’ve been exploring here: product managers moving closer to the work so teams can reason about the product together.

If you enjoyed this article, I encourage you to check out Alex’s newsletter, where he writes about engineering leadership, software teams, and the decisions that shape how products actually get built.

You can subscribe here: Thriving in Engineering

---

Looking for more practical tips to develop your product management skills?

• Product Manager Resources from Product Management IRL

• Product Management FAQ Answers to frequently asked product management questions

---

Connect with Amy on LinkedIn, Threads, Instagram, and Bluesky for product management insights daily.