1 of 5

WHEN & HOW TO USE R&R DOCS

Early and often! It’s amazing how much x-functional ambiguity there is in roles & responsibilities until nailed down
When ICs are going to managers complaining about another function dropping the ball on something
When ICs are complaining about cross-functional turf wars
Rollup manager (i.e. the person who both functions report to) should create a first pass, then ask function leads to polish up, align on final details and share with their respective teams

2 of 5

Roles & responsibilities: Product Development

	Pick what to design Combine business priorities w eng input (PRDs)	Talk to urs Regularly chat w users to stay grounded	Design (UX) Drag-n-drop components, decide when new one is needed	Analytics spec & readout Spec & readout	Pick what to build Roadmap, assignments, setting & reporting on timelines	Product quality Drive QA process (PM recruited to help)	Release analysis Quick-n-dirty monitoring post-release for top-level metrics and outages	Design (UI) Component design (pixels colors, states, animates)
PM	X	X	X	X
Eng					X	X	X
UI Design								X

3 of 5

PM <> Design FAQs (1/2)

Isn’t it standard to have a UX designer as well?

The ‘trinity’ is still the most common product development team structure, especially in older companies and big tech. However, the past decade of tooling improvements and industry standard solidification has made a 2-person model possible and it’s now starting to become increasingly popular. We believe this evolution will gradually happen industry-wide, much like SDETs circa 2013.

What are the advantages of this this system vs the ‘trinity’?

Having fewer stakeholders makes building great product faster & less prone to politics. Cutting the core product unit down to two people results in less communication overhead, more functional incentive-alignment, and faster iteration.

4 of 5

PM <> Design FAQs (2/2)

What are the disadvantages of this this system vs the ‘trinity’?

Hiring is harder. This model requires both the engineer and the product person to be good at things many people with that title aren’t. This puts more pressure on the interview process to test for necessary skills.

Are we expecting to “outgrow” this model at any point?

We have no reason to believe this model won’t scale. That said, we’ll need to maintain a strong design system and to continue hiring and nurturing strong generalist product & engineering talent. Those are the two potential breaking points.

5 of 5

PM <> Eng FAQs

Yes, eng gets to make the final call on what they want to pull in and when they want to pull it in. Eng can choose between design-complete features, user-facing improvements that fit within an existing design (e.g., ops automation), internal tools, or tech debt/infra, based on what’s ready for eng.
If PM disagrees, then they need to pitch harder! It’s their job to be convincing. If they can’t convince eng that a feature is more important, then they need to try harder, find more proof points. No need to give them a pass.
Design and eng backlogs are asynchronous. PM and eng have shared priorities, but do not need to precisely synchronize their schedules. PM can build up a design backlog without the need to granularly synchronize with eng, and eng can take on design-complete features without needing to granularly schedule designs with PM.