When Pitching Designs Stops Working

Most product designers know the familiar loop: produce a proposal, gather a few people in a room (or on a video call), present the screens, collect feedback, and iterate. In small, co-located teams, this can work well. In a remote or distributed setup, the same approach often falls flat. Stakeholders are distracted by their own tasks, feedback is vague, and proposals stall without ever reaching a clear decision.

This is exactly what happened to product designer Ismael González when he joined a remote team in 2018, coordinating design work with colleagues in Mexico and Brazil from his home in Madrid. Despite producing what he believed to be strong work, his proposals kept failing to move forward. The issue was not the design quality — it was the lack of an adapted process for asynchronous, remote collaboration.

Looking at how engineering teams solve the same problem, González found a model worth borrowing: the pull request. Developers document their changes, submit them for review, and incorporate feedback in an explicit, trackable loop. The design equivalent, he argues, is the Product Design Doc (PDD) — a living document that records the entire design journey from problem statement to final solution.

Anatomy of a Product Design Doc

A PDD is built around four core concepts:

  • Metadata — practical information about the document itself, such as title, date, and current status.
  • Context — everything a reader needs to understand the design problem: description, abstract, goals, and the intended outcome.
  • Stages — consecutive iterations of the solution, each building on the previous one and addressing feedback. Stages typically start broad and narrow in focus over time.
  • Feedback — the comments, requests, and critiques collected from stakeholders and teammates at each stage.

These four components are flexible, so a PDD can be adapted to any company's workflow. The structure below is one working example, not a fixed template.

A Practical Section Structure

González used the following sections in his PDDs:

  • Title — concise and unique, easily distinguishable from other PDDs in the same project.
  • Status — signals where the document currently stands:
    • Draft — still defining context; not ready for feedback.
    • S30, S60, S90 — three solution stages (details below).
    • Complete — all feedback resolved and no remaining open points.
  • Abstract — describes the design problem, often with links to relevant background material.
  • Goals — the key criteria the solution must satisfy; a checklist revisited at every stage.
  • S30 — the first proposal, focusing on the broad approach rather than details (e.g., low-fidelity wireframes). Major conceptual feedback is expected here.
  • S60 — applies feedback from S30, refining the solution to about 60% completeness. Uses high-fidelity wireframes, more use cases, and defined flows. Feedback at this point targets missed scenarios and edge cases.
  • S90 — applies feedback from S60, taking the design to near-final polish: corner cases, visual design, and prototypes. Only minor feedback is anticipated.

The naming and ordering are not sacred. S30/S60/S90 can be renamed to Exploration, Proposal, and Solution. The order of sections can also be reversed, placing the final version at the top and working backwards through the iterations, which can make reading easier for stakeholders who just want to see the result.

Starter Templates

Templates are available for popular writing platforms so teams can get started quickly without over-complicating the setup:

Why Write It All Down

The shift from pitching to documenting carries several practical advantages.

  1. Design decisions have a permanent record. When a designer leaves a team (which happens to everyone eventually), the knowledge behind their work remains accessible. Future colleagues can review, learn, and iterate from where the previous designer left off instead of starting from zero.
  2. Communication becomes more inclusive and aligned. Anyone can read the PDD and provide feedback asynchronously, so more voices are heard and no one is left out of the conversation. The whole team sees not just what was decided, but why.
  3. Stakeholder feedback stays scoped. Because each stage narrows the feedback focus, reviewers face a single, manageable set of considerations at a time. This prevents the common problem of late-stage requests for major directional changes.
  4. The product gets built collaboratively. By inviting engineering, product, and other teams into the document — rather than presenting them with a finished solution — the design process becomes a shared effort, and the team takes ownership of the outcome.

Fit for Remote Teams

González reports that using PDDs across at least five projects in his remote role significantly reduced frustration. Proposals reached consensus and product development continued to move forward. He notes that the topic remains relevant — he originally drafted this material in 2019, paused it, and finished it in 2021 after seeing another company introduce tooling for the same documentation gap. As remote and async workflows become more common, expecting designers to get approval through a single live presentation is outdated. A document that lets the design process be inspected, questioned, and approved on its own merits is a more durable model.