A product manager at a late-stage startup had shipped ten features in the past quarter. Her roadmap was full, her sprints were running on time, and her team was productive. She was also nagged by a persistent doubt: she did not know whether any of it was moving the metric that mattered. She suspected she was executing well on the wrong things. The calendar data gave her a specific reason to act on that suspicion.
The Layer Setup
She created five layers: Discovery & Research, Roadmap & Strategy, Execution & Delivery, Stakeholder Management, and Team Operations. She tagged four weeks of data — a representative period spanning an active sprint.
The Breakdown
- →6% Discovery & Research
- →9% Roadmap & Strategy
- →44% Execution & Delivery
- →28% Stakeholder Management
- →13% Team Operations
The 6% discovery allocation was the core finding. She was spending six minutes out of every hour doing the work that most directly informs whether the product is solving the right problems. The remaining 94% was execution, coordination, and management — all important, none of it generative.
A product manager who does no discovery is not a product manager. She is a project manager with a fancier title. The distinction has consequences for outcomes.
What She Changed
She protected a minimum of four hours per week for discovery — customer calls, data analysis, competitive research, and user session review. She moved two recurring stakeholder syncs to biweekly. She delegated sprint tracking to her engineering lead, freeing two hours of execution overhead per week.
The Outcome Three Months Later
Discovery rose to 18%. She killed two roadmap items that discovery showed had no user demand. She added one feature that came directly from a customer call she would never have had before. That feature drove a measurable improvement in a key activation metric within six weeks of launch.
I was not shipping badly. I was shipping blindly. More customer time fixed the blindness.
— Senior product manager, San Francisco