Pragmatic Institute's State of Product Teams report says that where product teams got time back, much of that time went to alignment, not market learning.
You may be telling your leadership team that automation, and AI in particular, has sped up your product people and given them more time for strategy. And their calendars look strategic enough. Roadmap reviews. Prioritization syncs. Stakeholder readouts. And of course, the pre-meeting for the stakeholder readout. You've had those too.
So the question is who that time actually faces: the people inside your building, or the customers and users outside of it.
By the end of this article, you'll have a way to sort one week of your team's time by who it faces. You'll also have one line to use in the next meeting that mistakes agreement for evidence.
A Strategic-Sounding Week
Picture a product manager at the start of a week, looking at what's ahead. Product managers are usually some of the busiest people in the organization. Say she has 30 hours booked, and 19 of them face inside the building, with teams and coordination.
Monday, she has a roadmap review. Tuesday, a prioritization sync with her stakeholders. Thursday is the stakeholder readout on how the programs are going, which is where leaders agree on what customers want. But wait, there's also the meeting before the meeting. That Thursday readout has its own pre-meeting on Wednesday, so everyone arrives on Thursday already agreeing.
Sound familiar?
Another nine hours face delivery: refinement, sprint reviews, questions from the developers. All valuable things we have to do.
That leaves about two hours facing the market, the users, the customers. One customer call, and maybe a skim of the support queue to see what's going on out there.
Every one of those internal hours is about customers. Not one of them has a customer in it.
By Friday, she's tired, and nobody would look back and call it a bad week. Every meeting on the calendar had a strategic-sounding name, and you could reflect on each one and say it was worth doing. But ask her what she learned from customers this week, and she'd probably have to stop and think about it. That's very common across most of the product managers I work with.
That week isn't broken. It ran exactly the way it was scheduled. The better question is how much more we could learn about our customers inside it.
If you've been counting freed-up time as a win because of all the great tools we have these days, it matters where that time went. I don't think people are focusing on that nearly enough.
What the State of Product Teams Report Says
The source for this is Pragmatic Institute's State of Product Teams report, released in 2025. I'm hoping a new one comes out soon.
A couple of caveats first. Pragmatic sells product management training, and the report recommends its own courses, so set that aside. It also doesn't publish a sample size, fielding dates, or how the survey was run. As always, hold it loosely. I'm using it because it names a pattern worth checking in your own building and your own processes.
Start with the one change it actually measures. In the report, 47% of respondents say they're spending more time on strategic activities than last year, and 24% say they're spending less. The report never defines what counts as strategic. So when I say product teams got time back, I mean 47% of the people who answered the survey.
Then comes the conclusion I built this whole episode on. Pragmatic says much of that reclaimed time is absorbed by coordination and alignment rather than market learning and decision clarity. Market learning means hypothesis testing, which is exactly what we teach in our Product Owner class.
It's worth being clear about what the report means by "product teams." It means the whole product organization: product management and product marketing together, go-to-market, whatever you call it in your company. That's a bigger group than product managers, so I'm not singling them out. I'm talking about the whole go-to-market function.
Where the Hours Sit
I'm a product operations guy myself, and a conclusion is only as strong as what sits under it. So let's look at where the hours rest.
The report doesn't say how its time data was collected. But in the same report, 46% of respondents say they spend more than 20 hours a month managing meetings and internal communication. Does that sound familiar? When I looked at that number, my reaction was, yeah, that seems about right.
Twenty hours a month is roughly an hour a day. So that's nearly half of respondents above a line. It doesn't mean meetings are swallowing the whole week.
And 53% say they spend less than five hours a month on customer interviews: win-loss analysis, interviewing potential buyers, any kind of user research. That isn't all customer contact. Support calls, sales calls, and usability sessions aren't in that number.
Here's the part to read carefully. Both numbers are shares of people above or below a line. Neither one is a share of anyone's time, and neither is compared with last year. So they can't tell you that time moved from customers to meetings. What they give you is a snapshot of where respondents' hours sat in 2025.
That snapshot is still worth looking at, and it's what this whole episode rests on, because who those hours face is the question I'm asking. I'm giving you the data so you can check whether the same pattern shows up in your organization.
Agreement Inside, Evidence Outside
I don't want to make coordination the villain here. The risk is what coordination quietly stands in for. After reading the report, my view is this: when internal consensus stands in for external validation, the room can agree and nobody checks the market. Off we go to start working on something.
I'm not against alignment, either. A product team that can't agree obviously can't ship anything. But agreement tells you the people inside your building believe the same thing you do. It doesn't tell you whether a customer will use what you build, or how they'll respond to it.
Who Actually Sets the Priorities
The report has a related figure on how priorities get set in those meetings. Executive mandate is the most common real-world prioritization factor, named by 20% of respondents. The industry has a name for this: the HiPPO, one of the dangerous animals in the product management safari. Prioritization by HiPPO means the highest paid person's opinion wins, and that's rarely the best way to prioritize.
Market evidence models come in at 15%. That's what we should be doing. Even the most common answer is still a minority answer. But the top answer comes from inside the building, and that's what I want to call out.
Why Speed Makes It Worse
This is where speed gets dangerous. If agreement is standing in for evidence, a faster team doesn't fix anything. It just builds the wrong thing sooner. That has a small upside, since we can find out earlier, but it's still a huge amount of waste. Reducing waste in organizations is the thing I advocate for most.
The Feature Only Executives Validated
Watch what happens when one of those meetings approves a feature.
Go back to Thursday's stakeholder readout. Three executives back a custom reporting dashboard. One of them heard a big customer mention wanting it on a call, so the roadmap marks it as validated. Everybody in the room agrees, partly because of conformity bias. Nobody wants to stand out from the herd. The agreement feels like proof, and once everybody agrees, the product person feels relieved. Let's move on.
The team builds it in six weeks, and it ships on time. The release notes look great. All the boxes are checked. Then, a month after launch, 12 customers have opened it.
Nothing went wrong in delivery. The team built exactly what was asked, on schedule, and everything looks good, especially on the slides we showed everybody.
What failed was the word "validated." It got written down as evidence. Nobody put the hypothesis in front of a customer before the team spent all those weeks building something 12 customers use. And nobody went back to the customer who mentioned it and asked what problem they were actually trying to solve. That conversation would have taken maybe an hour.
Skipping an hour of conversation to save time on a six-week build is ridiculous. Why not go talk to the person who wants the feature? Keep in mind, customers aren't always right. They can be very selfish about what they want, and what they want isn't always best for the product. That's a hard line to face, and it's one more reason to have the conversation instead of guessing.
What the Product Manager's Job Is For
If alignment isn't the job, it's worth being clear about what the job is. Alignment is a small piece of it.
I think a product manager's job is market learning: finding out what customers need, what they'll pay for, and which problem out of the infinite list of problems is actually worth solving. Alignment exists to serve that purpose. It carries what you learned outside to the people inside, so the organization can decide how to use the precious capacity of its teams.
When alignment is the only thing on the calendar, it has nothing to carry. The meetings pass the same opinions around the room, and you get conformity bias, confirmation bias, and the other biases we work through in our Advanced Product Owner workshop.
Think about the week from the beginning. The product manager was in every room. She kept everyone informed, and nobody was ever surprised. That's good, and it's a real skill. It's also only part of the job, and there are other ways to get it done. Being in every room inside the building is not the same as knowing what's true outside it.
So bring one question to your next roadmap review: what did we learn from a customer that changed this item?
If nobody can answer, the item isn't validated. It's just agreed. As product people, we need to step outside that room and push on the problem.
The Discovery Displacement Audit
That's why I don't start with another meeting about a meeting. I start by seeing where one week of product time actually goes, then work to make sure a large share of it is dedicated to market learning in some form. I usually tell product people that most of the answers to their questions are outside the headquarters building. If you're a product manager inside corporate IT, that's probably a different story.
You can't correct a drift you can't see. So the first goal is simply to see where the time goes. That's what the Discovery Displacement Audit is for. It's a one-page worksheet you run on a single week.
Step 1: Pull Last Week's Calendar
Take last week's calendar, or whichever week you want to look at. It can be yours, or the calendar of one product person on the team.
Step 2: Sort Every Block by Who It Faces
Sort every calendar block into one of three columns. Market facing is time with customers, buyers, or market data. Delivery facing is time with the team building the product, and as I said, I'm not villainizing that. It's important work. Internal alignment is time spent getting people inside the building to agree.
Sort by who the time faces. Whether the meeting was any good is a different question. A great alignment meeting still goes in the alignment column.
Step 3: Write Down the Split You Intend
Before you total anything, write down the split your team says it intends. How much of the week should face the market, and how much shouldn't? That answer will be different for every team.
Step 4: Total the Columns and Find the Drift
Total the columns and set them beside the intended split. The gap between the two is your drift, and it shows you where to start fixing the calendar.
Back to our product manager. Say her team intends a third of a 30-hour week to face the market. That's 10 hours. She logged two, which leaves an eight-hour gap. That gap is the drift. It describes which way her week faced. How hard she worked is a separate matter, and this audit doesn't measure it.
One week won't tell you everything, and it's certainly not a trend. But it will tell you whether the priorities your team states show up on the calendar at all, and it lets you be more intentional and deliberate about them.
The full worksheet, with a worked example, goes up here on the blog on Wednesday.
When you sort last week's work, what's the biggest block in your internal alignment column, and who put it on the calendar? I'd love to hear whether your experience matches what I'm seeing.
Consensus Is Not Validation
The next time your roadmap calls something validated, ask who validated it. Consensus is not validation. It's an agreement about a guess we all share, and usually the people with the loudest voices or the most positional power win it.
Product management is a hard job. It's one of the hardest in the organization, and usually the first role to crack in an agile environment. So we scale the role, and once we scale it, we focus so much on coordinating the work that we lose sight of what we're really there to do, which is advocate for the customer.
So get back in there and advocate for your customers. And remember: progress over perfection.
If you want to build the discovery and hypothesis-testing skills that keep "validated" meaning something on your roadmap, take a look at our upcoming Product Owner and Advanced Product Owner classes.