Clarify priorities categories so severity 1/2 bugs are not part of 15% budget...

| Step | Owner | Description |

|---|---|---|

| **1. Vision and planning** | Product, curated with the trio | Each team maintains a single source of truth for the problems it is solving, each mapped to one of the four customer outcomes. When a team picks up work, it should be clear what is happening and how it ladders to an outcome. Although flexibility to be reactive matters we hold ourselves accountable to ensuring we're always delivering on these customer outcomes. |

| **2. Prioritization** | Product, with trio inputs | Design and engineering each bring their own backlogs into prioritization alongside feature work. Before each planning cycle, Design maps quality gaps to customer outcomes and brings that list into planning. Engineering does the same for maintenance, bugs, and tech debt. A fixed 15% of each milestone is reserved for each, so neither backlog compounds over time. Both Design and Engineering own the input, not the roadmap. |

| **2. Prioritization** | Product, with trio inputs | Design and engineering each bring their own backlogs into prioritization alongside feature work. Before each planning cycle, Design maps quality gaps to customer outcomes and brings that list into planning. Engineering does the same for maintenance and tech debt. A fixed 15% of each milestone is reserved for each, so neither backlog compounds over time. Bugs are prioritized by severity per the org-wide [Issue Triage SLO guidelines](/handbook/product-development/how-we-work/issue-triage/#severity-slos). `~severity::1` and `~severity::2` bugs follow their SLO timelines regardless of the 15% allocation, given their active risk. Lower-severity bugs (`~severity::3` and `~severity::4`) without an SLO breach may be planned within the 15% maintenance/tech-debt pool. Both Design and Engineering own the input, not the roadmap. |

| **3. Design cycle** | Design, with the trio as collaborators | At the start of each planned feature the trio runs a design session: one PM, one designer, and engineering. This is a 30 minute working meeting to align on experience direction before work begins. PM brings the spec or brief, written and thought through beforehand. Design leads, owns the experience direction, and is responsible for the desirability and craft of what ships. Engineering and PM are collaborators who bring technical and product input. The output is a plan the trio has agreed to, often followed by a prototype to pressure test it before building. Engineering input happens here, at the start of the cycle, not at review. <br><br> Two kinds of work skip the design session: reversible low-risk changes, and exploratory POCs or feasibility spikes. If a POC graduates into a prioritized feature, it enters the design session at that point. Each team defines what qualifies as reversible or low-risk in their team charter. |

| **4. Milestone planning** | Product and EM | Prior to milestone kickoff the trio agrees on committed scope, the reversible and irreversible calls for the work (see Step 6), success criteria, and features which require design before development. Engineering commits to what they intend to ship in the milestone before the milestone begins. PM agrees to protect that scope. Issues intended to ship will use the `~Deliverable` label. Work can only enter the milestone when the trio has signed off on "readiness".|

| **5. Development** | Engineering | Work moves in small increments that are easy to deploy and roll back, shipping behind feature flags so the team can dogfood as it builds. Nothing ships to customers until PM confirms it meets the Minimum Lovable Product bar and Design has signed off. MLP is the quality bar that defines what we commit to customers. Increasingly AI handles code generation, tests, and first-pass review. Engineers engage where human judgment is required. |