How designers can work better with product managers

Simple lessons from working with product managers in fast-moving teams. This is about starting before Figma, using sketches as thinking tools, disagreeing early, and keeping the problem bigger than personal taste.

By Devendra SinghNotes between me and myself

  1. I used to think the PM-designer flow was simple.

    PM writes requirement. Designer makes screens. Engineer builds.

  2. It is simple on paper.

    In real work, the requirement changes, engineering finds limits, business wants speed, and users do not behave like the doc expected.

    That is why the relationship matters.

  3. So where should design start?

  4. Before Figma opens.

    If design starts only after the requirement is locked, you are mostly arranging decisions someone else already made.

    Start with the problem: where are users dropping, which users are dropping, what do they expect, and what business goal are we trying to protect?

  5. But PMs also come with design ideas.

    Sometimes even sketches.

  6. A PM sketch is not an attack on design.

    Most of the time it is raw thinking. It shows how they see the flow or business logic.

    Do not copy it blindly. Also do not reject it just because it is not polished. Ask what it is trying to solve.

  7. What should the PM own then?

  8. The PM should be clear about the problem, priority, business reason, and success measure.

    The designer should own the experience quality and the path that makes sense for the user.

    The engineer should say what is easy, risky, or expensive.

    Everyone can have ideas. Ownership still needs to be clear.

  9. What if I disagree with the requirement?

  10. Disagree early.

    Late disagreement is expensive. Early disagreement is still useful.

    Do not say "bad UX" and stop there. Say the user has to think too much here, or this adds one step before value, or this may help conversion but hurt trust.

  11. Should I show one strong design or many options?

  12. Show options when the tradeoff matters.

    One final design can make people react to pixels. Two or three options make the choice visible.

    • Fast to build, but weaker for the user.
    • Better experience, but more effort.
    • Stronger long-term direction, but not for this release.

  13. So the goal is not to win against the PM.

  14. No. The goal is to make the product decision clearer.

    Start together. Ask better questions. Explain design in simple product language. Share tradeoffs. Keep roles clear, but keep ideas open.

    Good PM-designer work starts before Figma opens.

Back to all notes