The 60% Problem: Where Product Teams Actually Lose Their Time

The Job Nobody Hired You For

Ask a product manager what they were actually hired to do, and you’ll hear some version of: figure out what to build, decide what matters, and talk to customers. Ask them what they actually did last Tuesday, and you’ll hear something different: reformatting research notes, writing the fourth draft of a spec nobody read carefully, chasing sprint updates in Slack, and reconciling a Figma file with a ticket that says something else entirely.

This gap is not a personal failing. It’s structural. Product work has always had a core of judgment (prioritization, taste, relationship management) wrapped in a much larger shell of supporting labor (synthesis, documentation, coordination, translation). The judgment part is why you were hired. The supporting part is why you’re tired.

The useful question isn’t “how do I do my job faster.” It’s “which parts of my job were never actually my job to begin with, and can they be handled differently.”

Separating Judgment from Support Work

Before changing anything, it helps to sort your actual week into two buckets.

Judgment work

• Deciding what problem is worth solving right now
• Weighing tradeoffs between competing priorities
• Reading a customer’s frustration and knowing what it really means
• Deciding when a design is “good enough” versus needs another pass
• Managing the trust and politics of a cross-functional team

Nobody else can do this for you. It requires context, accumulated pattern recognition, and stakes you’re accountable for. This is the part of the job that justifies the title.

Supporting work

• Turning fifteen interview transcripts into a coherent theme
• Drafting the first version of a spec from a rough outline
• Producing design variations to react to
• Compiling sprint status from scattered updates
• Translating a design decision into terms an engineer can implement without guessing

This work is real and necessary. It’s also mechanical enough that a first draft, a first pass, or a first synthesis doesn’t require your particular judgment to produce. It requires your judgment to evaluate. That distinction matters more than it sounds like it does.

Where the Time Actually Goes

Research synthesis

Most PMs and designers sit on more user research than they ever fully process. Interview notes pile up. Support tickets get skimmed once and forgotten. The synthesis step, pulling patterns out of scattered qualitative data, is exactly the kind of task that eats hours without requiring you to be in the room. The judgment happens after synthesis, when you decide which pattern actually matters and why. Treat the first pass as raw material generation, not as the analysis itself.

Spec drafting

A blank document is the single biggest time sink in most product workflows. Writing a spec from scratch, structuring the sections, restating context that everyone already knows, drafting acceptance criteria, takes far longer than reviewing and correcting one. If you can get from zero to a rough-but-structured draft faster, you spend your time on the part that matters: sharpening the actual decision and making sure the edge cases are covered.

Design iteration

Designers lose real time to the mechanics of producing variations, not to the decision of which variation is right. Generating five layout options to react against is different work from deciding which layout serves the user. The former is volume and speed. The latter is taste. Conflating them is how a designer ends up spending an afternoon on production instead of on the judgment call the afternoon was supposed to be for.

Sprint administration

Status updates, ticket grooming, standup notes, retro summaries: none of this requires your product sense. It requires accuracy and consistency, which is exactly the kind of task that benefits from being handled by something rigorous and repeatable rather than by a person’s dwindling end-of-day attention span.

Design-to-engineering handoff

This is where ambiguity costs the most, because it compounds. A design decision that isn’t translated precisely into implementation terms turns into a Slack thread, then a meeting, then a rebuild. The handoff step is supporting work with outsized consequences when it’s done poorly. Tightening it up doesn’t reduce the importance of design judgment, it protects that judgment from getting lost in translation.

A Simple Filter for Any New Tool or Process

Whenever you’re evaluating a new way of working, whether it’s a tool, a template, or a delegation to a teammate, run it through one filter:

1. Does this replace a decision, or does it replace the labor before a decision? If it’s replacing labor, it’s fair game. If it’s replacing the decision itself, be careful. Decisions are where your accountability lives.
2. Can you verify the output faster than you could have produced it yourself? If reviewing a draft takes as long as writing one, you haven’t saved anything. The value only shows up when verification is meaningfully cheaper than creation.
3. Does it preserve your fingerprints on the final version? A spec, a design, or a research summary should still sound and look like something you’d stand behind. If the output is generic or unrecognizable as your team’s work, it needs another pass before it goes out the door.

Consolidation Beats Sprawl

One trap worth naming directly: adding five new point tools to handle five separate supporting tasks usually makes things worse, not better. Each new tool adds a login, a context switch, and a place for information to get stranded. A sprawling stack of narrow tools creates its own tax, one that looks like productivity but functions like fragmentation.

Before adding anything to your workflow, ask whether it consolidates effort or scatters it further. The goal is fewer places where your attention has to context-switch, not more surfaces to manage.

What Doesn’t Change

None of this touches the parts of the job that make you good at it. Customer relationships still require you to show up, listen, and follow through. Prioritization still requires you to say no to good ideas in favor of the right ones. Taste is still earned through repetition and exposure, not generated. The point of reclaiming supporting work isn’t to do less of the job, it’s to spend more of your actual working hours on the 40% that only you can do, and less of it re-typing what you already know into a different format.

Start by tracking your own week for a few days. Note where the hours actually go. Most people are surprised by how much of their calendar belongs to the supporting-work bucket rather than the judgment bucket. That gap is usually the first thing worth fixing.

For the complete, structured playbook on this topic, see AI for Product Teams: Workflows for PMs, Designers, and Engineering Managers Who Want Their Time Back in our library. New here? Start with our free guide.