skip to content

Search

Working With Engineering and Design

Less than one minute read Updated:

The PM triad only works when product shares context, invites real discovery, and knows when to defer to craft versus when to hold the line on outcomes.

# product-management
# strategy
# leadership
# learn
# collaboration
# engineering
# design
Product Management Foundations

A PM who reviews every mock and every pull request is not thorough. They are the bottleneck the team routes around.

I have watched this pattern on three teams now: a supply-chain platform at Dell, a 20-person AI creative team at Pixis, and the data platform under InMobi’s ad exchange. Same failure each time. The PM writes the spec, design paints the screens, engineering estimates and builds. By the time anyone talks, the assumptions are locked and the arguments are personal instead of technical.

The fix is not more meetings. It is sharing the problem earlier than feels comfortable, and knowing exactly when to defer versus when to hold the line.

So that’s today’s post.

Today’s Post

How to run the triad so it ships fast without becoming a rubber stamp, in six sections.

  • Why the spec handoff trains everyone to optimize for the wrong thing
  • The two failure modes: bottleneck and order-taker, and why they are the same mistake
  • When to defer to engineering, with a real example
  • When to push back, and how to tell inertia from a real constraint
  • What designers actually need from you, and what they do not
  • How trust gets built or destroyed, in specifics

1. The triad is one system, not three handoffs

Every healthy product decision runs through three lenses: desirability, feasibility, and viability. Will anyone want this? Can we build and operate it? Should we, for the user and the business? Split those into a relay, PM to design to engineering, and each function optimizes only for its own lens. Design chases desirability. Engineering chases feasibility. Nobody owns viability until launch week, when it is too late to change anything cheaply.

One system, or three handoffs Desirability, feasibility, viability decided together versus decided in sequence. Left: all three lenses live at once. Right: the same three lenses, run as a relay. The healthy version Desirability will anyone want it? Feasibility can we build and run it? Viability should we, for the business? Healthy zone all three, from day one The relay-race failure Lane 1: PM owns desirability writes the spec, alone Lane 2: design owns feasibility of use paints screens off the locked spec Lane 3: engineering owns feasibility to build estimates and builds the locked mocks Viability arrives at launch week too late to change anything cheaply desirability / input lens feasibility / process lens viability, arriving too late
Held together, the three lenses overlap from day one. Split into a relay, viability shows up last and costs the most. PNG ↓

Your job is not to have every answer. It is to hold the problem, the success criteria, and the tradeoffs visible while engineering and design bring craft to the solution.

2. The spec handoff hides discovery until it is expensive

The anti-pattern looks efficient on a roadmap slide: PM writes the doc, design ships mocks, engineering implements. In practice, the first real technical or user objection shows up after the flow is locked, when a rewrite costs a sprint instead of a conversation.

Run the relay, or overlap from day one Same three stages. Top: run end to end before any objection surfaces. Bottom: present together from the start. Scroll slowly, this plays once. Grey monospace text is what actually changed at that step. RELAY PM writes spec alone, then hands it off flow not yet shared Design ships mocks off the spec, as given flow now visually locked Engineering builds estimates the locked mocks a sprint of work committed First objection surfaces flow is already locked rewrite costs a sprint COLLABORATIVE DISCOVERY Framing conversation, day one: PM, design, and engineering in the room together rough prototype or a technical spike happens before the launch narrative is written objection surfaces while it still costs a conversation, not a sprint a stage owned alone handed off on the locked artifact the objection, arriving too late
The relay runs to completion before anyone objects. Collaborative discovery puts the same three people in the room from day one. (animates as you scroll to it) PNG ↓

Collaborative discovery means engineers and designers sit in customer conversations at a useful cadence. Not every call. Enough that the “why” is not filtered only through you. It means a rough prototype or a technical spike happens before you commit to a launch narrative. At Pixis, the pods that worked were built this way on purpose: engineers, APMs, and designers in the same discovery loop, not stacked in a queue behind one PM.

3. Bottleneck and order-taker are the same mistake in different directions

A bottleneck PM centralizes every question: design cannot pick a pattern without approval, engineering cannot choose between two implementations without a meeting. Sometimes that caution is earned, brand risk, regulatory language, a commitment already made to a partner. Most of the time it is a failure to delegate clarity.

Fix it by publishing decision rights alongside the goal. Say explicitly that design owns interaction detail within stated guardrails, or that engineering picks between two approaches if both clear the success bar. Withhold that, and you train the team to stop proposing anything, then complain that nobody acts like an owner.

The opposite failure, order-taking, feels collaborative and is actually passive. Whatever engineering estimates becomes the roadmap. Whatever design prefers becomes the vision. Your accountability is the outcome you committed to. If the team drifts toward technical elegance or visual polish without moving that number, staying quiet is not humility, it is abdication.

4. Defer to engineering when the risk is theirs to carry

Engineers live with the operational cost of a shortcut: the incident, the edge case, the migration nobody scoped. When an engineer says a shortcut will produce incidents, believe them unless you have strong evidence otherwise.

Here is the shape of the tradeoff worth deferring on: you want a real-time dashboard. Engineering proposes a five-minute delay with stronger caching instead. If the actual job is a morning review, not a trading floor, take the simpler version. The five minutes costs you nothing the user job needs, and it buys the team a system that does not page anyone at 2 a.m.

At Dell, moving from engineer to product taught me this the slow way: I had already lived the cost of a shortcut from the other side, so I read the code before I read the roadmap. That habit, checking what a proposal actually costs to run before arguing against the simpler version, is the single most useful thing that transition gave me.

5. Push back when the constraint is a habit, not a wall

Not every “that’s hard” is immovable. Sometimes difficulty is protecting inertia: a module nobody wants to touch, a pattern that made sense three years ago, risk aversion wearing the costume of architecture. Push with a question, not a demand: what would need to be true to make the better experience feasible? Often the answer is a phased rollout, a temporary flag, or finally staffing the refactor everyone has been avoiding.

Defer to craft, or push back on habit The same disagreement, placed in one column or the other. Ask which side an engineer's "that's hard" actually belongs on before you argue. DEFER — engineering craft Risk of the shortcut is theirs to carry Cost is operational: an incident, an edge case, a migration Simpler version costs nothing the user job needs You have not read the code well enough to argue the cost Example "real-time" dashboard vs. a 5-minute cache job is a morning review, not a trading floor the delay buys a system nobody pages at 2am for PUSH BACK — unexamined habit "That's hard" is protecting inertia, not a real wall A module nobody wants to touch, not a load-bearing one Risk aversion is wearing the costume of architecture A pattern that made sense three years ago, unexamined since Example push with a question: what would need to be true to make the better experience feasible? answer is often a phased rollout or a staffed refactor Deferring to craft builds trust. Challenging an unexamined default moves the product. Mixing them up loses both.
Same disagreement, one column or the other. Deferring to craft builds trust; challenging an unexamined default moves the product. PNG ↓

Deferring to craft builds trust. Challenging an unexamined default moves the product. Mix the two up and you are either a pushover or a jerk, and the team stops trusting either read.

6. Designers need partnership from the framing stage, not a flow to skin

Design is not paint on a finished spec. A designer synthesizes the user’s mental model, cuts cognitive load, and holds the surface to brand and accessibility standards you did not have to think about because they already did. Loop them in after the flow is “locked” and you have wasted their highest-leverage work on cosmetics.

Bring designers into the framing conversation itself: who is this for, what are they trying to accomplish, what does failure look like for them? Inside agreed brand and accessibility guardrails, let design own interaction detail, hierarchy, and motion without your sign-off on every spacing choice. Push back only when a visual direction outruns the outcome, when something demos beautifully but fragments engineering or confuses the actual user. Negotiate that with a prototype and a number, not an opinion: if a fancier onboarding measurably lifts activation, prioritize it; if it adds weeks for a marginal gain, scope it down.

7. Trust is a compounding account, and it is funded in specifics

Engineers trust PMs who protect their focus and never pretend an artificial deadline is physics. Share the real business context: why leadership cares, what commercial commitment exists, what is genuinely uncertain. Nothing corrodes faster than a PM who knows a date is soft and broadcasts it as fixed anyway.

Designers trust PMs who engage on user evidence, not personal preference, and who credit the work publicly when it ships. Both trust a PM who follows through: who fights for a sustainable pace, removes a policy blocker before it is asked for, and never treats an estimate as a promise given without the team’s consent.

None of this scales by adding headcount or renaming the standup. It scales when the rituals match the actual risk in front of you, a discovery sync for the ambiguous bet, a technical spike before the launch narrative is written, and nothing heavier than that for the low-risk iteration.

Takeaways

Working with engineering and design, in six moves The triad ships fast without becoming a rubber stamp when you know which move applies Hoshank Ailani · hoshank.vercel.app 1. One system, not three lenses Desirability, feasibility, viability decided together, not handed off in turn Split into a relay and each function optimizes only for its own lens nobody owns viability until launch week, when it is too late to change cheaply your job: hold the problem and tradeoffs visible 2. Handoff versus discovery SPEC HANDOFF COLLABORATIVE objection surfaces objection surfaces after the flow is locked before it is locked Rewrite costs a sprint instead of a conversation Pixis pods: engineers and designers in the discovery loop, not stacked behind one PM 3. Bottleneck and order-taker 1 Bottleneck: gates every micro-decision 2 Order-taker: goes quiet, calls it humility 3 Both skip publishing decision rights fix: state the goal and who owns which call, design owns interaction, engineering picks the approach your accountability is the outcome, not the silence 4. Defer when the risk is theirs "real-time" dashboard 2am pages 5-minute cache instead nobody paged Job is a morning review, not a trading floor; the delay costs nothing the job needs Dell: reading the code before the roadmap is the most useful habit that engineer-to-PM move gave me 5. Push back on habit, not craft Not every "that's hard" is a wall sometimes it protects inertia a module nobody touches a pattern from three years ago risk aversion costumed as architecture push with a question: what would make it feasible? answer is often a phased rollout or a staffed refactor 6. Trust compounds in specifics 1 Share real business context, no fake deadlines 2 Engage on evidence, credit the team publicly 3 Never treat an estimate as a promise you gave alone rituals should match the actual risk: a discovery sync for the ambiguous bet, nothing heavier for the routine The PM who "works well" with the team shares context before it is asked for. The test to run this week: pick your last three-way disagreement and place it in a column. Full post: hoshank.vercel.app/posts/pm-track-working-with-engineering-and-design Takeaways
The whole post on one card. Save it, share it, argue with it. PNG ↓

Six panels, one per section. The test to run this week: pick your last three-way disagreement and place it in the defer or push-back column.

Final Words

The PM who “works well with engineering and design” is not the nicest person in the room. It is the one who shares context before it is asked for, holds the outcome clearly, argues tradeoffs with a number instead of a title, and knows exactly when to get out of the way.

Reply and tell me which side of the defer or push-back line your last argument actually belonged on.

Cheers, Hoshank