Learnings from Design Execution & PM Collaboration

These are working principles I've developed from collaborating closely with PMs across product teams. Some came from getting things right, most came from getting them wrong first — shipping too fast, misreading scope, or presenting the wrong thing to the wrong room. I revisit these regularly.

• Don't jump into Figma immediately.
• First, read the user story or PRD carefully.
• Ask:
  • Why are we building this?
  • What's the user goal and business context?
• If unclear, set up a requirement-gathering call with the PM. Bring specific, thoughtful questions.

• Identify what truly matters for this feature. What is critical for v1?
• Clarify where the boundaries lie: What should be solved now vs deferred?

• Before designing, outline your initial approach in plain text or rough user flow.
• Share with PM to align on direction before jumping to visuals.
• Start by designing the happy path first. Handle edge cases later.

• Keep the PM in the loop as you explore—don't wait until you're "done".
• Ask early:

  "Am I solving the right problem the right way?"

• Get an internal PM review first before involving wider stakeholders.

• Only touch what's in scope. If you spot unrelated UX debt, flag it separately as a backlog improvement task.

• Consider the product-wide impact of your decisions.
• Use or extend reusable components where possible:
  • Card layouts
  • Info modules
  • Steppers / Tabs
  • Consistent patterns = scalable design

• Create 2–3 design variants.
• Alongside visuals, clearly explain:
  • The why behind each direction
  • The trade-offs considered
  • Any assumptions made

• Before any review:
  • Summarize the problem and context
  • Share design goals and constraints
  • List what specific feedback you need
  • Present different iterations, not just polished output
• Refer back to key ideas from Articulating Design Decisions (Tom Greever).

• Schedule review meetings in advance to give everyone time to review.
• Don't wait for someone to ask—drive the feedback process.

• Say no to shallow UI tweaks if you can contribute to core end-to-end features.
• Aim to work on tasks with clear user value or measurable product impact.

• Before revising someone else's design:

  Ask the PM, "Why was it originally done this way?"

• Avoid unnecessary rework or breaking intentional decisions.

• Create a basic interactive prototype to support your design presentation.
• Helps reviewers experience the flow and provide better input.

The thread through all of these is the same: slow down at the start, communicate more than feels necessary, and treat the PM relationship as a genuine collaboration rather than a handoff chain. The designs that land well are almost never the ones built in isolation.

---

Credits & further reading

• Articulating Design Decisions — Tom Greever (O'Reilly). Already referenced in point 8, and worth calling out properly: his three-question framework (what problem does it solve? how does it affect the user? why is it better than the alternative?) is the most useful structure I've found for preparing design reviews. Directly shaped how I run feedback sessions.
• Continuous Discovery Habits — Teresa Torres. Her framework for making discovery a regular habit rather than a project phase is the underlying logic behind "start with understanding, not building." Pairs well with the PM collaboration principles here.
• Inspired — Marty Cagan (SVPG). His writing on the difference between delivery teams and empowered product teams is the broader context these principles live inside. Understanding what a good PM-designer relationship looks like requires understanding what good product teams look like at all.