Working with product managers and designers

The best product work happens when engineering, product, and design solve the same problem together. You can still do excellent work in imperfect orgs, but the career lever is the same: understand the why, shape the what, own the how, and disagree productively when the plan will not work.

Two failure modes show up everywhere. In the first, eng is a ticket factory: low agency, low learning, high resentment. In the second, eng ignores users and invents architecture for sport: high agency, low impact. The middle path is shared problem ownership.

Deeper product concepts live in product thinking and PRDs. Here the focus is how you show up as an engineer day to day.

Concepts in this section

Step	Concept	What it answers
1	Discovery and delivery	Who owns what, and when do engineers join?
2	Cheaper product cuts	How do you offer an MVP with a cost, not a no?
3	Feasibility spikes	How do you raise a hard constraint before launch is marketed?
4	Working with designers	What belongs on the wireframe, not in QA?
5	Product-minded habits	What do you do after merge so the metric still has an owner?

In 1:1s, ask your PM: "What problem are we trying to move this month, and how will we know?" Volunteer for discovery spikes. Review PRDs with a written eng response. Pair with project execution: product alignment without delivery is still failure.

Disagree about goals and evidence, not status. Restate their goal, name your constraint, offer two or three options, escalate together if the stakes are high, then disagree and commit. Push hard on harm, security, data loss, and fantasy dates. Yield faster on taste when they have clearer customer signal. Silence on a PRD reads as agreement.

If the process is a feature factory, still ask for the user problem in the ticket, attach a cheaper alternative, and instrument so the next debate has data. Pick one collaboration improvement per quarter. Exit if you are permanently blocked from learning product sense — that skill compounds, and ticket work will not rebuild it.

Common mistakes

Implementing the ticket literally while knowing it will not solve the problem.
Saying "that's a product question" to avoid thinking.
Surfacing blockers only in sprint review.
Winning the argument and losing the partnership.
Giving design feedback only after the visual design is "final."
Skipping the post-launch metric check because "eng is done."

Key takeaways

Shared problem ownership beats a ticket factory and architecture-for-sport.
Start from user problem and success metric, then offer cheaper MVPs with explicit cost.
Raise feasibility risks early with time-boxed spikes.
Disagree with options and evidence; commit once decided.
Product-minded engineers join discovery, read metrics, and own outcomes after launch.