Design as a Discovery Discipline (Not Downstream Delivery)

Design is popularly misconceived as a downstream, delivery-facing role: product and engineering decide what to build, and design receives handed-off requirements to make it "look pretty." Chris Jones (SVPG) argues the best companies invert this — design is fundamentally a discovery role, which is why a designer sits paired directly with a PM (see Product Trio) from the start rather than receiving specs afterward.

Evidence cited for design-as-discovery:

Steve Jobs, as quoted in the episode: design is not what something looks or feels like, but "how it works" — design is about total experienced value, not aesthetics or feature count.
A good designer produces on the order of two dozen prototypes a week across many fidelity levels, most of which are discarded, as part of Discovery (Product Discovery Process). Delivery assets for engineering account for only about 10% of a designer's time.
Marty Kagan's analogy, as credited by Chris: handing a designer pre-made wireframes to build from is as absurd as handing an engineering team pseudo-code and telling them to just implement it.

When design is undervalued this way, companies frequently understaff it or place it under marketing for purely visual work — treating it as decoration rather than a discovery function that determines whether the right thing is being built at all.

Pairing at the Start & the Pseudo-Code Analogy

Designers are paired directly with a PM from the beginning of problem exploration — not brought in after the "what" is already decided — so design shapes the solution rather than just its visual skin.

Marty Kagan's analogy: handing a designer finished wireframes is like handing an engineering team pseudo-code and telling them to just implement it. Requirements that already contain wireframes force designers into 'solutioning' around an imposed layout instead of working the design problem from scratch. See Product Trio and Extended Trio (Commercial Stakeholders in Product Trios) for related team-composition patterns.

Из тем: The Product Operating Model