Article
November 12, 2026
6 min read
What I Expect From a Product Manager Now
I expect PMs to help build the first version, work through technical questions with specialists, and use more of their time to learn from customers.

I expect product managers to help build the first version of an idea and spend more time learning from customers. AI gives us more ability to do both. I want that to change how we spend the week, how we work with the team, and what we take responsibility for.
For much of my career, a large part of my direct contribution happened through requirements, conversations, and decisions. We framed a problem, made the case for an investment, and helped people agree on what to build. The idea often passed through several people's interpretations before we could try it.
Coordination could consume the role. A PM could spend the week preparing for meetings, following up on decisions, and translating information between groups, with little time left to explore the product or understand what customers were experiencing. If AI helps with some of that work, I want us to use the time to participate more directly in developing the idea and finding out whether it helps anyone.
Building with the team
That first version might be a working interaction, an exploration of a ranking rule, or a prototype that lets a customer try a proposed flow. The starting point should depend on what we need to understand.
We can bring something we have tried into a conversation with design and engineering, explain what surprised us, and show where the idea still breaks down. The team can engage with the behavior while the choices are open. The PM needs to remain willing to let that work change the proposal, including when someone with deeper expertise sees a problem in an approach we have already spent time building.
In an algorithmic product, I expect the PM to understand enough of the underlying system to investigate a disappointing result. Suppose a recommendation looks promising but fails a requirement the customer has given us. We need to understand whether the relevant information was missing from the data, whether the ranking rule gave it too little weight or treated a firm requirement as a preference, or whether the interface presented a preference as a guarantee. Each explanation leads to a different change. Another version of the screen may leave the problem untouched.
A PM can help make those possibilities concrete and explore them with the people qualified to judge the result. Being able to generate a prototype does not qualify us to assess every part of its implementation. We need enough technical depth to ask useful questions, recognize the limits of our understanding, and work through the answers with specialists.
In my writing about builder teams, I described starting with three to five people around a focused product problem. Their specialties give the group depth, and AI helps them explore across the boundaries of their roles. I want that collaboration to happen while the team is still deciding what the product should do. A designer should be able to try a change in the running experience. An engineer should have enough customer context to challenge the proposed behavior. A PM should be able to investigate an idea without turning every step into a request for someone else's time.
With fewer people, there is less capacity to spread across competing ideas. The PM needs to help choose a problem worth the group's attention and keep the work connected to it as new possibilities appear.
The scope has to fit the people. Three to five is a starting point for focused work, not a staffing formula for every product area. People need shared time, access to the relevant systems, and a way to bring in expertise they do not have. Their existing commitments have to change. Giving a group a new responsibility accomplishes very little if everyone has to fit it around a full schedule.
I also expect the commitment to extend beyond the prototype. Some work will need substantial revision before it can reach customers. The people making the early choices should stay involved in those consequences, with capacity for review and whatever the team learns needs fixing. A brief can establish the problem and constraints, and a decision record can help the next person understand why the team chose an approach. Those artifacts support the work as it develops.
Making time for customers
My biggest concern is that we use all of this new capacity to fill the roadmap faster and leave the PM's relationship with customers largely unchanged.
If AI helps us prepare a status update, analyze feedback, or explore an idea more quickly, I want some of that time to go into direct customer contact. We should have more opportunities to understand a problem before committing to a solution, observe someone trying a prototype, and return after launch to see what actually changed.
Building can absorb every available hour. There is always another variation to try, and the ease of making it can become its own reason to continue. I think the PM has a particular responsibility to interrupt that momentum when we need more evidence.
If we are uncertain about how an interaction should work, another prototype may help. If we are uncertain whether the problem matters, I want us to spend time with the people experiencing it. A customer struggling with a step we thought was simple might give us a reason to explore a different version. We might also discover that the proposed feature adds work to a task they already complete successfully. That should be able to change the plan.
I want to evaluate this way of working by looking at the decisions it improves. Discovering a weak assumption before committing the team can justify an exploration even if we discard the prototype. Customer feedback should be able to change our approach, and after release we need to find out whether the people we intended to help have an easier time accomplishing what they came to do. Pull requests and feature counts cannot answer those questions on their own.
The PM also has to understand the business well enough to decide where the team should invest. A goal might be helping new customers reach a useful result sooner or improving the quality of a recommendation. We should be clear about the behavior we hope to change and how we will evaluate it. Whether the solution needs AI is a decision we make in service of that goal.
I am optimistic about a PM role with more room to build and more time with customers. I want to work through an idea with the team, put it in front of the people it is meant to help, and have enough time left to act on what we learn. That is how I want us to use the capacity AI gives us.
This writing reflects my personal perspectives on product management, AI, and content discovery. It does not represent the official position of my employer or any affiliated organization.
