2 min lesson
Triage by trust impact, not by who's loudest
For each case in "Triage by trust impact, not by who's loudest", name the signal and the response you would use.
Step 1 of 2
Triage by trust impact, not by who's loudestseverity × frequency × trust
The trap is fixing the bug the loudest person filed instead of the one quietly hurting the most users. A simple scoring lens keeps you honest: how bad is it when it hits, how often does it hit and how much does it make people distrust the tool. The third factor is the one most teams forget and it's the one that matters most for a daily-use product.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
The loudest report is one input, not the ranking - trust impact is the factor most teams forget.
Learn more
Full explanation
Drive closure, not tickets
Drive closure, not ticketsthe hard part is finishing
Filing the paper cut is the easy 20%. The reason these bugs persist is that they're individually small enough to always lose to the next big feature, so they rot in a backlog forever. The PM's real job here is to manufacture the conditions where they actually get fixed.
- Batch them into a recurring quality budget - a standing slice of eng time so paper cuts compete against each other, not against the headline feature.
- Make the long tail visible to leadership as a trust metric, so "polish" has a number behind it instead of being a vibe.
- Drive each one to closed and verified in production, not "merged" - for a daily-use tool, the fix only counts when users stop hitting it.
- Celebrate the closes the way launches get celebrated, so the team feels the quality work is valued, not invisible.
Track paper cuts to verified-in-production, not to "merged" or "closed." The whole point is that the user stops hitting the friction. A bug that's marked done but still fires for real users in the field is worse than untracked, because now everyone believes it's handled. Confirm on real telemetry that the cut actually stopped bleeding.
Own the small fixes yourselfPMs and designers push the P2s and P3s
The most reliable way to make sure paper cuts get fixed is to stop waiting for someone else to fix them. At Cursor, PMs and product designers own a lot of the frontend and UX and iterate on it very autonomously - they push code for the small things the team is never going to get to, the P2s, the P3s, the one-line UI tweaks. It's not a fantasy reserved for engineers. With a dev environment set up, it's a very doable place to get to.
There's also no blank-page tax on the way in. Because you start from the ticket or PRDProduct Requirements Document. The spec describing what to build, for whom and why, before implementation starts. Increasingly the artifact you hand an AI agent as the source of truth for a feature. Press Enter for the full definition. and point Cursor at it to define a plan - and often the PR itself - you're rarely cold-starting. You pick up work from an agent's investigation or a near-complete draft and take it from there.
“Every time someone starts actually building something they can essentially start with like a 90% of the PR complete or an entire plan or architecture diagram.”
The setup that makes this safe is a short loop: background agents pick up the small Linear tickets, BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. reviews their output, and you test it in a local dev environment before it ships. That review gate is what lets a non-engineer push code without lowering the quality bar. The payoff is less deliberation - anyone with an opinion can just make the change and judge it in the running product instead of arguing about it in a meeting.
Learn more
Full explanation
PM-Owned Paper-Cut Fix Loop
Interactive diagram. Step through it with the Next and Previous controls below, or Tab to a region to read its detail.
From ticket to verified-in-production without a cold start - Bugbot is the review gate that keeps the bar high.
Have one real story ready of a quality bar you held - a small fix you fought for and shipped that earned user trust. Tell it with the system, not just the heroics: how you found it, why you ranked it over louder work using frequency and trust impact and how you drove it to verified-in-production. That narrative proves taste and ownership at once, which is exactly what this round tests.
QYou have two bugs: a dramatic crash that affects a rare workflow once a week and a tiny autocomplete glitch in the core editing loop that fires for most users dozens of times a day. Eng can only take one this cycle. Which do you push and how do you justify it?
Learn more
Optional practice