pm-design-process-routerlisted

# PM design process router Most PM teams have one design process, and they run every feature through it. The team that ships a bug fix the same way it ships a new product line wastes the small work, and the team that ships a new product line on Express Lane ships something half-baked. This skill takes a feature scope description and recommends which lane it belongs in. The router applies a scope estimate (XS, S, M, L, XL), accounts for moderating factors (user novelty, reversibility, public visibility), and outputs a specific recommended process with named stages and owners. The two-lane pattern is borrowed from enterprise design organizations that have separately optimized their pipeline for big-features-with-real-uncertainty vs. small-fixes-with-known-shape. Most PM teams don't formalize this and pay the cost in both directions. ## When to use Use this when: - Kickoff for a new feature, before committing design and engineering time - The design team is over-loaded and the PM needs to decide which features get the full process - A feature feels small but is taking weeks to review — surface whether it should be on Express Lane - The team is debating whether something needs a Figma or not - Estimating timelines across a backlog with mixed scope Don't use this when: - The feature is research-only with no shipping artifact (use `pm-decision-coach` instead) - The organization has its own mandatory design-intake process that supersedes this routing - The scope is genuinely u