Working with Product

The highest-leverage technical decisions get made while the requirements are still soft — before the ticket exists, while someone is still deciding what to build and why. An engineer who only shows up after the spec is frozen has already missed the window where their input would have changed the most. They can build it well; they cannot change what gets built or whether it should be built at all.

This is the difference between an order-taker and a partner. The order-taker's ceiling is implementation quality. The partner's ceiling is the product itself. Engaging with product is not scope creep on your job description — it's where a senior engineer's leverage actually lives.

Why Engineers Must Engage With Product

• Soft requirements are cheap to change. A sentence in a doc is free to rewrite. A shipped feature is not. The cost of influencing a decision goes up by an order of magnitude every step it travels from idea toward production. Engage early or pay later.
• You know things the PM doesn't. The PM does not know that requirement #3 is ten times the cost of #1, #2, and #4 combined. You do. If you stay silent until the estimate, you've let an avoidable decision get made blind.
• You see the cheaper path. Half the time the thing the PM asked for is not the thing they actually need. The user problem has a solution that costs a fifth as much, and only someone who understands both the problem and the implementation can spot it. That's you.

An engineer who only takes orders caps their impact at how fast they can type. The leverage is upstream.

Product Thinking for Engineers

You don't need to become a PM. You need to stop treating "what to build" as someone else's problem and "how to build it" as the first question. Ask the other two first:

• What problem are we solving? Not "what feature did we agree to" — what is the user's actual pain, and whose? A feature is a hypothesis about a problem; if you can't state the problem, you can't evaluate the feature.
• How will we know it worked? What changes if this succeeds — a metric, a behavior, a support-ticket volume that drops? A feature with no success criterion can't fail, which means it can't teach you anything, which means you're building on faith.
• Then: how do we build it? This is your home turf, and it's the third question, not the first.

When you can hold all three, you stop building things that technically match the spec and miss the point. You also earn the right to push back, because you're arguing about the problem, not just the work.

The Engineer↔PM Relationship

The healthy version is complementary, not hierarchical. Each side owns a domain and feeds the other:

• Shared ownership of the outcome. If it ships and the metric doesn't move, "the spec was right" is not a defense an engineer gets to use. You own the result with the PM, not just your slice of the build.
• No throwing over the wall. The PM who writes a spec, drops it, and reappears to ask why it's late is not partnering. Neither is the engineer who builds exactly what was written, knew it was wrong, and said nothing. Both are wall-throwing in different directions.
• The PM is not your boss. Prioritization is their call; how it gets built is yours. A relationship where the PM dictates implementation, or the engineer reprioritizes unilaterally, is broken in a way that will surface as a slow grind of resentment.

The best pairs operate like co-owners of a small business: different jobs, same bottom line.

Bringing the Technical Perspective to Prioritization

Prioritization is where engineering input is most valuable and most often absent. The PM is ranking value; they cannot rank value-per-cost without you.

• Surface cost, not just feasibility. "Yes, we can" is almost never the useful answer — everything is feasible. "Yes, and it's two weeks; here's the one-day version that gets 80% of it" is the answer that changes the roadmap.
• Surface risk and sequencing. "If we do B before A, A gets twice as hard" is information only you have. The order of the work is a technical input to a product decision.
• Offer the trade-off menu, not a single estimate. Instead of "this is six weeks," offer: the gold-plated version (6 weeks), the version that ships the core and instruments the rest (2 weeks), the throwaway prototype that tells us if anyone wants it (3 days). Now the PM is choosing among real options instead of negotiating one number down.

The cheaper alternative that hits 80% of the value is the single highest-leverage thing an engineer brings to a planning meeting. Look for it every time.

Influencing the Roadmap With Engineering Concerns

Tech debt, platform investment, reliability — these are real, and they lose every argument when phrased as engineering wants. "We need to refactor" is not a business case; it's a request for trust you may not have.

Translate into the language the roadmap is actually written in:

• Not "the auth module is a mess." Instead "every feature touching auth is taking 40% longer than it should, and that's three of the next quarter's five items."
• Not "we need to pay down tech debt." Instead "we're spending one engineer-week a month on incidents in this system; two weeks of work cuts that to near zero."
• Not "the platform needs investment." Instead "teams are blocked an average of three days waiting on environments; here's what that costs in shipped features."

Frame it as risk, cost, or velocity that the business already cares about. A PM can sell "this unblocks the roadmap" upward; they cannot sell "the engineers want to refactor." For the longer game of steering technical direction, see technical strategy.

Estimation and Scoping Honestly

Estimates are where credibility is won and lost. The goal is calibration, not bravado.

• Ranges, not false precision. "Three to five weeks, most likely four" is honest and useful. "27 days" is a lie with a decimal point. False precision feels confident and destroys trust the first time reality disagrees.
• The cone of uncertainty is real. Early estimates are wide on purpose; they narrow as you learn. Communicate the width, and re-estimate at known checkpoints instead of defending a guess made when you knew the least.
• Decompose. A six-week estimate is a guess. Six one-week pieces are six smaller guesses whose errors partly cancel, and the act of decomposing surfaces the work you forgot. If you can't break it down, you don't understand it well enough to estimate it.
• Defend against scope creep without being the "no" person. "Sure, we can add that — it pushes the date out by a week, or it swaps with feature X. Which do you want?" makes the cost visible and hands the trade-off back to the owner. You're not refusing; you're pricing.

Honest estimation includes admitting when you don't know. "I need a two-day spike before I can estimate this" is a professional answer, not a dodge.

Saying No, Constructively

The engineer who only says no becomes furniture people route around — see the blocker anti-pattern in influence without authority. The skill is pushing back in a way that moves things forward.

• Push back with an alternative. A "no" with no door open is a wall. "Not that, because X — but here's what would work" is a contribution. Never close a path without opening another.
• Make the trade-off the PM's to make. Most of the time you shouldn't be saying no at all; you should be making the cost visible and letting the owner decide. "That's possible but it means dropping Y" is more powerful than "no."
• Disagree and commit. Once the call is made — even against you — get behind it fully and visibly. Quietly relitigating a decided thing, or building it half-heartedly to prove it was wrong, is corrosive and noticed. The engineer who loses gracefully gets listened to next time.

Discovery and MVPs

You don't always know what to build, and pretending you do is how teams ship six months of the wrong thing. Build to learn.

• Ship to learn. The smallest version that puts the idea in front of real users teaches more than another planning meeting. Optimize the first release for information, not completeness.
• Spikes and prototypes. Time-boxed throwaway code that answers one question — "is this API fast enough?", "will users even click this?" — is cheaper than arguing. Label it throwaway and actually throw it away.
• Instrument to validate. A feature without telemetry is a feature you can't tell succeeded. Wire in the measurement before you ship, because retrofitting it after launch never happens. Tie it back to the "how will we know it worked" you asked at the start.

Anti-Patterns

• The order-taker. Receives tickets, builds exactly what they say, asks no questions. Reliable and replaceable. Their impact is capped at typing speed because they've outsourced every decision that mattered.
• The gold-plater. Builds the elegant, extensible, configurable version of something nobody asked for, while the thing users actually needed slips. Solving the problem you find interesting instead of the one the user has is a failure of product thinking dressed up as craftsmanship.
• "That's not my job." Draws a hard line at the spec and refuses to engage with the why, the user, or the business. Technically defensible and professionally inert. The line you drew is exactly the boundary of your impact.
• Hiding complexity until it's too late. Knows a requirement is brutally expensive and stays quiet, hoping it won't come up, until it surfaces three days before the deadline. The cost was the same all along; you just removed everyone's ability to make a different choice about it.
• Sandbagging estimates. Padding every number so you always look fast. It works until people learn to halve your estimates, at which point your real numbers are wrong too and you've lost the one thing estimates are for: trust. For pushing decisions to a clean close across stakeholders, see external collaboration; for keeping the underlying requirements honest, requirements management.

Self-Check

Before you start building the next thing on your plate:

Can you state the problem it solves and how you'd know it worked — without looking at the ticket?

If yes, you're a partner, and your input shaped what you're about to build. If no, you're an order-taker on this one, and you're about to spend real weeks on a hypothesis you never examined. Go ask, before you write the first line.