Working With Engineering
Ask questions that clarify constraints without pretending to choose the architecture alone. · Execution & Communication · Lesson 62 · 4 min
Working With Engineering · 4 min
Situation
“Can’t you just add a field?”
A PM asks for a second account owner. Engineering explains that permissions, billing, notifications, and historical records assume one owner.
The visible change is small; the underlying product assumption is large. Treat that explanation as information to understand, not resistance to overcome.
Mental model
Own the problem; collaborate on the solution.
Product typically clarifies user needs, outcomes, priorities, scope, and business rules. Engineering brings expertise in system design, implementation, reliability, and technical risk. Design shapes the interaction and experience.
Boundaries vary by team. The important work—feasibility, trade-offs, sequencing, and acceptance—is collaborative rather than a handoff between isolated owners.
Ask well
Start with the constraint behind the estimate.
“What assumption in the system makes this difficult? Which parts are required for the outcome? What options reduce scope? What risk would a shortcut create? What evidence would improve the estimate?”
These questions invite expertise. “Why does this take so long?” without context can turn an uncertain estimate into a defensive negotiation.
Example
Explore a narrower product rule.
If the immediate need is backup access when an owner is away, a delegated admin role may be simpler than fully equal co-ownership. Or it may not meet billing and legal requirements.
Clarify the actual user need, then ask engineering and design to compare options. Do not assume the narrower wording automatically means the implementation is easy.
Failure case
Promising a date before understanding the work.
An external commitment can pressure a team into hiding risk or dropping quality. Bring engineering into discussions that depend on feasibility and estimates.
When a date is fixed for a real reason, explain that reason and ask which coherent scope fits. Negotiate the outcome and constraints instead of demanding certainty from incomplete information.
Collaboration
Make technical debt discussable in product terms.
Ask what the debt prevents, which failures or costs it creates, and what becomes easier after addressing it. Some work protects reliability; some accelerates a specific roadmap investment.
Avoid requiring an invented revenue number for every maintenance task. Evaluate the concrete operational and delivery consequences with the team.
Think it through
Respond to an unexpected estimate.
Engineering estimates three weeks for a request you expected to take three days. Write a response that seeks the assumptions, alternatives, and risks before challenging the number.
A useful opening is: “Help me understand the work that drives the estimate. The essential outcome is backup access; what options do we have within that boundary?”
Remember this
Technical fluency improves collaboration, not role imitation.
Understand the system well enough to ask useful questions and defend product trade-offs. Let engineering expertise change the plan when it reveals a real constraint.