This week’s backstory is about multiple product managers on the same initiative:

What Prompted This Article?

“Do you two even talk to each other?”

This question came from a sales leader after “Stephen” and I asked about the same customer problem.

How embarrassing!

It doesn’t matter if it was my mistake or Stephen’s mistake. Ultimately, our actions reflected poorly on our organization.

When I work with another product manager, I always feel uncomfortable about having an “operating model talk”. I’ve worked with Stephen for years and I didn’t want to say “let’s coordinate more.”

I wrote this article to help product managers find another way to be effective when working with another product manager.

Instead of having “the talk”, here is what product managers can do:

recognize the situation:

• shared execution ➡️ reduce duplication

• incident coordination ➡️ protect trust and be clear

plan joint work:

• Exploring: agree on the driver for a topic

• Learning: focus offline and come back

• Sharing: single living document

• Decision ownership: by type, not by task

• Communicating: coordinate before external communications

Writing this for the newsletter seemed simple. I wasn’t sure how I would put this into practice with Stephen.

What Happened After This Article?

Read more

You finally got the green light on a critical product initiative. Yet every week slips further behind schedule.

It could be another product manager.

A functional partner.

An executive stakeholder.

A team that’s overwhelmed.

Someone who debates every decision, misses commitments, or simply responds too slowly.

The natural reaction is to improve communication, strengthen the relationship, or create even more alignment.

But those efforts often make execution slower.

The real problem is that your workflow assumes every dependency will execute reliably.

Once that assumption breaks, your own execution breaks with it.

Instead of avoiding dependencies, you can redesign your workflow so collaboration improves execution instead of becoming a prerequisite for it.

That starts with changing the question you’re asking.

Stop asking “How do I work with this person?”

Your usual reaction when you hit an obstacle is to directly fix it. Or work toward consensus. You want to cooperate.

Consensus isn’t the objective of every interaction. Sometimes the objective is learning. Sometimes it’s refining a recommendation. Sometimes it’s making a decision.

There are three workflow principles for execution:

1. Separate information from decisions

2. Reduce unnecessary synchronization

3. Make execution visible

The result: execution continues despite unreliable dependencies.

With the traditional workflow: One dependency fails. Everything stops.

With execution workflow: the work isn’t organized by people. It’s organized by purpose.

The good news is you don’t have to wait for every dependency to improve before you can improve execution.

Share

Reduce dependency instead of reducing collaboration

Collaboration remains essential. The workflow determines when and how collaboration happens.

But collaboration doesn’t require every conversation to happen with every stakeholder present.

Effective workflows separate learning, debate, and decision-making into different moments.

A step product managers can take is removing unnecessary synchronization.

Examples of synchronized collaboration:

• One product manager gathers information and shares it.

• Debate happens before stakeholder meetings.

• Stakeholders validate recommendations rather than watching them be invented.

A way to keep your initiative moving is to sequence the work into multiple steps. Building blocks of success.

Once you reduce unnecessary synchronization, the next step is organizing work for execution.

Subscribe now

Separate work by purpose

The breakthrough is categorizing your work for success. Think of product work in three buckets:

Bucket 1: Information gathering

Learning.

Collecting constraints.

Building understanding.

Bucket 2: Internal product work

Debate.

Explore alternatives.

Refine recommendations.

Bucket 3: Decision & Execution

Present recommendations.

Make decisions.

Assign actions.

The mistake is allowing all three to happen in every meeting.

Each bucket has a different objective, different participants, and a different definition of success. Separating them keeps work moving. This is how sequencing helps.

Multi-step product workflows need single-purpose meetings to get results. Inviting everyone to every conversation often mixes learning and decision-making into a single meeting.

Product managers who protect the workflow from distractions often get to outcomes faster.

Share

Protect the flow of execution

Every product initiative has bottlenecks. Product managers get tough problems to solve. If there is widespread agreement, then there is no need for a product manager to drive a new outcome.

So by definition, you are going to encounter obstacles and dependencies. And product managers want to improve bottlenecks.

An alternative is to redesign the workflow for results. You still need to handle the buckets of information gathering, internal product work and execution.

Organizing work by purpose naturally changes how execution becomes visible.

Make execution visible

Leaders and stakeholders evaluate your visible progress.

The teams working with you want productive conversations with you. Each encounter with product needs to make progress. Cross-functional partners value conversations that have a clear purpose and lead to progress.

Making execution visible is the key to controlling your workflow. Each bucket of product work uses execution to stay on track:

• Gathering information controls the participants to real interest. Limit to participants who have information relevant to the meeting objective. Learning is for finding solutions.

• Internal product work is a forum for debate. But execution requires cutting off side issues and circular discussions. Execution gives collaboration focus.

• Decision and execution make progress visible. Execution keeps discussions anchored to the decision that needs to be made. New ideas can be captured without changing the meeting’s objective.

Visibility becomes part of the workflow.

Subscribe now

Closing - Workflow execution for success

Product managers spend years learning how to prioritize work and influence stakeholders. As product initiatives become more complex, another skill becomes just as important: designing workflows that keep execution moving across teams.

Every product manager eventually encounters an unreliable dependency. The product managers who continue delivering are the ones who intentionally shape how information is gathered, decisions are made, and execution becomes visible.

A resilient workflow helps every conversation contribute to progress, every meeting serve a purpose, and every dependency move the initiative closer to delivery.

When execution becomes the priority, workflow design becomes part of the product manager’s craft.

Q&A

Isn’t it wasteful doing all these work arounds?

The harm from exposing product internal debate can delay product work. You might not achieve your outcome and possibly hurt your credibility by combining too much in a single meeting. It’s about avoiding unnecessary delays.

Won’t I get in trouble for excluding key team members?

No. Gathering necessary information and reporting back is an efficient way to advance your product work. Share what you learned, explain why participants were chosen for that conversation, and involve people when their expertise is needed. Sequencing participation is different from excluding people.

What if my manager expects everyone to be included?

The workflow still includes everyone.

It simply sequences participation around the purpose of the work.

Information gathering, internal product discussion, and execution happen at different times.

What if the unreliable dependency owns part of the work?

Design the workflow so ownership remains clear while dependencies become smaller, more specific, and easier to complete.

How do I know if I’ve become too dependent on one person?

If one missed meeting...

or one unanswered message...

or one debate...

stops your initiative...

your workflow probably needs redesigning.

Looking for more practical tips to develop your product management skills?

• Product Manager Resources from Product Management IRL

• Product Management FAQ Answers to frequently asked product management questions

• Premium Product Manager Resources (paid only) This month’s guide is about AI-assisted product initiatives. It helps you build context that your whole product team can use.

Upgrade

drpp The Drip featured Product Management IRL articles. This newsletter has handpicked product management articles every day, summarized to give you the big picture of product management and tech.

TLDR Product featured Product Management IRL articles recently! This biweekly email provides a consolidated list of recent product management articles.

Connect with Amy on LinkedIn, Threads, Instagram, and Bluesky for product management insights daily.

This week’s backstory is using AI to generate marketing material:

What Prompted This Article?

Marketing needed a product abstract and updated external FAQs urgently for an upcoming trade show. This request came on top of end-of-quarter sales support questions and work on a new product concept.

Could AI help with the product abstract and FAQ?

I gathered my sales overview, my internal FAQ and an example product abstract. I asked AI to generate the product abstract. The AI-generated abstract required some minor adjustments to complete it.

Amazing.

Next, see what AI writes for the FAQ questions. The answers were pretty accurate. Just needed a few tweaks to finalize.

Both of these jobs would have taken 2-3 hours without AI. This time I was done in 30 minutes.

I was energized by the time savings when I wrote the article. Here is the process I used:

It was too early to know if my shortcut with context and AI helped marketing.

What Happened After This Article?

Read more

“There is no story here.” This is the response to your latest product initiative.

The initiative seems straightforward: customers are asking for something better, the opportunity is growing, and the leadership team wants to deliver it.

Advice from a coworker: “Do a roadshow. That worked last time.”

The program manager wants to schedule a series of workshops to align the team.

You know what comes next: everyone will start from scratch. Your context from researching the opportunity and convincing leaders covers more about the reasons for the initiative than you’ve ever had before.

Each team wants enough context to contribute their part.

This article covers an alternative way to enable each team to deliver their part.

Collaboration Isn’t the Work

Most teams know how to collaborate. More collaborating doesn’t lead to understanding.

Teams are raising real issues in understanding what the initiative means for them:

• Marketing needs the narrative to fit what has already been communicated

• Pricing is looking for commercial understanding

• Program managers are seeking dependencies and plans

• Architects want to discern the design changes

The same understanding gets rebuilt over and over.

The issue isn’t collaboration. The issue is that every function starts with too little context.

Share

Product Context Changes What You Share

You created product context as you learned the opportunity and potential solutions. You don’t need more understanding.

The rest of the team needs enough understanding to contribute.

In the past, you took your summary slides to each team and collaborated until you could agree on a plan. Often, a program manager organized a workshop to get the product team aligned. This got each team the context they needed.

Instead of sharing one summary deck, you start sharing starting points. Just enough context for each function to begin.

Each function needs:

• Story

• Decisions

• Questions

• Risks

• Dependencies

These become shared context assets.

Subscribe now

Workspaces Emerge Naturally

Each cross-functional team has their own context and AI tools. They don’t need the entire picture to contribute effectively.

Each function puts the pieces together differently. Decisions, questions and risks have a unique impact on the teams.

Each function’s context evolves as you head toward an agreed plan.

More collaboration isn’t usually the missing ingredient. Delivery is waiting on agreements.

As functions learn, they naturally develop their own working context.

Each team develops a workspace that evolves at different rates. The functions evolve their workspaces together.

You and the product team reach delivery agreements and the workspaces and product context match. The delivery agreements can be tracked as usual with the product development process.

The product manager’s job increasingly becomes helping the workspaces evolve together.

Share

Product Managers Enable Context

Product manager job before context:

Maintain requirements.

Product manager job with context:

Help workspaces evolve together.

Less time:

• Repeating decisions

• Updating slides

• Running alignment meetings

More time:

• Helping functions succeed

• Surfacing risks

• Making decisions

• Creating agreements

Closing

Product context helps you understand the initiative.

Delivery depends on helping others contribute.

Every team starts faster when they begin with context designed for the work they’re trying to do.

Product managers spend less time creating understanding and more time helping functions succeed.

The interesting question is how to help every function stop starting from scratch.

Curious about the mechanics?

This article focused on the idea.

I’ve put together From Context to Delivery to show the practice (paid subscribers). This is a practical guide for AI-assisted product initiatives:

• Shared context assets

• Portable workspaces

• Learning loops and enablement loops

• Versioning and delivery agreements

• Templates and examples using today’s tools

Context to Delivery (paid)

Last article on creating context:

• The 5 Workflows that Build Product Context

Looking for more practical tips to develop your product management skills?

• Product Manager Resources from Product Management IRL

• Product Management FAQ Answers to frequently asked product management questions

• Premium Product Manager Resources (paid only) Templates that I use to explain ambiguous product situations like business opportunities, customer journey and operating principles. New items monthly!

Upgrade

drpp The Drip featured Product Management IRL articles. This newsletter has handpicked product management articles every day, summarized to give you the big picture of product management and tech.

TLDR Product featured Product Management IRL articles recently! This biweekly email provides a consolidated list of recent product management articles.

Connect with Amy on LinkedIn, Threads, Instagram, and Bluesky for product management insights daily.

This week’s backstory is about getting cross-functional teams involved in your initiatives:

What Prompted This Article?

I ended a frustrating week in product management. It felt like each thing I did resulted in a huge debate.

• A partner changed the terms of service - two product managers claimed that I didn’t understand the change and they weren’t going to help resolve it

• A product manager assigned to help me - he questioned actions from a year ago and deep dived into old decisions

• Major feature releases not ready - product managers debating about support of OpenSource after shipping

These are familiar situations for product managers. But it felt like everything was stuck in debate.

I did some research. Did I just have a bad week, or did other product managers feel decisions were being made over and over again?

My research turned up:

• product managers stretched by AI-driven speed

• the product management playbook is changing

• AI isn’t simplifying work

• overcoming “AI brain fry”

Now I have signs that I’m not the only product manager doing AI speed without accomplishment.

After thinking about this problem, I decided the endless debates were caused by a lack of “gravity” to pull the initiative forward.

I realized that I need to build momentum by pulling people into the work.

I wasn’t sure if I could step out of the debates to take these steps…

What Happened After This Article?

Read more

You’ve been working on requirements for a new opportunity for weeks. You keep hearing about product managers generating requirements in a day with AI assistance.

The untold story of requirements in a day is the product thinking leading up to the requirements. Fast requirements are usually the visible result of weeks of context-building work.

In this article, product context means the shared understanding of:

• the opportunity

• the evidence

• the solution options

• the decisions

• the requirements

Product teams build context that leads to effective requirements.

That same context often feeds launch plans, stakeholder updates, evaluation tracking, and go-to-market activities, but those are outside the scope of this discussion.

Share

The Workflows Behind Requirements

Traditional requirements follow three phases:

Opportunity ➡️ Write requirements ➡️ Build

These living requirements would evolve as the product team worked through architecture and design decisions.

Product building picked up as the requirements got firmer. Some requirements were deferred as feasibility was understood.

The requirements writing was actually compressing several overlapping activities into one shared context.

AI Changes How Product Context is Created

AI can handle part of the requirements, while other parts still need collaboration. AI can quickly generate stories, acceptance criteria, specifications, and in some environments, code.

The tangible outcomes of requirements work can be done quickly by AI. But there are product thinking jobs in the workflow.

These product thinking items go beyond discovery activities. Important context also comes from decision-making and delivery planning.

Like many other workflows, the requirements workflow can be broken down to get the value of AI and the human product team.

This article is about creating context as teams work through opportunity discovery to requirements. The context is created from the workflows and updated through iterations.

Share

Product Context is Created Through Five Workflows

Product teams learn five different kinds of information as they move from opportunity to delivery:

• Is the opportunity worth pursuing?

• Is the opportunity real?

• What solutions could work?

• Which solution should be chosen?

• How should it be delivered?

These workflows run continuously and often in parallel. The distinction is not timing. The distinction is the type of learning being added to the product context.

Workflow 1: Opportunity

An outcome that is worth pursuing.

• Why to spend resources on the potential opportunity at this time.

• Explanation of the outcome and how it handles the opportunity.

• Understand who is affected by the outcome.

AI helps:

Building context for the next stages on the specific opportunity and why.

Creates context about:

• Continuously refined opportunity definition

• Who is being served by the outcome

• Vision of the outcome

Workflow 2: Evidence and Validation

The evidence that it is worth pursuing.

• Customer evidence

• Market signals

• Business impact

AI helps:

Adding organization and analysis to the context

Creates context about:

• Running list of the evidence showing the need for the outcome

• Market assessment aligned to the timeline

• Potential business opportunity

Workflow 3: Solution exploration

Proposing and refining solutions to the problem.

• Gaps to close

• Tradeoffs

• Risks

• Constraints

AI helps:

Pattern matching on similar solutions is added after validation. Agreed solutions are continually updated in the context.

Creates context about:

• Architecture and other agreements of the solution to be built

• Innovations that are needed for the requirements

• Strategies to support constraints in resources, quality and timeline

Workflow 4: Decision Formation

Selecting among viable alternatives and documenting the tradeoffs.

• The options that are the basis of the solution

• Reasons for discarded alternatives

• What is acceptable when the solution is done

AI helps:

Checking logic and dependencies across the solution. Continuous updates to the context as options and acceptance are defined.

Creates context about:

• Chosen and rejected paths

• Reasons for the chosen approach

• Success criteria

Workflow 5: Requirements and Specifications

How to build it and address the opportunity.

• Who is doing each requirement

• Dependencies

• Triggers for adjustments

AI helps:

Requirements, evals and acceptance criteria based on the context

Creates context about:

• Implementation expectations

• Dependencies

• Acceptance criteria

• Delivery risks

Subscribe now

Context is the Shared Understanding from the Five Workflows

When you break apart the requirements workflow this way, product teams build context while AI helps organize, analyze, and apply it. By centering the product thinking in context that AI and the product team use, you get more than requirements in the end.

The benefits of product context developed with requirements are:

• Stakeholders can participate from the early concept through requirements and delivery

• AI has accurate and curated context to generate requirements and more

• You develop context for GTM and sales material as you go

Context is what unifies the efforts:

• Opportunity narrows

• Through validation and

• Solution tradeoffs

• Supporting decisions for

• Requirements

AI can help organize, analyze, and apply context while the product team continuously refines it

Share

Conclusion - Product Thinking Leads the Way

Product teams don’t build successful products from requirements alone.

They build shared understanding through opportunity, validation, solution exploration, decision formation, and requirements development.

Together, these workflows create the shared understanding that makes effective requirements possible.

Requirements become easier when the context already exists.

Q&A

Isn’t this what we do in product discovery?

Discovery contributes to product context, but it is only one workflow.

Product context also grows through solution exploration, decision-making, and requirements development. The framework describes the full path from opportunity to delivery rather than discovery alone.

Aren’t the 5 workflows the sections in a PRD?

Sometimes.

In some organizations, the five workflows are captured in a single document. In others, they are distributed across discovery notes, design artifacts, evaluation plans, decision records, and specifications.

The artifact matters less than the workflow. Product context is created regardless of where the information is stored.

Does every project need all five workflows?

Yes, but not every project needs to create the same amount of context.

For a new initiative, the product team may spend significant time refining opportunities, gathering evidence, exploring solutions, and making decisions.

For an enhancement, much of that context already exists. The team can reuse prior understanding of customers, decisions, architecture, and constraints rather than starting from scratch.

The workflows remain the same. The amount of new context being created changes.

Earlier articles on context that product managers maintain:

• Re-usable external product context

• External product context is needed to purchase your product

• How to create product context for teams that use your product

• Product explainability is how AI uses your product context

Looking for more practical tips to develop your product management skills?

• Product Manager Resources from Product Management IRL

• Product Management FAQ Answers to frequently asked product management questions

• Premium Product Manager Resources (paid only) Templates that I use to explain ambiguous product situations like business opportunities, customer journey and operating principles. New items monthly!

Upgrade

drpp The Drip featured Product Management IRL articles. This newsletter has handpicked product management articles every day, summarized to give you the big picture of product management and tech.

TLDR Product featured Product Management IRL articles recently! This biweekly email provides a consolidated list of recent product management articles.

Connect with Amy on LinkedIn, Threads, Instagram, and Bluesky for product management insights daily.

This week’s backstory is about keeping leaders involved while working on a product initiative:

What Prompted This Article?

This started with constructive feedback: “You need to present in office hours more often”. This means I need to present complex, in-progress product initiatives to my boss’s boss.

Doing this kind of thing is different this year:

• AI-assisted product management means I’m handling bigger initiatives

• Increased delivery pressure means fewer chances to collaborate with others

• A flatter organization means office hours are key to advancing product initiatives

My challenge is preparing for the update without having details because the initiative isn’t finished.

One of the partners I handle changed their terms of service. As a result, senior leaders asked for a risk assessment of every new customer sale with this partner.

I needed to present a point of view in office hours on the situation. I had to present quickly so senior leaders could decide about long-term handling.

My calendar was filling up with many teams wanting to understand the partner situation. There was a lot of noise that the senior leaders didn’t need from the point of view.

I separated the work into

a) leadership communication

b) team exploration

I presented in office hours a few days after posting the article. I learned a lot from the experience of presenting an unfolding situation to leaders.

What Happened After This Article?

Read more

A year ago, collaboration in product teams felt productive. It was common to explore adjacent ideas, loop in other functions early, and treat unfinished thinking as part of the process.

Recently, many product managers have started noticing a shift: conversations feel sharper, feedback arrives faster and more directly, and there is less patience for work that doesn’t sit on the critical path.

As organizations adapt to AI-assisted work, tighter budgets, flatter teams, and higher expectations, many product managers are noticing something else changing: the tone of collaboration.

In the past, high productivity and forward-looking collaboration were a compliment.

Today, many product managers find that the same behaviors are being interpreted differently.

Product managers often sit at the center of the resulting pressure. The question for product managers is how to stay effective while workflows settle out.

The signal: collaboration is getting sharper

At first, product managers noticed decisions getting reopened. And now the tone inside products is becoming sharper:

• Feedback becomes more absolute (”you always…”, “why are you doing X at all?”)

• Public correction increases

• Narrowing of allowed work (”only focus on X”)

• Exploration is questioned more quickly

These changes often appear when pressure increases faster than teams have a way to deliver. Demands for tangible outcomes are fierce. After organizations have flattened and cut costs, there is nothing left except to show results.

While the pressure to deliver is everywhere, product managers can still be effective and avoid reacting negatively.

Share

Being effective during the transition

The pressure on product managers is real. Business growth and outcomes matter.

Product managers are producing more than ever before. More deep work time.

But stakeholders still expect collaboration. At the same time, stakeholders want faster outcomes. The market is moving fast. Competitors are changing fast.

The old operating model isn’t ready for the rapid delivery model.

These competing models converge on product managers. This is how it shows up:

• Requests to narrow focus as a default control mechanism

• Pressure is a proxy for alignment

• Feedback becomes more direct because leaders are balancing coaching with increasing operational demands.

When the product operating system is unclear, the communication tone becomes a substitute for clarity.

This pushes product managers to deliver outcomes through ambiguity. And forward-looking collaboration, which helped product managers reduce ambiguity in the past, can’t fit into high-focus delivery.

The challenge for product managers is staying effective without becoming reactive.

Product managers can control how they interpret pressure and how they respond to it. The following adjustments can help product managers remain effective while the operating model catches up.

Subscribe now

How to thrive in the middle of it

The middle of a long journey is often hard. Like the transition to the new product operating model, it is a journey that product managers are living through. Fortunately, product managers have navigated operating model changes before.

A. Stop treating tone as signal, start pulling signal out of the content

Product managers get feedback. Here’s how to handle a change in the tone of the feedback.

Signal

Feedback feels sharper and more absolute than before. Comments that used to be curious now feel critical.

Why this breaks

Product managers react to the tone by defending themselves or overexplaining. You miss the gist of the feedback by going into defensive mode.

The shift

Tone is no longer a reliable indicator of meaning. Content is.

This doesn’t excuse poor communication. It simply recognizes that reacting to tone alone can cause you to miss useful information.

What to do instead

• Translate critiques into a concrete expectation (what outcome is being requested?)

• Separate emotional packaging from actionable input

• Ask questions that get to specifics:

  • What would ‘fast enough’ look like in observable terms?

  • What outcome is most at risk right now?

• Respond to the underlying constraint, not the phrasing

Example

• You are going too slow

  • What is needed sooner than you expect? What tradeoffs should I make?

B. Shift from “activity visibility” to “leverage visibility”

The change is making impact relative to outcome.

Signal

People interrupt explanations of activity.

Why this breaks

Activity used to imply progress.

Now, leaders want proof that activity changed an outcome.

The shift

Show the consequence of the work.

What to do instead

• Reframe “I talked to sales about the forecast” into “The sales forecast would improve with a playbook.”

• Head off risk by collaborating and then taking action

• Prepare for 1-on-1s with focus on near-term outcomes

Example

• I spoke with Sales

  • The Sales conversations uncovered a pricing risk that could delay launch.

C. Narrow collaboration intentionally (don’t abandon it)

Reduce “ambient collaboration” in favor of decision-making collaboration.

Signal

People don’t come to open-ended meetings. No time to discuss potential approaches to a problem.

Why this breaks

When there is pressure to deliver, then general collaboration delays results.

The shift

Be explicit about why you are engaging people. The goal isn’t less collaboration. It’s more intentional collaboration.

What to do instead

• Quickly recap the near-term reason for collaboration

• Focus on the “better together” outcome

• Follow up on the result from the collaboration

• Have a specific agenda for every meeting (even 1-on-1s and “quick calls”)

• Redirect IMs to a reason for engaging

Example

• Asking engineering for status of the next release

  • Collaborate on the ideal demo for stakeholders (you’ll get the status while working on results)

D. Don’t mirror harshness forward

Convert sharp communications into meaningful information. You can’t lead by simply passing on negative messages.

Product managers often become the transmission layer between stressed stakeholders and delivery teams.

Signal

Your stakeholders are concerned that the product team doesn’t understand the urgency of delivery.

Why this breaks

Passing on stakeholders’ requests to speed up makes the team feel underrepresented to the stakeholders. You are perceived as “not adding value”.

The shift

Dig into the reasons for the harshness. Communicate the question behind the question. Add value.

What to do instead

• Translate “This needs to be done soon” into “This needs to be ready for a customer demo next week.”

• Get clarity on the harsh message, then convert it to a next step in a neutral tone

• Tone spreads faster than strategy. Stay calm so your message doesn’t get lost in the tone.

Example

• Sales doesn’t like this feature

  • Several customers want a different interface and sales need to know how to handle this objection.

E. Maintain a private operating scorecard

In fast-paced environments, gratitude disappears. Measure your progress anyway.

Signal

Your contribution on a result isn’t mentioned. No one says thank you when you send notes from a customer meeting.

Why this breaks

Teams are looking for results before risks and problems. Without collaboration, teams can’t see individual contributions.

The shift

Look for progress on your goals over time. Note your contribution and learning.

What to do instead

• Learning new things from tools to process prepares you for the future

• Clearing up a misunderstanding that gets faster results

• Reaching a decision or strategy to deal with uncertainty

• Fixing near term risks

Example

• You realize you could have mocked up a dashboard instead of doing it in slides

  • You learned that you need half the options after reviewing the slides with the architect

F. Re-anchor in responsibility signals, not emotional signals

Keep a watch on the product structure and responsibilities. Responsibility carries more weight than criticism.

Growing responsibility and growing criticism can coexist.

Signal

You and your team’s responsibility is growing despite feeling that you need to do more.

Why this breaks

Focusing on feedback before delivering on commitment hurts dependencies. If teams can’t depend on your delivery, then they avoid you.

The shift

Focus on what it takes for more responsibility. Use feedback for quality improvement and not for delay.

What to do instead

• Responsibility increase means trust is increasing (even if the communication is rough)

• Investigate if you are bypassed on decisions; this could be a signal to change

• Evaluate structural changes for responsibility changes

Example

• Your boss announces that new team members are joining the team

  • Align your work to the broader responsibility of the team

Share

A note on performance

Not every sharp comment is transformation pressure.

Sometimes feedback is simply feedback. Product managers still need to understand criticism (don’t dismiss it).

The goal is to separate:

• tone from content

• organizational stress from capability gaps

• urgency from direction

Separating tone from content does not mean accepting disrespectful behavior. It means avoiding the mistake of dismissing potentially useful feedback because it arrived imperfectly.

Share

Conclusion

Many product managers are seeing contradictions in their work.

Responsibilities continue to grow.

Expectations continue to rise.

Yet collaboration often feels harder than it did only a few years ago.

It’s tempting to interpret every sharp comment as a judgment on your performance. Sometimes it is. Often it isn’t.

Organizations in transition frequently increase pressure before they develop clarity. Communication becomes sharper before operating models stabilize.

The product managers who thrive in this middle ground become more intentional.

They learn to:

• extract signal from feedback

• connect work to outcomes

• collaborate with purpose

• filter pressure instead of forwarding it

• measure progress even when gratitude is scarce

• pay attention to responsibility, not just emotion

Eventually the operating model catches up.

The middle doesn’t last forever.

But while you’re in it, these behaviors help ensure that you develop the capabilities that will matter on the other side.

Related articles:

• Builder PM strategies

• Handling product operating model changes

• IC product manager acceleration

Looking for more practical tips to develop your product management skills?

• Product Manager Resources from Product Management IRL

• Product Management FAQ Answers to frequently asked product management questions

• Premium Product Manager Resources (paid only) Templates that I use to explain ambiguous product situations like business opportunities, customer journey and operating principles. New items monthly!

Upgrade

TLDR Product featured Product Management IRL articles recently! This biweekly email provides a consolidated list of recent product management articles.

drpp The Drip featured Product Management IRL articles. This newsletter has handpicked product management articles every day, summarized to give you the big picture of product management and tech.

Connect with Amy on LinkedIn, Threads, Instagram, and Bluesky for product management insights daily.

This week’s backstory is about solution packages:

What Prompted This Article?

I was seeing two different ways to package a group of products:

1. General product documentation with architectures, picture stacks and sometimes whitepapers on the products working together

2. Configuration tools that group multiple products for ordering and managing through a consolidated dashboard

A product manager on my team, Vivek, was packaging the first way. Vivek was becoming the bottleneck to sales because each potential customer had something unique.

I wrote this article to explore if Vivek could take a small step to the second way. Here is the small step I had in mind:

Next, I imagined how Vivek could move from left to right and create a solution package. The desired outcome is less dependency on Vivek for each potential customer.

I defined a light process to watch for customer patterns, define a grouping and maintain the solution package.

I planned to give the lifecycle a try before talking to Vivek about using it.

What Happened After This Article?

Read more

Organizations want faster execution, more adaptability, and stronger product leadership. At the same time, organizations want more certainty and struggle to absorb faster ways of working.

Six months ago, product people were trying builder PM strategies, developing product context and growing product business with AI-accelerated product work.

The surprise was how unevenly teams absorb these changes in product management.

The expectation was that the new product work would be rapidly absorbed by leaders and stakeholders.

Comments from product managers highlight the disconnect:

“They just reopen requirements instead of deciding.”

“No one reads the decision log.”

“Do I discuss this live or put it in a dashboard?”

“Can you share templates that worked?”

Stakeholders are gradually absorbing a different way of operating with the product management changes.

Share

The trends were real but unevenly absorbed

A quick recap of the trends from six months ago includes AI acceleration, faster execution and higher product management expectations.

The changes are visible in day-to-day product work. Teams are experimenting faster, product context is improving discoverability, and product managers are increasingly influencing customer and business outcomes.

Subscribe now

What changed in product work

Six months ago, product managers felt that building and experimenting with their business sense would be widely adopted.

And now:

• Product managers don’t feel ahead on these changes

• Teams are still learning how to operate with less upfront certainty

• Everyone feels held back from product development changes

The changes are still uncomfortable for many teams.

Teams are learning new operating habits in real time

Teams are seeing real changes that speed delivery to customers. At the same time, there is a lot of change to assimilate. Signs that these ways of working are hard to soak up:

• decisions reopening

• endless alignment

• documentation uncertainty

• communication overload

• pressure for speed without reduced process friction

Organizations are moving, but change comes at the pace of learning.

Share

What progress looks like

Slowly, product managers are making progress despite these setbacks. Examples of progress:

• Product context enables customers to find you quickly

• You can show a product change to stakeholders

• You have more options to fix issues early

• More ways for customers to give feedback

• Sales efficiencies from AI assistance

The changes in product management are visible. And not yet absorbed.

The progress is encouraging. Everyone wants it faster.

Why the speed feels uncomfortable

Product managers are moving faster and, at the same time getting mixed feedback:

• AI creates visible productivity gains

• organizations absorb change socially

• trust systems change slower than tooling

• operational habits lag capability shifts

These changes take time to absorb.

Subscribe now

Persistent learning may be the real trend

Product people are being persistent in their learning. The setbacks are part of the learning.

The gains from the trends are visible, but teams are still learning how to absorb faster product work, AI-assisted workflows, and more adaptive ways of operating.

That learning is messy.

Decisions reopen. Alignment slows momentum. New workflows create uncertainty before they create confidence.

But still we make progress.

Many product managers are already doing the difficult work of helping stakeholders adapt one iteration at a time: showing product changes earlier, improving customer context, experimenting faster, and helping teams learn through real outcomes instead of perfect certainty.

Maybe that is what this phase of product management actually looks like.

Persistent learning.

Related articles:

• Product Explainability for AI and People

• How Product Managers Improve AI’s Perception of Their Products

• Builder PMs at Scale

Looking for more practical tips to develop your product management skills?

• Product Manager Resources from Product Management IRL

• Product Management FAQ Answers to frequently asked product management questions

• Premium Product Manager Resources (paid only) 4 learning paths, 6 product management templates and 7 quick starts. New items monthly!

Upgrade

TLDR Product featured Product Management IRL articles recently! This biweekly email provides a consolidated list of recent product management articles.

drpp The Drip featured Product Management IRL articles. This newsletter has handpicked product management articles every day, summarized to give you the big picture of product management and tech.

Connect with Amy on LinkedIn, Threads, Instagram, and Bluesky for product management insights daily.

New paid subscriber templates for learning-stage products. I’m sharing the templates I use when working through learning-stage products with leadership teams:

• Learning log template

• Phase-based orchestration tracker

• Opportunity presentation templates

• Customer journey and operational principles templates

• GTM templates

Learning-stage templates (paid)

This week’s backstory is about working with engineering:

What Prompted This Article?

The relationship between a product manager and engineering is a crucial one. Both are heavily invested in the product's success.

I was delighted when asked about a collaboration. I was curious about what engineers think about builder PMs.

Alex volunteered to write about his real-world experiences with product managers. I was looking forward to seeing what an engineering leader valued from product managers.

He wrote about 5 collaboration habits that lead to better products.

What blew my mind on Alex’s advice: it can apply to any stakeholder. Replace “Engineering” with “Sales” or “Marketing,” and the advice holds up.

And Alex’s shared engagement model works with waterfall, agile or builder PM modes of product development.

My own tries at these techniques are spotty. I wasn’t sure if engineering or other stakeholders wanted this type of engagement.

Alex sees value in product manager engagement like this.

What Happened After This Article?

Read more

Not long ago, the product manager's job was figuring out answers before execution started.

You explained the business model.

You defined a winning scope of work for the opportunity.

You validated the assumptions.

You took care of the hard questions upfront.

Then the product team executed.

A lot of teams still expect product work to behave that way.

But AI initiatives, subscription products and platform transitions don’t work like that anymore.

Because now, some of the most important answers only show up after customers, operations, partners and delivery systems start interacting in the real world.

Which means your job changes from:

“Figure it all out before we begin”

To

“Figure it out enough to begin and help the organization learn the rest safely.”

Then you get to experience “enough” and “safely” on your product. It goes like this:

You bring a proposal.

Leadership asks for more detail.

You refine it.

The questions shift.

You answer those too.

Then new concerns appear:

• Scaling

• Margins

• Customer expansion behavior

• Operational trust

• Automation dependencies

• Partner execution

The harder you work on “enough” and “safely”, the more gaps show up.

And then the feedback starts feeling a little personal:

• “I still don’t think we fully understand this.”

• “This needs more detail.”

• “I’m not confident we’ve thought this through.”

At first, you think this means you aren’t working hard enough to explain.

Often, something else is happening:

The organization is looking for impossible certainty from product managers.

This article gives you a way to keep moving without turning every unresolved uncertainty into your problem.

The work changed underneath you

Product management work has changed rapidly from AI and recurring revenue business models:

• the product depends on operations

• customer usage changes the offer

• scaling reveals new constraints

• partner ecosystems create unpredictable interactions

You can no longer predict the business before customers interact with the system.

This is a learning-stage product. A learning-stage product is a product where key parts of the business model can only be learned through real customer and operational usage.

This new type of learning-stage product blindsides your leaders. Almost every leader is under pressure to grow the business. They want certainty and not unplanned risks.

Now you show up with an opportunity for a learning-stage product. Your leaders want certainty that will only come from execution.

This is where many product managers start feeling stuck.

Take Vivek, a product manager adding third-party networking capabilities to an AI product.

He already has two successful customer deployments. He’s validated the technical path and identified broader market demand.

But once the proposal reaches leadership, the questions begin shifting:

• How sales changes to offer networking

• Handling partners, pull-through revenue, scaling and ongoing support

• He answers the questions and then more clarity is needed

Circular feedback is a learning signal

Your opportunity is clear-cut. But the stakes are high for your leaders. They need certainty.

The circular feedback starts with a minor issue that needs more detail.

Then the business opportunity is missing pull-through from related products.

Then scaling needs investment.

Then the feedback goes back to clarity on details.

The questions keep moving because the organization is absorbing the business model in layers.

Share

The product manager role shift

Your role moved from having the answers to bringing the team along to get answers together. There are too many unknowns for you to have all the answers.

Product managers naturally adapt as they learn. The challenge is helping the organization adapt at the same pace

Your role shifts because you are developing a learning-stage product. Your job becomes teaching the organization about the unknowns.

Instead of managing dependencies, you are managing learning.

Learning-stage products are governed differently — not less rigorously.

Additionally, many learning-stage products have dynamic pricing and time-bound prices. The organization needs to learn a new business model. Revenue growth and margins are still important. But a learning-stage business model has more risks to track:

• Customer retention: depends on customer satisfaction

• Expansions: depends on ease of use

• Upsells: depends on ease of ordering

Product managers handle this change with organization learning strategies.

Subscribe now

How to lead through the new expectations

Product managers learn enough to handle their products. The extra strategy is to bring the organization into the learning.

Learning orchestration: Track the learning

Product managers naturally learn as they go. Prioritizing based on phasing and cost risk. On learning-stage products, product managers expose the learning to the organization.

An example of learning tracking is your answers to opportunity questions. Answers about why a customer would buy can be forgotten when operational questions arise.

Keeping a learning log can remind everyone of the progress to date and future risk handling.

Learning orchestration: phase framing

Learning-stage products have a different phasing than mature products. You can remind stakeholders of the learning phase.

Without phases, organizations try to solve scaling, retention, automation, and operations simultaneously and the initiative starts feeling impossibly incomplete.

The typical phases are:

• Validation: the opportunity and baseline business model

• Operational standardization: a repeatable system to go after the opportunity

• Expansion handling: estimating the lifetime value of the customers

• Scaling: getting to the full potential of the opportunity

These phases are used to prioritize the learning. The organization needs to learn the basic model before standardizing on the operational handling. Likewise no need to work on scaling before expansion is understood.

Learning orchestration: showing progress

When working on a learning-stage product, it is ideal to establish the phases and track the learning. In the excitement of getting started, you might jump into the product work.

Then the circular feedback reminds you that your learning is getting ahead of the organization.

Sometimes it is more helpful to show the learning log and phases together. Stakeholders who are used to mature products will be puzzled by your learning talk.

Whether you get caught up in circular feedback or want to set early expectations, the way you work with stakeholders has a format built on transformation learning.

The format to help the organization learn with you:

You are not trying to prove the business completely upfront anymore.

You are helping the organization learn the business safely through visible iteration.

Paid Subscriber Resource: Learning-Stage Product Templates

A big part of reducing circular feedback is making learning visible.

To help operationalize this, I’m sharing the templates I use when working through learning-stage products with leadership teams:

• Learning log template

• Phase-based orchestration tracker

• Opportunity presentation templates

• Customer journey and operational principles templates

• GTM templates

Learning-stage product templates (paid)

Once Vivek realizes the organization is learning the business model in layers, his role changes too.

Create a learning log

Vivek notices this doesn’t stop the circular feedback. It helps him reuse his offer definition and opportunity summary.

Plan the learning for the organization

He uses this to sequence his work. When he gets an early question, such as scaling during the validation phase, he adds it to the assumption log to review the question for later.

The circular feedback slows down but Vivek wants business growth. And that depends on sales enablement.

Potential phasing

Vivek handles circular feedback with his learning log and phasing. Vivek is ready with small, low risk GTM steps such as sales qualification and limited target customers. In parallel, he works with operations and engineering to be ready for limited new customers.

Share

You still own outcomes (differently)

None of this removes accountability.

Learning-stage products still need revenue growth, operational discipline, and responsible execution.

But the accountability shifts from:

“Prove the final model upfront.”

to:

“Show that the organization is learning, reducing risk, and sequencing investment responsibly over time.”

Your product work is spread out over a sequence of learning phases. You continue to be accountable for clarity over time. This includes responding to unplanned issues and pulling back if the business growth isn’t viable.

The key is frequent and deep collaboration with your stakeholders, who are under extreme pressure to generate growth.

Conclusion: When circular feedback helps

Many product managers think they’re struggling because they can’t get the work to stabilize. Circular feedback is often a sign that the organization itself is still learning how to absorb the new model.

Learning-stage initiatives are teaching the organization how to operate in a new model while the organization is still expecting proof from the old one.

In these cases, the product management skill that matters most is helping the organization learn.

Q&A

How do I know this isn’t just poor planning?

You can distinguish this from planning by the ambiguity of the initiative. Changes in the business model, as well as AI in the workflow, introduce too many unknowns for planning. This approach sequences learning about the unknowns so planning can begin. This means more discipline to show progress in learning enough for the planning.

How do you prevent endless iteration?

Tracking progress through the learning phases is essential for effective collaboration with your stakeholders. Most stakeholders are used to mature products with clear dependencies. Learning-stage products are defined in front of stakeholders. The sequencing of learning provides stakeholders with a clear path to a defined outcome.

What if leadership still expects certainty?

Don’t fight the requests for certainty. Translate the uncertainty into:

• A learning phase

• A goal in the sequences

• Part of the risk reduction steps

• Operational checkpoints

Use orchestration to show how you reach certainty together.

How do I know when the product is leaving the learning stage?

As you move from a broad opportunity to use cases, stakeholders will become more comfortable. When the team can “see” the product idea, the questions become predictable. The organization learns about the initiative through:

• Discussing why the idea has potential

• Contributing to the business model

• Reaching consensus on the assumptions

When there is enough learning about these, you can move to experiments and customer adoption activities.

Connect with Amy on LinkedIn, Threads, Instagram, and Bluesky for product management insights daily.

This week’s backstory discusses why to work on solution packaging:

What Prompted This Article?

This article continues with “Vivek”. He is a builder PM. I work with him frequently.

Vivek commented that he was spending a lot of time with sales explaining how to configure his AI products to support potential customer requests.

I felt like Vivek’s modular products could be put in pre-defined packages to help sales. I came up with this idea:

This is one of those simple ideas that is challenging to carry out. I needed to try this idea on different use cases before I could write about doing it.

I felt like this idea needed more development before I could break down the steps in an article.

What Happened After This Article?

Read more

At some point, as an IC product manager, your calendar starts to change.

Reading the meeting transcript is quicker than attending the meeting. Operational decisions resolve themselves before you step in. Product teams mock up experiences directly with customers and fix issues in hours instead of weeks.

You suddenly have open space again.

And instead of feeling productive, it feels disorienting.

For years, product manager leverage came from product integration:

• connecting stakeholders,

• driving alignment,

• ensuring releases met requirements,

• reducing delivery friction,

• anticipating disconnects before customers saw them.

But teams move differently now. There is less need for product managers to constantly stitch work together.

The uncomfortable realization is that many product managers still operate like product integrators in an environment that increasingly rewards product acceleration.

This article is about learning how to use the freedom well.

The uncomfortable moment: your product integration can become avoidance

Being busy and in demand isn’t as valuable as it used to be.

A lead engineer can’t remember why a customer wanted that UI change. Finding the screenshot is easy. Just look it up and move on.

This simple act takes away a chance to collaborate on the customer experience. Together, you and engineering can see other UI rough edges, like headers not aligned with data.

You’re substituting easy responses in place of handling the harder work.

Your challenge is putting your deep work on:

• Reducing ambiguity

• Identifying real customer pain

• Making strategic judgment calls

• Creating momentum

Your product integration instincts become a substitute for confronting uncertainty directly.

Product integration still matters in complex environments, large cross-functional launches, and dependency-heavy programs.

But for many product managers, integration is no longer the primary source of leverage.

Share

Why the environment changed

When everyone has access to data and AI helps organize data, then there isn’t much need for product integration. Teams have:

• Fast communication loops: meeting transcriptions minutes after the meeting

• AI assistance: to organize context

• Easy self-correction: fixing the misses is fast

This means each person in the product team can be autonomous. The bottleneck moves to tangible product acceleration.

Subscribe now

What does product acceleration work look like?

Builder PMs create momentum by sharing context and learning earlier. Examples:

You clarified a confusing customer problem

Now, engineering, design, and GTM all understand the same thing.

You identified the real adoption blocker

The issue wasn’t missing features. It was onboarding friction.

You changed the narrative

The product wasn’t “missing capabilities.”

Customers simply didn’t understand the value

You connected the disconnected signals

Support issues, sales objections, and usage drops were actually one underlying problem.

You exposed false urgency

A noisy stakeholder request turned out to have no customer impact.

You made the next decision obvious

This is huge leverage and is rarely celebrated enough.

These outcomes don’t come from polished status updates. They come from faster learning loops:

• Constant build-in-the-open: sharing research and point of view before it is “ready”

• Working teams: build relationships and compare work

• Experiments: hypothesis as a precursor to decision-making

• Rapid iteration: learn and adjust with working teams

These outcomes require a different way of spending attention and time.

Share

The product acceleration operating model

Adapting to a different operating model can shift you out of product integrator to product builder. Your operating model has served you well. Small adjustments let you build on the environment changes.

Share

Optimize for momentum over ownership

Ownership creates maintenance gravity.

Momentum creates learning and movement.

The product integrator instinct

Owning living documents. Acting as the approval layer to prevent costly problems.

Why it breaks down

Ownership creates maintenance and turns you into a coordination bottleneck.

The builder shift

Focus on users of the living document and drive to their needs. Living documents move to build-in-public.

What this looks like practically

No longer paying attention to issues and changes in the living document. The living document is maintained by the team.

This frees you to:

• Address customer pain points with fast loops

• Handle undefined opportunities

• Support the unowned workflows

Why this matters

You spend less time maintaining systems and more time creating movement.

Build your own operating system

Builder PMs compound learning instead of repeatedly rediscovering problems.

The product integrator instinct

Reactive problem solving.

Why it breaks down

Because teams can self-correct quickly, product integration reactions are wasted time. Evals catch problems and generate fixes faster than reaction meetings.

The builder shift

Persistent signal collection

What this looks like practically

Your operating model shifts from preventing problems to monitoring signals. Monitoring is continuous:

• Customer friction points with your product

• Demand validation points

• Potential adoption blockers

• Evals and feedback

• Identifying hidden stakeholders

Why this matters

You stop solving isolated problems and start building reusable judgment.

Use your storytelling skills for building

Narrative is no longer just stakeholder management. It becomes a tool for thinking clearly.

The product integrator instinct

Storytelling to gain alignment

Why it breaks down

If you can’t explain the opportunity to yourself, then you probably can’t build a solution.

The builder shift

Using storytelling to reduce ambiguity for yourself.

What this looks like practically

Build your own narrative to explain to yourself:

• The user pain

• Identify the conflict simply

• Suggest the solution

• Describe the outcome

Using this plain language, you can move from problem to solution very fast.

Why this matters

Create a stakeholder story for yourself to build quickly.

Change your scorecard

Changing your scorecard to learning and customer benefits leads to real growth.

The product integrator instinct

Measuring how you are needed:

• Meetings

• Responsiveness

• Stakeholder visibility

• Coordination heroics

• Organizational presence

Why it breaks down

Debating possible efficiency gains that aren’t visible to customers

The builder shift

Measure and celebrate progress to results

What this looks like practically

Measuring your results:

• Clearing confusion

• Improved customer understanding

• Shipping something

• Behavior changed

These results are more valuable to celebrate than how much you are needed.

Why this matters

The hardest part is that deep product work often feels quieter than product integration work.

Become known for clarity

As teams become more autonomous, the highest-leverage product managers increasingly reduce uncertainty instead of managing communication.

The product integrator instinct

Product integrator reputation:

• The person who keeps things moving

Why it breaks down

Monitoring for likely outcomes is slower than an eval and fix.

The builder shift

Product accelerator reputation:

• The person who makes unclear things understandable

What this looks like practically

Shift your reputation to the person who figures things out: Some of the clarity-finding actions are:

• Find clarity on something unclear

• Make new opportunities real

• Turn vague strategy into customer value

These things take continuous learning and relationship building to put into action.

Why this matters

Figuring out what works and doesn’t is a high-value skill.

Subscribe now

Shifting from product integrator to product accelerator

In the past, being the product integrator gave constant reinforcement:

• People need you

• You’re busy

• Meeting show importance

• Responsiveness created validation

Building work for product acceleration is harder because:

• Progress is quieter

• Ambiguity is uncomfortable

• Nobody tells you what to do

• You must decide your best next step

Product integration work gives immediate social feedback. Builder work gives delayed outcome feedback. That’s why many product managers unconsciously drift back toward product integration.

Builder PMs get more satisfaction from product acceleration:

• Uninterrupted thinking

• Discovering hidden opportunities

• Seeing patterns compound

• Customer understanding

• Momentum from clarity

• Creating direct outcomes

In a fast-iteration environment, the work becomes quieter, but you can get more done.

Conclusion - building is more satisfying

The strange part of becoming a builder PM is that your work can start feeling quieter while your impact grows larger.

Fewer meetings.

Less debate.

Less visible coordination.

More clarity.

Faster learning.

Better judgment.

More tangible customer outcomes.

You stop measuring your value by how much work flows through you.

You measure it by how much uncertainty disappears because of you.

And eventually, you realize something unexpected:

Building products is more energizing than managing the movement around them.

Share

Q&A

Won’t customers be impacted if I don’t make sure the parts come together as planned?

Product acceleration does not mean abandoning quality checks. It means shifting from personally stitching everything together to creating fast feedback loops that expose issues early. Modern teams can detect and fix disconnects much faster than traditional release cycles allowed.

If my time is on clarifying the unknowns, then how do my leaders know I’m doing my job?

Your leaders want to know your decisions about handling the unknowns. Leaders can check a dashboard and your built-in public artifacts to get details. For example: “I decided to delay the ordering guide by one week to include the feature that 5 customers requested.”

Won’t salespeople take advantage of product acceleration for more customization and experiments?

More contact with salespeople is always valuable. If you get more invalid requests for product changes, then you have a good signal of where to work. Your reaction to increased sales and customer interactions is what matters. You ultimately get to decide your delivery plan.

How can I possibly have an impact alone without project managers and engineering?

You are already alone. Your program managers and engineering team are waiting for your experiments, decisions and clarity. Once you make it clear what is next, they will run with it.

What if my organization still rewards visible integration and coordination activities?

Then some integration work remains politically necessary. But even in those environments, your highest leverage still comes from clarity, momentum, and customer understanding.

Looking for more practical tips to develop your product management skills?

• Product Manager Resources from Product Management IRL

• Product Management FAQ Answers to frequently asked product management questions

• Premium Product Manager Resources (paid only) 4 learning paths, 6 product management templates and 7 quick starts. New items monthly!

Upgrade

TLDR Product featured Product Management IRL articles recently! This biweekly email provides a consolidated list of recent product management articles.

drpp The Drip featured Product Management IRL articles. This newsletter has handpicked product management articles every day, summarized to give you the big picture of product management and tech.

Connect with Amy on LinkedIn, Threads, Instagram, and Bluesky for product management insights daily.

This week’s backstory is about getting builder PM ideas out to customers:

What Prompted This Article?

I’ve written several articles about “Vivek”. He is a fast-moving builder PM. I work with him frequently. I’ve been fascinated by the way he stays focused on delivery and bypasses the usual obstacles that slow my own deliveries.

Vivek has spent several weeks exploring why sales isn’t contacting him about his products. He made sure his products were being positioned with customers.

He noticed that his products and technology (AI) are so new that salespeople are unprepared to engage with customers. Vivek decided to check every pre-sale inquiry about his products.

Builder PMs sometimes do unscalable things like this to build demand.

I wrote this article to explore alternatives for builder PMs in a similar situation. This diagram shows the many product connections a builder PM needs to make:

My article grew longer than usual. I prepared a free resource to discuss each of these connections so I could get the article to the normal size. The Bright Spot Playbook covers practical tips to connect new features to the product solution.

The open question: can builder PMs keep moving fast while building this structure?

I was looking forward to building these connections with Vivek.

What Happened After This Article?

Read more

An AI initiative starts simply enough. Add an AI agent to a time-consuming product management process.

At first, the conversation sounds like normal product work:

• Requirements,

• Capabilities,

• Integration questions,

• User experience.

Then the initiative starts expanding.

The workflow is inconsistent across teams.

Documentation is stale.

Ownership is unclear.

Exceptions are handled differently across products.

Within a few meetings, the discussion is no longer about the AI initiative.

It becomes:

• Process redesign,

• Governance,

• Knowledge quality,

• Operational consistency,

• And organizational risk.

This is the moment product managers feel the urge to stabilize the system before moving further.

Those instincts are usually correct. But this is what makes AI initiatives difficult.

AI initiatives look like normal product work until you see AI needs more than normal product work.

What looks like a normal product initiative quickly expands into operational and organizational redesign.

Normal features don’t change the workflow, operate dynamically or need ongoing evals to keep it tame.

Adding AI to anything that touches the product pulls you into disruption. The closest pattern to tackling AI is transformation. The main difference is that the AI change doesn’t come with the transformation label.

In the usual stable product environment, you drive for clarity and risk management as a product manager.

In transformation environments, you need high velocity learning.

This changes how product managers operate.

Share

The familiar AI initiative that suddenly expands

You finally have a real opportunity to use an AI agent. Leaders are investing in it before you suggest an approach.

You decide PRDs are a high-leverage place to use an AI agent. Mistakes in a PRD have many downstream impacts and product managers never seem to get enough time to do the PRD right.

Quickly you find:

• Workflow differences

• Multiple owners of PRD contents

• Program managers and engineering teams have little trust in PRDs

• Non-existent governance of PRD contents

• Scope explosion

This is where your product manager instincts kick in.

Why your product manager's instincts slow the initiative

Going into normal product management mode, you look for stable and known items to build up. But every product does requirements differently.

Continuing product manager thinking leads to more concerns:

• If the PRDs and requirements workflow are so different, then how can you reuse the agent.

• If engineering already doesn’t trust PRDs, their trust could break more with a mistake from AI

• Scaling starts looking like a custom agent for every product

These are huge caution signs for a normal product initiative.

Subscribe now

AI initiatives become transformation work early

AI systems interact with workflows dynamically instead of deterministically.

That means organizational inconsistency becomes visible much earlier than with traditional feature work.

Your instinct for a stable environment is technically right. But setting up stability for a dynamic AI agent that contributes to a PRD will hold up the benefit of the initiative.

On the other hand, if you rush into the AI-assistance without context and guardrails, you could lose trust and credibility.

This is a situation where traditional product management techniques delay progress. Transformation leadership can enable progress.

Instead of going into systems thinking and stabilization strategies, you drive for learning.

How does learning make progress? Your systems thinking shows plenty of problems to solve. But you and your team haven’t learned enough about a system with AI to understand the problems.

Transformation product management focuses on enabling the next step. Stabilization product management focuses on optimizing several steps ahead.

Here is a comparison of these two approaches to product work:

Share

The trap: solving the whole system too early

Early AI transformation conversations often create a trap for product managers and systems thinkers.

You can see where the initiative will eventually struggle:

• trust in generated outputs,

• inconsistent process inputs,

• operational gaps,

• unclear ownership,

• stakeholder concerns,

• scaling limits.

So the natural response is to improve the system before taking AI into the workflow.

That works well in stable environments.

It works less well during the earliest transformation stages because the organization is usually trying to answer a different question first:

“Can we create useful learning quickly enough to justify continued movement?”

Learning enough to start is a different goal from getting to a stable environment.

But transformation is new territory. You need to learn enough for the next step. You don’t know what works yet. Your focus is learning.

Strong transformation leaders understand that introducing every important concern at once can accidentally overwhelm the organization’s ability to move.

This is because the organization has not yet built enough shared context to absorb the changes.

Using transformation thinking, the AI agent idea is about:

• Learning enough

• For controlled risk

• In a bounded pilot

Share

Shaping without slowing

Strong transformation product managers shape the system early just like product thinkers.

They just shape it differently.

Instead of trying to fully stabilize uncertainty, they:

• narrow the scope,

• reduce the exposure surface,

• constrain the workflow,

• and create bounded learning environments.

Instead of:

“We need enterprise knowledge quality solved first.”

The framing becomes:

“Let’s start with one trusted workflow and learn from that.”

Instead of:

“The process is too inconsistent for AI.”

The framing becomes:

“Which parts of the workflow are stable enough to support useful experimentation?”

This is sequencing complexity.

You still apply systems thinking at the right altitude for the organization’s current learning phase.

That often means:

• smaller experiments,

• narrower context,

• faster feedback loops,

• and less pressure to solve future scaling problems immediately.

Because early transformation phases are about generating believable learning.

Subscribe now

The leadership transition

Until AI touches your product, you are rewarded for stabilization leadership:

• Seeing risk early

• Improving operational coherence

• Designing scalable systems

AI transformation changes the sequencing of your instincts.

The focus is on learning and less on rigor. The learning focus includes:

• Where workflows are stable

• Which inputs matter the most

• What level of human review is needed

This is one of the hardest transitions for product managers building with AI.

What transformation thinking product managers do early

When AI enters a workflow, transformation-minded PMs often:

• choose one narrow workflow instead of redesigning the whole system,

• identify trusted inputs instead of solving enterprise knowledge quality,

• add human review instead of demanding full automation reliability,

• measure learning velocity instead of scale efficiency,

• and delay organization-wide standardization until patterns emerge.

The goal is to apply rigor in the sequence that the organization can absorb.

Transformation thinking is not permanent.

As learning stabilizes, workflows repeat, and trust increases, stabilization leadership becomes increasingly important again.

The mistake is introducing scale-stage rigor before the organization has enough learning to support it productively.

Share

Conclusion - AI touching your product needs transformation thinking

AI initiatives often look like normal product work at the beginning.

But once AI starts interacting with real workflows, organizational inconsistency becomes part of the product problem itself.

That is why product manager instincts can suddenly create friction. Those instincts are optimized for a different phase of organizational maturity.

Transformation leadership is deciding:

• which rigor is necessary for learning now,

• and which rigor belongs later as confidence grows.

The strongest product managers in AI transformation are the ones who sequence systems thinking to preserve momentum while the organization learns.

That is the leadership shift.

Q&A

How do I get product team engagement on an AI transformation project?

Initially, work with a small team to learn how AI changes your product workflow. Usually, the product team gets involved before scaling to customers.

Won’t the AI transformation get paused to unify the product data and workflows?

No. You control the inputs to AI. A small set of inputs tuned for the product workflow is usually enough to make progress.

With senior leaders focused on the AI transformation, how can I just experiment with a fraction of the product?

Targeting a part of the workflow that is time-consuming can show a business impact. Dependency checking, for example, can be offloaded and free you up for business growth. By narrowing your focus, you have results to show quicker.

How do I know when to move from experimentation to stabilization?

When the changed workflows become repeatable and usage is increasing. At this point, governance, standardization and scaling start adding value.

How small should a bounded AI pilot be?

Small enough to learn something with controlled risk. Large enough for a person to see a result in weeks/days.

Looking for more practical tips to develop your product management skills?

• Product Manager Resources from Product Management IRL

• Product Management FAQ Answers to frequently asked product management questions

• Premium Product Manager Resources (paid only) 4 learning paths, 6 product management templates and 7 quick starts. New items monthly!

Upgrade

TLDR Product featured Product Management IRL articles recently! This biweekly email provides a consolidated list of recent product management articles.

drpp The Drip featured Product Management IRL articles. This newsletter has handpicked product management articles every day, summarized to give you the big picture of product management and tech.

Connect with Amy on LinkedIn, Threads, Instagram, and Bluesky for product management insights daily.

This week’s backstory is about trusting automation:

What Prompted This Article?

This article started with an email from Tim Varelmann. He was offering a guest post on prototyping for product managers.

He also offered to give information on optimization strategies. That got my attention.

My product is being used in complex environments. I was looking forward to learning from Tim.

Tim’s story about working with a product team on a complex retail ordering system was one of those gritty stories that felt like a real situation from my product work.

Tim was brought in after a prototype planning tool wasn’t working right. He worked with the product team to define:

• Objectives - what you are optimizing for

• Constraints - naming where rules can bend

• Tradeoffs - defining decision tension

He re-wrote the logic around objectives, constraints and tradeoffs.

And he did one more thing: he made the prototype show how the decision aligned with the objective.

With that change, the prototype could be tested and rolled out.

I don’t have the benefit of an operations research consultant in my product work. But I thought Tim’s approach to a complex situation would help.

What Happened After This Article?

Read more

Jon’s first big product initiative wasn’t supposed to go like this.

“You aren’t focusing on the right details here,” his boss said.

“This is the third time I’ve asked for this information. If we don’t get this feature out soon, sales will miss the forecast again.”

He leaves the meeting with a familiar feeling that no longer feels temporary: he’s behind, but not sure on what.

This is one of the most common failure modes in cross-functional product work and one of the hardest to recognize while you’re in it.

If you’ve ever felt like:

• Progress means filling in more slides, not making decisions

• Every stakeholder wants something different

• And you’re being asked for details without clarity on direction

You’re likely in the Completeness Trap. This shows up whether you’re working on a feature, an initiative, or a full product; what changes is the scale, not the pattern.

A few months earlier, this initiative looked like a clear step forward.

Jon had just delivered a telemetry report on capacity usage for their largest customer. It went well. Leadership noticed.

So when taking that capability to all customers, he was excited to own it.

It felt like a real product moment.

Sales supported it immediately. They even suggested enhancements that could improve uptake. Finance helped shape the business case and flagged important cost targets. Engineering raised concerns early: the cost targets would be difficult to hit in the first release, though they weren’t convinced the feature would even see strong demand initially.

Still, there was momentum. And ownership.

Now Jon is stuck in something different.

Every conversation adds detail, but nothing feels settled.

And now something that started as his first meaningful product responsibility is starting to feel like a performance problem.

What’s happening to Jon is a predictable failure mode in ambiguous cross-functional work.

It has a name: the Completeness Trap.

Share

Why this stalls

It looks like a coordination problem. It isn’t. It’s a definition problem.

No one has clearly defined what decision is being made.

So the team substitutes something else:

“Let’s get the details right first.”

Each function optimizes for its own concerns:

• Sales pushes for edge-case flexibility

• Finance looks for scalable control mechanisms

• Delivery evaluates feasibility in isolation

• Product tries to reconcile everything at once

And somewhere along the way, “progress” becomes:

How much have we filled in?

Instead of:

Are we ready to decide?

The trap

The Completeness Trap is when teams replace decisions with detail.

What makes the Completeness Trap difficult to see is that no one is doing anything wrong.

Sales is trying to protect revenue.

Finance is trying to protect margin.

Engineering is trying to protect feasibility.

Leadership is trying to protect delivery certainty.

And the product manager is left trying to reconcile all of it by adding more detail.

But detail only redistributes tension. Avoiding the tension by investigating details ends up delaying progress.

Jon’s situation is missing a structure for decision-making.

And once you see it that way, the path forward stops being about alignment and starts being about design.

There are three moves that break the Completeness Trap:

1. Shrink the problem until a decision becomes possible

2. Define constraints before expanding detail

3. Turn objections into boundaries, not blockers

These are ways of forcing decisions in ambiguous situations.

Subscribe now

Make the decision smaller

In Jon’s case, the organization is trying to answer a large question:

“Should we roll this capability out across all customers?”

But that question is too broad for the current level of uncertainty.

So instead of forcing clarity through more detail, the first move is to change the shape of the question itself.

Not:

“How do we solve everything correctly?”

But:

“What is the decision-ready slice of this?”

That usually means defining a bounded rollout, such as:

• a specific customer segment

• a constrained usage scenario

• a limited commercial structure

• or a time-boxed 60–90 day window

The point is to create a version of reality where the organization can actually observe outcomes and make a decision.

This is where most teams hesitate because shrinking the problem feels like admitting it isn’t ready.

For Jon, it would feel like this:

• The initiative is already tied to a major customer story

• Sales is expecting it to support forecast recovery

• Leadership is watching delivery timing closely

But that delays the moment of commitment.

What’s actually missing is not scope. It’s a decision-ready slice.

A decision-ready slice is the smallest version of the problem that allows the organization to answer one question with real evidence:

“Does this work well enough, under controlled conditions, to justify scaling?”

For Jon, this feels like lowering ambition. In reality, it is the only way to preserve it.

Why this feels risky

Finding a way to reset the Completion Trap means shrinking the problem and setting a decision-ready slice. You still need to deal with strong personalities and delivery urgency.

So the question is:

“What is the smallest structural move that still changes how decisions get made under pressure?”

Setting a decision-ready slice doesn’t remove pressure. It gives it structure.

Share

Turn objections into boundaries

This is where most product managers lose control of the model.

The moment you propose a “smaller slice,” stakeholders start doing what they are trained to do:

• Sales expands use cases

• Finance tests downside risk

• Engineering challenges feasibility edge cases

And suddenly, the “slice” starts growing again.

So the problem is when objections are treated as inputs into redefining the slice.

The shift is subtle but critical:

Objections are not used to reshape the decision-ready slice.

They are used to define the boundary conditions of it.

A boundary condition is different from a requirement.

It defines the limits within which the decision will be made.

For example:

• Instead of “we need flexibility for all deal types”
  → “within this slice, only standard deal structures are in scope”

• Instead of “cost needs to work at scale”
  → “this slice is evaluated under capped usage conditions”

• Instead of “we need full engineering readiness”
  → “this slice uses existing system capabilities only”

The key difference is this:

A requirement asks for inclusion.

A boundary condition enforces exclusion.

This sounds clean in theory. It rarely is in practice.

Here’s what it looked like for Jon:

Why this works (even here)

At this point, it’s easy to think:

“This only works if you have control over scope.”

Jon doesn’t.

His boss is already frustrated.

Stakeholders are already fragmented.

The customer is already using the feature.

And there is pressure to show progress quickly.

So this feels like a recovery problem.

But that’s exactly where the Completeness Trap becomes visible.

Jon is missing a shared definition of what “good progress” looks like right now.

Without that, every action he takes will be evaluated differently:

• Leadership sees delay

• Sales sees under-delivery

• Finance sees uncertainty

• Engineering sees overreach or under-scope depending on direction

So Jon’s focus is changing the structure of what they are reacting to.

And that is where the “decision-ready slice” becomes practical.

Subscribe now

Breaking the pattern

He fixes this by doing something that feels risky in the moment:

He goes back to his boss first. With a reframed question.

“We’re getting a lot of detailed input, but it’s not converging into a decision.

I think we’re trying to solve for full rollout before we’ve proven a version that works.

I want to propose a bounded version of this so we can decide what to do next.”

This is not a fully formed plan.

It’s a shift in how progress is defined.

His boss doesn’t immediately agree.

But for the first time, the conversation changes.

From:

“Where is the missing detail?”

To:

“What exactly are we trying to decide right now?”

Jon then does the harder part.

He defines a decision-ready slice.

• A limited set of customers similar to the original use case

• A constrained usage model that caps cost exposure

• A standard commercial structure with no variations

• A 90-day window to evaluate actual usage, cost, and willingness to pay

And just as importantly, he defines what is not included.

No edge-case configurations.

No expanded packaging options.

No system-level optimizations.

Then he brings it back to the group.

This is the uncomfortable meeting.

Because for the first time, Jon is not collecting input.

He is presenting a boundary.

And asking a different question:

“If we operate within these conditions, is this enough to decide whether we scale this or not?”

The reactions come quickly.

Sales pushes on flexibility.

Finance questions margin exposure.

Engineering raises feasibility concerns.

Just like before.

But something is different.

The conversation doesn’t expand.

Because the slice is not up for redesign.

The discussion shifts to:

“Does this bounded version answer the question we care about?”

And for the first time, the team is reacting to the same version of the problem.

Jon doesn’t win every argument.

Some constraints get adjusted.

But the boundaries hold.

And that’s what matters.

Because within those boundaries:

• Finance can model risk with actual limits

• Sales knows what is and isn’t sellable

• Engineering knows what they are committing to

• Leadership can evaluate timing and impact

Not perfectly.

But concretely.

A week later, Jon goes back to his boss.

Not with more detail.

With something different:

“Here’s the version we’re proposing to move forward with.

Here’s what we’ll learn in 90 days.

And here’s the decision we’ll be able to make after that.”

This time, the conversation is shorter.

It’s about whether to proceed.

Share

Conclusion: what actually changed

Jon didn’t solve everything. He did something harder: he made it possible to decide.

A shift in the unit of work breaks the Completeness Trap.

It moves you from an unbounded problem that invites endless input

→ to a bounded decision that forces convergence

Your job as a product manager is to define the conditions under which a decision can be made despite it.

And sometimes, the most important move you can make is deciding where detail stops, so the organization can finally move.

Common questions in the Completeness Trap

Won’t stakeholders just reject a smaller slice?

They might. That’s not the point.

The goal of a decision-ready slice is forcing a reaction to a bounded proposal instead of an unbounded one.

Unbounded work expands. Bounded work forces clarity

Isn’t this just delaying the real decision?

No. The decision is already being delayed by the expanding requests for details.

What looks like progress is actually ongoing deferral through detail accumulation.

What if the customer is already using the feature?

That’s exactly when the trap is most visible.

Usage without boundaries creates the illusion of adoption without clarity on value, cost, or scalability.

A slice is about defining what part of that usage is being evaluated.

My boss is already asking for detail. How do I introduce this?

You introduce it as a response to the current lack of convergence.

That repositions it from abstraction → progress mechanism.

Looking for more practical tips to develop your product management skills?

• Product Manager Resources from Product Management IRL

• Product Management FAQ Answers to frequently asked product management questions

• Premium Product Manager Resources (paid only) 4 learning paths, 6 product management templates and 7 quick starts. New items monthly!

Upgrade

TLDR Product featured Product Management IRL articles recently! This biweekly email provides a consolidated list of recent product management articles.

drpp The Drip featured Product Management IRL articles. This newsletter has handpicked product management articles every day, summarized to give you the big picture of product management and tech.

Connect with Amy on LinkedIn, Threads, Instagram, and Bluesky for product management insights daily.

This week’s backstory is about who uses your product context:

What Prompted This Article?

I’ve been struggling with the idea of AI finding product documents before people find the product documents. What makes AI discover my product? How long after releasing a change does it take AI to find it?

AI hasn’t been around long enough for us to study AI discovery of products.

In the meantime, what should I do with my product to be discovered by AI and potential customers?

This led me to think about a customer’s journey from first being aware of the product to buying the product. How do I investigate a product that I might buy?

I usually start by asking questions of AI, and if the product still looks promising, then I’ll invest time in learning more about it. In other words, I evaluate the product twice:

For an interesting product, there is limited information available unless you buy the product or talk to a salesperson.

The second part of the article covers architecting product context for reuse and potential buyer use cases. I still have a lot to consider about developing product context that is easy to maintain and useful.

What Happened After This Article?

Read more

Two product managers are celebrating a customer win.

Their experimental UI change showing capacity usage over time finally worked for a difficult customer.

A few weeks earlier, that outcome looked unlikely.

A customer IT director escalated: capacity monitoring wasn’t helping him decide when to order more.

Two product managers were pulled in:

• One working from telemetry data to identify expansion signals

• One responsible for the customer experience

Both did what strong product managers do. They started asking questions.

The builder PM reached out to understand usage and performance expectations.

The CX PM checked where the customer expected to see the report and whether others had the same issue.

The sales engineer went back to the customer again and again.

Same topic. Different angles. No coordination.

Eventually, he asked:

“Do you two even talk to each other?”

That question surfaced the real problem.

• The customer team was confused

• Sales paused PM access until there was something concrete

• And the IT director quietly started looking at competitors

This was more than a communication gap.

It was a breakdown in how product management showed up.

Why this is increasing now

This situation isn’t unusual anymore. Product managers are now expected to drive business outcomes, not just deliver features.

That means:

• More experiments

• More off-roadmap initiatives

• More direct engagement with customers and stakeholders

And increasingly, more than one product manager on the same problem.

Each product manager needs input to move quickly.

So they act in parallel.

That’s where overlap turns into duplication and duplication turns into confusion.

Share

The hidden failure mode

When multiple product managers work the same problem without coordination, the failure mode is predictable:

• The same questions get asked twice

• Stakeholders are engaged in parallel

• Ideas diverge before they converge

• Misalignment shows up externally before it’s resolved internally

And the breakdown happens early; during discovery and planning.

But this isn’t just inefficient.

Every external interaction represents product management as a whole.

Cross-functional teams don’t experience individual product managers.

They experience a single function.

If product managers aren’t aligned with each other, there’s no reason for anyone else to stay aligned with them.

That’s when teams step back:

• “Who owns this?”

• “Who’s making the decision?”

• “Who should I respond to?”

Progress slows because the ownership model is unclear.

Subscribe now

This is how trust erodes; quietly, before anyone names it.

So, how do you prevent this?

Operating models product managers use

Product teams already use two coordination patterns:

Shared thinking, single-thread execution

• Used for ambiguous problems

• One person drives exploration

• Prevents duplicated discovery and stakeholder fatigue

Incident-style coordination

• Used for escalations

• Clear ownership of workstreams

• One consistent story outward

When multiple product managers are involved, these patterns don’t disappear.

They need to be applied intentionally between product managers.

Subscribe now

2+ product managers = Dual-PM operating model

When two or more product managers share a problem, you’re no longer operating independently.

You’re operating in a dual-PM model.

Internally, work can be divided.

Externally, it must feel coordinated.

Individually efficient. Collectively confusing.

That’s what creates trust:

• Work is routed, not duplicated

• Stakeholder engagement is intentional

• Communication is consistent

Without this, even strong product managers create friction.

With it, they move faster together than they would alone.

Share

How the dual-PM operating model works

In practice, the dual-PM model comes down to a few behaviors:

Exploring

One PM drives a topic forward.

Others act as navigators—connecting context and preventing rework.

Learning

Done offline, in focused bursts.

Return with answers, not ongoing questions.

Sharing

Maintain a single, living source of truth.

No parallel documents. No fragmented updates.

Deciding

Be explicit about decision ownership—by type, not by task.

Communicating

Coordinate before engaging externally.

One voice per topic. Always.

Subscribe now

The example

Coming back to the pair of product managers integrating capacity reports into the product for sales growth.

That question, “Do you even talk to each other?” forced a reset.

Instead of both asking questions, they divided how they engaged:

• The builder PM focused on engineering integration

• The CX PM partnered with sales

• External communication was coordinated through one person

• Leadership updates were aligned before being shared

• Customer outreach paused until there was something real to show

Same people. Same problem.

Different coordination.

That’s what led to the win.

Share

A path forward for product managers

A dual-PM model gives you a way to move quickly without creating confusion. The model is simple but only if you decide to use it.

It comes from the two product managers deciding how they’ll work together.

Because no one else will define it for you.

Conclusion - Coordination is the product

When multiple product managers own the same problem, alignment isn’t the hard part.

Coordination is.

Individually, each product manager can be effective. Each asks good questions, moving quickly, driving progress.

But without a shared operating model, those same behaviors create duplication, confusion, and eventually, loss of trust.

The shift is subtle but critical:

• From individual ownership → shared system of work

• From multiple voices → one coordinated front

• From speed of action → clarity of motion

In a dual-PM operating model, how you work together becomes just as important as what you build.

Because to the rest of the organization and to your customers,

there is no “PM1” and “PM2.”

There is only product management.

Q&A

Who leads in a dual-PM model?

Leadership doesn’t mean one product manager owns everything. It means ownership is clear by topic:

• One product manager leads exploration per topic

• One product manager owns external communication per topic

• Decision ownership is clearly stated

Leadership shifts based on the work; not hierarchy

Isn’t it awkward to suggest splitting up product management work?

This is about coordination when it comes to external teams. It’s best to treat this as:

• Flexible patterns, not fixed practices

• Invisible structure, not visible process

Adapt this to different personalities and situations.

How do you apply this to a new product manager partnership?

Test what works through a few questions:

• Do we both explore, or should one lead?

• How do we avoid asking stakeholders the same thing twice?

• How do we stay aligned without over-syncing?

What if the other product managers aren’t ready for this?

Product managers can be independent-minded or even difficult to work with. Some product managers have never partnered with another product manager. None of this matters.

Your leadership needs an outcome from both of you. If one person falters, then the initiative falters.

Use the steps in this article to drive an outcome:

• Identify the decisions at each step

• Be clear on external communications

Isn’t it faster for 2 busy product managers to just do their job instead of coordinating?

It feels faster in the moment.

But uncoordinated speed creates downstream costs—confusion, rework, and loss of trust.

Coordinated product managers move slightly slower upfront,

and significantly faster when it matters.

Looking for more practical tips to develop your product management skills?

• Product Manager Resources from Product Management IRL

• Product Management FAQ Answers to frequently asked product management questions

• Premium Product Manager Resources (paid only) 4 learning paths, 6 product management templates and 7 quick starts. New items monthly!

Upgrade

TLDR Product featured Product Management IRL articles recently! This biweekly email provides a consolidated list of recent product management articles.

drpp The Drip featured Product Management IRL articles. This newsletter has handpicked product management articles every day, summarized to give you the big picture of product management and tech.

Connect with Amy on LinkedIn, Threads, Instagram, and Bluesky for product management insights daily.