How do the best Product Managers spend their time?

It's a bit like a sine wave

Our writing rarely targets early-career product managers, even though we love them - we were them! This is an exception. Here, we are speaking to anyone under Principal PM, including people who want to be PMs. Above those leadership levels, time allocation shifts significantly in different directions.

However, this piece will also be useful to founders, managers, and C-suiters for whom the product management role can often be an opaque mystery. What do they do, you ask? How do I know if they’re doing it well?

Product Management as a craft is still taught primarily by apprenticeships. There are almost no schools for product management¹. You have to learn on the job. The most frequent question asked to active product managers is “What is product management?” (Please confirm in the comments!). This level of role ambiguity is not the same with other branches of a core software team or shipyard, i.e., Software Engineering and User Experience Design (EPD).

First, it's a complicated job description.

Fundamentally, a product manager (PM) works:

1. To maximize customer satisfaction - workflow acceleration, useful and delightful user experiences, etc.

2. And simultaneously maximize business outcomes - adoption, conversion, retention, and business growth.

They do so in 3 key areas (see our previous article on this):

• Solving for customer needs/pain and shepherding software construction

• Working to shape how that product gets into customer’s hands

• Looking for market opportunities within their product’s business arena

Their highest-level tools are:

1. The product and company strategy - to know where they are aiming².

2. ‘Captaining’ the team that helps execute the roadmap - build in an urgent sequence from the sharpest problem onward.

Impedance matching between customer needs and desires, which leads to revenue, can take many forms. Therefore, there are many flavors and dialects of the product management craft. Sometimes, it's building an API. Other times, it's creating a user experience. Sometimes, it’s engineering a physical customer experience, i.e., a streamlined customer process, a hardware device, etc.

A Product Manager’s creative support teams can differ as well, ranging from software engineers to designers, researchers, data specialists, and product marketers. For example, @ Microsoft, Oji often collaborated with Microsoft Research to bring super early innovation to the market. And sometimes, that creative team can change within a single project.

In our careers, we have often found ourselves identifying a missing skillset and going to beg/borrow/steal it as needed, even if it means some initial dissonance or opposition from certain quarters.

We told you it was complicated. We never just get to sit and do a couple of things.

So what do they do day to day?

Our many experiences and conversations with PMs have shown us that a multitude of early career product managers don’t have a consistent mental model of what their day-to-day and week-to-week should look like to be effective. This is not a suggestion that there is only one way to do this. But it is an admission that PM mentorship can be shockingly lacking in specifics because often mentors are no longer practitioners and can’t get intimate with mentees such as how an army lieutenant leads his squad into battle.

And remember, there is no equivalent to West Point for PMs… yet. So while one specific prescribed way is likely wrong-headed, a description of the ideal key steps and key work scopes for being a PM can be useful to associate PMs, PMs, and Senior PMs - to help them level up significantly. So, let's try to describe an archetype of how a PM does PM day to day and week to week.

First, let's dispense with an important philosophical point. We believe in full-stack PMs. This means:

• PMs who can both execute and synthesize basic customer research on target customers

• PMs who can set small team strategy and tactics:

  • Synthesize the biggest customer problems.

  • Distill a roadmap - a sequence of paired problems and solutions in priority order.

  • Write specifications that clearly encapsulate the creative scope of an item on the roadmap that is clear to engineers, designers, and marketers.

  • Work with an EPD squad to build the right thing for the customer and the business.

  • Marshal the best release of the product feature set to customers.

We don’t believe in the split along the lines of Product Owners and PMs. We believe the best PMs aren't meant to have a split between strategy (objectives and customers) and delivery (execution). This creates structural gaps in insight from customers, that can be applied to building emotive products. This kind of partition is common in internal IT teams and contracting companies that build to order but less so in native software companies where the loss of fidelity in the product process could mean billions of dollars in opportunity. The riskier the problem you are solving, the more important using full stack PMs matters.

A PM’s ideal time distribution is like a sine wave

What follows is a generalization with some variation and applies most especially to early stage PMs.

We’ve found that great feature (solution) PMs split their time between customer insight & planning and execution in a roughly 50/50 split. The exact way this moves through time is best expressed as a sine wave. Good PMs do planning and execution simultaneously through smart time allocation. In the first part of the wave, they spend about 80% of their time planning and 20% in execution. In the second part of the sine wave, they spend only 20% on planning (the next feature) and the rest on execution.

The first part of the wave

The first part of the wave is about finding prioritized problems or opportunities and then finding creative solutions for them. This part is an extreme team sport. First, the PM must spend time getting to the heart of the problem or opportunity.

Key questions:

1. What will it solve for customers, and is that going to be significantly valuable for them and the business?

2. Is this the right thing to do right now, or should it be deferred (roadmap)?

Answering these questions properly requires a lot of customer listening, interviews, and data spelunking. Then based on this information and the creative sparks from the customer process, the PM defines the goalposts and what success is. And then finds creative solutions with designers, product marketing, and engineering leads (the shipyard team); who need to weigh in early on feasibility and also inform the rest of the software engineers what the coming project looks like.

The second part of the wave

The team that planned a feature then takes that plan and works with the rest of the engineering team in the squad to realize and build. More people now get to pick apart the details. The first part of this is intense collaboration. Here are key questions that need to be answered: Does the initial approach outlined by the engineering lead hold? If not, what needs to change? How long will it take, given that approach? What do we need to cut to keep the time to customers within a manageable range?

The first sprint in a build cycle is meant to put the framing of the feature in place and lay out the markers for a successful feature that will meet the goals of the customers and the business. Subsequent sprints should be about finishing strong. These subsequent sprints can be majority managed by strong product-centric developers and dev leads. And so the PM can again shift the majority of their time to the first part of the sine wave again.

A Time Management Symphony

No part of the sine wave demands 100% attention. As a 'full stack' PM juggling countless responsibilities, mastering time management isn't just helpful—it's survival.

Yet, there are critical "majority allocation" principles for each phase. You're never solely planning or executing, but you must always know where you stand on the wave and how to distribute your energy accordingly.

In planning mode, while you'll still attend execution meetings and file bugs, your primary focus (80%) should be giving shape to what comes next. This is non-negotiable.

Similarly, during execution, dedicate most of your time to the trenches—working alongside developers, designers, PMMs and data teams to clear roadblocks until the build finds its rhythm. This is the 'grind' phase, where you transform from architect to general contractor. Even here, reserve about 20% for customer immersion on future problems—interviews, data gathering, and discussions with customer-facing teams.

This balancing act impacts how product leaders should size PM teams. When individual PMs oversee too many developers, they inevitably neglect certain responsibilities, gravitating toward their comfort zones. The antidotes? Experience—seasoned PMs develop economic efficiency, especially when familiar with the company or domain—and Management—PMs with direct reports can delegate effectively when properly trained.

The full stack PM dances between creation and execution, never fully abandoning either, but always knowing which beat to emphasize.

Execution mode and the engineering team

For contrast, let’s overlay the engineering cycle on the PM cycle to see how they harmonize.

Great PMs work closely with their engineering team when a new feature needs to be built. In the first part of the sine wave, their primary partner is usually the engineering lead - they should regard them as a core creative partner, almost like a consulting PM. The dev lead can and will pull in specific expertise from other developers on his team to consult on questions they cannot answer, but remember that these individuals are doing something else already - trying to land an existing project to release / customers. Once the second wave starts, the PM now works with all developers (not just the eng lead) to build the feature.

There will be engineering docs to write and review, there will be questions about the spec, scope changes, and updates, and there will be open issues to crush. All these and more are the different costs for getting a project moving and into a groove.

Once a groove is established, most risky questions are answer, it should free up PMs to spend most of their time in the first part of the sine wave again - working with customers to sense the next important problem to tackle. Their capacity and velocity of doing this depends a lot on how much they have carried their team along - sharing customer insights, exposing engineers to customer interviews, and clarity in the objectives. Teams - especially developers who are dialed in on the soft and hard parts of the customer goals and the business goals - can intuit the right decisions to technical problems while building, meaning fewer questions get asked of the PM. Product-minded and customer-exposed engineers are worth a lot in productivity for the entire team. PM can catch any decision errata asynchronously or by quality checks at the end of the release cycle.

Small and intimate teams

Small and intimate teams can be very different from scaled teams. We think of a scaled squad as 1 pm, 7-15 engineers, 1 designer, and matrixed data analysis and customer insights. Intimate teams can be much smaller. Teams like these problem-solve together intimately so that there is little chance for the PM to strike out ahead, and thus, the PM and Engineering cycles tend to coincide. Teams like these tend to have to find things to do while PMs work out the right problems to solve. Or don’t spend enough time listening to customers for fear of being inefficient with engineering time (and salaries). However sometimes this can be a good thing, as build cycles can be much shorter and faster.

Summary

We believe that being concrete about the early career PM cycle will be helpful. We hope this helped at least one early stage PM out there 🚀
Sometimes, we are too abstract in describing our craft, and we’re working to make things tangible where they need to be.

In a follow-up, we will discuss how this basic cycle is speeding up in the age of AI and how it will fundamentally change the product development process for the most cutting-edge teams.

At the same time, we recognize that many teams still struggle with this basic PM cycle, which will be with us for a long time. As software eats the world, there will be more and more product teams in formerly non-technological businesses, and we’d like to provide a map for their success too.

—--

Listen to this article in our latest pod discussion!

Please sound off and tell me if you recognize your PM feature cycle in this article or if you think these descriptions are very different from what you have experienced.

1. The Kellogg School of Business has a product management program. Carnegie Mellon too. The rest are usually some kind of bootcamp. Not that we are knocking those.

2. Many people blame bad strategy on PMs. Don’t. That is the job of the C-Suite and the CPO.