This week’s backstory is about handling a lack of alignment:

The Risk Default Checklist (paid only) This worksheet is designed for product managers navigating competing concerns across engineering, finance, sales, or leadership — especially when no one is “wrong,” but no decision is being made.

What Prompted This Article?

My first review of the requirements was a disaster:

• The business case forecast was too high

• Not enough automation requirements

• No one could understand the ask

Second requirements review with only sales was meh:

• Need a lower price and value selling isn’t working

• Need more opportunities before features

Third requirements review with only finance was discouraging:

• New requirements must meet margin targets

• Need quote automation to reduce finance effort

These requirements are just not coming together. There is no alignment among powerful teams.

But…is alignment my problem? Yes and No.

Yes, because I have an opportunity and development can’t start.

No, because the issues are outside of my control.

I decided to try a different approach to alignment:

• consider risks

• agree on the default

I settled on three risks to explore with the product team:

After struggling to reach alignment, I was looking forward to hearing about risks from the product team.

What Happened After This Article?

Read more

This week’s backstory is about builder PM moves that work in flat organizations:

What Prompted This Article?

I’ve been fascinated by Builder PMs for a few months. Builder PMs are product managers who step out of their lane to unblock product work.

In my day job as a product manager, I’ve noticed that some product managers take on builder PM roles, while others don’t. In medium to large organizations, being a builder PM has a big learning curve:

• understanding architecture and engineering challenges

• knowledge about different marketing roles

• learning how to navigate sales incentives and operations

The problem comes while product managers work on this learning curve: they get bypassed in the fast pace of product development.

Here are a few signals that product managers are being bypassed:

I wrote this article to help technical and non-technical product managers stay involved while working on their builder PM learning curve.

3 moves to scale yourself while adapting to the fast pace:

1. Focus on dependencies that are customer visible

2. Conversations before documents

3. Learn where offers break first

I was seeing the early signals of bypass…for example, a decision from a meeting. Is the team moving fast or was I bypassed?

I planned to take these steps and trust that the team is moving independently and fast.

What Happened After This Article?

Read more

This week’s backstory is about handling AI when it touches your product:

What Prompted This Article?

I got a comment on LinkedIn from Matthew Skelton, author of Team Topologies, about product managers drifting into AI Theater instead of using AI to improve our work:

Matthew’s comment resonated because product managers are conducting high-risk product experiments with AI. The risk comes from:

• security gaps

• intellectual property exposed to competitors

• AI model mistakes

Matthew hit on another issue: AI experiments that don’t improve the outcome for the customer.

I saw this on a recent vibe coding experiment with the free resources for this newsletter. AI suggested adding alerts if the content gets older than 3 months. I almost made this code change.

Luckily, I took a break and remembered this is unnecessary.

I wrote this article to give thinking tools to product managers when AI-first overtakes our product instincts.

What Happened After This Article?

Read more

This week’s backstory is about measuring how AI sees our products:

What Prompted This Article?

“How do we know if the blog article helps?”

This is the question my boss asked me the day after he posted on the corporate blog. My boss and I knew a blog article wouldn’t lead to instant revenue. However, we both wondered about how to measure its impact.

The goal of his blog article was to build awareness of our managed services offers. We ended the conversation by looking for an increase in sales inquiries as a good indicator. The question was still open for both of us.

This conversation pushed me to explore further. I had more questions:

• Do we want human awareness or AI awareness? Both

• Is human awareness influenced by AI? Yes!

• What is attractive to AI?

  • currentness,

  • natural language matches,

  • 3rd party references,

  • ease of finding information

• How does anyone measure AI awareness?

This line of questions led to last week’s follow-up article What makes your product attractive to AI (product explainability). But I didn’t answer the question of measuring AI’s product awareness.

Measuring anything about AI is complex since the answers change frequently. I decided a system: the Product Perception Loop would help product managers measure what AI thinks about their product.

Here is the Product Perception Loop:

I tried the loop out on this newsletter (it’s a product too).

The results? AI doesn’t know about this newsletter.

I added a Q&A section to cover what I learned using the Product Perception Loop with this newsletter.

As I published the article, I still didn’t have an answer for my boss about the value of his blog article.

What Happened After This Article?

I’ve been happy to see others confirming the importance of AI’s perception of your product. With most of us using AI daily, we see how AI understands products.

What does success look like?

Read more

This week’s backstory is about putting explainability in product context:

What Prompted This Article?

Recently I asked AI about my product. The response was mostly accurate. But the answer wasn’t convincing for a potential customer.

This led to a new question:

Is there anything I can do as a product manager to “make” AI give a more appealing answer for people thinking about buying my product?

It turns out there isn’t a clear answer about improving what AI thinks about our products. And there is very little information about measuring the perception of AI over time.

When I think like AI, then I come back to product context. AI finds all the material on my product and then responds to questions.

After some research, I found this type of material is more likely to be used by AI:

• Recent stuff - material created or updated in the past month

• Outside reference - established publishers that reference your material

• Social media - Reddit and YouTube especially

Each of these items would ideally point to my product context.

But what product context matters?

The items that make a difference to potential customers are:

1. clear product positioning in product material

2. material that covers how to configure and use the product

3. showing product outcomes for customers

Here is a visual to show before and after product context explainability is added.

In my product, this information is easiest to cover in the product FAQ. I know well-established products have whitepapers to cover many of these aspects. For most product managers, there is a limited budget for whitepapers.

FAQs are usually created and maintained by product managers. After sending this article out, I focused on product context maintenance and the FAQ.

What Happened After This Article?

Read more

This week’s backstory is about the emerging trends in product management:

What Prompted This Article?

Each year, I write about the trends in product management on the first day of the year. This is the third year doing this.

I noticed these differences from a year ago:

• Fewer meetings and fewer people in the meetings - people use the AI transcriptions and shared files to contribute to product work.

• Complex topics are discussed in very small meetings - notes and follow-up fan out from the small meetings

• We’re re-thinking our product documents - we need scannable and easy-to-find documents for each task

• Single-purpose documents are gathered into product context - which helps AI and humans understand your product

And two themes are taking on new importance: business growth and working through ambiguity.

The trends this year are about how product management is changing under our feet:

1. Business growth focus is required

2. Builder product managers forge ahead

3. Business growth doesn’t mean taking on GTM

4. AI checks your product before people

5. Product managers own ambiguity

Are there any signals of these trends showing up yet?

What Happened After This Article?

Read more

This week’s backstory is about helping the GTM team:

What Prompted This Article?

This article comes from two of my favorite product managers in real-life: Vivek and Sam.

Vivek cold-called a lot of salespeople and told them about his latest product launch. His goal was to generate quick revenue. As a result of these calls, Vivek learned what was missing in his product. No revenue came from his “dialing for dollars” play.

Sam watched Vivek’s efforts with interest. Sam’s latest launch had a lot of organic interest from sales. Orders were trickling in for Sam’s product. Sam wanted more sales.

Sam asked if he should help the GTM team, but in a different way from Vivek. Sam had the classic product manager’s dilemma: Does he help GTM or focus on the next launch?

Sam asked me about ways to help GTM. I immediately told him to focus on the next launch. It’s performance review time, and Sam needs to show product delivery.

I felt bad after this. I gave Sam the right answer but the wrong reason.

It was Sam’s question and my flawed answer that prompted this article.

The simple reason is that product managers have operational sellability steps after the launch.

What Happened After This Article?

Read more

This week’s backstory is pre-seed. pre-revenue product management:

What Prompted This Article?

I love getting product management questions on LinkedIn! This article began with this question:

I’m at a pre-seed, pre-revenue startup building our first product, so “following the money” is mostly hypothetical right now. In that kind of environment, how would you approach building a business case and “following the money” when there aren’t real deals or revenue yet? And similarly, when things are still very ambiguous, how do you like earlier-career PMs to form a strong point of view on “where to play” without a lot of historical data to lean on?

This question shows the contrast in product management at an established company and at a startup.

Beyond the obvious differences in people and budget, product managers at startups do most of their work alone.

The question became: how does a new product manager build a business case in a pre-seed startup?

I decided on a learning loop for quick discovery and experiments:

After writing the article, I met the product manager who asked the question on a video call. He writes most of the code in his product along with the founders. He has very little time to interview potential users or explore hypotheses. He was happy to know “this is normal” for product managers.

I also struggle to give time to the learning loop in my product management job. I set out to find something similar to a startup to try the learning loop.

What Happened After This Article?

Read more

This week’s backstory is about builder PMs:

What Prompted This Article?

I disagreed with some of the big product management thinkers. These influencers commented that product managers should focus on strategic functions and stop wasting time on building.

At the same time, I’m getting conflicting signals in my job:

• A respected program manager said I was “making things too complex.”

• 3rd conference call with architecture leaders on a “few questions” about automation options

• My slides on real customer use cases were rejected as “too technical” for sales training

Builder PMs seem to be controversial in the product manager community.

Concerns about builder PMs range from

• won’t scale

• breaks trust

• don’t take on extra work

I don’t agree.

Product development is moving fast. We don’t have the luxury of staying in our lane. There is no time for rework either.

This article is about bringing product information to engineering, GTM and sales ahead of being asked.

My first break from product manager influencers. Is it a mistake to become a builder PM?

What Happened After This Article?

Read more

Alignment Worksheet

This week’s backstory is part 2 on alignment:

What Prompted “Alignment Isn’t the Problem”?

I was losing sleep over my alignment problem. Multiple meetings with Sales, Finance, Engineering, my boss and peer product managers without agreement.

• First pass: problem and high-level solution

  • Feedback: Too much detail; need to understand concept

• Second Pass: Traditional concept and “what we need to win”

  • Feedback: Not enough detail. Show examples.

I needed to find a way to stop the bouncing and get these powerful teams aligned. The pressure was increasing from the product team, which was waiting for requirements. (Well, not really waiting; they were working on lower-priority items.)

Once I stopped beating myself up about the lack of alignment, I started thinking about worst-case scenarios. And then I remembered that I never got opinions on the risks of moving ahead. What was everyone so worried about?

This led to 3 steps to unblock alignment:

• First, stop debating proposals and ask what failure each stakeholder is trying to prevent. Most disagreements make sense once you name the risk behind them.

• Second, ask which failure would be worse. Which downside the organization is more willing to live with.

• Third, clarify where judgment should live by default. Should most cases flow automatically, or should humans intervene unless conditions are clearly safe?

Can talking about risks and default handling get alignment when persuasion didn’t work?

What Happened After This Article?

Read more

This week’s backstory is about context engineering for product managers:

What Prompted This Article?

This article started with a poll on LinkedIn about behind-the-scenes work, such as a product ordering guide, AI context, and product knowledge base upkeep. Over 80% of the respondents are seeing an increase.

The funny thing is, no one is talking about how they keep all this product context updated and usable. Many product people talk about the importance of product context for product work with AI.

The reality is that this product context goes out of date almost as soon as you save it. Plus, I always have something new coming: features, fixes, and enhancements.

An accurate and up-to-date product context is key to growth. But in today’s fast-paced products, I can’t ask for a timeout to pull together a product context system.

I wrote about the steps to ease into a starter product context that can grow over time:

1. Create a single source of truth in a shared space

2. add some structure such as release notes

3. review the structure periodically to keep it fresh

4. add AI assistance to begin automation

5. focus on what people use for maintenance

Here is a summary:

I figured no one in my product team would care about the product context. Which meant I didn’t need to get fancy about it. I expected to be the biggest user of the product context.

What Happened After This Article?

Read more

New for paid subscribers: Staying AI-First 6 examples of AI work using product principles. It provides product practices you can do now to match outcomes to your AI experiments.

This week’s backstory is about agency as a product manager:

What Prompted This Article?

Tim transitioned from market analyst to product management. His first job in product management was interviewing customers about their data center environment.

Tim obtained a list of customers who were willing to speak with employees and help improve products. Tim emailed them asking about a time to speak further.

Tim didn’t get any response to that email.

By the time Tim contacted me about his problem, he almost believed his boss needed to make the customers meet with him.

I pulled in another product manager to help Tim set up an interview system that resulted in customers speaking with him.

Tim’s struggle reminded me that we often need to handle ambiguous projects that seem impossible.

While I watched Tim land his interviews, I was quietly dealing with my boss getting frustrated that “he has to help me shape the executive narrative” for the next product release. I almost made excuses that my boss hadn’t set a clear direction.

I wrote this article to help myself and other product managers in turning ambiguous goals into a system that makes progress:

I could see the email system helping Tim and I was looking forward to developing a system to handle my executive narrative problem.

What Happened After This Article?

Read more

This week’s backstory is about handling big themes like AI, modernization and transformation as a product manager:

What Prompted This Article?

The big themes in this article (AI, modernization, transformation and automation) hit me from several directions in one week:

• All-hands meeting where senior leaders encouraged modernization through AI usage and automation.

• Ping from boss that I need to take mandatory agentic AI training.

• A key business operations team can’t work on my feature until they see the path to an internal transformation initiative.

Of course, I still need to drive new launches and incorporate these big themes in my product.

Is this something only happening in my organization or is it happening to product managers everywhere? After a few checks, the answer: this is happening to product managers frequently.

These big themes need a long-term approach to product management. I can’t do a simple change for these themes. My cross-functional teams have new requirements, too.

I defined three activities to make tangible progress on big themes over time:

1. Architectural alignment - to centralize today’s solution structure and agreement on steps to update

2. Incremental automation - steps to automation through AI and new automation tools

3. Platform maturity - phasing for scale and growth for monetization and sales enablement

With all the swirl around these themes, would focusing on architecture, automation steps and maturity models be helpful? Or does this delay making critical long-term decisions?

What Happened After This Article?

Read more

This week’s backstory is surviving setbacks as a product manager:

What Prompted This Article?

The idea for this article came from a heated discussion with another product manager about product scale testing before the product has many customers. We settled on a good balance of testing.

The debate brought me back to a telecom product in a past life. This telecom product grew quickly to many customers in a short time. This product failed at several customers, leading to many call failures across the US. The outages were reported in the news.

At the time, many people on the team believed the outages would be career-limiting. All the people in the midst of the outage went on to career success. The product continued growing due to the handling of the crisis.

After going down memory lane about this outage, I remembered other career-impacting events in my product life. Here is the list of my own 9 lives in product management:

1. taking my product through end-of-life

2. surviving a major product outage

3. a sudden strategy change

4. a launch that goes nowhere

5. flatline growth

6. stakeholders who don’t trust the product team

7. a product team that doesn’t care about the product

8. merging with another team

9. a transformation initiative that deeply affects the product

Would other product managers see these events as a growth opportunity or the end of their career?

What Happened After This Article?

Read more

This week’s backstory is early learning from context engineering:

What Prompted This Article?

I had multiple demands in my product management job leading up to this article on context engineering for product managers:

• Automate workflows

• Learn AI

• Check what the internal copilot says about your product

I also read several articles about giving AI context before prompting.

This gave me the idea that I need to manage my product’s knowledge base so that AI can find the right information on my product. I wrote about what would be in an ideal Product Context:

Pulling together a product context that supports AI and humans is one thing. But developing a structure and a system to maintain it is another thing.

I wanted to try this on a small product before taking it to my “day job”. This newsletter is a safe and small product for an experiment. The product managers who read this have been very supportive.

Trying Product Context Engineering on This Newsletter

The product context of this newsletter is:

• the offer for followers, free subscribers and paid subscribers

• content with and without a paywall

• human users and AI users

• marketing on social media and Substack

There are some problems today:

• You have to hit the subscribe button to find the benefits of the offer

• AI can’t find recent information or FAQs on the product

• People have trouble finding product management information

• Some of the product management material is out of date

The steps from the article that I used:

1. Create a single source of truth or a repository of product context - in GitHub

2. Add one layer of structure - tags and versioning in one place

3. Add a review cadence - easy to check from the list of materials

4. Add an AI assist - a small script to generate a list of materials

5. Only maintain what people use - Google Analytics to monitor usage

Would these steps help solve problems with this newsletter? Is the effort worth doing?

What Happened After This Article?

I learned a few things from this experiment:

Read more

New Learning Path! Developing Standard Offers Offer definition, maturity mode and operational sellability for product managers. Version 3 of this learning path with additional examples and checklists. (paid only)

What happened after writing a recent Product Management IRL article? These insights are exclusive to premium subscribers of Product Management IRL.

This week’s backstory is about handling circular debates:

What Prompted This Article?

I was on a decision-making high after unburdening my worries and documenting decisions. I published the article on decision logs and some readers pointed out that many decisions are too complex for a decision log.

My first thought: Oh, then it is too early to decide. I almost responded to say it’s just too early.

But then I remembered my own case where a decision log wouldn’t work. I responded to the readers that I’d tackle the complex decision situation.

I’ve been in a long-standing circular debate situation with a related team in my organization.

After researching other methods to make decisions, I discovered complex decisions have layers. Below are the typical layers that apply to product management:

I tried the decision layers on a pretty typical scenario: limited engineering for a future risk. Breaking the problem into layers makes progress.

I was looking forward to trying decision layers on my own complex situation.

What Happened After This Article?

Read more

This week’s backstory is how a decision log saved time:

What Prompted This Article?

The program managers were avoiding me. My PRD was done and the requirements were assigned to each functional team.

And then silence. No questions. No updates in product team meetings.

I’d ask about a schedule risk. The response: “That’s a good question. Could you investigate?”

Due to launch requirements, I couldn’t take time to investigate. Escalation to the leadership team of peer program managers would cause more trouble.

I remembered a technique from engineering: a decision log.

I needed a decision log to get agreement that all the independent work would come together in the end.

I’ve never seen a product manager use a decision log. I adapted my old way of raising a risk to a decision log. Here is the adaptation:

I tried the decision log on two issues and my worries about those 2 risks evaporated. But the real question: Will the decisions stick?

What Happened After This Article?

Read more

This week’s backstory is about communicating with data:

What Prompted This Article?

Some of the best moments in this newsletter are when another writer offers to do an interesting guest post. approached me with a guest post idea: how to tell a narrative with data.

This topic is an area I struggle with at work. I get constant feedback to simplify my business cases and improve my executive communication.

Product managers can access more data than ever before. I lept at the opportunity to learn new tips to communicate with data from Hodman’s data scientist experience.

Hodman’s suggestions on issue trees and MECE structure will help simplify my presentations:

I had never heard of MECE before. I was looking forward to trying Hodman’s narrative tips.

What Happened After This Article?

Read more

This week’s backstory is about handling an urgent situation as a product manager:

There is a new section for paid subscribers: Behind the Scenes at Product Management IRL. This new section has short updates on what I learn as I make the newsletter content more “findable”.

What Prompted This Article?

This article came from a real situation in my product management job. “Gerry” a product manager, had a sudden change to her product initiative after a routine executive update. With this change, Gerry’s low-priority sales incentive product work was turned into an urgent end-of-year growth program.

Gerry had to quickly get agreements to launch the incentives a few days before her scheduled vacation. She wanted to enable sales through the incentive and grow her product.

To hit the urgent timeline, Gerry had to cut corners. I was most impressed with how Gerry recovered after she returned from vacation. Most product managers would move on to the next thing.

Gerry took these steps to recover:

I wrote this article after watching Gerry go through these steps. What would be the long-term impact of Gerry’s handling?

What Happened After This Article?

Read more

This week’s backstory is about adding inspiration to orchestration:

What Prompted This Article?

My VP is not happy with our readout on the product release plan. He thinks the business case forecast isn’t supported with real data. Why is he doing an executive roadshow now when the release is months away? Doesn’t the team understand the pressure to accelerate?

My boss and others explained that it is hard to bring the product to market. Touching 1000s of product configurations with our new offer takes time.

Of course, the VP would have none of these excuses. He won’t approve going forward until the release is pulled in.

Now comes the really shocking part of this story. No one followed up. The reaction was “meh”…the VP doesn’t understand.

Slowly, my team replanned and got a partial release approved by the VP.

In the midst of the replanning, I couldn’t figure out why orchestration wasn’t working. I was worried the VP would give up on our product release. Why was I the only one worrying about accelerating the release?

After researching this question, I realized inspiration was missing from my orchestration efforts. I wrote this article to provide 5 strategies to bring back inspiration:

• Setting out with purpose

• Translating into shared benefits

• Communicating early success

• Inviting contribution

• Storytelling urgency

Even though I felt like pointing out the orchestration plan would get the release done, I tried inspiration instead.

What Happened After This Article?

Read more