This week’s backstory is about requirements that help teams hit the ground running:

What Prompted This Article?

One of the lengthy parts of product management is getting from requirements to a plan. I was able to write requirements fairly quickly with AI assistance.

I wanted to shorten the time for the cross-functional teams outside of engineering to reuse the requirements with their own AI tools. For me, the non-engineering teams have many dependencies to work out before they settle on a plan.

Engineering has separate challenges to reach a plan. But there are established processes and tools to lock in a plan.

Before AI assistance, I would do a roadshow to each function on the use cases and requirements. I’d answer their questions. The program manager would follow up on action items. After a few follow-ups, the team developed a plan to deliver the high-priority items in the requirements.

With AI tools, I prepared requirements details for each major team: Marketing, Pricing and pre-sales quoting.

I hoped with a starting point of requirements and specifications, that they could save time in planning. I called each starting point a “workspace” in the requirements.

I put the details that I normally put in Jira stories into each requirements workspace. It was easier for me to delay entering Jira stories. I was curious if planning could go faster.

What Happened After This Article?

Read more

Intro

Product managers rarely have the deepest expertise on the problems they own. It’s part of the product job. The challenge is creating the conditions for the people who do have that expertise to make better decisions together.

We have a guest with us, Ron Robinson. Ron has published 4 books on business performance. He is known for overcoming disruption and building compassion and resilience.

This week is a little different from the usual format. Ron brings the stories; I bring the product management perspective. Together, we’re looking at how these situations apply to product managers when expertise is distributed across a team.

At a glance

The common thread: product managers can stay accountable for the outcome without being the person making every decision.

1. Align around reality before aligning around a plan

Ron’s story: first create a shared picture of reality

I was asked to join the McDonald’s leadership team to win in the competitive Washington, DC region. The leadership team wanted a new restaurant model to gain market share.

We studied our competition and our own capabilities. In teams, we visited competitive restaurants at noon and counted cars in parking lots. We drove through drive-throughs and measured time to delivery, how hot the meal was, how accurate the order was, quality of the food and how polite the service people were. We then sampled our own restaurants using the same measurements. We were ready to design a plan.

The planning session included stakeholders such as “the bread man” (the bun supplier) and other suppliers. Everyone agreed on goals and tasks for building new restaurants and increasing customer satisfaction.

What changed

At the end of the session, the team bought into the new restaurant model. Leadership challenged them to build 30 restaurants in one year with the new model. They and their families would be treated to a week’s vacation in Hawaii if they could hit the goal. The two development groups (construction and real estate) reorganized and planned together. They built not 30 but 32 restaurants and went to Hawaii.

The product management perspective

Product teams often try to align on a solution before they agree on what they are seeing. That puts the product manager trying to reconcile competing opinions. In this case, Ron helped the team build a shared picture of the problem.

• Start with evidence. They studied competitors and their own capabilities before deciding what to do.

• Make the strategy visible. Everyone understood the competitive challenge and the goal.

• Bring the people who execute into the strategy. Suppliers, operators, employees, finance, HR and marketing all participated.

• Turn strategy into ownership. Each group left with goals and responsibilities.

Share

2. Don’t solve every problem yourself

Ron’s story: let people own the decision

The Eastern Band of Cherokee Indians (EBCI) needed us to provide management development for tribal programs. I was asked to be part of that initiative. When training EBCI management, a construction manager became a star pupil.

After learning to listen, he started conducting Monday morning meetings with his crew. He asked, “What do you need to do your jobs better?” They responded, “New boots!” Many had boots that leaked and made working uncomfortable. He got them new boots.

At their next meeting he asked, “What do you need to have a good week?” They responded, “We don’t have the tools we need in our trucks.” He suggested they take the first hour of the shift to survey their trucks, order any missing tools, and get organized.

What changed

The following Monday, the construction manager reported in class that his crew leader told him, “We know you have class today, but don’t worry. We have everything taken care of.” Not only did they take care of everything, but crew production improved!” he said with a grin.

The EBCI construction manager involved his crew in the first decision regarding boots and empowered them to fix the truck inventory in the second decision.

The product management perspective

Don’t solve every problem yourself simply because you’re the product person:

• Start with evidence before asking teams to choose a solution.

• Ask who is closest to the problem before taking ownership of it.

• Give teams the context so they can make the decision.

• Step in when a decision affects the outcome or creates cross-team consequences.

The product manager’s job is to decide how each decision is made:

Subscribe now

3. Accountability doesn’t require control

Ron’s story: Giving experts room to design

Air Canada was transforming from government-owned to a publicly traded airline. Our consulting firm was contacted, and I offered a proposal to coach union members and management on making decisions together.

As we progressed, Bill, the station manager for Winnipeg, mentioned that he was going to design a new laboratory for the station. I asked what he thought of putting the technicians in charge of designing their lab.

Several weeks later, Bill invited me to join him for the grand opening. The laboratory sparkled with new tables and equipment arranged in circles in each half of the room. Bill explained that he had delegated everything to his technicians.

What changed

The technicians designed their space to facilitate a smooth workflow. Each side of the room was organized to accommodate specific research activities.

Bill admitted he would never have conceived of such an arrangement. Several months later, Bill announced they won their first and second outside maintenance contracts.

The product management perspective

• Don’t confuse owning the product with designing every detail.

• Identify where expertise actually lives.

• Give domain experts enough context to make good decisions.

• Stay accountable for the product without becoming the bottleneck.

What changes for product managers

Ron’s stories show three ways to create the conditions for experts to solve their problems. Like product managers, Ron was part of the teams, but he didn’t have to be the center of every decision.

Product managers are deliberate about where they lead and where others lead:

• bring people into the problem first

• listen to the people closest to the work

• give experts room to design

Product managers make sure the team has the right context, direction and ownership to make the right decisions. And they step in when a decision affects the product as a whole.

Share

Thank you to Ron

Thank you to Ron for collaborating on this article. I appreciated his insights from coaching leaders.

To learn more about Ron:

- His website: ronspeaking.com

- His newsletter: RonSpeaking.substack

He updates both places on how to work better in today’s changing world.

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 focuses on AI-assisted product initiatives. It helps you build context that your whole product team can use.

Upgrade

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

This week’s backstory is about doing requirements with AI assistance:

What Prompted This Article?

After using AI (Claude) for several weeks on a product requirements document (PRD), I had over 70 pages in it.

PRDs aren’t supposed to be big. They should just set up Epics and Stories in Jira.

I know product teams rarely read a PRD. Especially not 70 pages!

But I was doing something different this time with AI. I wanted a PRD that the cross-functional teams could use without having to read the whole thing.

This meant the PRD had these new features:

• A narrative section explaining the customers’ use case and why the customer would buy

• A pricing strategy workspace explaining the customers’ total cost of ownership and the costing factors

• A quoting workspace that showed how the solution is presented to the customer

• Detailed list of risks, dependencies and open questions

The PRD had the normal things too. Market sizing, potential revenue and the business case along with requirements.

I followed the five workflows in the article:

It took weeks of back-and-forth with Claude to generate the PRD. A few obstacles slowed me down:

• AI crashes: after several days of working through the opportunity and executive readouts, AI stopped working. I started over with Claude using my saved PRD.

• AI won’t write to Confluence or a document: Lots of copy/paste from Claude to the working PRD.

• AI reads the PRD: Claude spotted every disconnect and logic flaw. Claude also gave text for the next update of the PRD.

• AI used the PRD: Claude could use the PRD to generate a solution price based on input parameters

The question after this learning and generating the big PRD: can it save time in delivering the product to customers?

I was secretly hoping that the new PRD would speed up delivery. Would I see an AI ROI from doing the PRD this way?

What Happened After This Article?

Read more

A quick personal note: My role was impacted by a recent restructuring, so I'm currently looking for my next product management opportunity. The newsletter isn't changing: I'll continue publishing one free newsletter and one paid newsletter each week, including the templates and guides for paid subscribers. Thank you for being here and for your support—it means a lot.

Product managers are developing new capabilities for a faster product environment:

• Builder product managers make ideas tangible faster

• Product context makes thinking portable

• New operating models help teams work at a faster pace

• Invisible integration helps distributed work fit together

These capabilities let us move faster in product. They also mean plans change just as fast. For example:

Engineering discovers the design isn’t feasible.

Sales raises a customer problem.

A key person changes roles.

AI makes a different implementation suddenly feasible.

The outcome stays the same. The path changes.

The next challenge is keeping the product moving even when the path to the outcome changes.

The destination is stable while the path changes

Whether you are working on a feature or a product initiative, there are multiple ways to reach the outcome. Even with extreme time and resource constraints, product teams collaborate and find options to deliver.

After working through tradeoffs, something changes and then you have new options.

Many of these changes don’t affect the destination. The path to reach the destination changes.

If you know change is coming, then you act differently. Product management examples:

• Making a directional decision: a product manager delivering a feature to onboard customers sets a direction while the lead architect is on vacation.

• Creating a point of view: two product managers agree that the units of measure for a new feature are nodes instead of GPUs before meeting with customers

• Target customer strategy: selecting target segments based on early adopter customers and adding segments as the product grows.

• Pricing strategy: directional pricing based on customers’ willingness to pay and adjusting after a few sales

In each case, the destination stayed firm, but the path to the destination changed.

When you know the path will keep changing, your job is preserving what those decisions are trying to accomplish.

Subscribe now

From guarding the product to shepherding it

When the path feels uncertain, product managers can fall into a protective mode: preserving the plan, defending decisions, and tightening process. The instinct can become limiting when the work is moving faster than the plan can adapt.

A product guardian:

• Preserves the plan

• Protects the decisions

• Drives consistency

A product shepherd

• Protects the outcome

• Watches for changing conditions

• Anticipates what is needed next

• Helps the right people make the next decision

• Redirects when the path stops working

Guarding is useful when stability is valuable. As the product environment becomes more dynamic, then shepherding becomes more valuable.

Shepherding means protecting the destination and staying flexible about the path.

Share

Balancing product direction with distributed decisions

In fast-paced products, product managers deal with rapid changes. Product managers feel accountable for product success. At the same time, product managers want to prevent problems by controlling most activities.

Product managers can balance accountability with control by focusing on:

• The outcome

• The product intent

• Critical constraints

• Decisions that affect multiple teams

And product managers distribute control of:

• Implementation choices

• Local tradeoffs

• Sequencing inside functions and teams

• Solutions to new obstacles

Shepherding is the productive way to balance product direction with distributed work.

Once you know what stays under your control and what you can distribute, shepherding comes down to three jobs.

Subscribe now

Three jobs of a product shepherd

Shepherding is about focusing on the destination and distributing the path choice to teams doing the work.

Shepherding looks like this:

Notice what is changing around the product

What happens: You learn from engineering that a requirement change needs extra eval time.

Typical instinct: Rework the plan around the extra time.

Shepherding response: Ask about options to meet the launch outcome and joint decision on changes (documentation, deferral, short-term risk)

Strategies to notice a change early enough to take a different path to the outcome:

• Be proactive about changes in the team

• Listen to undercurrents in 1-on-1 conversations

• Dynamic approaches over static approaches to watch for changes that increase or decrease risk.

Give control to the people closest to the work

What happens: You don’t invite the UX lead to a customer meeting because she is working on the next feature.

Typical instinct: Can’t increase the schedule risk when you are in the meeting.

Shepherding response: Ask about tradeoffs and let the UX lead decide the solution

Strategies to distribute control to the team

• Distribute control through coaching by exploring tradeoffs and leaving the decision in the experts’ hands

• Stay close to the work and co-create solutions

• Use relationships when the situation doesn’t fit the process.

Keep everyone pointed toward the outcome

What happens: A new customer needs a feature that isn’t finished before their annual blackout of IT changes

Typical instinct: Ask sales to explain the risks and tell the customer to wait.

Shepherding response: Ask about the customer's usage and explore alternatives with the team working on the feature. Provide options to the customer.

Letting others understand the intent is the foundation for enabling a diverse team to accomplish more than a single builder.

You can show the intent behind the destination by:

• Connecting the work to the outcome

• Showing the relation to the customer/problem

• Being aware of constraints

• Communicating the reasoning behind the direction

Your product context is what makes shepherding possible. By providing context and intent, you are enabling the people closest to the work to decide how to handle changes.

Share

Directional awareness: the product manager muscle supporting shepherding

Shepherding means noticing what is moving, deciding what matters, and helping the team adjust. Directional awareness helps you decide what requires action, what can wait, and what the team can handle without you

When you orient to the destination, you learn to continuously ask:

• What’s changing?

• What is the effect of the change?

• What will the team need next?

• Is something missing?

• Where is a missing connection?

• Are we still moving toward the right outcome?

Directional awareness takes you beyond these questions into a way of staying active with the product work. Directional awareness questions become the beginning of a loop:

Notice what is changing

Interpret to decide the effect on the destination, the path or both

Redirect to a decision, if needed

Recheck the path to the outcome

Notice everything. Act on what matters.

Many times you can decide not to take action. You notice something changing and it might be too early to take action. For example, engineering decides to put a UI change at a different point in the workflow than in the specification. You wait until the demo so you can see the change through your customers’ eyes.

By looping through the questions and watching the changes, you have multiple chances to distinguish among:

• Trends that don’t need action

• Path changes that don’t affect the outcome

• Changes that risk the outcome

Whether you are building a new feature, changing a workflow or supporting a new customer, directional awareness lets control flow to the teams doing the work. It gives you chances to step in if the outcome might be impacted.

Subscribe now

Shepherding enables parallel work with speed

Product managers are developing many new skills. Shepherding product initiatives is a new skill to keep the product team moving in the same direction.

The capability stack now looks like this:

Building helps the team create faster.

Context helps more people contribute.

Operating models help the team absorb the pace.

Invisible integration keeps distributed work connected.

Shepherding keeps all of that movement pointed toward the outcome.

Product work is becoming more distributed, more parallel, and more dynamic.

The goal is to make sure the product can keep moving in the right direction without you controlling every step.

Share

Q&A

Does shepherding apply to any level of product manager?

Yes, but it looks different at different levels. The scope changes based on your level.

• Feature / early-career product managers

Distributed feature and enhancement outcomes: Give engineering/design room to decide the best implementation while you understand the customer problem and constraints.

• Product / mid-level product managers

Multiple teams or workstreams outcomes: Watch dependencies, changing conditions, and risk triggers while leaving teams to make local decisions.

• Senior/lead product managers

Product initiative or product system outcomes: Communicate about the destination and intent, distribute authority and watch for potential incompatibilities.

Isn’t this just stakeholder management?

No. Stakeholders provide key feedback on the outcome. Stakeholders benefit from shepherding because the cross-functional team adjusts to changing conditions to reach the outcome.

How do I shepherd without becoming responsible for everything?

Shepherding doesn’t mean you own every decision and risk. It means making sure the right people understand the intent and make decisions for themselves.

How do I know when to step in?

Step in when:

• The outcome is at risk

• Teams are making incompatible decisions

• A decision has consequences beyond the team

Otherwise, let the team own the path.

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 focuses on AI-assisted product initiatives. It helps you build context that your whole product team can use.

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 handpicks product management articles every day, summarizing them to provide you with a comprehensive overview of product management and technology.

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

This week’s backstory is about changes in collaboration:

What Prompted This Article?

For several weeks, I noticed increasing harshness from multiple directions in my product management job. Both public and private comments about:

• going faster

• making more sales

• overexplaining in a presentation

• don’t work on X, focus on Y

And the tone of these directions seemed angry. Plus, there was little information about the desired outcome.

At first, I thought this was something happening only in my organization.

Next, collaboration opportunities dropped:

• meetings cancelled at the last minute

• people too busy to meet

• delayed responses to instant messages

• people out of the office due to illness or vacation

I began to consider that other product managers are seeing the same thing.

A little research turned up Reddit product managers concerned about decision pivots and unreasonable demands.

The pressure is real for product managers as we go faster with process changes. I wrote about six things to do instead of passing on the tough talk:

I felt better after these reminders to myself. I also saw these actions as a way to continue being productive even though I expected the pressure to continue.

What Happened After This Article?

Read more

When you add AI to your product, you might notice customers struggle to trust and use it. The problem is often the product decisions leading to the AI addition.

This week, we have a guest post from Patrick Neeman. He has been designing AI experiences as a senior Principal UX designer and in various leadership roles for over 10 years. Patrick has been incorporating gen AI into enterprise applications at Workday for the past 3 years.

Patrick will share eight decisions a product manager must make from discovery through launch and operation before adding AI to a product.

Share

From Patrick

Most AI failures are organizational, not technical. Ironically, it’s usually a failure of the human in the loop making unrealistic decisions. I’ve spent 11 or so years around AI, the last three and a half in generative AI. The bottleneck sits upstream every time: in the human-created scaffolding around the model, not the model itself.

Most of it is just solid product and software practice, but now more important than ever.

Eight problems, each wearing a technical hat. Here’s each one with the human decision it’s really asking you to make.

Intent: Start From What People Are Trying to Do

Most AI efforts start from the technology solution and work backward to a use case. The model can summarize, so we add a summarize button. It can chat, so we bolt on a chatbot. Nobody asked what the person was trying to accomplish; the technology proposed itself, and the team said yes.

This is a failure of the most basic product principle: what are you solving for?

We should always start from intent: what problem the person is trying to solve before any mention of AI. I’ve written about what Will Manidis calls a tool-shaped object. That’s something that produces the feeling of work without the work. Capability-first AI is a factory for them: it feels productive, looked great in the demo, and ships nothing anyone needed.

If you can’t state the job and the outcome plainly, you need to do more work. Otherwise, the most capable model in the world will execute the wrong task perfectly.

What product managers should do

• Write the intent as a user goal. Use their words, with no mention of AI. Bring UX and research in before the solution is chosen.

• Kill capability-first ideas. If the pitch leads with what the model can do rather than what someone needs, send it back until it names the job.

Outcomes: Name A Number You Can Defend

Walk into most AI initiatives and ask what success looks like. You’ll hear improve productivity, or reduce costs, or, more candidly, leadership wants AI. None of those is an outcome. They’re wishes with a budget attached and they can’t be measured, which means they can’t be defended when the spending review arrives.

Marty Cagan has argued for years that teams should commit to business outcomes, not system output. AI makes this even more urgent: decide what changes in the business if this works, name the number, and you’ll know whether to scale it or kill it. Product teams decide which problem is worth solving, and the model won’t do that for you.

What product managers should do

• Write the outcome as a number. If you can’t state the metric that will move, you’re not ready to build.

• Pick a job, not a category. “Cut first-response time in support” beats “add AI to support” every time.

Tool Fit: Use an Agent Only When the Work Needs One

The fastest way to fail with AI is to reach for the most powerful version of it without understanding the need.

Fit the tool to the job: an agent when a decision must be made, automation when the steps are fixed, an assistant when someone just needs an answer.

For example, chat fits exploration and turn-by-turn steering, but ambient agents can be a better fit for ongoing work. Ambient agents work well on background work, triggered by an event, surfacing only when it needs a decision or hits a limit you set.

List to decide whether the work is agentic.

• A real decision under uncertainty. If you can draw the flowchart, it’s automation, not an agent.

• Steps that depend on each other, so the plan adapts as it goes rather than following a script.

• It has to act, not just answer — calling tools, not only returning text.

• Inputs too varied to hardcode, where a fixed workflow would break or need constant patching.

What product managers should do

• Match the tool to the task. Decision needed → agent; fixed steps → automation; retrieval → assistant. Work with engineering to challenge if an agent is really needed.

• Match the mode to the moment. Chat for exploration; run ongoing work ambient, on triggers, not behind a chat box someone has to remember to open.

• Demand proof of autonomy. If a vendor sells an agent, ask what it decides without a human. If the answer is nothing, it isn’t one.

Context: Give the Model What It Cannot See

A model knows what’s in the prompt and what’s in its training. It does not know your pricing exceptions, your renewal calendar, the customer who threatened to leave last week, or the unwritten rule that finance signs off on anything over ten thousand dollars.

The MIT researchers found that pilots stall on brittle workflows and a lack of contextual learning, and the tools never absorb how the work is actually done. It’s a human context-supply problem, and the supply chain runs through your documentation, your data, and your willingness to expose both.

A mediocre model with rich, current context will outperform a frontier model working blind.

What product managers should do

• Inventory what the model can see. Write down the context it has and the context it needs; the gap is your roadmap.

• Surface the context it can’t reach. A document no system can retrieve is context the model doesn’t have. Naming those is how you know where the risk is.

Language: Write Instructions Tight Enough to Execute

Ask three people to summarize the customer feedback and you’ll get three different documents; ask a model and you get a fourth. Since the instruction never specified length, audience, format, what to include or leave out, you get different answers.

Ambiguous in, ambiguous out.

The model fills any gap you leave with a plausible prediction. It predicts likely next words rather than running your instructions literally, so controlled, unambiguous language is a core skill now, not a nicety. A request with clearly defined fields, explicit constraints, and worked examples beats a paragraph of hopeful prose every time.

Good product teams have spent years turning fuzzy intent into precise decisions, requirements, and constraints. AI just made that discipline foundational for everyone who ships.

A controlled prompt is built, not typed. I use a format I’ve written about — CARE: Context, Ask, Rules, Examples. The background the model needs, the request in one clear sentence, the constraints it must respect (format and tone included), and worked examples of what good looks like. Leave any of the four blank and the model fills it with a guess; name all four and the output stops drifting, because there’s nothing left to infer.

What product managers should do

• Write the prompt in CARE format. A blank in any one of the four is where the output starts to drift.

• Specify before you prompt. State audience, length, and constraints up front; don’t make the model infer them.

Expectations: Show Users What to Give It and How Far to Trust It

Most AI systems rarely tell users what to give them for a good result. A user types a vague line, gets a vague answer, and concludes the model is weak when the real gap was the context.

Telling humans what to give a system is the cheapest quality lever there is.

Likewise, a good system makes it clear what it can do and how well it does it. Most products hide limits, then act surprised when users get a wrong answer.

Accuracy itself has to be an expectation we set and check as humans in the loop by design. None of this is glamorous, which is why it gets cut, but it’s the difference between a tool people trust and one they quietly stop using because they never understood the constraints.

What product managers should do

• Tell users what to give it. Show a good request, the context to include, and what the system ignores, so a vague input doesn’t become a vague output you both blame on the model.

• Tell users what to trust. State what the system does well, does poorly, and how often it’s wrong. This makes an uncertain answer look different from a sure one.

Oversight: Decide What the AI Is Allowed to Touch

Most AI deployments have no owner, and that’s a problem.

There’s always a sponsor who approved the budget and a vendor who sold the tool, but no one is accountable for what happens when it decides wrong. That vacuum is fine in a demo; it’s not fine when the agent has write access to customer records.

One of the most reliable ways to stop an agent from taking a harmful action? Assign an owner to it, and they set the rules to make sure it never has permission from the beginning.

You give AI the same guardrails you already give people. That’s true human in the loop.

Security teams have known the fix for decades under a plain name: least privilege. Give the system the narrowest access that still lets it do its job, and the exposure of any mistake shrinks to something you can live with.

What product managers should do

• Scope permissions to least privilege. Everything the agent cannot reach is a harm it cannot cause.

• Name an accountable owner and a stop condition. One person is answerable in production, and a documented way to halt it, settled before the first deployment, not after the first incident.

Evals: Measure Whether It Works Before You Ship It

Most teams can’t answer a simple question about their AI feature: is it better or worse than last week? When they change the model, tweak the prompt, or swap a vendor, they’re guessing; the system might have improved, might have quietly broken, and nobody can say.

Evals are the fix: a fixed set of real inputs with known-good outputs, scored the same way every time, so a change produces a number instead of a feeling.

AI needs more test cases, not less, because the output is probabilistic and a change that helps one case can break another you never thought to check. Most AI teams have none.

The eval set is built from the messy real cases your users send, the edge cases that embarrassed you, and the categories that matter to the business. It’s the only thing that turns “the new version feels better” into something you can defend.

Without evaluations, every release is a vibe and every regression a surprise.

What product managers should do

• Build an eval set from real cases — actual inputs, especially failures and edge cases, with the output you’d consider correct, and score every change against them.

• Gate releases on the score. Don’t ship a model, prompt, or vendor change that drops the number, however good the demo looked.

Subscribe now

Conclusion

The AI models are ready; the organization around them usually isn’t.

Human problems are the ones you can fix without waiting for a vendor. Start from the user’s intent. Name the person accountable. Give the model the context it can’t infer. Specify the work in language tight enough to execute. Tell the user what to expect. Measure whether it works. Define the outcome as a number you can defend. Match the tool to the job instead of buying the most powerful one in the room.

Do all of this and the model you have performs like the one you were waiting for. It was our expectations of technology that were still early in its maturity. The hard part of any technology was always going to be us and that we can control.

Thank you to Patrick

Many thanks to Patrick for his best practices from working with agentic AI. If you enjoyed this article, I encourage you to check out Patrick’s newsletter AI for UX. Patrick’s insights will help you navigate the complexities of user experience with confidence and creativity.

Want to put this into practice?

Patrick turned these eight decisions into a practical AI Product Readiness Checklist you can use with your team before an AI feature ships.

Download the AI Product Readiness Checklist

It’s designed to be something you can bring into a product review—not another AI framework to read and forget.

Product Management IRL free resources

Resources

• The GenAI Divide: State of AI in Business 2025 (MIT NANDA) — ~95% of enterprise GenAI pilots deliver no measurable P&L impact; the barrier is a learning gap, not model quality.

• Claude Code turned every engineer into three (VentureBeat) — the bottleneck shifting from writing code to deciding what to build.

• Gartner: over 40% of agentic AI projects canceled by 2027 — escalating costs, unclear value, inadequate risk controls, and “agent washing.”

• An AI coding tool wiped a company’s production database — the 2025 Replit incident; the fix was enforced dev/prod separation.

• Guidelines for Human-AI Interaction — Amershi et al., Microsoft Research; the first two guidelines are about setting expectations.

• Automation Bias in AI-Assisted Medical Decision-Making — experts overturned their own correct calls to follow erroneous AI in ~7% of cases.

• The State of AI in 2025 (McKinsey) — a defined process for validating AI output distinguishes high performers.

• Outcomes Are Hard — Marty Cagan (SVPG), on moving from output to outcomes.

• From Model-centric to Data-centric AI — Andrew Ng, on why the fastest gains come from improving the data.

• The key to great AI-generated content — the CARE prompt framework.

• Agentic Content Design — Yuval Keshtcher on content design as rule-governed language.

• Tool-Shaped Objects in UX, Part 1 & Part 2 — building from intent rather than capability, and what survives the shift to AI.

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

This week’s backstory is about the mid-year trends in product management:

What Prompted This Article?

Each June, I look back at my product management trends prediction from January.

The funny thing: each trend is moving and not moving at the same time. I’m doing product management tasks faster than ever due to:

• research and connecting product data with AI asisstance

• product context is up to date and less time spent looking things up

• more involved in go to market and customer feedback

But the collaborative parts of the job don’t speed up:

• cross functional teams often don’t have access to some of the product context

• leadership needs synthesis for investments, understanding constraints and accepting trade offs

• process is still aligned to Agile methodologies

There is a lot of learning across teams to adjust to the new approach.

The experiments are showing results. Now it is time to mainstream the advances in product management.

It is only a matter of time before seeing product benefits.

What Happened After This Article?

Read more

Product managers rarely struggle to find opportunities. The harder problem is helping the organization act on them. Every roadmap is full of good ideas that never become meaningful business results.

There is a bit of magic to go from idea to building products. Some people call this:

• Discovery

• Market research

• Trend analysis

Whatever name it gets, some ideas grow into reality while other ideas fizzle out.

Product managers often find opportunities for growth in their daily work. The other part of the work is going from insight to action.

Spot something worth pursuing

Opportunities usually start as observations that make sense when you connect them:

You notice a customer buying trend.

A senior product manager sends market analysis about market growth.

A customer reports a new use case for your product.

Your boss spots a pattern in competitive wins that shows a new market for your product.

Most ideas lie out there until you can develop them into an opportunity.

The opportunity isn’t the finish line

Good that there is a growth idea for your product. Next is developing the idea into a business opportunity.

To actually pursue the opportunity with others, you need:

• A meaningful opportunity or risk

• A way to reduce uncertainty

• People pulling in the same direction

• A path to hand it off

Ideas need your help to turn into a meaningful opportunity.

Share

Build confidence in the idea

At this stage, the organization begins believing the opportunity is real.

Moving from a hunch about a trend to evidence needs a blend of research and buy-in as you go. Ideally, your research process leads to stakeholders who can be co-creators with you.

You initially find proof of your insight:

• Usage and customer comments about how products are being used

• Support trends and feature requests

• Churn and win/loss analysis

Depending on your organization, you’ll discover what cross-functional teams (Sales, Marketing, Engineering, Architecture) are seeing in their domain. They can help with filling gaps in the story.

Next, take a look at external market data. Summarize for yourself analyst data that relates. Check how competitors position similar capabilities.

Socialize continuously:

• Communicate small pieces of evidence as you discover them

• Give influential peers or leaders early material in 1-on-1s

• Include feedback so it gets into your next update.

Evidence convinces people that the opportunity is real. Momentum convinces them it’s worth changing how they work.

Subscribe now

Build momentum

At this stage, people begin changing how they think about the opportunity.

Moving from shared understanding to operational change requires stakeholders to accept real tradeoffs and workload shifts. This is where many promising ideas stall. Everyone agrees with the opportunity, but no one has yet agreed on how their work will change.

You are moving the idea with stakeholders to the real world.

Start with the choices the organization will and will not take. Define “Where to Play” and “How to Win” based on the opportunity. Be sure to document what you are not doing. Product managers usually show “Is / Is Not” at this point.

Use the “Is / Is Not” non-goals list to offset concerns about work disruption. A lot of the concerns are about the size of the change and available capacity. The tradeoff discussion is crucial to a handover that sticks.

Socialize continuously:

• Co-design the potential execution with “no surprises” as you reach early commitment

• Some product managers organize solution workshops, design reviews, or customer journey discussions

Summarize the solution with the tradeoffs into an actionable overview. Topics you can cover:

• The problem and opportunity with the evidence

• Quantified impact with clear success metrics

• Possible next steps to validate, such as a pilot or smoke test for proof before full rollout

At this point, you and a close working group have a draft understanding of what the idea means. You have hard-won agreements about putting the idea into practice.

Share

Transfer ownership

At this stage, the initiative can continue making progress without depending on you.

Your job is less about convincing others that the idea is good and more about transferring the agreements to others for execution.

Think about the cross-functional needs in your organization:

• Engineering and architecture to translate into technical feasibility

• Marketing and sales enablement for the market narrative, pitch decks and pricing/packaging strategies

• Operations and delivery to support customer onboarding and workflow changes

Find and encourage functional champions as you collaborate on the actions to hand over. Give them early reviews and credit them for contributing.

Align on metrics with leadership for shared ownership:

• Tracking the adoption or velocity of customers after the change

• Monitor lagging indicators that apply, such as revenue, user retention, cross-selling and market share changes

• Periodically check back and update the strategy as conditions change

Socialize continuously:

• Handle any lingering doubts through risks and mitigation

• Some product managers orchestrate a readiness review across product, engineering, marketing, sales and operations

These steps get the idea into the hands of the affected teams.

Subscribe now

Your job isn’t to do everything

Getting cross-functional teams moving on your idea is a significant job that requires focus. While you might be able to do the work on carrying out the idea, don’t do it. You will lose your proactive concentration on getting movement.

Your goal is to get the idea over to others for implementation.

Leadership and stakeholders need you to tie together the evidence into actions.

At every stage, your job is to leave the idea stronger than you found it.

Share

Closing - create change along with ideas

Taking ideas into growth is one of the unique jobs of product managers.

It’s about

• Finding relevant evidence

• Building confidence with peers and stakeholders

• Socializing the work

• Transferring to cross-functional teams

This is how product managers create change that’s larger than a single product manager.

Q&A

What if another team owns implementation?

This is ok. Your goal is ownership transfer and not retaining ownership.

What if I’m not senior enough?

Developing ideas to evidence and action builds on communication and relationships. Product managers of all levels can contribute.

How do I know when to hand off?

When stakeholders understand:

• Why

• What

• Tradeoffs

• Success metrics

Without you in the room.

What if nobody agrees?

Then keep researching. Don’t keep presenting.

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 focuses on AI-assisted product initiatives. It helps you build context that your whole product team can use.

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 handpicks product management articles every day, summarizing them to provide you with a comprehensive overview of product management and technology.

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

This week’s backstory is about handling organizational change as a product manager:

What Prompted This Article?

When I wrote this article, I felt responsible for the delays in my product initiative.

This initiative was tricky:

• first time for an embedded technology partner

• high risk of costly mistakes

• dependency on new automation

• adjacent market segment with only early customer demand

In addition to being a sensitive initiative, AI and modernization-related process changes are beginning. And there are a couple of re-orgs in the mix.

Tricky product work mixed with org changes are normal. What isn’t normal is my reaction to take so much stress on myself.

I felt responsible for the delays because of this feedback:

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

• “This needs more detail.”

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

I was spinning my wheels trying to respond to every possibility.

Honestly, I thought stakeholders and my leaders were worried about manageable risks. If they knew more about the offer, then they would be less worried.

This idea led me to learning-stage products. These are products that need the organization to learn along with me. I would focus on phasing the learning:

Moving myself to a learning-stage product would help me focus on the basics of my product initiative. I wasn’t sure about getting powerful stakeholders into learning-stage product handling.

What Happened After This Article?

Read more

AI makes individual product work faster. Organizations need focus more than ever.

But the faster people can build, the more tempting it becomes to say:

“Don’t start until we know exactly how this fits.”

That sounds like discipline.

But it can create a problem.

Sometimes you can’t know how work fits together until people have created enough useful work to see the connection.

• Your product context curation may not make sense until someone reuses it

• A workflow improvement may show value after cost savings can be measured

• A packaging change reduces sales effort after repeated sales training

Strategy provides direction and constraints. The problem is that strategy can’t answer every next question. Building is one way to discover what the strategy should become.

This article is about building to support strategy.

Share

Build anyway means taking a useful next step when the problem is real, the learning is valuable, and the work can survive more than one possible future.

This doesn’t mean secretly launching products, bypassing prioritization, or using scarce engineering capacity without agreement.

Building can mean creating a prototype, curating customer feedback, testing a workflow, packaging an offer, modeling a business opportunity, or making a small change that lets you learn.

The point is to create enough to make the next decision better.

Building for a product manager might mean:

• a prototype,

• a customer evidence base,

• a commercial model,

• a workflow,

• a solution package,

• a context asset,

• a new operating mechanism,

• a decision framework,

• a tested way of working.

Product managers can create useful material that moves the product forward.

Subscribe now

Independent exploration is changing

Product managers and leaders are both under pressure to show business results. That means the focus is on work that supports current business objectives.

This leads to a dilemma for product managers:

• Vital learning from exploration

• While making execution visible

Exploration happens inside the work:

• a customer conversation becomes a prototype,

• a recurring problem becomes a workflow improvement,

• a collection of notes becomes a reusable context asset,

• or a solution experiment becomes a new way to package the product.

These are a few ways to learn while continuing to execute as a product manager.

Share

Useful work can start independently

Some of the best learning comes from product managers supporting each other.

One product manager was developing the product context on how the product worked. Another was creating a way for developers to use the product. Separately, each effort was useful. Together, the context could make the developers’ kit easier for customers to understand and adopt.

Neither person needed to predict the final connection before starting. The connection became visible because both people built enough to see the better-together solution.

The connection was the contribution.

Subscribe now

Independent movement is different from independent execution

Eventually, another team needs to invest time, change a workflow, support a customer, or help bring the work to market. That is when the work needs a bridge.

Cross-functional teams are looking for:

• how the work connects to something they care about,

• what outcome it can produce,

• what they will learn,

• and why this is worth supporting now.

The Builder PM’s job is to create enough connection that other people can see why the work matters to them.

Share

Build enough to make useful connections and invite others to contribute

Collaborate with purpose by showing the outcome that becomes possible together. Showing a better-together outcome helps others discover connections.

How to operate while building responsibly:

Build something useful

When the problem is real and the next step is reasonably clear, then you create movement.

Movement starts small. Useful work is:

• Customer value

• Commercial learning

• Delivery learning

• Reusable capability

• Better understanding of the product

You don’t need a complete strategy to take a useful next step.

Build for optionality

If the strategy changes, then there is still useful work. Focusing on reusable contributions leaves your options open:

• Changing a workflow that leads to a better customer experience

• Consolidating customer needs into actionable change

• Solution packaging for a set of customers

• Curating product context that helps customers and sales learn your product

These can support many outcomes.

Build things that can survive more than one possible future.

Make the work discoverable

Make what you build discoverable:

• What problem were you solving?

• What did you build?

• What did you learn?

• What could this connect to?

Connecting initiatives becomes more valuable than a single initiative done in a vacuum.

Make it possible for another person to recognize the value of their own work in yours.

Look for convergence

Periodically, take a look at the rest of the team for connections:

• What did other product managers learn?

• Are other product managers seeing the same customer problems?

• Are there complementary capabilities underway?

• Are there the same commercial constraints?

• Is a pattern emerging?

Look up from your own work and see whether the organization is revealing a pattern.

Connect and amplify the connection

The strongest connections show up when two efforts make each other more valuable. Connect when:

• one effort makes another more useful,

• the combined result solves a bigger problem,

• the connection reduces effort,

• or the connection creates a clearer path to customer or commercial value.

When you see the connection:

• Celebrate the connection

• credit the people involved,

• explain why the combined work matters,

The Builder PM can contribute by recognizing and amplifying connections.

Subscribe now

Good work often needs a connection before other people can see its value.

Winning together means useful work can find its way to the other work that makes it more valuable.

It means your progress becomes shared progress when the connection is real.

It means the organization can learn from movement instead of requiring every answer before movement begins.

Share

Conclusion - Build what is useful. Make it visible. Connect it when the time is right.

You rarely need every connection to be visible before you take the next useful step. Build something useful. Build for optionality. Make the work discoverable. Look for convergence.

When the right connection appears, amplify it.

That is how independent movement becomes collective momentum.

Sometimes that’s how the next strategy gets developed and how more people decide it’s worth building together.

Q&A

Isn’t it better to wait and watch for a strategy from leadership?

Sometimes. If leadership has clearly chosen a direction, your job is to execute against it. But when the strategy is still developing, waiting for leadership to specify the next step can leave valuable learning undiscovered.

You are giving leadership better evidence in developing the strategy.

What if there is no time to build something ahead of product strategy?

You don’t always need a separate project. Build into the work you already are doing.

If something isn’t working for your customer, take the smallest useful step toward a better one. Break the work into phases. Learn as you go. Reuse what you discover.

The goal is to avoid repeating work that is not producing the result you need.

If I’m acting at the next level in my product organization, then don’t I need to handle product strategy along with building?

Acting at the next level means increasing the quality and speed of the connections that impact strategy.

You build something useful. You connect it to customer, commercial, delivery, or product patterns. You make it visible. Then you help the organization decide whether the pattern should change the strategy.

What if my manager tells me to stop?

Then stop and understand why.

“Build anyway” is not a license to ignore explicit decisions, consume resources without agreement, or undermine your manager.

But there is a difference between building something useful as part of your normal work and launching an unauthorized initiative.

If the work is valuable, keep the learning. Ask what would change the decision. Look for a smaller version of the work that fits current priorities.

Sometimes the right move is to pause. Sometimes the right move is to continue building within your existing responsibilities. The key is to distinguish between waiting for permission to learn and ignoring a decision that has already been made.

What if my idea never connects?

Not every experiment becomes part of the strategy. That’s okay. Useful work is still valuable when it teaches the team something, improves a customer interaction, simplifies future work, or helps another PM move faster.

The goal isn’t to predict every winning idea.

It’s to create enough useful movement that the right opportunities become easier to recognize.

Builder product managers use a new operating model that creates product acceleration. From Product Integration to Product Acceleration

Pressure for results means a different approach to collaboration. Collaborate with purpose enables outcomes through learning. Pressure before Clarity

Product managers can create gravity around their initiatives and make progress over time. Going Beyond the Roadmap has some ways to create a solution package.

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 focuses on AI-assisted product initiatives. It helps you build context that your whole product team can use.

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 handpicks product management articles every day, summarizing them to provide you with a comprehensive overview of product management and technology.

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

This week’s backstory is about product manager operating models:

What Prompted This Article?

I read an article by Elena Verna about her move to an individual contributor (IC) from leading growth at her company. She discussed how rewarding it was to handle a product change from start to finish as an IC.

But she didn’t say how she actually accomplished this.

I began to think about how I could do a product change by myself in my organization. It was overwhelming to consider permissions, collaboration, tooling, and processes.

But Elena didn’t have this problem.

She didn’t have this problem because she cut back her work to the bare bones needed to release the change.

Cutting back for me led to 5 changes:

These changes mean I have time to build things. But it feels weird to stop coordinating each initiative.

I will need to let go of some hard-won instincts and develop new ones.

What Happened After This Article?

Read more

Your product work is going well. Decisions get made. Everyone believes progress is being made.

And yet.

Every few days you find yourself reconnecting everything.

You remind engineering why finance changed the pricing model.

You explain to operations why a customer request affects onboarding.

You update requirements because a legal discussion quietly changed what can actually be sold.

At first, you think a slide explaining the product strategy would help. But then you realize it is something different.

You realize something unexpected. You’re carrying the initiative’s understanding.

The strange part is that you probably didn’t plan for this to happen.

The surprising realization

Like many product managers, you’ve nurtured an idea into a real thing. A feature, an enhancement, a service or a product is coming together.

Your understanding is concentrated. You know what each function can do.

And each team is busy telling you:

• Nothing new here

Or

• This is a huge change

You pause. Maybe the strategy and requirements aren’t clear. You patiently explain again.

On the second repeat, you realize the understanding of the initiative lives in your head.

Cognitive concentration is what happens when understanding accumulates in one person.

Once you recognize the pattern, the next question becomes: Why does this happen even on well-run product teams?

Share

Why coordination doesn’t solve it

For years, product work scaled through coordination.

Program managers.

Scrum masters.

Delivery leads.

Better planning, tracking and communications kept product initiatives on track.

But coordination solves a different problem. It assumes the product team has a common understanding of the solution.

Coordination moves work.

Shared understanding improves decisions.

If coordination isn’t the issue, how do you know understanding has started to concentrate?

Subscribe now

Recognize the problem

You may be experiencing cognitive concentration if

• Every meeting ends with you explaining why today’s discussion matters to the product.

• Teammates remember decisions but not the reasoning behind them.

• Cross-functional discoveries never make it back into the requirements unless you do it.

• Program managers keep work moving but rarely identify second- or third-order impacts.

• Progress feels dependent on your presence; when you’re out, the initiative slows because no one else has the whole picture.

The pattern is less about workload and more about cognitive concentration: too much of the initiative’s understanding lives in one person’s head.

And the way to change this pattern is building a shared understanding. The goal is to help understanding spread naturally across the initiative.

Understanding only scales when it spreads.

Share

Four ways to help understanding spread

As products have become more interconnected through architecture, pricing, operations, finance, AI capabilities, legal constraints, and evolving business models, the scarce resource is shared understanding.

Expand who contributes

Instead of you carrying the knowledge depth of each area, you can get a valuable evolving understanding from the subject matter experts on your product team. You can extend to include centralized experts in your organization.

This means creating more opportunities for other people to strengthen the initiative’s understanding before everything comes back through you.

Ask

Who else should help maintain understanding?

Try

Ask each subject matter expert,

“What changed this week that everyone else should know?”

Watch for

Pricing changes, for example, may affect positioning, packaging, or requirements. More than price.

Expand what gets discussed

Resist asking “What’s next?” after key developments or decisions. Instead, ask questions that get people thinking about what they learned:

• What assumptions changed?

• What requirements changed?

• What new risks came to light?

• What decisions need revisiting?

These questions encourage going deeper instead of surface-level status.

It’s normal for nobody to answer. They’re learning a new way of thinking.

Ask

What changed because of this?

Try

Start small with questions that expand shared understanding.

Watch for

Engineering has a risky architecture change coming up. Instead of monitoring engineering’s delivery, you ask program managers, architects and engineers about the new risks.

Expand where understanding lives

Lightweight artifacts help everyone understand the product initiative. For example,

• Key assumptions

• Decision logs

• Requirements changes

• Open questions

These can be added to active projects and PRDs.

You’re creating a place where understanding can accumulate instead of disappearing. It’s ok if no one reads it; it is there when you need it.

Ask

Where can someone discover this later?

Try

Get one topic into a shared space for wider understanding.

Watch for

You get to celebrate a delivery after writing assumptions in a shared space.

Expand who applies it

Some people are naturally detail-oriented. Others are relationship builders. Others have deep domain expertise. Build on these strengths instead of depending on a detail person to suddenly define a pricing strategy.

Shared understanding increases the quality of the information you’re making decisions with.

Ask

Who could act on this understanding better?

Try

Give people a chance to use their strengths on end-to-end problems.

Watch for

A team member who excels at coordinating to organize working meetings.

Share

None of these practices eliminates your responsibility as a product manager.

Together, they increase the initiative’s ability to understand itself.

Conclusion - how a team scales reasoning

Most product initiatives slow down because understanding stops spreading.

Eventually, one person becomes the connection between architecture, operations, pricing, customer feedback, legal, and delivery.

That approach can work for a while.

It doesn’t scale.

Strong product teams create ways for understanding to grow beyond any individual.

Every successful product eventually becomes too large for one person to fully understand. The teams that continue to grow are the ones that make understanding easier to build, easier to share, and easier to extend. That’s how product work scales.

Q&A

Isn’t it more efficient for a single person to understand these system-level impacts?

Most products are part of complex systems. One person can’t be effective at scale. The single person becomes the bottleneck to scaling. Standing on the shoulders of giants lets products scale.

How do I know this is working?

You’ll notice you spend less time reconnecting conversations and more time making product decisions. Other people begin bringing implications to you instead of waiting for you to identify them.

Does this mean giving up ownership?

No. Ownership doesn’t mean personally holding every connection. It means ensuring the initiative continues building shared understanding.

What if nobody participates?

Start with one conversation. One artifact. One expert.

Shared understanding grows incrementally.

You’re increasing capacity, not redesigning the organization.

How does a product manager communicate well and still not see shared understanding?

Your drive to develop shared understanding might be greeted by silence. Change is still happening even through the silence. The real benefit is increasing the cognitive capacity of the product team.

There are no product builders in the team. How can I strengthen something that isn’t there?

Product teams often have extended teams who understand the space of the product. Sometimes another product that touches your product or common customer teams. You find common ground with them to get product builder understanding part-time.

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 focuses on AI-assisted product initiatives. It helps you build context that your whole product team can use.

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 handpicks product management articles every day, summarizing them to provide you with a comprehensive overview of product management and technology.

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

This week’s backstory is about adding AI to your product workflows:

What Prompted This Article?

It was an initiative from above: prioritize product manager workflows for AI agents. I’m one of four product managers picked for this.

We had a single slide with typical product manager activities. Writing PRDs, developing business cases, generating marketing material. It missed a few key activities like supporting sales and defining offers.

We ranked about 20 activities for AI agents. Activities that needed judgment or human trust were ranked low. Tedious work was ranked high for AI agents.

Writing PRDs seemed like a good candidate for an AI agent.

I started thinking about the requirements for an AI agent that writes a PRD.

I quickly found things that an AI agent could do:

• market research and summarize TAM and SAM

• PRD overview that summarizes the initiative

• Pricing sensitivity

• competitive analysis

• use cases

Then I found the AI agent needed much more to go farther:

• business case ownership

• product business decisions

• process adaptations

• governance and approvals

When I’m faced with a product initiative with this many problems, I park it.

On the other hand, every day I read about a product manager who did something amazing with an AI agent. Including using agents to write PRDs.

What are product managers doing differently?

I found that product managers don’t follow their usual approach to AI initiatives. This is what is different:

Product managers doing an AI initiative focus on learning and controlled experiments. They don’t worry about operational stability.

Its a different approach to product management when AI touches your product. It is more akin to transformation leadership.

This means my AI transformation is one workflow and not a whole PRD.

I was curious if I could ditch my product manager instincts and think like a transformation leader.

What Happened After This Article?

Read more

Your product initiative is moving faster than ever.

You have AI helping with research, requirements, and documentation. Subject matter experts answer questions in minutes instead of days. Engineering can prototype ideas almost immediately.

Everything looks like it’s accelerating.

Yet somehow the initiative still feels harder to handle.

New dependencies appear every week. Teams interpret the same requirements differently. Sales asks questions no one anticipated. Small UX decisions don’t quite fit together. The product works, but it doesn’t feel cohesive.

That’s because acceleration didn’t eliminate integration work. It made it easier to overlook.

But products still need someone to connect the work that happens between teams, functions, and decisions.

If no one owns that invisible integration, acceleration starts creating fragmentation instead of product growth.

Acceleration creates more decisions than it removes. Someone still has to connect those decisions into one coherent product.

Share

Builder PMs changed the game

Builders now spend more time validating their ideas, defining solutions and experimenting. Whether the outcome is delivered to customers or improves internal workflows, you see progress daily.

This acceleration creates coordination pressure across your product. That pressure rarely shows up as missed deadlines. It shows up as disconnected decisions.

Why fast products become fragmented

On the surface, you’re accelerating:

• Requirements

• Prototypes

• Documentation

• Analysis

The invisible integration work has become orphaned.

Most of the team is lulled into good feelings about products shipping.

Then the signs that some invisible work is missing:

• Requirements are excellent, but sales still can’t position the product.

• Teams keep discovering dependencies during implementation instead of before it.

• UX is consistent within features but inconsistent across the product.

• Every team optimizes locally while the portfolio becomes harder to understand.

• The project looks on track until late-stage integration reveals commercial or operational gaps.

If you’re new to Builder PMs, here’s the operating model: https://amycmitchell.substack.com/p/product-operating-model-product-management

If you’re wondering how product decisions become commercial products, this article on solution packaging provides additional context: https://amycmitchell.substack.com/p/builder-pm-product-context

Subscribe now

Don’t become the only integrator

The usual fix to these problems is calling you. Because cross-functional issues flow to product managers.

Even though most invisible integration problems land with product managers, that doesn’t mean product managers need to pick up integration work.

The early integration work prevents those last-minute issues that end with “call the product manager”.

But innovative product managers usually aren’t positioned to cover how a product comes together.

Invisible integration often catches preventable problems, such as:

• Pricing assumption conflicts

• Support isn’t prepared

• Onboarding that doesn’t match the workflow

• Sales can’t explain positioning

These problems are caused because no one continuously connected the pieces. Your goal is to make sure invisible integration has an owner.

Most organizations solve these problems by pulling the product manager back into coordination. That’s the wrong long-term solution.

Share

Four ways to expose invisible integration

There are a few things product managers can do to get integration owners early while staying focused on product work.

Who notices when the pieces stop fitting together

Often, the job of protecting the product is about handling risks and dependencies. But if product work is iterating rapidly, product managers are in the middle of the pieces coming together.

The thinking goes: people closest to the work know the risks and dependencies. Watching out for integration issues isn’t a priority in accelerated builder PM work.

Watch for this:

No one is asking how the changes affect sales or support of the customer journey.

Why this happens

People in the middle of product work won’t realize when pieces stop fitting together.

What to change:

Before building starts, ask “Who will notice if this change misses the mark?”

Instead of waiting for customers or stakeholders to notice a problem, you can get an owner for risks and dependencies.

Create product integration checkpoints

How your product touches sales and business operations is easy to overlook. Instead of focusing on schedules and critical paths, you can organize integration checkpoints as you build.

Typical checkpoints are:

• Early architecture review of an upcoming change - look for disconnects between business and technology

• Review commercial readiness - some teams do a walk-through of the changes in the customers’ journey

• Customer experience consistency - demo planning and demos with the cross-functional team

Watch for this:

End-stage surprises that conclude with “no one told me about this”.

Why this happens

Fast-moving teams don’t see the inconsistencies across the product.

What to change:

Pause for value-add integration check points so everyone can see the product come together.

Invite systems thinkers early

Systems thinkers recognize patterns long before specialists do. Each product team has system thinkers:

• Architects

• Program managers

• Delivery leaders

• Operations

These are the people who see around corners and don’t hold back on feedback. These systems thinkers can grasp your barely started concept and discuss risks.

Watch for this:

You are making changes, but people are too busy to give feedback.

Why this happens

“Early” doesn’t have meaning when features take days to develop.

What to change:

Bring in systems thinkers earlier than ever before to prevent problems.

Make integration visible

When people notice an integration gap and handle it, then celebrate it. There is more to your product than shipping the next feature. Delighted customers value the whole product and not one part.

Celebrate the things that make a difference to customers:

• avoided rework

• dependency discovery

• consistent customer journeys

• reusable capabilities

Watch for this:

Heroic last-minute saves before customers are affected.

Why this happens

Attention to fast customer delivery overshadows delivering an exceptional customer experience.

What to change:

Recognize the integration moments to give focus on the customer experience.

Subscribe now

Conclusion - Connecting pieces for growth

AI lets one product manager accomplish the work that once required several people.

The faster your product organization becomes, the more valuable invisible integration becomes.

Your next acceleration challenge may be ensuring someone owns integration.

Acceleration builds products. Invisible integration builds product growth.

Share

Q&A

Isn’t invisible integration just product management?

No. Product managers own product decisions. Invisible integration ensures those decisions become one coherent customer experience.

Different organizations assign that work differently.

Who usually owns invisible integration?

It depends. Sometimes: program managers, staff product managers, architects, product operations, or engineering managers.

The important part is that someone owns it.

Do program managers and project managers do this kind of work?

Yes, they are some of the key systems thinkers who work on product initiatives. Their value comes from seeing connections across teams. Fast product iteration can unintentionally bypass that perspective unless they’re involved early.

Why do product managers need to invite program and project managers to join their initiatives?

The rapid product development loops make it difficult to find an insertion point. Bringing them in early shows the bigger picture where they can contribute. Once in the product development loop, it is challenging for program/project managers to have enough background to anticipate dependencies that affect customers.

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 focuses on AI-assisted product initiatives. It helps you build context that your whole product team can use.

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 handpicks product management articles every day, summarizing them to give you the big picture of product management and technology.

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

This week’s backstory is about getting ahead of demands for “more detail”:

What Prompted This Article?

I was behind on my product work but not sure on what. It felt like this:

My boss was upset about the lack of progress on my initiative. Key stakeholders wanted details about a new concept. My boss wanted details from key partners.

In my situation, I had decisions on decisions that can skew the details.

It took pausing to write this article to figure out the pattern of the completeness trap.

The Completeness Trap is when teams replace decisions with details. It looks like this:

The article was about doing three moves to break out of the loop:

1. Shrink the problem until a decision becomes possible

2. Define constraints before expanding detail

3. Turn objections into boundaries, not blockers

It was going to take courage to put these steps into action. I was behind. My boss and stakeholders wanted more progress.

I steeled myself to handle some disagreements to reach decisions.

What Happened After This Article?

Read more

Product management has never been easier to learn.

There are books on discovery, courses on strategy, templates for PRDs, podcasts about leadership, and now AI that can explain almost any framework in seconds.

Yet many of the lessons that shape you as a product manager don’t come from any of those places.

They show up while you’re trying to solve a messy problem, wondering why an executive changed direction, watching an organization shift beneath your feet, or realizing an important insight has quietly disappeared into yesterday’s AI conversation.

After talking with product managers across different companies, one pattern keeps appearing: there is a hidden curriculum in product management. These are the lessons you recognize after you’ve had time to connect the dots.

Here are four lessons that often become obvious after you’ve built a product and looked back.

These lessons are about the habits that help you keep learning while you’re building products.

Share

Lesson 1: Your AI isn’t building your knowledge

You’ve spent a week using AI to explore competitors, summarize interviews, refine messaging, and polish an executive summary. Then someone asks, ‘Can you share the key insight?’ Suddenly, you’re scrolling through a long chat history trying to find the breakthrough you remember having.

AI doesn’t know what an insight is vs what you already know. When you learn something, capture and curate it. Your future self will thank you when you want to share it.

Preserve what matters

Strong product managers don’t confuse AI conversations with knowledge management.

They build systems that preserve the ideas they’ll need six months later.

Subscribe now

Lesson 2: Some problems can’t be shortcut

Sometimes the best learning comes from doing. Struggling with a problem teaches more than getting advice.

It’s about knowing when advice can save time and when you need to prove the advice to yourself.

• Getting key domain knowledge on your own:

  • Advice: A sales engineer tells you what customers need.

  • Learning: You personally validate how the customer problem behaves.

• Understanding your pricing structure:

  • Advice: Someone tells you the product is overpriced.

  • Learning: You calculate customer value for yourself.

The pattern to recognize is that you need time to absorb new information.

Work through the evidence

Frameworks can accelerate understanding, but some judgment only develops when you work through the evidence yourself.

Use colleagues’ advice to narrow the search space, not to skip the learning entirely.

Share

Lesson 3: Leadership rarely changes direction without changing information

Last week, the priority was locking the plan for your product initiative. This week, leadership wants help justifying the product opportunity.

A change in direction can feel abrupt when you don’t yet have the context behind it.

Over time, you look for the patterns that changed the information available to leaders. But sometimes the changes are something you can’t see.

Leadership reversals often reflect information you can’t yet see.

Stay curious about change

Some reversals are part of the iteration. Often there is no apparent reason for the change.

Learning to become curious about the change saves you from missing the mark with your product.

Subscribe now

Lesson 4: Organizations leak information before they announce it

Product managers often feel unusual signals early because they’re connected to customers, engineering, business stakeholders, and delivery teams.

When product work goes weird, possible explanations include:

• A big customer about to leave

• A financial metric change

• A strategy change

• A reorganization or merging of teams

While the pending change is outside of your control, you can control your reaction. Keep yourself from burning relationships when the craziness eventually recedes.

Stay calm during uncertainty

When you see the early signs of unexplained behavior, don’t assume everything is broken. The learning is avoiding being negative. Be the one who calmly adjusts to change.

Share

Conclusion - Being a product manager is a learning experience

Building products gives you hundreds of small experiences every week. Most feel like isolated events at the time. Only later do some of them reveal themselves as lessons.

• You’ll catch yourself preserving an AI insight because you know you’ll need it later.

• You’ll pause before assuming an executive is being inconsistent.

• You’ll give yourself permission to wrestle with a problem instead of rushing to someone else’s answer.

• You’ll recognize organizational confusion without letting it turn into cynicism.

Looking for the patterns can help you worry less about today’s confusion and pay more attention to the habits you’ll still be using years from now.

Related articles:

• Context engineering in product management

• Keeping executives involved in product work

• Learning while building products

• Handling uncertainty in product management

  ---

  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 focuses on 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 handpicks product management articles every day, summarizing them to give you the big picture of product management and technology.

  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 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.