First PM presents her quarter. 11 features shipped. New recommendation engine. Redesigned onboarding. Push notification system. Loyalty points. Saved addresses. Dark mode. Quick reorder. Referral program. Three more I can’t remember. The slide has a long list and a big number at the top.

Applause. “Great velocity.” 👏

Second PM presents. 2 features shipped. One: a simplified checkout that reduced cart abandonment by 18%. Two: a reorder flow that increased order frequency by 23% in the test group.

Polite nods. “Anything else in the pipeline?” 👀

Here’s the thing.

The first PM shipped 11 features. Nine of them have less than 5% adoption. Two of them created support tickets. One conflicts with a feature another team shipped the same quarter.

Total business impact: unclear and probably negative when you count the maintenance cost.

The second PM shipped 2 features. Both moved a KR. Both have clean adoption curves. Both are low-maintenance because they were tested and iterated before launch.

Who’s the better PM?

You already know the answer. But your org probably rewards the first one.

Shipping Is No Longer the Bottleneck

There was a time when shipping was hard where engineering cycles were scarce, and getting something from idea to production took months - Do you remember?!.

The PM who could ship more was, by definition, creating more value. Because the constraint was output.

AI broke that constraint.

When a PM can prototype in an afternoon. When an engineer can build a tested feature in days instead of sprints. When the cost of “let’s just ship it and see” approaches zero. The bottleneck moves.

The bottleneck is no longer “can we build this?” It’s “should we build this?”

And most PMs haven’t made that shift. They’re still optimizing for velocity. Shipping more features. Filling the change-log. Counting releases.

But when building is cheap, shipping is not the signal because shipping the right thing is the signal. And shipping the wrong thing is now cheaper to do, which means it happens more often, which means the cost of bad decisions compounds faster than ever.

Think about the Real Cost of Shipping

Every feature you ship has a price tag (RCS) that extends far past the build.

Adding a feature is easy but removing one is nearly impossible.
Every feature is a one-way door disguised as a two-way door.

The PM who ships 11 features just added 11 lines to the maintenance budget. 11 sources of support tickets. 11 things that can conflict with future features. 11 things that make the product slightly harder to understand.

That’s a culture problem, not a PM problem.
But the best PMs fight that culture anyway.

What the Best PMs Do Instead

The PM who ships 2 features and moves 2 KRs didn’t get lucky. She followed a different process.

1. She killed ideas early.

Before anything got to a sprint, she ran it through a 48-hour validation. Prototype or fake door test. If users didn’t engage, the idea died on Wednesday, not after 3 sprints of eng time.

Most PMs validate ideas after building them. That’s like checking if someone wants to buy your house after you’ve already built it.

2. She defined “done” as impact, not deployment.

“Shipped” isn’t done. “Users changed their behavior” is done. The checkout simplification wasn’t marked complete when it hit production. It was marked complete when cart abandonment dropped 18% and held for 4 weeks.

This changes how you scope features. When “done” is a metric, you build the minimum thing that moves the metric. Not the maximum thing your engineer is excited about.

3. She said no and explained why.

Her stakeholders brought her 14 feature requests that quarter. She built 2. But she didn’t ignore the other 12. She responded to each one with data: “We tested a version of this. Here’s what happened. Here’s why it didn’t make the cut.” That’s harder than saying yes. And it builds more trust.

4. She measured the features she didn’t ship.

The requests she killed? She tracked what happened without them. Did the problem get worse? Did customers churn because of the gap? Did a competitor ship it and win users?

In 11 out of 12 cases: nothing happened. The feature nobody built was the feature nobody missed and this data reinforced her judgment for next quarter.

Restraint Filters

A simple tool for deciding what not to ship. Before any feature makes it to a sprint, run it through these 4 filters.

Filter 1: Behavior Test
“Will this change user behavior, or just add a capability?”

Adding a “share” button adds a capability. But if nobody shares, it just adds a button. The question isn’t “can users do this?” It’s “will users do this?” If you can’t articulate which user, in which context, would use this feature every week, it probably shouldn’t exist.

Filter 2: Removal Test
“If we shipped this and removed it 3 months later, would anyone notice?”

Please Pls Pls Be honest. Most features would disappear without a single support ticket. If the answer is “nobody would notice,” you just answered whether it should be built.

Filter 3: Maintenance Test
“Am I willing to maintain this for 3 years?”

Because that’s roughly how long features live. You’re not deciding to build a feature. You’re deciding to support a feature for 3 years. Does it still feel worth it?

Filter 4: Metric Test
“Which KR does this move, and by how much?”

If a feature doesn’t connect to a KR, it shouldn’t be in the sprint. If it connects to a KR but you can’t estimate the impact, you need to validate before building. “It might help retention” is not a product strategy. “We tested it and it improved 7-day retention by 4% in the test group” is.

Any feature that fails 2 or more of these filters gets killed. Not backlogged. Killed.

Common Mistake PMs Make, We All DO

Measuring themselves by output instead of outcome.

It’s natural. Output is visible. You can count features. You can list them on a slide. You can point to the changelog and say “look how much we shipped.”

Outcomes are harder to see and they take time to materialize. And they require you to admit that some of what you shipped didn’t matter.

But the PM who ships 2 things that work will always beat the PM who ships 11 things that exist. “Exist” is not a product strategy. “Works” is.

AI made it possible to ship more features than ever. It also made it possible to validate, test, and kill ideas faster than ever. The PMs who use AI to ship more will lose to the PMs who use AI to decide better.

The Line I Want You to Remember

When building is free, the scarce resource isn’t engineering time: It’s user attention.

Every feature you ship asks users to notice it, learn it, and decide whether to use it. Their attention is finite. Your feature list is not. That math only works if most of what you ship earns that attention.

The PM who ships nothing and learns everything will outperform the PM who ships everything and learns nothing. Not because shipping is bad. But because shipping without learning is waste. And waste, no matter how fast you produce it, is still waste.

If this made you look at your feature velocity differently, share it with a PM who’s about to present a slide with 15 features shipped and zero metrics moved.

Subscribe now

Have you ever worked with a PM who was completely wrong about everything and completely sure they weren’t?

Yeah. We all have. The uncomfortable follow-up question is: have you ever been that PM?

There’s a piece of ancient wisdom that has survived centuries because it cuts straight to the bone of human self-awareness:

Men are four:

1/ A man who knows and knows that he knows; he is wise, so follow him.

2/ A man who knows but doesn’t know that he knows; he is asleep, so wake him.

3/ A man who doesn’t know and knows that he doesn’t know; he is ignorant, so teach him.

4/ And a man who doesn’t know and doesn’t know that he doesn’t know; he is a fool, so avoid him.

I’ve spent years working with product teams across multiple companies and markets. And I can tell you with full confidence: every product manager I’ve ever met fits cleanly into one of these four categories.

The scary part? Most of us have been all four at different points in our careers.

Subscribe now

A Wise PM; Knows and Knows It

This is the PM who has earned their confidence. They’ve shipped real products, taken real losses, and built mental models that actually predict outcomes. They don’t just know what to do — they know why it works, and they can teach it.

You recognise them instantly. When they walk into a room with a problem, they ask the right question before anyone else has finished reading the brief. They’re not the loudest voice, however they’re the most listened-to one.

If you’re lucky enough to work with one, stop talking and start absorbing.

A Sleeping PM; Knows But Doesn’t Know It

This one is fascinating and often tragic. They’ve built real skills ( not Claude Skills ;) ), shipped real things, developed genuine product instincts but somewhere along the way, they stopped trusting themselves.

Maybe a bad boss crushed their confidence. Maybe a failed launch broke their conviction. Maybe they’re just chronically humble in a world that mistakes loudness for competence.

The sleeping PM is often the most underrated person on any team. They’re sitting on gold they think is dirt.

If you manage one, your job is simple: create the conditions for them to hear their own voice again. Give them a win they can’t rationalize away.

An Ignorant PM; Doesn’t Know, But Knows It

Don’t let the label fool you, this is one of the healthiest places to be. The PM who walks into a new domain and says “I don’t know this space yet, teach me” is infinitely more dangerous (in the best way) than the one who pretends they do.

Junior PMs in this category outperform senior PMs in the next category every single time. Their superpower is asking the question that everyone else is too embarrassed to ask.

Curiosity + humility + energy = a PM you build around, not just with.

A Foolish PM; Doesn’t Know, And Doesn’t Know It

Aaah! Here we are. The one nobody wants to talk about because, statistically, some of us reading this are this PM in at least one area of our work.

This is the PM who confidently defines a roadmap for a market they’ve never spoken to a real user in. The one who prioritizes based on gut feeling and calls it “product sense.” The one who dismisses data that contradicts their thesis because “the data doesn’t capture the full picture.”

The dangerous thing about this archetype isn’t incompetence but it’s the confidence that makes the incompetence invisible to everyone, including themselves.

A true quote: “Organizations don’t fail because of ignorance. They fail because of confident ignorance at the wrong level of seniority.”

So, Which One Are You?

The honest answer is: it depends on the domain, the moment, and whether you slept well last night.

The best PMs I know are obsessively self-aware about which category they’re in, for which topic, on which day. They treat self-knowledge as a live system they’re constantly updating and not a fixed identity they earned once and kept forever.

The goal isn’t to permanently become the wise PM. The goal is to always know which one you are right now, and act accordingly.

Know that you know. Know that you don’t. The rest is just execution.

23 used the word “agent.”

4 actually were!

The rest? Workflows and skills wearing agent costumes. Every team was convinced they were building the right thing. None of them had the vocabulary to question it.

Why that matters; McKinsey surveyed nearly 2,000 companies. 62% are experimenting with AI agents right now. Only 5.5% are seeing real financial returns. The other 94.5% have the budget. They have the tools. They’re building the wrong things. And they don’t know it. I’m going to give you the vocabulary that fixes this.

One Question. That’s It.

Every AI decision you’ll make as a PM comes down to this:

Who decides what to do next?

Human decides each time? Prompt. Saved instructions run on command? Skill. Fixed path across multiple tools? Workflow. AI decides, evaluates, adjusts on its own? Agent.

Four items. That’s the whole menu. You’ve been ordering from it for months. You just didn’t have the words, however you already understand all four. Deeply. Because you manage them every single week. Just not the AI versions of them.

You Already Manage All Four

Monday morning. You Slack your designer: “Hey, can you make the signup button blue?” She reads it. She does it. Done. One message, one answer.

That’s a prompt.

Customer escalation comes in. Nobody panics. There’s a playbook in Notion. Check the tier, loop in the right person, use the template, log it. Same steps every time.

That’s a skill.

Your RevOps team has a flow: lead comes in, enrich it, score it, route to sales or nurture, notify the team. Fixed path. Multiple tools. Nobody deviates.

That’s a workflow.

You hire a Head of Growth. You tell her: “We need 1,000 signups this month. Figure it out.” She tests ads. They flop. She pivots to partnerships. Works. Doubles down. You never told her how. She tried, observed, adjusted, tried again.

That loop is what makes her an agent.

See! you’ve lived all four. The AI versions work exactly the same way. The only question is whether you’re matching the right level of autonomy to the right problem.

Subscribe now

Autonomy Gap

This is where the data gets uncomfortable. Gartner predicts 40% of enterprise apps will feature AI agents by end of 2026. Great. They also predict more than 40% of those projects will be canceled by 2027. Built and killed within a year.

MIT went deeper. 95% of enterprise GenAI projects are producing no measurable financial returns within six months. Not “underwhelming returns.” No returns. And 42% of companies are now actively abandoning AI initiatives. A year ago that number was 17%.

Sorry, we’re saying it again, and will keep coming back to this: it’s not an AI problem. It’s an ordering problem.

Companies reach for agents when skills would work. Build workflows when a prompt would do. Invest six months in something that should have taken two weeks. Because nobody stopped to ask who needs to decide what.

The most expensive mistake in AI is not the wrong model. It’s the wrong level of autonomy.

McKinsey’s data backs this up. The 5.5% that ARE seeing returns? They’re 2.8x more likely to have redesigned their workflows around AI. And 3x more likely to have senior leadership owning AI decisions.

How to Pick the Right Thing

This is the part you’ll screenshot and share.

Do you have a well-defined process with known steps?

YES →

• Instructions for one task → Skill

• Steps cross multiple tools in a fixed sequence → Workflow

NO →

• Quick answer, one-off → Prompt

• Requires judgment, trial-and-error, figuring out the path → Agent. But define what it can’t do before you build what it should.

The skill vs workflow distinction trips everyone up. The gut check: a skill is one person following a playbook at their desk. A workflow is a relay race. If the process dies when you remove one tool from the chain, it’s a workflow. If it all happens in one place, it’s a skill.

$4,200 Lesson

If you imagine a team who built a fully autonomous support agent. Read the ticket, checked the account, diagnosed the issue, took action, responded. No human in the loop. Full autonomy from day one.

Worked great 85% of the time.

The other 15%? It refunded $4,200 to a customer who was asking about a feature. The agent “diagnosed” frustration as a billing issue. Autonomy without guardrails. That’s not a feature. That’s a Sev-1 waiting to happen.

Last period, we saw the incident report. The root cause was not the AI. It was the PM who chose “agent” when “workflow with a human approval step” would have been safer, cheaper, and faster to build.

This pattern is everywhere. McKinsey found the companies seeing real AI returns are 3x more likely to have built “human in the loop” validation. 65% of the top performers have it. Only 23% of everyone else.

That gap. 65% vs 23%. That’s the difference between the 5.5% and the 94.5%.

This Is Bigger Than You Think

We want to share something that changed how we think about our own career.

HBR published a piece in February 2026. Their argument: the skills companies need to drive AI adoption are product management skills. Problem definition. Tool selection. Experimentation. Workflow integration. That’s literally what we do every day.

Russell Reynolds, one of the biggest executive search firms in the world, now names “AI Product Leader” as one of three Chief AI Officer archetypes. Their words: “a strategic systems thinker who understands the business, the voice of the customer, and the functions.”

Read that again 👆. That’s a PM.

26% of organizations now have a CAIO. Two years ago it was 11%. It’s one of the fastest-growing C-suite positions in the world. And the skill set it requires? It’s yours. If you sharpen it.

The PM who understands this menu. Who can classify any initiative in 30 seconds. Who insists on guardrails before autonomy. Who starts in the Workflow Room, not the Build Room.

The Line I Want You to Remember

Everyone is incentivized to call everything an “agent.” That’s why the vocabulary is confusing. Not because the concepts are hard.

You’ve been managing all four for years. Now you have the words. Use the right one. Build the right thing.

Do this Monday: Take the AI initiative your team is building right now. Ask: who decides what to do next? If the answer doesn’t match what you’re building, you just found your problem.

On Friday: We’re publishing the implementation guide. You’ll build each concept yourself in Claude Code. Plus the GUARD framework. Five questions that scope any AI initiative in 10 minutes. And /ai-classify, a skill that classifies any AI initiative and tells you if you’re ordering the right thing.

Become A Prime Voyager

Next Tuesday: You have the vocabulary now. But sometimes AI makes you slower. The METR study tracked experienced developers using AI tools. They were 19% slower. They thought they were 24% faster. Chapter 2 introduces the Verification Tax. The framework that tells you when AI helps and when it hurts.

P.S.
This is Chapter 1 of a 14-chapter system we’re building in public. Six original frameworks. Real data. Real experiments.

Every Tuesday: one insight that changes how you think about AI.
Every Friday: the implementation plus a Claude Code skill you install and use immediately.

By Chapter 14, you’ll have a complete operating system for making AI actually work. The AI that survives Monday morning.

So I will.

The job of a product manager is not to have good ideas. It’s not to write clean PRDs. It’s not to be “the voice of the customer” or to “manage stakeholders” or whatever other soft-focus corporate language we dress this thing up in.

The job of a product manager is to be loud in rooms full of people who want you to shut up.

That’s it. That’s the whole game.

And if you’re shy, if you need to be liked, if you’d rather let your work “speak for itself,” you’re going to get steamrolled.

• Your roadmap will become a dumping ground for other people’s priorities.

• Your product will become a Frankenstein’s monster of features nobody asked for.

• And you’ll sit there wondering why your “great ideas” never ship.

Your work does not speak for itself. It has no mouth. You are the mouth. And if you don’t open it, someone else will speak for you. Someone who isn’t you, doesn’t know your users, and definitely doesn’t care about your roadmap.

Huge Myth of the “Collaborative” PM

The lie we tell ourselves: “I don’t need to be aggressive. I can be a collaborative PM. I build consensus. I bring people along.”

I/We believed this. For years. And it cost all of us.

Here’s what “collaborative” actually means in most organizations: you spend three months fighting for alignment, getting everyone to nod along in meetings, feeling really good about your process. And then one executive walks into a room, overturns your entire roadmap in seven minutes, and walks out to catch a flight.

Collaboration doesn’t mean being agreeable. Collaboration means fighting for your perspective until the decision is made, then committing to execution. The “fighting” part is where most PMs go quiet. And that silence is career suicide.

Three Rooms Where Shy PMs Die

There are specific moments in product work where the difference between a mediocre PM and a great one comes down to one question: Did you open your mouth?

Room #1: Roadmap Review

This is the room where your product lives or dies. Executives, senior leadership, cross-functional stakeholders. Everyone has opinions. Everyone has their pet project. And your roadmap is sitting on the table like fresh meat.

And what happens to shy PMs: They present the roadmap. They get questioned. They get defensive. They start negotiating. They add “just one more thing” because a VP asked. Then another. Then another.

They leave with a roadmap that belongs to everyone and no one. A political compromise that guarantees mediocrity.

Your Job: Walk into that room knowing exactly what you’re willing to die on and what you’re willing to sacrifice. And when someone pushes on something core, you don’t be quiet. You say: “That’s not on the roadmap, and here’s why. If we add it, we cut this. Those are the trade-offs. What’s your call?”

You’re not asking permission, however you’re forcing a decision.

Really that’s a big difference.

Room #2: Engineering Sync

Most PMs treat engineering like a restaurant. You submit an order, you wait, you get a dish. Maybe it’s good, maybe it’s not.

This is a disaster - and bad product thinking!

Your relationship with engineering is the engine of your entire job. And if you’re shy about it, if you let engineers make product decisions because you “trust them” or because you “don’t want to be that PM,” you’ve abdicated the throne.

Your Job: Be in their business. Not micromanaging. Not speccing every button. But deeply, annoyingly, persistently in their business. Ask why decisions were made. Challenge assumptions. Push back on scope changes that weren’t discussed. Call out when something doesn’t match the spec.

This will feel uncomfortable. Do it anyway.

Engineers respect PMs who know what they want and fight for it. They lose respect for PMs who say “whatever you think is best” because they’re too scared to have an opinion.

Room #3: Exec Standup

This is the room where careers are made. Five minutes. One slide. The CEO/CPO/SVP wants to know what’s happening.

Shy PMs bury themselves in data. They hedge. They say things like “we’re still gathering learnings” and “we’re seeing mixed signals” because they don’t want to be wrong.

Your Job: Walk in with a point of view. Not a guess please. A point of view. “We’re seeing X, I believe it means Y, and here’s what we’re doing about it.” If you’re wrong, you’ll learn. If you’re right, you’ve just become the person who sees around corners.

PMs who get promoted are not the ones who avoid being wrong. They’re the ones who are willing to be wrong loudly, learn quickly, and course-correct visibly.

Subscribe now

Productive Rudeness: Top Skill

Not cruelty. Not arrogance. Not bulldozing people for the sake of ego.

Productive rudeness is the willingness to say the thing that needs to be said, even when it makes you unpopular.

It’s interrupting a meeting that’s going off the rails: “I need to pull us back. We’ve drifted from the decision. What’s the ask here?”

It’s challenging a stakeholder directly: “I hear your request, but I need to push back. This doesn’t solve a user problem we’ve validated.”

It’s naming the elephant: “We’ve been in this meeting for 45 minutes avoiding the real question. Let me ask it: Are we killing this project or not?”

Shy PMs don’t do this. They sit quietly. They let the meeting drift. They wait for someone else to say the hard thing. And then they complain in Slack afterward about how “that meeting was a waste of time.”

You are the meeting. If the meeting was a waste of time, you were a waste of time.

Confusing Kindness with Silence: A Trap

I’m not telling you to be an asshole. The best PMs I know are deeply empathetic, incredibly kind, and genuinely beloved by their teams.

But they are not silent.

And the trap: we conflate kindness with not making waves. We think that being a “good collaborator” means agreeing, smoothing things over, avoiding friction.

• Real kindness is telling an engineer their technical approach won’t scale before they waste three sprints building it.

• Real kindness is telling a designer that the user research doesn’t support their direction before they invest a month in high-fidelity mocks.

• Real kindness is telling leadership that the strategy is flawed before the company burns through a quarter of runway.

That kindness is uncomfortable. It requires you to say things that people don’t want to hear. It requires you to be the villain in a meeting so you can be a hero in the outcome.

Shy PMs avoid this discomfort. And they pay for it in failed launches, wasted effort, and the slow death of user trust.

“Visibility”: It is the truth of the job

Nobody will admit this out loud: Product management is a performance.

Not in the shallow, self-promotional sense. In the literal sense. Your job is to perform conviction. Your job is to perform leadership in rooms full of people with competing interests who all want to do their own thing.

If no one sees you do this, it didn’t happen.

How many brilliant PMs around us (maybe incl. you) get passed over for promotion because they did everything right, quietly. They built conviction in DMs. They won alignment in 1:1s. They solved problems before meetings so the meetings were “smooth.”

And then someone louder, with half the skill, stood up in a room, said something obvious, and got the credit.

This isn’t fair. It’s also reality.

Your Job: Stop hiding. If you won the room in a 1:1, win it again publicly so leadership sees it happen. If you solved a problem, tell the story of how it got solved. If you made a hard call, make that call visible.

This isn’t self-promotion, I name it leadership. The difference is intent: Are you making noise so people see you, or so people see the work? One is ego. One is strategy.

Proactive PM: It is a tactic of being LOUD

In fact, what separates good PMs from great ones. It’s not just being loud when challenged.

It’s being loud before the challenge arrives.

A great PM doesn’t wait for the exec standup to form a point of view. They already have one and they’ve already circulated it. They don’t wait for the roadmap review to surface a trade-off. They surface it two weeks early, in writing, so they control the framing.

A reactive PM responds when cornered. A proactive PM sets the agenda.

If you’re waiting to be asked, you’ve already lost the room. The PM worth promoting is the one who showed up with a position before anyone thought to request one.

A Real Test for You

Do it this week if you’ve time.

Go back to the last three meetings where a decision was made that you disagreed with. Ask yourself:

1. Did I say anything?

2. Did I push back?

3. Did I make my case?

4. Or did I sit silently and complain later?

Now look at your calendar for next week. Find the meeting where you know something needs to be said, something uncomfortable, something that might make you unpopular.

Say it.

Not aggressively. Not rudely. But clearly, directly, and without hedge.

Watch what happens. Either you’ll be right and you’ll change the outcome, or you’ll be wrong and you’ll learn something. Either way, you’ll have done your job.

Because the reality after all these years with product management: It is not a quiet profession. It’s not a job for people who want to sit in the back and do good work and hope someone notices.

It’s a job for people who are willing to be wrong out loud.

It’s a job for people who fight for their users, their roadmap, and their conviction in rooms where fighting is uncomfortable.

It’s a job for people who understand that the only thing worse than saying something stupid is saying nothing at all.

So open your mouth.

Next Round

How to be loud with AI and in the era of AI Agents. Can you even do that?

Subscribe now

“Sure, I’ll have ChatGPT take a first pass at that.”

That sentence is the sound of you willingly training your own replacement. It’s the sound of you handing over the keys to the kingdom, but with the whimper of a thousand lazy prompts.

We’ve been so obsessed with the question of whether AI will take our jobs that we’ve missed the far more important one: Is AI making us better, or is it just making us faster at being mediocre?

The answer to this question defines your next decade. It’s a choice, and you’re making it with every query you type. Are you going to be the person who operates the machine, or the person whose thinking the machine can’t replicate?

Are you going to AI, or is AI going to you?

Subscribe now

New Performance Review: AI Turing Test

Forget your quarterly goals. Forget your 360 reviews. Here’s the only performance review that matters now.

Take the last strategy doc you wrote. The last email to a client. The last piece of code you committed. Put it on a screen. Now, open a new window and spend ten minutes writing a good prompt to have an AI generate the same thing.

Place them side-by-side.

Now, be brutally honest with yourself: If you showed these two documents to your boss, could they reliably tell which one you wrote? Could your team? Could your customers?

If the answer is “no,” or even a hesitant “maybe,” you are already obsolete. You just haven’t been fired yet.

When your unique professional contribution becomes indistinguishable from a machine’s derivative output, your value is zero. You’re a commodity. A prompt-follower. A fleshy interface for the API. And commodities are always replaced by a cheaper, faster alternative.

2 Paths: A Choice Between Leverage and Redundancy

Every time you open an AI tool, you’re standing at a fork in the road.

Path #1: You are being AI’d.

This is the path of least resistance. The path of efficiency. Your goal is to get the task done.

Your prompts sound like this:

• “Summarize this meeting transcript.”

• “Write a marketing email for the new product launch.”

• “Give me 5 ideas for a blog post about productivity.”

You’ve asked the AI to do your job for you. You’ve outsourced the thinking.

The result is a generic, soulless, C+ output that’s “good enough.” You’ve saved an hour. But what you’ve lost is an opportunity to think, to synthesize, to create a unique point of view. You’re not building a skill; you’re eroding one. You’re becoming the manager of a very capable intern, and your only real value is knowing the intern’s name.

Path #2: You AI-ing.

This is the path of agency. The path of amplification. Your goal isn’t to get the task done; it’s to arrive at a better, non-obvious answer.

Your prompts sound like this:

• “Act as a panel of my five sharpest critics: a skeptical CFO, a cynical engineer, a demanding customer, a visionary futurist, and a pragmatic CEO. Here is my strategy document. Each of you, tear it apart from your unique perspective.”

• “Generate 10 radically different business models for this product. Three must be illegal or impossible in today’s market. Three must be based on business models from the 18th century. The rest are up to you. I want to break my own thinking.”

• “Simulate a board meeting where I present this plan. You are three board members who have just seen a competitor’s product that is twice as good and half the price. What are the three questions that make me sweat?”

You haven’t asked the AI to do your job. You’ve commanded it to build you a cognitive gym. You are using it to pressure-test your ideas, to simulate futures, to make your own thinking more resilient. You’re not outsourcing the work; you’re scaling your intellect.

Subscribe now

Playbook: From Prompting to Architecting

This isn’t an abstract choice. It’s a ladder of skill, and you need to be consciously climbing it.

Level 1: AI Intern. You give it simple, task-based commands. “Write,” “summarize,” “list.” This is the danger zone. The more time you spend here, the faster your own skills atrophy.

Level 2: AI Analyst. You ask it to synthesize data, find patterns, and create first drafts. “Analyze this data and tell me the three most surprising correlations.” “Take these raw notes and structure them into a coherent proposal.” This is better, but it’s still passive.

Level 3: AI Sparring Partner. You use it to challenge you. You feed it your ideas and ask it to find the flaws. “Here’s my argument. What is the strongest possible counter-argument?” This is where real value creation begins. You are using the machine to sharpen your own mind.

Level 4: AI Simulator. You use it to model complex systems and explore possibilities. You architect worlds for it to inhabit. “Simulate a market with three competing products. Here are their specs and marketing strategies. Run a thousand rounds and tell me who wins and why.” This is the future of strategy. You’re not just thinking about the future; you’re building a laboratory to test it.

IC’s Playbook: How to Not Get AI’d

As an individual contributor, the pressure is to be faster. Your boss might even be the one asking you to “just use AI.” Your job is to resist the siren song of mediocrity and actively demonstrate that your value isn’t your output but it’s your thinking.

1. Show Your Work.

Never present an AI-generated artifact as a finished product. Present it as a starting point.

Don’t say: “Here’s the new marketing copy.”

Do say: “The AI generated five initial concepts. I’ve discarded the first four because they were generic. The fifth one had an interesting kernel of an idea, …”

You’re not showing them what you made; you’re showing them how you thought.

2. Become a “Prompt Architect.”

The new senior IC is the one who can build the best cognitive gym. Share your powerful, thought-provoking prompts with the team.

Don’t just share the answer. Share the question that got you there. When you share a great prompt, you’re signaling that you’re not just a task-doer; you’re the one who knows how to ask the right questions.

3. Use AI to Go Upstream.

When you’re asked to do a task, use AI to challenge the premise of the task itself.

The ask: “We need to write a requirement document about our new feature.”

Your process: Go to your AI sparring partner. “Our goal is to increase user adoption of this feature. What are nine other, more creative tactics we could use to achieve this goal? Think about channels we’ve never used before.”

You’ve just elevated your work from execution to strategy.

A Question for Leaders: Are You Building a Team or a Prompt Farm?

You think your job is to encourage your team to use AI. You’re wrong.

Your job is to stop them from using it badly. Your job is to elevate their taste and their critical thinking so they can distinguish between derivative garbage and genuine insight.

Stop asking your team, “What did you produce?” The artifact is irrelevant if it was generated in 30 seconds.

Start asking them:

• “What were the five worst ideas the AI gave you before you got to this one?”

• “What was the most challenging question you asked the AI?”

• “Show me the prompt that led to a surprising insight.”

You need to reward the quality of the thinking, not the speed of the output. If you don’t, you’re not building a team of strategic thinkers. You’re managing a prompt farm, and your company’s intellectual property is now just a folder of clever `.txt` files.

3 Traps AI Will Set For Your Career

This isn’t just about good habits. It’s about avoiding career-ending traps. AI is a powerful tool, but it’s also a trickster. It sets traps that look like shortcuts.

1. Taste Trap.

AI has no taste. It is a brilliant synthesizer of the average. It can tell you what is popular, but it cannot tell you what is good exactly for your work. It can write a song that sounds like The Beatles, but it could never have been The Beatles. If you rely on it for creative, strategic, or branding decisions, you are outsourcing your taste.

2. Conviction Trap.

AI is a confidence machine. It presents its answers with absolute authority, even when they are completely, catastrophically wrong. It doesn’t say “I’m not sure.” It hallucinates with perfect grammar. If you stop fact-checking it, if you stop pressure-testing its assumptions, you will eventually present a beautiful, confident, and utterly false piece of work that will destroy your credibility.

3. Stagnation Trap.

The most seductive trap of all is using AI to make your current job easier. You become incredibly efficient at doing the things you already do. But you stop learning. You stop stretching. You’re so busy optimizing your current workflow that you don’t see that the workflow itself is about to become obsolete.

Your Choice At The End

The battle for your career won’t be fought against a machine. It will be fought inside your own head between being efficient or knowing your only real value lies in being original.

You can be the person who gets answers from the machine, or you can be the person the machine can’t answer without.

One is a career. The other is a temporary job.
So, who is it going to be? You AI, or AI you?

Become A Prime Voyager to AI :)

If you’ve been in a leadership role for more than a few months, you’ve said it. And if you’re an IC, you’ve had it said to you. It’s the verbal escape hatch we pull when a debate has gone on too long, when consensus is a fantasy, and when the meeting needs to end so people can get back to work.

We treat it like a magic wand. Wave it, and all the tension, all the counter-arguments, all the gut feelings that we’re marching off a cliff... they’re supposed to just disappear. The team is supposed to fall in line, united in execution, even if they were at each other’s throats five minutes earlier.

What a convenient lie.

Most of the time, when a leader says “disagree and commit,” what they really mean is, “I’m done listening, now shut up and do your job.”

And the team’s “commitment” is a thin veneer over a toxic sludge of resentment, silent sabotage, and a resume that’s getting a quiet update on LinkedIn that night. We’ve taken a powerful principle for high-velocity teams and turned it into corporate jargon for “because I said so.”

This isn’t a tool for ending a debate. It’s a pact. And if you don’t understand the rules of that pact, you’re not leading; you’re just dictating.

Subscribe now

Two Conversations You’re Having

Every hard decision is actually two separate conversations, happening at the same time.

Conversation #1: The Disagreement. This is the intellectual debate. It’s about the market, the data, the user, the technical constraints and sometimes we name it “politics“. It’s a search for the “right” answer. This conversation is loud, messy, and full of friction. It’s where the best ideas are forged and the dumbest ones are killed.

Conversation #2: The Commitment. This is the social contract. It’s about trust, psychological safety, and shared ownership. It’s a search for alignment, not agreement. This conversation is often silent, but it’s the one that actually determines whether a project succeeds or fails.

The mistake most leaders make is thinking that winning Conversation #1 is the goal. They think their job is to have the best idea, to convince the skeptics, to get everyone to nod.

But the real job is to ace Conversation #2.

Because a team that is 70% aligned on the plan but 100% committed to each other will run circles around a team that is 100% aligned on a plan but is secretly at war with itself.

Leader’s Job: Earn the Commit

You don’t get to ask for commitment. You have to earn it. And you earn it during the disagreement, not after it.

If you want the right to ask your team to go all-in on a decision they think is wrong, you have to pay a price. That price is creating an environment where they believe their dissent was genuinely heard, respected, and considered.

Here’s how you pay it:

1. You Go First.

The meeting starts. You lay out the decision. Before you make your case, you actively try to kill your own idea.

“The plan I’m proposing: Now, let me tell you the three biggest reasons it might fail. I’m worried about X, I’m not sure we’ve considered Y, and our competitor could kill us with Z. What am I missing? What’s the argument against this?”

This isn’t a trick. You are signaling that your ego is not attached to this plan. You are giving everyone in the room permission to attack the idea without attacking you.

2. You Amplify the Dissenters.

When someone raises a counterpoint, you don’t rebut it. You reward it. You turn to the rest of the room and you amplify the criticism.

“That’s a great point. Sarah’s worried that the performance cost of this feature will kill engagement. Let’s really sit with that. Who else shares that concern? What data do we have that supports Sarah’s argument?”

You are now the advocate for the opposing view. You are demonstrating that you are not just listening; you are thinking with them. The trust in the room skyrockets.

3. You Decide, and You Take the Hit.

The debate is over. You’ve heard all the angles. Now you have to make a call. This is the moment of truth. You don’t pretend there’s consensus. You acknowledge the divide.

“Okay, I’ve heard the arguments. Sarah and Tom, I understand your concerns about performance. You might be right. But I’ve decided we’re going to take this risk, and here’s why... My core assumption is that the value of the feature will outweigh the performance hit for our power users. This is my call. If this fails, it’s on me. My neck is on the line. Now, what does everyone need to make this succeed?”

You have just done three critical things:

• You made the dissenters feel heard by explicitly naming their objection.

• You explained the why behind your decision.

• You took sole accountability for the outcome, releasing the team from the fear of being blamed if it fails.

Now, and only now, have you earned the right to say, “I need you to commit.”

IC’s Job: Disagree Cleanly, Commit Fully

If you’re an Individual Contributor, your responsibility is just as great. Your job is not to win the argument. Your job is to improve the decision.

That means learning how to disagree in a way that helps, not hinders.

1. Argue with Data, Not Adjectives.

“This design is bad” is useless feedback. It’s an opinion, and it forces a defensive reaction.

“This design requires three taps to complete the core action. Our data shows a 50% drop-off for every tap after the first. I’m concerned this will kill the conversion rate” is a scalpel. It’s an argument based on shared reality. It’s not personal. It’s about the user.

2. State Your Case Once, with Conviction.

Make your argument → Bring your data → Tell your story → Make sure it’s heard.

And then... let it go. Your obligation is to get the information on the table. It is not to filibuster until you get your way. If you’ve made your case and the decision-maker still goes the other way, repeating your point with more adverbs isn’t productive disagreement. It’s ego.

3. Your “Commit” Must Be Louder Than Your “Disagree.”

When the call is made, you have a choice. You can go silent, arms crossed, and do the bare minimum. This is malicious compliance. It’s poison for the team.

Or, you can commit. And that commitment must be visible and vocal. You turn to the leader and say, “Okay, I’m in. What’s the first thing I can do to help us win?” You say it in the meeting. You say it on Slack. When your work buddy complains about the decision later, you say, “I had the same concerns, but the call has been made. Our job now is to make it work.”

This isn’t being two-faced. This is being a professional. You are separating your intellectual opinion from your professional commitment to the team’s success. Your leader will notice. And your currency in every future debate will skyrocket.

Subscribe now

Senior-Level Sacrifice Play

But what happens when you’re not an IC arguing with your boss? What happens when you’re in a room full of leaders, and the group agrees on a “big picture” move that you know will be a tactical nightmare?

The strategy is sound, but the execution plan is a fantasy. You see the hidden costs, the downstream chaos, the burnout on the horizon. If you just “commit,” you’re complicit in the inevitable mess. If you don’t commit, you look like you’re not a team player.

This is the senior-level version of the game. Your job isn’t to block the decision; it’s to force a clear-eyed acknowledgment of its true cost.

1. Reframe the Disagreement: From “Bad Idea” to “Expensive Idea”

Don’t argue against the strategy. Argue for a realistic budget and not just in money, but in time, focus, and team morale.

Don’t say: “This plan will never work.”

Do say: “I agree that this is the right strategic direction. To get there, the plan as written will cost us an estimated 800 engineering hours in unplanned work and will delay the launch of Project Atlas by at least one quarter. My question for the group is: are we willing to pay that price? Is this move more important than Project Atlas?”

You’ve shifted the debate from a subjective “good vs. bad” to an objective discussion of trade-offs.

2. Propose a “Commitment Contract”

When it’s clear the group is moving forward, your next move is to define the terms of your commitment. You make the “if” explicit.

Don’t say: “Fine, we’ll do it, but this is going to be a mess.”

Do say: “Okay, I’m ready to commit to this. If we are all agreeing that this is the #1 priority, then I need our public agreement that we are officially de-prioritizing Atlas and I have the authority to pull my best two engineers off of it to put them on this. Can we all commit to that support right now?”

This does two things:

• It makes the consequences real and immediate for everyone, not just a problem for your team later.

• It transforms your commitment from a passive surrender into an active, negotiated pact.

3. Commit, then Document the Sacrifice.

Once the terms are agreed upon, you commit 100%. And then you immediately send a follow-up email to the group.

This is creating accountability and you are holding the leadership group to the sacrifice they agreed to make.

When other leaders inevitably ask in two months, “What’s the status of Project Atlas?”, the answer is clear, documented, and owned by the entire group.

In this scenario, you’re still disagreeing and committing. But you’re not committing to a fantasy. You’re committing to a difficult, expensive, but now fully understood reality. You’ve done your job: you protected your team, forced strategic clarity, and upheld your responsibility to the bigger picture.

When You Should Never, Ever Commit

This principle is not a blank check. There are times when “disagree and commit” is not only wrong, but dangerous.

1. Ethical Red Line.

If a decision asks you to lie, to cheat, to harm a customer, or to violate your own ethical code, you do not disagree and commit. You disagree and escalate. You go to HR. You go to your skip-level. You become a conscientious objector. Some lines are not worth crossing for a paycheck.

2. “Violates Physics” Decision.

If a decision is based on a fundamental misunderstanding of reality that was not heard, you have an obligation to dissent again. For example: “We’ve decided to launch next Tuesday.” “I’ve tried to explain, but I need to be clearer: the servers literally do not exist yet. It is physically impossible.” This is a rare exception. You get to play this card once a year, maybe. If you’re playing it every month, you’re the problem.

3. Pattern of Failure.

If you find yourself on a team where you are constantly disagreeing, committing, and then watching projects fail for the exact reasons you predicted, the system is broken.

The problem isn’t this one decision. The problem is a leader who doesn’t listen, a process that doesn’t learn, or a culture that punishes dissent. At that point, your commitment isn’t to the project. Your commitment is to finding a new job.

At The End

The goal of a high-performing team is not to always make the right decision.

That’s impossible. The goal is to be able to execute with velocity and unity, especially when you’re not sure it’s the right decision.

“Disagree and Commit” isn’t the end of a conversation. It’s the beginning of a pact. A pact that says, “I trust you enough to argue with you, and I respect you enough to go all-in with you, even when I think you’re wrong.”

That’s the kind of team that wins. Not because they have the best ideas, but because they have the healthiest conflicts.

Become A Prime Voyager

The Story: When a Simple Question Turns Into a Maze

It’s 4:00 PM on a Tuesday.
You’re switching between tabs, half-preparing for tomorrow’s review, half-answering Slack pings.
Your Engineering Lead messages you:

“Hey, quick one — how’s the onboarding experiment going?”

You start typing:
“Well, we’ve been running it for two weeks. Last week we had an unexpected issue with the event tracking, so data is a bit incomplete. We’re cleaning it now. Also, Design suggested a small tweak in step four, so the variant isn’t fully consistent across markets. And we haven’t added the fallback logic yet, because—”

You pause.
You re-read the message.
You sigh.

Because you know exactly what happened:
You didn’t answer the question.

You explained your work.
Not the status.

And the worst part? Your Engineering Lead didn’t ask for any of the context. They asked for exactly one thing:

👉 Is the onboarding experiment working?

And this is where most PMs — even the senior ones — unconsciously slip.
We answer with the process instead of the point.

Subscribe now

Why This Matters More Than You Think

When someone asks you:

“Can you give me an update?”

They’re not asking for a diary entry.
They’re trying to make a decision.

Different people make different decisions:

• A VP wants to know whether to invest more, pivot, or stop.

• A Head of Customer Support wants to know whether to hire more people.

• A Design Lead wants to know whether the experience improved.

• A Business stakeholder wants to know whether this affects revenue or cost.

• An Engineering Lead wants to know whether it’s stable and worth optimizing.

• Your squad wants to know what to do next.

But if you respond with:

• who you talked to

• what meetings you had

• how the process went

• which confluence page you updated

• or the Jira ticket journey of a single feature

…you’re not enabling decisions.
You’re creating noise.

No one can act on noise.

And that’s why the Answer → Explain method is so powerful.
It turns noise into clarity — fast.

The Core Method: Answer → Explain

This is the storytelling technique that turns a 3-minute monologue into a 15-second answer that builds trust, clarity, and direction. A great update — the kind that travels across the company — has two parts:

1. ANSWER (what they want to know)

This is the headline.
The bottom line.
The “one big number” people will remember and repeat.

Answer = Big Number + Decision

Examples:

• “Activation is up +6% — I recommend we expand the experiment.”

• “The chatbot resolved 62% of questions — we can delay hiring additional agents.”

• “Drop-offs decreased by 14% — the redesign is working.”

2. EXPLAIN (only what they need to make that decision)

This is not a process recap.
This is not your journey.
This is not your Jira board.

Explain = Relevant context → Why this matters → What’s next

That’s it. This structure forces clarity, reduces noise, and builds trust fast.

And now let’s combine it with the most important PM skill of all: understanding who’s asking.

Understanding Who’s Asking (and Tailoring Your Answer)

One question. One big number. Different explanations.

Imagine you launched an AI support chatbot.
After four weeks, you have one memorable, simple headline number:

👉 The chatbot resolved 62% of incoming questions without escalation.

That is your Answer.
You do NOT change this number per audience.
The number stays the same — the meaning changes.

Below: the same ANSWER, tailored EXPLANATIONS for each role.

1. VP of Product

🎯 Their decision: invest more, pivot, or stop.

ANSWER:

“It’s working — the chatbot resolved 62% of questions. I recommend scaling it.”

EXPLAIN:

“We focused on simple ‘quick questions.’ This reduced load on agents and improved issue resolution time. We have one guardrail: improving fallback for ambiguous intents before full rollout.”

2. Head of Customer Support

🎯 Their decision: Do we need to hire more agents?

ANSWER:

“The chatbot resolved 62% of questions — we can avoid hiring two additional agents this quarter.”

EXPLAIN:

“Most deflections were password resets and delivery ETA queries. Complex cases still go to agents, but the load reduction gives your team breathing room.”

3. Engineering Lead

🎯 Their decision: Is the system stable? Do we optimize?

ANSWER:

“It’s stable — 62% resolution with healthy latency.”

EXPLAIN:

“No major incidents. The only improvement needed is stronger fallback logic for unclear intents next sprint.”

4. Design Lead

🎯 Their decision: Was the experience improved?

ANSWER:

“We resolved 62% of issues — users finish support flows faster with less friction.”

EXPLAIN:

“Feedback shows clarity in simple flows. Users struggle with multi-step topics, so we have room for refinement.”

5. Business / Commercial Stakeholder

🎯 Their decision: Does this reduce costs or increase value?

ANSWER:

“The chatbot resolved 62% of issues — it meaningfully reduces handling costs.”

EXPLAIN:

“We’re lowering per-ticket cost while keeping satisfaction stable. This impact will grow as we expand to more segments.”

6. Your Squad

🎯 Their decision: What do we build next?

ANSWER:

“The chatbot resolved 62% of questions — next we focus on better fallback logic.”

EXPLAIN:

“This unlocks coverage for more complex topics and increases overall resolution rate.”

Notice What Happened Here

You didn’t change:

• the number,

• the success signal,

• or the core message.

You changed the lens — because different roles make different decisions.
That is Product Storytelling.

Bad Answers That Every PM Should Avoid

🚩 Process dumping

“We deployed the first version last week, then cleaned the data pipeline, then ran into a bug…”
Nobody asked.

🚩 Chronological recaps

“First we tested A, then B happened, now we’re working on C…”
This is a status log, not a decision-enabling update.

🚩 Thinking out loud

“So maybe users are expecting… I guess we’re seeing some traction…”
If you are unsure, they become unsure.

🚩 Burying the headline

“We talked to support yesterday and…
…oh yes, the experiment is actually performing well.”
Start with the answer.
Always.

How to Use Answer → Explain in Your Daily PM Work

Here’s what great PMs do consistently:

1. They choose ONE big, repeatable number.

The number that travels across the company.

2. They form a headline that carries a decision.

Not “progress.”
A decision.

3. They tailor the explanation to the listener’s decisions.

Staffing.
UX.
Stability.
Revenue.
Direction.

4. They make their update useful, not exhaustive.

Useful = “I know what to do next.”
Exhaustive = “Why did they tell me all this?”

5. They turn updates into momentum.

Every answer ends with a clear next step.

Closing: Your Update Is Not About You

It’s not about your process.
It’s not about the effort you put in.
It’s not about the meetings you attended.

It’s about enabling someone else to move.

When someone asks:

“Can you give me an update?”

You respond with:

Answer → the headline, the big number, the decision.

Explain → only the context that helps them make their decision.

That’s how you build trust.
That’s how you influence decisions.
That’s how you lead.

Not by talking more —
but by saying the right thing, in the right order, for the right person.

Subscribe now

She moved across the world, survived the relocation chaos, and now she is back. Inês Pinheiro-Kumar returns with a new chapter of The Product Manager in the Middle, this time sharing the truth about vibe coding: the fun, the pain, and the sheer number of 404s.

If you’ve ever glued yourself to a chair to fix one tiny life annoyance with AI, you’ll feel seen.

Most of you who know me must be searching the sky for flying pigs. But it’s true. After much resistance and wondering when I would finally give in to AI vibe coding, the moment finally arrived. I learned a lot about this trend, and even more about why so many people struggle with it or fail at it altogether. So jump in and let me take you on my vibe coding ride.

And for those who might be getting deja-vu from this, there was a small misfire of the article before it was ready to go, and this is the revised edition. The consequences of taking too long a hiatus from Substack.

Subscribe now

Finding a (Me) Problem

This all started with my relocation to Singapore and figuring out how to strengthen my presence as a Product Manager in a place where I had a very small network. After looking at the trends out there, I decided to build my own product portfolio. I had plenty of case studies, but they were just that. Great at showing my thinking, but not great at showing what I could actually build beyond taking an idea and writing a two pager about what it could become.

Add to that the doomsday idea that AI will kill Product Managers (yes, this is how I am choosing to frame it), and it felt clear that thoughts alone would not cut it. I needed to show what I could create. But whenever I tried to come up with a concept, it failed from the start. It took me quite a while to get to the why.

(Yes, yes, we all know this is a hoax. But it is a fun one.)

The why was so obvious it might as well have slapped me in the face. I saw the same pattern happening to my peers too. Product Managers are, hopefully, innate problem solvers. The kind of people who cannot look at a problem without thinking here, let me fix that for you, even as we get weird looks from strangers whose phones we just snatched because they were trying to scan a boarding pass with the screen brightness at zero.

But the worst case is when that instinct gets paired with the second most common trait in PMs. We are visionaries. People who dream big and dream of disrupting. Which makes us want to take down the world and solve its problems. But there is a reason world problems are world scale. They are complex, multi layered and require far more than an afternoon of chatting with an LLM as it spits out code for you to copy and paste into a project.

Most people were aiming too high with their problem statement to vibe code. And many went at it with aspirations that were too big. The moment vibe coding actually worked for me was when I found a problem so annoying that I was willing to glue myself to the chair until I could find a way to make my own life easier. That is when it clicked.

Finally Ripping the Itchy Band Aid

The breakthrough came when a problem that was unique to my reality became so annoying I had to solve it.

Since moving, there was a broken job to be done between me and my husband. Because I work on site most of the week, I usually pick up dinner on the way back home from the closest hawker center every evening. If you have experienced hawker centers in Singapore, you know the following:

• There are usually over 50 stalls and exponential options.

• They loosely follow schedules, and the opening days depend on the owner.

• They close when they sell out, which makes availability unpredictable.

• They are not easily found or identified on Google Maps or other directories.

So every day I found myself doing laps around the market on a call with my husband, reporting what was open, whether they still had what he wanted, and repeating the conversation until we finally secured dinner. It easily added 15 to 20 minutes every evening, which made me more frustrated by the day.

If only there was a way to easily show him what was open, and he could tell me what he wanted.

And that is how I finally got my feasible vibe coding idea. I needed a database with all the options, an interface for me to mark stalls as open or closed, and another for him to select what he wanted and send it back to me.

The Ups and Downs of It All

The idea was clear in my head, and I could write a PRD for this life saving application in my sleep. Yet the first realization of vibe coding is that not only are you the PM and the developer, you are also every other function you normally get to delegate work to.

So my first step was not sitting with my loyal friend ChatGPT. It was spending a morning in 32 degrees Celsius and 90 percent humidity, walking around the market taking photos of the stalls, mapping out their numbers, and starting to write their menus down. This is still only 25 percent done, even now. I knew this was the core of my prototype. A visual cue to identify the stall, the name, and the number. Enough for me to find it physically, and for my user to pick it. The menu could wait for a second iteration.

After that suffering was done, I threw my PRD at ChatGPT and told it that I had both it and Claude Pro available to tackle this project. I asked it to recommend free tools for anything else I might need. Luckily, it offered some familiar names and a list of next steps. That is when I put my developer costume on.

I used its SQL prompts on Supabase, a great tool for data hosting and architecture that does not require more than your usual familiarity with database design. I uploaded my clean data, mapped fields using clear naming conventions, and checked that ChatGPT had created some future proofing tables like events and sessions, which later became a headache.

I used Claude as my project terminal because some of its debugging features and AI coding assists paired well with the code ChatGPT was producing. One of the lessons I learned was to be very clear in my instructions when asking ChatGPT how to give me instructions. Whenever it gave me code snippets, it would not clearly explain where they belonged, and the message below became the most common and painful one to see in my terminal.

Sometimes it was easier to ask for the entire code of a page with the new logic added. It would often take the opportunity to clean and optimize its own code. But more often than not, it would over clean and over optimize to the point it forgot things and broke everything. Rule of thumb: if you are at 300 lines of code and it gives you 90, there is a high probability it killed your project.

Even with all this help, it took many attempts to troubleshoot with both Claude and ChatGPT why I kept getting 404s when trying to run the project locally. And unlike a software engineer, I could not truly understand the code. I could read it and know what the words meant, but I could not understand what they did or where they fit in the overall project. Once I finally figured it out, Vercel became my best friend and an easy and free way to bring the web app to life.

(My final product. My lifesaver for the past weeks.)

Once the app was live, we did a few tests ruins…and voilà. Took me under a minute of walking through the rows to mark the stalls as open or closed, and hit the “All stalls checked button". Once I did that, my husband got a notification to refresh the page. After perusing the available stalls, he chose the one he fancied for the day, and typed out his order. This triggered a notification on my side per each action. This way, I could head to the stall to start queuing whilst he still made the final decision. What usually took 20 min and was a source of friction, now was a 5 minute task.

The best part? I not only solved a problem I experienced, but I also learned a bunch of new things I would most likely never had in other situations.

Persistence, trial and error are the keys to this process. My biggest learning was to keep it as simple as possible to get the first version out so I could test it in real life and see if it solved our problem. ChatGPT will always try to sneak in more features, and that is where you have to switch back into PM mode and focus on delivering your own MVP. It can look rough, and that is fine. Keep the ideas in your back pocket and decide later if you actually need them.

Have I Changed My Mind About Vibe Coding?

Yes and no.

It brought me insights I could not have gotten any other way. I now have much more appreciation and patience toward my developers. Trying to be in their shoes for even a couple of days showed me how tricky certain errors can be, and how one small line can break everything.

It also brought me a feeling I had been craving for a long time. The feeling of making something myself, no longer feeling like I can talk the talk but cannot walk the walk. That is one of the biggest impacts this technology brings. I am sure I will never want to fully build a production level, sellable product with just me and a couple of LLMs. I would still need a human developer to think creatively, optimize without repetition and build reliably. And a development team would still need a PM to keep them on track and focused on the actual problem.

The takeaway from this article is to start small and start personal. Find something annoying enough that you will be willing to go through the grueling process of iterating alone. Something that gives you a euphoric sense of accomplishment that makes you want to come back again.

Will I ever sell my pet project? Probably not. Will some people want to use it? Possibly. But did it solve my problem? Most definitely.

Let us know in the comments if you have joined the Vibe Coding bandwagon, and how your first attempt that made it to production looked like!

And as a treat for making it to the end of my rant, here are the tools used in my tool:
Supabase / Vercel / Claude / ChatGPT

Subscribe now

I’ve seen this chaos up close, both as a PM drowning in it and as a product leader trying to eliminate it. And what I’ve learned: this chaos doesn’t come from moving fast or being agile or responding to market changes.

In fact; it comes from product leaders who don’t provide three fundamental things: a plan, a rhythm, and accountability.

Remember to avoid: No plan. No rhythm. No excuses.

Subscribe now

Plan: You’re Not Making

I don’t mean your three-year strategic roadmap that lives in a deck nobody reads. I mean the plan that answers these questions for every PM on your team:

• What problem are we solving and for whom?

• What does success look like in numbers we can measure?

• What are we explicitly NOT doing so we can focus?

• How does this connect to business objectives that leadership actually cares about?

Most product leaders skip this. They give their teams themes instead of clarity. “We’re focused on growth this quarter.” Okay, what does that mean? Growth in which metric? For which user segment? By how much? At what cost?

Without specific answers, every PM interprets differently. One optimizes for new user acquisition. Another focuses on reactivation or retention. A third works on expansion revenue. All three succeed by their own definitions and the company goes nowhere.

That’s not empowerment. That’s abdication.

I’ve seen some of the product orgs had seven different definitions of “active user” across teams. Seven. And they’re literally measuring success differently depending on who you asked. Revenue conversations were nightmares because nobody agreed on what was working.

The plan you’re not making creates the chaos you’re then spending all your time managing.

Rhythm: You’re Not Enforcing

Product work without rhythm becomes reactive thrashing. You know the pattern:

• Monday: Leadership wants an update on the initiative you mentioned two weeks ago.

• Tuesday: A customer escalation pulls your team into emergency mode.

• Wednesday: Sales/Commercial needs a demo of features that don’t exist yet.

• Thursday: Your skip-level wants to “align” on strategy, which means redoing your roadmap.

• Friday: You’re wondering why nothing shipped this week.

This isn’t bad luck. This is what happens when product leaders don’t establish and enforce rhythm.

Rhythm means predictable cadences for the activities that matter, what if we think of that rhythm in a different way:

User research happens in weeks 1 and 5 of every quarter. Not when someone remembers to schedule it. Not when a PM gets curious. Systematically, with protected time and required participation.

Roadmap review happens on the second Tuesday of each month. With the same stakeholders, the same format, the same decision-making framework (using existing materials and no extra preparations). So everyone knows when their input window is instead of ambushing PMs randomly.

Sprint planning happens Thursday afternoons. Retros happen Friday mornings. Product critiques happen Wednesday at 2pm. These aren’t suggestions—they’re infrastructure.

Strategy review happens once per quarter, not once per week. You set direction, then you execute against it. You don’t re-litigate the plan every time someone has a new idea.

Without rhythm, your PMs spend half their energy just figuring out when things are supposed to happen and who needs to be involved. They’re building calendars instead of building products.

This isn’t rigidity. This is respect for your team’s cognitive load.

Excuses: You’re Accepting

A PM misses their quarterly objectives. What happens?

In most organizations: nothing. Or worse; the PM presents a compelling narrative about market conditions, technical complexity, and cross-functional dependencies. Everyone nods sympathetically. The same PM misses next quarter too.

This is where product leaders fail most dramatically: accepting excuses instead of requiring accountability.

I’m not talking about being a sociopath who ignores legitimate obstacles. I’m talking about distinguishing between explanations and excuses:

Explanation: “We missed our engagement target because the technical approach we chose hit scaling issues three weeks before launch. We’re pivoting to a simpler implementation that we’ll ship next month, and what we learned about our technical decision-making process.”

Excuse: “We missed our engagement target because engineering was pulled onto other priorities and design took longer than expected and we didn’t get the marketing support we needed.”

One owns the outcome and articulates learning. The other diffuses responsibility across the organization until nobody’s accountable for anything.

As a product leader, your job is to call this out. Not with cruelty, but with clarity:

“I hear that engineering prioritization was a challenge. But you knew that in week three of the quarter. What did you do when you realized the plan was at risk? Did you escalate? Did you adjust scope? Did you renegotiate timelines? Or did you hope it would work out?”

This is uncomfortable. Most product leaders avoid it. They let their teams miss objectives repeatedly while accepting narratives about how hard product work is.

Yes, product work is hard. That’s why we need accountability, not sympathy.

What Happens Without These Three Things

I’ve watched product organizations operate without plan, rhythm, or accountability. How it looks like:

PMs become order-takers. Without a clear plan from leadership, they default to building whatever stakeholders request. The loudest voice wins, not the most important problem.

Teams burn out from chaos. Without rhythm, every week feels like improvisation. Nobody knows what’s important. Everything feels urgent. People work weekends trying to catch up on a treadmill that never stops.

Mediocrity becomes acceptable. Without accountability, shipping becomes the only metric that matters. It doesn’t matter if anyone uses the feature. It doesn’t matter if it moves metrics. You shipped, so you succeeded.

The organization stays busy but goes nowhere. You have activity without progress. Motion without movement.

The cruel part: your PMs will blame themselves. They’ll think they’re bad at prioritization, bad at stakeholder management, bad at execution. They’ll burn out thinking it’s a personal failure when it’s actually a leadership gap.

Product Leader’s Actual Job

Early in my career, I thought product leadership was about having the best product instincts. About being the person with the most visionary ideas.

That’s not it.

Product leadership is about creating the conditions where your PMs can do their best work. That means:

Providing clarity about what matters. This is the plan. Not themes, not platitudes of specific problems, specific outcomes, specific success metrics. If your PMs can’t explain what they’re trying to achieve and why it matters, you haven’t given them a plan.

Protecting focus through structure. This is the rhythm. Predictable processes that batch interrupt-driven work into specific windows so your team has uninterrupted time to think, research, and build.

Requiring ownership of outcomes. This is accountability. When PMs succeed, celebrate specifically what they did well. When they miss, require specific learning about what they’d do differently. No vague explanations, no diffused responsibility.

These aren’t the sexy parts of product leadership. They’re not the inspiring vision presentations or the clever product strategy. They’re the infrastructure that makes everything else possible.

What This Looks Like in Practice

If you want to to restructure product operations at your company, you can follow a simple approach:

Every PM has a one-page plan that fits on a single slide. Problem statement, target metric, success criteria, what we’re not doing. If you can’t fit it on one page, you don’t understand it well enough. We have spoken about it by building an operating model named “Autobahn“ in case you want to read about it.

Every ritual has a standing time. User research cycles, roadmap reviews, stakeholder syncs, team retros; all scheduled for the full year. No hunting for calendar time, no schedule negotiation. The infrastructure is just there.

Every quarter ends with PM presentations where they present: what they committed to, what they achieved, what blocked them, and what they learned. No slides about market conditions or technical complexity unless they’re explaining specifically what actions they took when they encountered those obstacles.

Subscribe now

Objections I Hear

“This sounds too rigid. We need to be agile.”

Agility isn’t the absence of structure. It’s the ability to change direction quickly when you learn something new. But you can only change direction if you had one to begin with. Random pivoting isn’t agility; it’s just randomness.

“Every team is different. We can’t have one rhythm for everyone.”

You’re right that teams face different challenges. You’re wrong that this means every team needs a different operating cadence. The rhythm is about when decisions happen and how information flows. Those should be consistent so people can collaborate.

“We don’t want to create a culture of blame with too much accountability.”

Accountability isn’t blame. Blame is retroactive finger-pointing. Accountability is proactive ownership. You’re not punishing people for missing targets. You’re requiring them to learn from misses and adjust. That’s how people grow.

To Every Product Leader Reading This

If your product org feels chaotic, if your PMs seem overwhelmed, if you’re constantly firefighting instead of building; ask yourself honestly:

• Do your PMs have a clear, specific plan they can articulate in two sentences?

• Do they know exactly what success looks like in measurable terms? Or are they interpreting vague strategic themes and hoping they guessed right?

• Does your organization have predictable rhythms for the activities that matter? Or is everything negotiated ad-hoc depending on who’s available and what’s currently on fire?

• When your PMs miss objectives, do you require them to own the outcome and extract learning? Or do you accept elaborate explanations about external factors while the same patterns repeat?

If you’re not providing these clarities; you’re not doing your job. And I don’t say that to be harsh but I say it because I’ve failed at this myself and watched the consequences at a point of time.

Your team doesn’t need you to have the best product ideas. They need you to create clarity, structure, and accountability. That’s the leadership that matters.

A Standard You Set

What you can tell every PM who joins your team: “I will give you a clear plan, protect your ability to execute through consistent rhythm, and hold you accountable for outcomes. In return, I expect you to own your commitments fully; no excuses, only learning.”

But for PMs who want to build things that matter, who want to grow through real feedback, who want clarity over comfort; this is how you create the environment where they thrive.

Build the infrastructure. Set the standard. Watch your team become what they’re capable of being.

Become A Prime Voyager

The possibility of solving a puzzle, of a breakthrough in a user interview, of seeing a feature you poured your soul into finally click with users.

This isn’t a fantasy. This is what a winning strategy feels like.

For too long, we, as product managers, have been conditioned to believe that success is a checklist: hit the quarterly OKRs, ship on time, keep the stakeholders happy, and climb the corporate ladder.

We chase metrics like a greyhound chases a mechanical rabbit, often finding the victory lap feels hollow. We celebrate the launch, but the joy is fleeting, quickly replaced by the pressure of the next thing.

What if we’ve been chasing the wrong rabbit?

The Tyranny of the Tangible

Salary bumps, promotions, and green dashboards are tangible. They are easy to measure and easy to celebrate. But they are lagging indicators of success, not the drivers of it.

The real engine of sustainable success, the one that propels you through the inevitable troughs of disillusionment and the frustrations of failed experiments, is something far less tangible: happiness.

I’m not talking about the fleeting, superficial happiness of free office snacks or a company-sponsored happy hour or party. I’m talking about a deeper, more resilient form of professional joy.

• The quiet satisfaction of turning a complex user problem into an elegant solution.

• The electric thrill of a brainstorming session where ideas flow freely and build on each other.

• The profound pride in seeing an aspriring team member you mentored step up and lead.

• The intellectual humility and excitement of learning from a hypothesis that spectacularly failed.

These are the moments that fuel us. They are the currency of a fulfilling career. When you are genuinely happy at work, you are not just a better employee; you are a better product manager.

Happiness as a Performance Enhancer

A happy product manager is a force multiplier.

• Creativity thrives in positivity. When you’re not bogged down by dread or burnout, your mind is free to make novel connections and see opportunities where others see obstacles.

• Resilience is a byproduct of joy. When you love the process, a setback is not a personal failure but a learning opportunity. You bounce back faster because the work itself is the reward.

• Collaboration becomes effortless. Genuine enthusiasm is infectious. A happy PM inspires trust and psychological safety, creating a team environment where everyone feels empowered to do their best work.

Chasing happiness isn’t a selfish pursuit; it’s a strategic one. It creates a virtuous cycle: you do great work because you’re happy, and you’re happy because you do great work.

Subscribe now

A Message to the Leaders in the Room

To the leaders, the VPs, the C-suite: look at your team. Are they merely productive, or are they joyful? The distinction is critical.

Your team’s happiness is not a line item for the HR department; it is a core component of your product strategy. You can’t A/B test for it, and you can’t capture it in a Jira ticket, but it is the single greatest predictor of your long-term success.

Stop asking, “Are we hitting our numbers?” and start asking:

• Is my team proud of the work they are doing?

• Do they feel safe to fail and to learn?

• Are they growing, not just as professionals, but as people?

When you give your product managers a mission they can feel proud of, you ignite a powerful chain reaction. A PM who feels a deep sense of achievement doesn’t just manage a backlog; they become an evangelist for the product, the team, and the vision.

Commitment and accountability cease to be items you track; they become the default state. This is how you build a team that doesn’t just ship features, but moves mountains.

Conversely, the absence of this feeling is one of the fastest routes to disengagement. A product manager who doesn’t feel that pride, who doesn’t see the impact of their work, will eventually retreat into ignorance or apathy. They’ll manage the process, but they’ll lose the passion.

Your role is not just to clear roadblocks, but to cultivate an environment where happiness can take root. Provide autonomy. Champion purpose. Celebrate learning as much as you celebrate winning. Trust your team, and give them reasons to be excited to walk through the door (virtual or physical) every morning.

Your Personal Winning Strategy

As a product manager, you are the architect of products. But you are also the architect of your own career. Don’t just build a roadmap for your product; build a roadmap for your happiness.

Identify what truly brings you joy in your work and actively seek more of it. Protect your curiosity. Find the courage to care, deeply, about the problems you are solving and the people you are solving them for.

Because when you find happiness in your work, you haven’t just found a better way to work. You’ve found your most sustainable, most powerful, and most authentic winning strategy.

Discover the playbook every Product Manager needs in 2025: how building real community —> beyond frameworks and job titles unlocks exponential growth in the age of AI.

In this article, you’ll learn how to avoid career stagnation, why horizontal growth matters, and concrete steps to expand your impact, build resilience, and accelerate your product career through the Learn–Earn–Return cycle.

One year ago, this started as a conversation with (the founder of Product lab) if we can host Marty Cagan in Berlin. Just a conversation.

A what-if. The market was rough. Jobs were drying up. Nobody was betting big on anything. And guess what: the event happened.

What we’ve noticed on that night was: this hunger.

You could feel it in every coffee chat during the event, every LinkedIn DM directly after, and so, we decided to do something about it and accordingly I’ve joined product lab as a board member for 2025 conference in Berlin.

I didn’t realize that decision would mean a year of my life. A year of explaining the vision to speakers who’d never heard of us. A year of budget spreadsheets that made our stomach turn. A year of plans changing, people canceling, doubts creeping in at 3 AM when we couldn’t sleep.

Everyone kept asking: “What’s the ROI? What’s the business model? Why are you pouring your life into this?” 👀

They were measuring the wrong thing.

And nobody tells you: the fastest way to grow as a product leader isn’t climbing the ladder. It’s building the campfire.

The Problem Most PMs Don’t See

We spend our careers learning frameworks. We read books, attend webinars, collect certifications. We climb from APM to PM to Senior PM to Principal. We earn the title, the salary, the respect.

But somewhere in that climb, we stop learning. We start repeating. We become isolated in our companies, in our processes, in our way of thinking.

And when the market shifts, when AI rewrites the rules, when the job disappears, we realize: we’ve been optimising for the wrong thing.

What Started in a Basement (Learn)

The preparations of ProductLab Conference started small and from a continuous chat in a basement.

A handful of 2 ambitious people in Berlin who wanted to learn, exchange ideas, grow together. No one was getting paid, just a founder of established community and a board member.

That’s where you find the signal. Not in the business plan, but in the people who show up when there’s nothing to gain but connection and knowledge.

That was the first lesson:

Community is where you learn what your company can’t teach you.

Inside your company, you learn one way of doing things. One tech stack. One customer segment. You become fluent in your company’s dialect of product management.

But in a community/external network? You meet the PM from Amsterdam who approaches growth completely differently. The Berlin PM who thinks in systems. The Munich PM solving the exact problem you’re stuck on, but from a totally different angle.

Subscribe now

The Year Nobody Sees (Earn)

I spent years earning credibility in product management. Evolving teams. Creating Capabilities. Shipping products. Proving I could deliver. That’s what we’re trained to do: create value inside our organizations.

But organizing this conference? That was earning something different. Earning trust from a community I didn’t own. Earning respect from speakers who didn’t know us. Earning the right to ask 250+ people to spend 2 days with us.

What a year of organizing a conference actually looks like:

Month 1-3: Pure momentum. Everything feels possible. You’re signing speakers, sketching out the dream. I’m learning to sell a vision with zero proof.
Every conversation with a potential speaker is a pitch where we have no metrics, no track record, just conviction.

Lesson: Before you have data, you need belief. Before you have traction, you need trust. we’re earning credibility one conversation at a time.

Month 4-6: Reality hits. The venue costs more than you thought. Two keynote speakers drop out. The market gets worse. Your partner asks, “Are we sure about this?”

Lesson: Every product faces this moment. The gap between vision and reality. Most PMs panic and start cutting scope randomly. I learned to ask better questions: What’s the core experience? What can’t we compromise on? This is stakes-setting, just like defining your product’s wedge.

Month 7-9: The grind. Content curation. A thousand small decisions. Negotiating with everyone who want to sell, not support. Reviewing proposals. Rewriting the schedule. Again. And again. Tiredness becomes your baseline.

Lesson: I’m doing product management, just not on software. I’m curating an experience. I’m making trade-offs. We’re saying no to good ideas to protect the great ones. Every framework I use at work applies here, and suddenly I see them differently.

Month 10-12: Panic and faith in equal measure. Last-minute changes. Doubts everywhere. But also: momentum. Ticket sales. People messaging you saying, “I can’t wait.” You remember why you started.

Lesson: The echo starts before you ship. People were excited about the conference before it happened. That’s signal. In product work, we wait for launch to measure success. We should be listening for the echo much earlier.

Throughout it all, the question kept coming: “What are you getting out of this?”

I was earning a different kind of credential. Not a title. Not a salary bump. I was earning the pattern recognition that only comes from building something from zero in public.

The Day It All Made Sense (Return)

Then the conference happened. 250+ people. From painting a vision of PMs as architects of the future. To many panel moderations about AI era. And a lab day with many workshops, that were really engaging.

And I understood something profound about product management.

The real product wasn’t the talks. It was the spaces between them.

You could feel it. A PM from Rome explaining her challenges to someone from Munich. Three people surrounding facilitators during lunch, asking about data frameworks. Conversations about AI panel continuing into the after-lunch.

This is what we miss in product management: we obsess over the features, the shipped code, the demo. But the value often emerges in the spaces we don’t control.

The way users combine our tools with others. The conversations our product enables. The community that forms around solving similar problems.

People weren’t just learning. They were connecting. Finding their people. Realizing they weren’t alone in their struggles. This is the return: not what I got back, but what I got to give back.

Isn’t this exactly what great product leadership looks like? You set the conditions for valuable interactions, then get out of the way.

And the real proof came in the messages after:

• “How did you do that?”

• “When’s the next one?”

• “This is what Berlin needed.”

The more I gave back to the community, the more I learned. The more I learned, the more I could earn. Not in a transactional way, but in a compounding way.

Why Learn, Earn, Return Matters for Product Managers

Most PM career advice is linear: Get good at the craft. Build products. Get promoted. Repeat.

That’s the trap. You optimize for the ladder, and you stop growing horizontally. You become really good at one company’s way of doing things, but fragile to market shifts.

The PMs who are thriving right now aren’t the ones with the best titles. They’re the ones with the strongest communities.

Learn: Your company teaches you one playbook. Community teaches you twenty. When AI disrupted product management overnight, the PMs who were active in communities already knew how others were adapting. They’d seen the signals. They weren’t starting from zero.

Earn: Your work inside a company earns you a title and a salary. Your work in community earns you trust and recognition from people who don’t have to care about you. That’s a different kind of credential, and it’s more portable.

Return: This is the part most PMs skip. They learn, they earn, they... keep climbing. But when you return value to the community, something magical happens. You learn faster because you’re teaching. You earn deeper relationships because you’re giving first. You become magnetic to opportunities because people remember who showed up when there was nothing to gain.

The Real ROI: Compounding Returns

What started as a conversation in Q4 2024 became Berlin’s first product conference. What began in a basement became a full venue with 250+ product people

And now? Product lab already planning 2026. More workshop tracks. Deeper frameworks. International speakers. I wish them all the best to keep growing 💪.

Takeaways for you

1. The magic is in the margins.

We obsess over keynotes, but people remembered the hallway conversations. In product: we obsess over features, but users remember how something made them feel. Design for the margins, not just the main path.

2. Community compounds, products depreciate.

Every feature you ship starts aging immediately. Every connection you help create starts compounding. What if you built your product to facilitate connections between users, not just between user and product?

3. You can’t engineer serendipity, but you can create conditions for it.

The best moments at the conference weren’t scripted. But they happened because we created the right conditions: diverse attendees, generous time buffers, permissionless conversation spaces. Same with products: create conditions for users to surprise you.

4. The echo tells you everything.

People were excited before the conference happened. That was the real signal. We spend too much time building in silence, then measuring post-launch. Listen for the echo while you’re building. If people aren’t excited before you ship, shipping won’t fix it.

Before we close, let’s practice what we preach @ Product Voyagers

I’d be a hypocrite if I wrote about Learn-Earn-Return without showing you how We’re living it.

Product Voyagers, this Substack you’re reading, is our ( & me) other campfire. It’s a content-led community where we share the frameworks, mental models, and hard-won lessons from building products in the AI era.

And we didn’t start Product Voyagers to build an audience. We started it because of having the same conversations over coffee. PMs asking: “How do I think about products? How do I tell better product stories? How do I lead when everything is changing?”

We were learning these answers by doing the work. So we started returning what we learned through writing.

The Learn part: Every article starts with a problem we’re wrestling with or a pattern I’m seeing across multiple PMs. We’re not writing from expertise; we’re writing from exploration.

The Earn part: The credibility doesn’t come from having all the answers. It comes from being willing to think out loud, to challenge conventional wisdom, to say “the MVP framework is broken” when everyone else is repeating it.

The Return part: This article you’re reading? This is me giving back what I learned from organizing ProductLab. The frameworks I develop here (like the Entry Stakes, Wedge, Obsession Loop model) are tools I wish I had when I was earlier in my career.

And the compound effect is real: the more I write, the more I learn from the community that forms around it. The more I learn, the better the content gets. The better the content, the more valuable the community becomes.

That’s the Learn-Earn-Return cycle in action!

And if you want to join the Product Voyagers community, you’re already here. Subscribe to get frameworks and mental models for building products that matter.

Be A prime Voyager

You’re a product builder/founder, you’re supposed to be on the cutting edge, but the AI landscape feels like a chaotic, deafening storm. The pressure to just “do something” is immense.

So you grab at tools. You try a chatbot here, an automation there. You’re busy, but you’re not making progress. The tools feel disconnected, brittle, and you’re still the one doing all the real thinking. This is the trap we’re seeing around.

Let's change the frame. The question isn't about tools. It's about AGENCY.

Subscribe now

The Core Metaphor: A Ladder of Agency

Agency is the power to decide and do.

Instead of thinking about AI as a pile of features, think of it as a ladder of escalating agency. Each rung represents a fundamental shift in your relationship with technology, moving from giving instructions to delegating outcomes.

Your job as a product thinker/founder is to choose the right rung for the right job.

Rungs 1-2: The Mechanic

You Command a Tool, You Design a Machine

This is where most of the business world lives. You're using AI like a better version of Microsoft Notepad (Rung 1) or a more complex set of rules in an automation tool like “Zapier - back in the days without AI Agents 🤖” (Rung 2). You define the plan, and the machine executes your instructions.

• The Trap: Believing this is the end game. You get stuck building ever-more-complex Rube Goldberg machines of linear automations. You’re saving time on tasks, but you haven't created any new leverage.
  You're working in the system, not on it.

• Your Job: Master repeatable systems. Use linear flows for predictable work like lead nurturing, data entry, or report generation.
  » The goal here is efficiency. Nail this for processes that don’t require judgment.

Rungs 3-4: The Conductor

You Work with a Partner, You Direct an Agent

This is the leap. You stop giving step-by-step instructions and start providing intent. You treat the AI as a partner that makes suggestions (GitHub Copilot, Rung 3) or an agent that executes your vision (Cursor, Rung 4). You delegate the "how."

• The Trap: Micromanagement. You try to control every step the agent takes, strangling its potential. You don't give it a clear enough vision, so it produces generic, useless output. You treat your agent like a machine instead of a teammate.

• Your Job: Learn to delegate with vision. Provide clear goals, context, and constraints. Your prompt isn't a command; it's a creative brief.

  » The goal here is effectiveness. Use this for complex tasks that require creativity and judgment, like drafting a marketing strategy or coding a new feature.

Rungs 5-6: The Architect

You Lead a Team, You Lead an Organization

This is the frontier. You're no longer directing a single agent; you are leading a team of them (Rung 5). You set the mission, and your agents collaborate to achieve it, even building and managing their own teams (Rung 6).

• The Trap: Fear of losing control. The system becomes a black box you don't understand. You haven't defined the organization's "Vibe," so the agents operate without principles, creating chaos.

• Your Job: Set the constitution. You need to build a "Vibe Stack" → the combination of your company’s principles (Vibe), its agentic workflows (Flows), and the underlying models (Coding). This stack becomes the operating system for your autonomous organization.
  » The goal here is scale, by building entirely new, self-managed business functions.

Linear vs. Agentic: The Right Flow for the Job

Your business has two kinds of problems: 1) predictable and 2) unpredictable. Using the wrong kind of AI flow is like using a hammer to turn a screw.

• Use Linear Flows (Rungs 1-2) for Predictable Problems: When you have a defined process where the steps don't change, automate it. Think invoicing, employee onboarding, or data backups. The ROI is saving time and money.

• Use Agentic Flows (Rungs 3-6) for Unpredictable Problems: When you have a goal but the path is unclear, deploy an agent. Think exploring a new market, designing a product, or running a competitive analysis. The ROI is speed of innovation and quality of decisions.

Subscribe now

Product Builders →Remember the Round Story

When an investor asks for your AI strategy, don't list tools. Give them your framework.

"We don't chase AI tools; we deliberately choose our level of agency. For our operational processes like finance and support, we run at Rungs 1 and 2, using linear automation to be ruthlessly efficient. But for our core product development and market expansion → the work that requires real innovation, we operate at Rung 4. We deploy agents with a clear vision to explore, build, and learn faster than any of our competitors who are still just commanding tools. This allows us to scale our creativity, not just our tasks."

A Real Test For You

Stop what you're doing. Pick one “just one” recurring process in your organisation, vertical or startup.

1. Identify what rung of the Ladder of Agency it lives on today.

2. Ask yourself: What would it look like to move it up one rung? Not to full autonomy, just one step up.

3. Write down the first, smallest action you can take to make that happen this week.

The future of your business isn't about buying more AI tools. It's about leveling up your agency.

Follow up read.

If you're not deep in the technical waves and feel lost in the sea of AI terminology, the collection below is a powerful starting point. It cuts through the noise.

A great collection by .

Product Release Notes

All-in-one AI Terminology For Non-Technical People

A great way to make AI and software concepts accessible is to build a leveled glossary that starts with core ideas and gradually introduces more technical terms. Below is a ready-to-use, layered glossary organized from beginner to expert level, with concise, kid-friendly definitions and clear distinctions (such as LLM tokens vs. API tokens). Enjoy 😉…

Read more

8 months ago · 22 likes · 12 comments · Elena Calvillo

Be A Prime Voyager

The kind that make people pause.
That open blind spots.
That make teams feel seen, not judged.

In a world that rewards fast answers and confident opinions, the ability to ask thoughtful, honest questions is often what sets the best leaders apart. Not the loudest in the room, but the most curious. Especially in the moments no one else is paying attention.

A Tale of Two Onboardings

You can often tell whether someone will thrive in a product leadership role within their first few weeks—not by what they say, but by what they ask.

Years ago, I got a new manager. In our early meetings, they asked what felt like an endless stream of basic questions—
"What do you do exactly?"
"What is this initiative about?"
"Which KPIs are we tracking?"
"What does each team member own?"
Then they asked how to use our internal tools.

At first, I was confused. These seemed like things a senior person should already know. Why were they hired if I needed to explain all the basics? But then I noticed something. Their questions weren't careless—they were deliberate. They weren’t pretending to know. They were trying to truly understand.

Soon, the questions evolved from “what” and “how” to “why.”
“Why did we prioritize this initiative over another?”
“Why is this feature built this way?”
“Why is this our scope?”

And suddenly, I was challenged. Not defensively, but constructively. I felt like someone finally understood the depth of our work—and wanted to make it better. That manager earned respect by doing something deceptively simple: asking questions that made us think sharper, act bolder, and deliver stronger.

Now contrast that with another experience. I was asked to onboard a product leader with impressive credentials. I was genuinely excited—until our first meeting. They opened with a long monologue about their past roles, notable companies, and opinions on the industry. It felt rehearsed.

When I gave a quick overview of what my team does, I expected curiosity. Questions. Engagement.
Instead? Silence.
No “What are your biggest challenges?”
No “Where do you need support?”
No “What are your expectations of me?”

It was underwhelming. I wrapped the meeting by offering help:
“If you have any questions, I’d be happy to explain more.”
Their reply? “Let’s do monthly 1:1s.”

Those became a 30-minute black hole each month—filled with generic talk about processes and previous jobs, none of it relevant to my reality.

So, what happened next?
Manager #1 thrived. They grew. The team flourished under their leadership.
Manager #2 quietly left after a while. I suspect they couldn’t hold their ground in high-stakes conversations. Not because they lacked knowledge—but because they never took the time to truly understand the products, the users, or the problems.

Their contributions remained surface-level. They spoke in frameworks and best practices—but couldn’t connect those to the messiness of real product work.

Subscribe now

Why Questions Matter

The strongest people I have worked with rarely lead with statements.
They lead with questions like:

• “What is the biggest risk no one is talking about?”

• “What is the real problem we are solving here?”

• “If this goes well, what changes for the user?”

• “What would we build if we started from scratch?”

These questions aren’t flashy. But they cut through noise. They create clarity. And they build trust.

What strong leaders do:

• Ask before advising.

• Listen before responding.

• Challenge assumptions, not people.

• Use curiosity to unlock impact—not to perform intelligence.
  

When Asking Questions Is Crucial

Let’s explore where asking the right questions makes the biggest difference:

1. Onboarding into a new team

We have all seen it: a new joiner walks in and starts offering “solutions” before understanding the problem. It is frustrating.
Strong leaders don’t rush to change things—they slow down to ask questions like:
✅ “What is the biggest challenge your team is facing?”
✅ “What would you improve if you had no constraints?”
❌ “Why are you still doing it this way?”

Respect is earned through curiosity. Listening builds credibility faster than expertise.

2. Working with cross-functional teams

Many PMs shy away from technical discussions, thinking it is “not their domain.” But the best ones lean in—with humility.
✅ “What is the biggest tech constraint we need to factor in?”
✅ “How does this API impact downstream flows?”
❌ “Can we just do it like in my last company?”

Asking thoughtful, non-judgmental questions shows engineers you respect their craft—and want to understand it, not override it.

3. Review sessions (design, sprint, product)

Saying “I don’t like it” is rarely helpful.
Instead of offering vague opinions, good product folks ask user-centered questions:
✅ “How does this help a first-time user complete the task faster?”
✅ “What is the one thing we want users to notice here?”
❌ “Can we make the button red instead?”

Good questions spark reflection, not defensiveness.

4. Strategy discussions

Even in the most senior conversations, questions matter.
✅ “What assumptions are we making here?”
✅ “How are we measuring long-term success?”
❌ “Is this aligned with the strategy deck?”
The goal isn’t to sound smart. It’s to think clearly, together.

Questions That Miss the Moment

It is not always about asking “bad” questions—but about asking the wrong ones at the wrong time.

Context 1: Team shares a new initiative

❌ “When will it be done?”
✅ “What problem are we solving—and how will we measure success?”

Delivery dates matter. But if that is your only question, it signals you care more about deadlines than impact.

Context 2: Team escalates a dependency

❌ “Can you align better with the other team?”
✅ “What is blocking progress—and what is the risk if it is delayed?”
✅ “Which initiatives are we deprioritizing if we say yes to this?”

Process talk won’t unblock them. Deep understanding might.

Context 3: Giving feedback

❌ “I would have done it differently.”
✅ “What were the trade-offs you considered when deciding this path?”

Judgment shuts down conversation. Curiosity keeps it open.

How Not to Ask Questions

Not all questions are created equal.
Even with good intentions, some ways of asking can lead to confusion—or worse, derail the conversation entirely.

Here are a few patterns I have observed that can weaken the power of a question:

1. Asking... then immediately answering yourself

Some people ask a question and jump straight into their own opinion—leaving the other person unsure whether a real answer is expected.

❌ “Why didn’t we prioritize this feature? I mean, I assume it is because the tech team didn’t have capacity, and anyway it probably wouldn’t have moved the needle that much…”
✅ “Why didn’t we prioritize this feature—and what were the trade-offs we considered at the time?”

If you’re genuinely asking, ask. Then pause. Give space for the answer. Let curiosity win over performance.

2. Combining multiple questions into one long sentence

This usually overwhelms the other person—and makes it unclear what to answer first.

❌ “So what was the user insight behind this change and how did you come up with the solution and what would you have done differently if you had more time?”
✅ “I have a few questions—can I ask them one by one?”
✅ “First, what was the key user insight behind this change?”

Shorter questions are more challenging to answer—not because they are difficult, but because they require clarity of thought. And that is a good thing.

3. Being vague or abstract

Vague questions lead to vague answers. If you are not clear in what you are asking, the other person is left guessing.

❌ “What’s the situation with that thing from last week?”
✅ “What’s the current status of the backend fix we discussed in last week’s bug triage?”

The more precise your question, the easier it is for others to respond meaningfully.

The takeaway:

🟢 Be clear. Be concise. Be intentional.
A well-crafted question is a sign of respect—it shows that you value the other person’s time, thinking, and perspective.
And that clarity often invites a deeper, more useful answer.

In Closing

The next time you're in a meeting, try holding back your opinion for just a moment longer.
Instead, ask:
“What am I missing?”
You will be surprised how much you learn—and how much faster you build trust.

Strong product leaders don’t have all the answers. But they ask the kind of questions that bring better answers to the surface. And that’s what makes all the difference.

Subscribe now

The VCs, your team, and the voice in your head are all asking the same paralyzing question: what do we chase first? Users or dollars?

And the brutal truth: while you're having this debate, your runway is burning and your competitors are shipping.

The classic playbook pits these two against each other in a brutal cage match.

• "Get a million users, then monetize!" shouts one camp.

• "No, find paying customers from day one!" screams the other.

This is a false choice, a trap that burns runway and morale while you chase ghosts.
Let’s change the frame.

Subscribe now

Instead of Traction vs. Monetisation, let's think Signal vs. System.

Your early goal isn't just "traction" in the vague sense of traffic spikes and sign-ups. It's to find a Signal: crisp, undeniable evidence that you've found a real pain for a specific group of people.

Monetisation is the System you build later to capture the value that signal represents.

Trying to build the system before you have the signal is like trying to sell tickets to a movie you haven't even filmed yet.

Part 1: Find Your Signal (The Traction-Kernel)

The Trap

The trap is mistaking attention for validation. Because tools like Replit and Lovable make building so fast, it's easy to build something cool that attracts attention but doesn't solve a real problem. You launch on Product Hunt, get a flood of curious clickers, and bask in the glory of a top-five finish.

But a week later, your retention chart is a cliff, and you have no idea why. The vanity metrics feel good, but they are a lie. You’ve measured the volume of noise, not the quality of the signal.

Your Job

Your job is to find your MVT: Minimum Viable Traction. This isn't a number; it's a story.

Forget 10,000 users. Can you find 10 who are obsessed? Ten people who don't just think your AI tool is "neat," but have woven it into their daily workflow? They aren't using it for the novelty; they're using it to solve a painful, recurring problem.

Here's the test: if your product disappeared tomorrow, would they scramble to find an alternative, or would they just shrug and move on?

Your job is to become an obsessive documentarian of this small cohort. 1/ What do they do right before they use your tool? 2/ What do they do right after? 3/ What language do they use to describe it to a peer? This is your signal. This is your Traction-Kernel.

Part 2: Build Your System (The Monetisation Engine)

The Trap

The trap is thinking monetisation is just a price tag and a Stripe checkout page. You see other products with three-tiered pricing, so you copy them. You spend weeks building the perfect billing flow, complete with annual discounts and a "most popular" tag. You've built a beautiful, intricate system to capture value that you haven't yet proven exists.

Your Job

Your job is to turn the story of your Traction-Kernel into a compelling narrative that attracts the next 100 users. Your first monetisation efforts aren't about optimising revenue; they're about validating the signal with the ultimate acid test: getting someone to pay.

This doesn't require a complex system. Start embarrassingly simple:

• Send a PDF invoice manually.

• Use a simple "Pay what you think is fair" form.

• Get on a call and ask for their credit card number.

The goal isn't to build a scalable machine; it's to get the first dollar. That first transaction is the final, critical piece of your signal. It proves not just that your product is useful, but that its value is tangible enough for someone to exchange money for it.

If they hesitate to pay, you haven't found your signal yet. Keep hunting.

Part 3: Feedback Loop For A Traction Echo

Your MVT Minimum Viable Traction creates an echo. Those 10 obsessed users start talking. They post about it in a private Slack/Whatsapp groups. They show it to a coworker. This isn't a viral explosion; it's what I name it a high-fidelity signal reverberating within a tiny, targeted community.

Your job is to listen for and amplify *that* echo, not to shout into the void of the general internet. This echo, real people telling specific stories about your product, is your most powerful marketing and your clearest path to your next cohort of users.

Be A Prime Voyager

Your Lethal Seed Round Story

Stop debating traction vs. revenue. You can use this paragraph in your next pitch:

"We've found a 'Traction-Kernel' with a small cohort of product managers who are using our tool daily to cut down their PRD-writing time by 50%. We manually invoiced our first five customers, and they all paid within 24 hours. We're not just showing user growth; we're showing a validated signal of obsession and a validated willingness to pay. Now, we're ready to build the system to scale it."

My Real Test For You … and For Me

Stop reading. Right now.
Go find one person who used your product this week. Get them on a call.

Don't ask your customers if they'd pay. Ask them what they would lose if your product disappeared tomorrow.

If their answer isn't visceral, immediate, and slightly panicked, you don't have a monetisation problem, then you have …. ? Yes, a “signal” problem.

In Action

With that same spirit, I’ve built the system for that signal. For paid subscribers/ Prime Voyagers who want to turn this framework into a rigorous process, I’ve created the “Signal vs. System Founder's Toolkit”.

It's a detailed Notion template with checklists, interview scripts, and a scorecard to help you methodically find your obsessed users and validate their willingness to pay.

This is me practicing what I preach: creating tangible value for those who need it most.

Want the Toolkit for That? 👇

Read more

Be A Prime Voyager

You have an idea. You’ve been told the next step is to build a "Minimum Viable Product" MVP. And so the agony begins.

You're trapped in endless debates over what "minimum" means. You/Your team is rushing a half-baked product into a crowded market where first impressions are final.

You're trying to test an idea, but a weak V1 doesn't get you feedback; it gets you ignored.

The MVP is a trap by its own.
It gives you the illusion of speed while leading you in the wrong direction.

Let's change the frame. You're not building a V1. You are making a bet. A single, focused, high-leverage bet on a specific outcome.

In this article, you will find a full guide to shaping that bet. Let’s dive deep 👇.

The Anatomy of Your First Bet

To place a smart bet, you need to be ruthlessly clear about its components. Every piece of your first product must serve one of three functions

#1. Entry Stakes (The Wheels)

These are the absolute, non-negotiable fundamentals. If you don't have them, you're not even in the game. Users expect them, and will only notice them if they're broken.

Think 👀: A way to log in. A button that saves. A screen that doesn't crash.

The Trap: Over-engineering the table stakes. For your first bet, the "wheels" might just be you manually onboarding users.

Your Job: Be ruthless. What is the absolute minimum required to function? Do that. No more. These are your what I name it “Minimum Actionable Standard”

#2. Differentiated Wedge (The Engine)

This is the core of your bet. This is your theory of victory. It’s the single dimension of performance where you are not just better, but different. This is your initial go-to-market wedge that opens up the market.

Think 👀: For a data tool, it’s not just speed, but the ability to query unstructured data. For a design tool, it’s not just the canvas, but native multiplayer collaboration.

The Trap: Spreading your bets. Trying to be faster and cheaper and have more features.

Your Job: Pick one vector of differentiation and aim to be world-class at it. This is where you focus your learning and development efforts. It's the hill you will win or die on.

#3. Early Obsession Loop (The Turbo Button)

This is the magic. The unexpected. The feature that makes a user stop, smile, and feel you get them. It’s the hook that creates your first believers and your most valuable feedback loop.

Think 👀: A tool that uses an AI call to auto-generate a perfect summary of a user's daily work, making them look like a rockstar to their boss.

The Trap: Mistaking a delighter for an engine. A turbo button is useless on a car that can't move.

Your Job: Find one small, clever way to create an emotional connection. This is often the perfect place to use an AI API an not as your core engine, but as a moment of high-leverage magic.

Subscribe now

The Echo: What Happens After You Bet?

This is the part everyone gets wrong. Your first product isn't the end of the process; it's the start.

You've placed your bet. You've shipped your focused V1. Now you stop and listen for the echo.

The echo is the signal you get back from the market. It's not just support tickets and survey responses. It is the qualitative, messy, human feedback that tells you if your bet is resonating.

• Is your Differentiated Wedge landing?
  Are users talking about your "Engine" in the way you hoped? Is it changing their behavior?

• Is your Obsession Loop working?
  Are people mentioning the "Turbo Button" when they recommend your product?

• Where is the friction?
  What are the "good" problems you're seeing? (e.g., "We love it so much we need to invite more users," not "We don't understand how this works.")

Listening to the echo is not passive, however It's an active process of sense-making.

The answer to "What's next?" lies in the patterns of the echo and it informs your next bet, creating a continuous loop of 👇

Your Story Is Your Bet

Here's what I wish someone had told me when I was starting out: you don't need a perfect plan. You need a clear bet.

This anatomy is how you articulate that bet to investors, to your team, and to yourself. Remember: Your pitch and your action plan are two sides of the same coin.

A Real Test for You: Put Your Bet on the Table

If you're still debating your full feature list next Monday, the do the following

Open a blank document. Right now. Create three headings:

• Entry Stakes

• Differentiated Wedge

• Early Obsession Loop.

Force every feature on your list into one of those buckets. If it doesn't fit, it goes into a fourth: Not Now.

Bonus, If you’ve time

With that spirit; I'm teaming up with , author of The AI Maker, for a live lightning deep dive: How to Ship AI Side Projects That Real Users Actually Want.

We plan to move beyond the theory and get our hands dirty. We'll explore the tricky terrain of AI-powered product development, focusing on how to:

• Navigate common traps that cause most AI projects to disconnect from real value.

• Map customer problems to viable prompts and AI capabilities.

• Demoing with Claude's project knowledge features to integrate AI into your thinking process as a true sense-making partner.

We're running it live for those in the USA timezone. You can see the details and join us here.

Be A Prime Voyager, To get All Templates

Inês Pinheiro-Kumar returns with another chapter of The Product Manager in the Middle, this time diving into the tangled world of product documentation.

If you’ve ever rolled your eyes at a “one-pager” that requires infinite scrolling, this one’s for you. Inês breaks down the true purpose of PRDs, Initiative Briefs, and RFCs, and shows you how to write the right doc for the right moment (with a little help from AI and a lot of honesty about font size crimes).

"Hey, can you review my one-pager for this initiative?"

Top 10 most frequent messages from my fellow PMs. And 99% of the time, I click the link only to find what I feared most... multiple pages.

So here we are. Join me on a noble mission: to bring the real, useful one-pagers back from extinction, to learn when long-form docs are actually the better play… and how to shortcut your way to it.

Call the Document by Its Name

Somewhere along the way, terms like one-pager, PRD, Initiative Brief, and RFC all got tossed into the same sad document soup. Depending on your organization, this mixing of terms might be a natural outcome of each team member’s past experiences from other companies. And honestly, there's nothing wrong with that until it evolves into bigger confusion and bigger documents.

The first step to untangling this evil web haunting our Google Drives is to call documents by their proper names and clearly define their purpose. Otherwise, we end up with a dozen poorly named Franken-docs doing too much or too little.

A PRD (Product Requirements Document) is the sacred scroll that PMs craft, hoping it guides the team to build the right thing. It's also frequently afflicted by the Franken-doc phenomenon. Ideally, it’s concise, structured, outlining the what, why, and how behind a feature or initiative. But reality often delivers a sprawling beast of specs, edge cases, and endless “just one more detail” additions.

• Good PRD: clear, concise, readable across functions. Bonus points if it fits on a single page.

• Bad PRD: 10 pages. Bloated, unreadable, and one sprint planning session away from becoming a horror story at a team event.

An Initiative Brief is your master doc, an ongoing, structured source of truth for a product initiative. It tracks everything from problem definition to discovery, trade-offs, delivery, and outcomes. Think of it as your product almanac or Wikipedia page (Just don’t turn it into War and Peace II).

The best Initiative Briefs are searchable, link-rich, and give any stakeholder the power to Ctrl+F their way to answers. They also stop you from answering “Wait, why are we doing this again?” fifty times.

If a PRD is a blueprint, an Initiative Brief is your field guide.

This one’s the engineering darling, and for good reason. The RFC (Request for Comments) is a structured proposal that says, "Hey team, here's an idea. Let’s poke holes in it before we commit." It’s not a final doc. It’s a feedback magnet.

A great RFC lays out context briefly, options and trade-offs in detail, and is filled with
comments and open questions on that right-side margin. It's the whiteboard of product docs meant to evolve with feedback, not sit quietly in a Drive folder.

If a PRD is a blueprint, an Initiative Brief a field guide, then an RFC is the brainstorming whiteboard.

So... What Even Is a One-Pager?

Short answer: a format, not a document type. A one-pager just means “this should be short.” That’s it. Not everything should be forced into a single page.

I’ve seen people cram entire multi-quarter initiatives into a single A4 sheet, abusing font size and line spacing in ways that should honestly be illegal. On the other side, if your doc is summarized to the point it reads like a CAPTCHA test, it’s not a one-pager. It’s a cry for help.

RFCs can occasionally fit into one page, if they’re lightweight. But honestly? Most good ones quickly spill over into multiple pages via the comments on the sidebar, and that’s exactly how it should be. Nothing is sadder than an RFC with zero comments. That’s not a document. That’s a ghost town.

Why, then, did “one-pager” become popular? We all ran short on time. Busy PMs,
stakeholders, and leaders demanded shorter summaries, prioritizing length over meaningful content. Ironically, the same leadership that demands you to be brief often falls prey to the same crime they judge. I’ve seen some of the best Product leaders give templates that were already 4 pages long without anything more than headlines and empty bullet points.

But fear not! Your favorite Product Manager has an ace up her sleeve.

Start from the End

Counterintuitive as it seems, start from the end. Just like how in school they taught us to write summaries after we read the whole story. So start by writing that lovely initiative brief that includes all the information you gathered and generated during discovery. It might seem like you are going the wrong way, but trust the process.

So here’s a guide to finally nail your documentation for the next quarters to come... with a sprinkle of how to use AI to make it easier.

We will share a structure Notion template with our subscribers containing guideline headers to point you on the right way, but you should feel free to adapt it to the specific scenario you are facing.

1st step - Write your Initiative Brief

This is your long-form, everything-in-one-place doc. Make it structured, linked up, and readable. It should walk someone through:

• The problem you’re solving (and why it matters)

• The impact (bonus points for breaking it down by user, ops, sales, etc.)

• The data backing it up in a story form (quantitative and qualitative, with source as a hyperlink)

• Explored solutions and why you chose the current one

• Risks (mention them, link full analyses elsewhere)

• The chosen solution: user stories, features, flows, constraints

• ...and after delivery, extra points if you add the learnings and success metric
  analysis.

Pro tip: write it with your designer and engineering manager. Not before them, not after them. With them.

Congratulations! You now have your initiative brief. It should be long, but not make
J.R.R. Tolkien quiver at the knees. Now to the fun part.

2nd step - Get all your documents out of one

Once you have the full Initiative Brief, you can carve out the parts you need for other docs:

• PRD? You’ve already written most of it. Just trim.

• RFC? Pull the proposed solution section.

• One-Pager? Take the top-level context and tailor it to the audience.

You can do it the old school way and use it as an encyclopedia of sorts to write the
following documents yourself. But in this day and age, you can simply drop your Brief into your AI sidekick of preference - ChatGPT, Gemini, Claude, Perplexity - and ask it to do its thing (I’m a ChatGPT girl myself; first-name basis).

Here are some prompts that will help you get started:

Prompt for a One-Page PRD

"Summarize this discovery document into a concise PRD that fits on one A4
page with font size 10. Include only the most critical context needed for
product, design, and engineering to align. Structure it with:

• Feature name & problem statement

• Goals & success metrics

• User personas / key user insights

• Scope (must-haves only)

• Assumptions / dependencies

• Key flows or UX principles (no screens, just logic)

• Open questions or risks

Be as compact as possible without losing clarity or intent."

Prompt for an RFC (Request for Comments) for Product + Design

"Turn this discovery document into an RFC for cross-functional feedback. Focus
only on solution X. The RFC should include:

• Context (brief)

• Problem statement

• Summary of user insights leading to this solution

• Proposed solution (how it works, pros & cons)

• Design principles or hypotheses

• Open questions for Product/Design feedback

• Risks or trade-offs

  Keep the tone exploratory, encouraging feedback. Bullet points are fine
  where helpful."
  

Prompt for a One-Page Leadership Summary

"Create a one-page executive summary for leadership from this 10-page
discovery document. Focus on strategic clarity. Include:

• The problem we're trying to solve

• Why it matters (impact potential or urgency)

• Key insights from discovery (keep it brief)

• Proposed direction(s) being explored

• Potential impact or opportunity size

• Any early risks or dependencies
  Use crisp, executive-level language with no fluff."
  

Prompt for a Memo to Support Teams (Marketing / Ops)

"Summarize the discovery findings into a clear memo for Marketing and
Operations. The memo should help them understand the feature and prepare for
enablement. Structure it like this when information is available. If not, skip the
command.

• What the feature is and why we’re building it

• Who it’s for and key user insights

• Timeline or status

• Expected impact

• Support needed (e.g. rollout, FAQs)
  Keep it jargon-free and easy to skim. Use plain language and bullet points."
  

The document is your oyster. Experiment with prompts and adjustments to the ones above to never again have to write repetitive documentation.

Why Change Your Ways?

You might be thinking, "I’ve been getting by just fine. Why bother?" Here’s why: this is the stuff that makes you senior.

Not writing more docs. Not writing longer docs. But writing the right doc, for the right people, at the right moment.

A PM who nails communication, who tailors message and medium, is a PM who gets trusted
with more. Because clarity is leverage.

AI can write your docs, sure. But only if you give it the right source to work from.
Otherwise? It's just going to hallucinate features and make up personas named Dave.

Anyway, who am I to advise you? I just wrote 2000 words on how to write documents.

Got doc horror stories? Pet peeves? One-pager crimes to confess? Drop them in the comments.
I’m all ears (and memes).

Pssst… If you are one of our subscribers, there’s a nice shiny Notion template for you.

Welcome to the final chapter of Product Voyagers' Sprint:
Storytelling in Product 🤌 → a 7-part hands-on series on turning product thinking into narrative mastery.

It's 12 minutes into your Series A pitch. The lead investor leans back, checks their phone, and asks the question that makes every founder's stomach drop:

"I still don't understand what problem you're actually solving."

You've just spent 12 slides explaining your product, your tech stack, your go-to-market strategy, and your impressive early metrics. But somehow, you never made them feel why any of it matters.

This isn't a product problem. It's a story problem.

And it's costing founders millions in missed opportunities every day.

What You’ll Learn to Win Investor Belief

Over the last weeks, I've been Entrepreneur in Residence at a top-tier accelerator, mentoring 27+ startups through their idea generation and fundraising journeys. I've sat through 45+ pitch rehearsals, watched brilliant founders stumble over their own stories, and seen the exact moment when everything clicks.

In this capstone article, you’ll master:

• 😰 Why Founders’ Storytelling Break Down
  The common narrative traps that even brilliant founders fall into

• 🎯 F.U.N.D. Thinking
  A 4-part methodology that transforms feature dumps into inevitable futures

• 📊 Investor Psychology Stack
  A minute-by-minute breakdown of what’s happening inside an investor’s mind during your pitch

• ⚡ Advanced Storytelling Techniques
  Emotional pivots like “Day in the Life,” “Contradiction Reveal,” and “Inevitability Stack” that move your pitch from competent to compelling

• 🤔 When Your Story Lands vs. When It Doesn't
  Clear signals that show whether your story is working or falling flat

To keep this guide focused and digestible, several advanced tools and bonus breakdowns will be delivered exclusively via email FREE to all Product Voyagers subscribers 👇

• Fundraising Narrative Arc
  How your story should evolve from Pre-Seed to Series B+

• Your Next-Level Storytelling Toolkit
  A 47-point narrative assessment to catch every weak spot before your next pitch

• The Story That Launched a Unicorn
  A Simple way to frame its story!

• The Ultimate Pitch Audit Checklist
  With 47-point story assessment

• Your Pitch Transformation Playbook
  Including the 60-second story test and slide-by-slide story-first sequencing

Subscribe now

😰 Why Founder Storytelling Breaks Down

What I've observed after sitting through dozens of founder pitches, both successful and... not so successful:

A Feature Trap: Founders get lost explaining what they built instead of why it needed to exist.

The Metrics Maze: They drown investors in numbers without wrapping those numbers in stakes and consequences.

The Solution First Fallacy: They lead with their brilliant solution before making the problem feel urgent and inevitable.

The Audience Amnesia: They forget that investors aren't just buying products—> they're buying stories about the future.

Sound familiar 👀 ?
If you've ever walked out of a pitch feeling like you "explained everything perfectly" but somehow didn't land the room, you know exactly what I'm talking about.

🎯 F.U.N.D. Thinking

After analyzing what separates funded founders from overlooked ones, I've distilled it into four narrative pillars that build on each other for a storytelling architecture.

Let's break down each pillar:

F – Frame the Inevitable Problem

"Why This, Why Now?"

Don't just describe a problem. Make it feel inevitable and urgent.

❌ Weak Framing: "Small businesses struggle with inventory management."

✅ Inevitable Framing: "Right now, there are 32 million small businesses in the US. Every single one faces the same impossible choice: tie up cash in inventory they might not sell, or risk running out of what customers actually want. This isn't a business problem—it's a survival problem. And it's only getting worse as customer expectations accelerate."

🪄 Storytelling Secret: Use the "Scale × Stakes" formula. Show the magnitude (32 million businesses) plus the consequence (survival problem) to make the problem feel both urgent and universal.

U – Unpack the Failed Attempts

"Why Haven't Smart People Solved This Already?"

This is where most founders stumble. They skip over existing solutions because they want to look unique. Big mistake.

Investors are thinking: "If this problem is so obvious, why hasn't someone else solved it?" Address this head-on.

✅ Smart Unpacking: "Smart people have tried to solve this. SAP built enterprise systems but they cost $200K and take 18 months to implement. QuickBooks added inventory features, however they're designed for accountants, not operators. Spreadsheets work until you hit 100 SKUs, then they become your biggest liability.

The problem isn't lack of solutions. It's that every solution was built for the wrong user, with the wrong constraints, at the wrong time."

🪄 Storytelling Power: By acknowledging existing solutions, you're not showing weakness → you're showing market validation. Then you explain why timing, technology, or approach creates a new opportunity.

N – Navigate to Your Unique Solution

"Here's What Changed Everything"

This isn't about features. It's about the unique insight that makes your approach inevitable.

❌ Feature Dump: "Our platform uses AI to predict demand, automate reordering, and optimize cash flow with real-time analytics and customizable dashboards."

✅ Insight Navigation: "Here's what we realized: small business owners don't want to become inventory experts. They want to focus on customers. So instead of building another dashboard, we built invisible intelligence. Our system learns from every transaction, every season, every trend and makes inventory decisions feel effortless.

When a local café owner can focus on creating the perfect latte instead of counting coffee beans, that's when you know you've solved the right problem."

🪄 Storytelling Technique: Lead with the insight ("they don't want to become experts"), then show how that insight shaped your approach ("invisible intelligence").

D – Demonstrate the Inevitable Future

"This is Where the World is Heading"

End with the future you're building toward. Make it feel both ambitious and inevitable.

✅ Future Demonstration: "In five years, every small business will have an AI-powered operations partner. Not because it's cool tech, but because the businesses that adopt it will outcompete those that don't. They'll have better margins, happier customers, and founders who can actually sleep at night.

We're not just building inventory software. We're building the operating system for the next generation of small business success."

Subscribe now

📊 Investor Psychology Stack

Before we dive into advanced techniques, let's understand what's actually happening in an investor's mind during your pitch:

• Minutes 1-3: "Is this worth my time?"

• Minutes 4-8: "Do I believe this problem is real?"

• Minutes 9-15: "Is this team uniquely positioned to solve it?"

• Minutes 16-20: "Can this become a $100M+ business?"

Advanced Founder Storytelling Techniques

1. The "Day in the Life" Opening

Start with a specific person facing your problem in vivid detail.

"It's 6:47 AM. Sarah is already at her bakery, not because she loves early mornings, but because she's counting yesterday's leftover pastries. Again. Twelve blueberry muffins that didn't sell. $36 in ingredients that became $0 in revenue. She'll throw them away and hope today's guess is better than yesterday's.

This happens 32 million times a day, in small businesses across America."

2. The "Contradiction Reveal"

Highlight the paradox that makes your solution necessary.

"Here's the contradiction that caught our attention: small businesses have more data than ever before, but they're making decisions based on gut feel. Every transaction is tracked, every customer interaction is logged, every trend is measurable—but the typical restaurant owner still eyeballs their potato order on Sunday night."

3. The "False Choice" Frame

Show how the market presents impossible options.

"Every e-commerce brand faces the same false choice: hire a $150K data scientist or keep guessing what to order. There's no middle ground. Until now."

4. The "Inevitability Stack"

Layer multiple trends that make your solution feel inevitable.

"Three things are converging right now: AI models that can predict demand with 94% accuracy, supply chains that can fulfill orders in 24 hours, and a generation of business owners who expect software to just work. When these three forces meet, inventory management transforms from guesswork to science."

Metrics That Matter in Your Story

Investors want numbers, but numbers without narrative are noise.
Let’s weave metrics into your story

• Problem Metrics (Frame the Scale)

  • "32 million small businesses"

  • "$1.1 trillion tied up in excess inventory"

  • "43% of restaurants fail in their first year"

• Solution Metrics (Prove It Works)

  • "94% demand prediction accuracy"

  • "Average 23% reduction in waste"

  • "Customers break even in 4.2 months"

• Future Metrics (Show the Opportunity)

  • "$50B inventory management market"

  • "Growing 23% annually"

  • "Less than 5% penetration today"

🪄 Pro Tip: Always pair big numbers with human consequences. "$1.1 trillion tied up" becomes more powerful when you add "that's working capital that could hire 22 million employees instead."

Common Founder Storytelling Mistakes

Let’s try to avoid them ALL

Mistake #1: Leading with Solution

❌ "We built an AI-powered inventory platform"

✅ "Small businesses waste $50B annually on inventory mistakes"

Mistake #2: Buried Lede Problem

❌ Spending 5 slides on market size before explaining the core problem

✅ Hook with specific pain, then zoom out to market

Mistake #3: Generic Competition Slide

❌ "Our main competitors are Excel, QuickBooks, and SAP"

✅ "Smart companies have tried three approaches, and here's why each falls short..."

Mistake #4: Metric Soup

❌ Rattling off 15 different growth metrics

✅ Choosing 3 numbers that tell a story progression

Mistake #5: Weak Future Vision

❌ "We want to be the leading inventory solution"

✅ "We're building the operating system for small business success"

When Your Story Lands vs. When It Doesn't

You Know Your Story is Working When:

• Investors ask about implementation, not explanation

• They start talking about "when you scale" instead of "if you scale"

• Follow-up questions focus on execution details, not concept validation

• They introduce you to portfolio companies facing similar problems

• The conversation shifts from "convince me" to "how can we help"

Red Flags Your Story Needs Work:

• "I don't understand what you do"

• "How is this different from [obvious competitor]?"

• "Who actually has this problem?"

• "What happens when [big company] builds this?"

• Lots of questions, no forward momentum

From Story to Funding: The Final Mile

Your job isn't to explain what you've built. It's to help them see the world you're building toward, and make them want to be part of creating it.

The best founder stories don't just secure funding but they secure believers.

People who champion your vision in partner meetings, introduce you to key customers, and help you navigate the inevitable challenges ahead.

If this guide helped you see your pitch in a new light, then imagine what the full toolkit will unlock. 🤓

Want the complete Product Storytelling toolkit? This is Part 7 of our comprehensive course → dive into the full series for frameworks, templates, and advanced techniques that turn product people into master storytellers.

Be A Prime Voyager, To get all Templates

You spent years learning that users want control. Click here, tap there, scroll down, fill out this form.

The entire discipline of UX rests on the assumption that people want to directly manipulate interfaces to get things done.

That assumption is not correct now.

• AI agents don't need your carefully crafted user flows.

• They don't care about your conversion funnels.

• They're not going to click through your onboarding sequence.

They're going to accomplish user goals through paths you never designed, using tools you never intended them to use.

If you're still designing interfaces like it's 2019, you're solving the wrong problem.

Subscribe now

What Are AI Agents and Why They Change Everything

Siri is not an agent. Alexa is not an agent. These are voice-activated search engines that respond to specific commands within narrow contexts. Real AI agents operate differently. They take complex, multi-step goals and figure out how to accomplish them.

You don't tell an agent to "book a flight." You tell it: "Find and book a round-trip flight to London for next month, balance cost and flight duration, add it to my calendar."

What happens next breaks every assumption about user interfaces.

Behind that single instruction, something unprecedented happens.
A primary agent spawns specialized sub-agents:

• A Research Agent scrapes flight data from multiple airlines and aggregators.

• A Planning Agent analyzes options against your preferences (avoiding red-eyes, preferring certain layovers).

• A Booking Agent interfaces with airline APIs to secure the ticket.

• A Communication Agent drafts booking summaries and handles notifications.

The user never clicks through a flight booking funnel. They never see the intermediate steps. They supervise a system of systems where outcomes aren't always predictable.

The agent might use tools you didn't design for it, or combine data in ways you never anticipated.

This is not an incremental improvement to existing interfaces. This is a completely different relationship between humans and software.

How to Design for Agents

If users aren't controlling every step anymore, what do we build? We build the cockpit. The navigation system. The dashboard that lets users supervise the journey. This is Agent Experience.

From Execution to Supervision

Users become managers instead of operators. They set goals, monitor progress, and approve, reject, or modify what the agent proposes.

Our interfaces must evolve from forms and buttons to dashboards and approval queues.

Language as Interface

In agentic systems, conversation replaces clicking. The prompt isn't just a query. It's the start of an ongoing dialogue.

How does an agent report progress? How does it ask for clarification? How does it present findings? These become core design problems.

Designing for Co-creation

The traditional handoff between design and engineering doesn't work anymore. Designers can't create mockups without understanding the AI's architecture, capabilities, and limitations.

What tools can the agent access? How reliable are they? What are the common failure modes?

This requires collaboration that goes deeper than typical agile workflows.

The Technical Reality

Building for AX means designing two interfaces simultaneously:

Human-to-Agent Interface This is where users oversee, approve, edit, and guide agent behavior. Think mission control, not task execution.

Agent-to-System Interface This is where agents interact with APIs, databases, and tools. This interface needs to be robust, well-documented, and optimized for machine efficiency.

Anticipating user needs changes completely. We must predict the most likely follow-up actions to agent outputs. If an agent drafts an email, the next steps are probably "send," "edit," or "save as draft." The UI must surface these actions contextually and efficiently.

Building successful agentic systems comes down to building trust. As we give more control to autonomous systems, our job is ensuring human users remain the ultimate authority. They need tools to confidently supervise, collaborate with, and trust their AI counterparts.

The era of Agent Experience is here. The question is whether you'll help define it or watch it happen to you.

Subscribe now

Agent Experience in the Real World

Agent Experience isn’t a theory-it’s already shaping how modern tools behave, and how people interact with them on a daily basis.

In Notion, users aren’t typing from scratch anymore. They’re prompting the AI to summarize meeting notes, rewrite paragraphs, or brainstorm bullet points. The work is no longer about typing-it’s about reviewing, adjusting, and steering the outcome. The writing interface now lives inside a dialogue box.

Replit’s Ghostwriter flips the role of a developer. Instead of building line by line, devs are guiding a coding assistant through intent. When the AI suggests code structure or highlights bugs, the human is supervising-not executing every step.

This isn’t automation of tasks-it’s augmentation of thinking.

On Shopify, merchants use Sidekick to manage stores more intuitively. They don’t fill out forms to run promotions-they describe their goals in natural language. Sidekick figures out the rest. What matters now isn’t how well the merchant understands the UI, but how clearly the agent understands the merchant.

Salesforce’s CXO Kat Holmes explains that true AX means designing systems both for AI agents and human supervisors. For instance, an agent might receive a customer request—say, changing a delivery time for a large appliance. To complete the task, the agent must coordinate across user profiles, shipping systems, inventory, and delivery partners.

The real UX challenge isn’t just building an agent that executes; it’s building the orchestration layer that coordinates subtasks, surfaces uncertainties, and lets humans intervene where needed .

And these are just the early signals.

Takeaways

In each of these cases, product teams had to reframe the core experience. The end user isn’t driving every action anymore. They’re partnering with the system-watching, course-correcting, and intervening when needed.

We’re moving from designing for task completion to designing for task supervision.

In this new world, AX isn’t a feature. It’s a philosophy.

It forces us to rethink how products are built, how trust is earned, and how users collaborate with systems that think, act, and decide.

The interface isn’t the journey anymore-it’s the checkpoint. And the winner won't be the company that adds agents the fastest. It’ll be the one that builds the clearest path to human authority.

Because when everything becomes automated, designing for when-and how-humans step in becomes the most important design challenge of all.

This is an open edition of The Product Voyagers. To unlock full playbooks, tools, templates and expert takes — go Prime and get everything in your inbox.

Be A Prime Voyager

📚Related Reads

stresses planning for human intervention as a user experience necessity, not just a safety net.

captures the core of Agent Experience by watching an app come to life from a simple prompt, with no traditional coding—just direction, iteration, and feedback. The story highlights a broader shift: product creation is moving from hands-on construction to guiding intelligent systems that interpret and act on human intent.

The AI Maker

How to Build Your First App With AI in 30 Minutes (Even If You Can't Code)

I was staring at my screen, watching an actual app come to life as I typed plain English descriptions. Sure, there were bugs to fix and iterations to make. But I was directing, not programming…

Read more

a year ago · 84 likes · 27 comments · Wyndo

If you're curious about AI agents and what really drives automation, grab a coffee and keep reading

It's 7pm on a Tuesday. Your brain feels like overcooked pasta, and you're about to send the most boring product update.

So, you're staring at a Slack message that needs to go out about the feature you just shipped, and you're about to type something riveting like: "We updated the dashboard with new functionality."

⛔️ Don't. Please.

This is the moment that separates product storytellers from feature announcers.

This is your 7pm Rewrite moment.

Why Tired Communication Fall Flat

When we're exhausted, we default to the easiest possible communication: feature lists. We describe what we built, not why it matters.

We announce updates instead of telling stories. We INFORM instead of INSPIRING.

Your audience is just as tired as you are. They're getting dozens of product updates, feature announcements, and progress reports every day. The last thing they need is another bland "we shipped X" message.

So What?! What they need is a reason to care.

Same Feature, Different Universe

BEFORE (Facts? Sure. Story? Zero.)

Nobody cared. Zero engagement. 😞
Let’s try the same update with a 3-minute rewrite and still at 7pm.

AFTER (The 7pm Rewrite)

Did you notice the difference? Same feature, completely different impact.

✍️ The 7pm Rewrite is just one of seven storytelling techniques we teach in our Product Storytelling course.

🎙 And soon, we’re going live on Substack to walk through all seven one by one, live and unscripted. Stay tuned.

There’s a Story Formula (60 Seconds)

When you're too tired to think creatively but need to communicate something important, use this model adapted from the best product storytellers:

1. Character (15 seconds): Who is struggling?

2. Conflict (15 seconds): What specific problem do they face?

3. Climax (15 seconds): What did we change/ship?

4. Resolution (15 seconds): What's the outcome/impact?

Example:

1. Character: "New users with limited budgets"

2. Conflict: "Can't find affordable options in our 10,000-product catalog"

3. Climax: "We launched price-first filtering"

4. Resolution: "23% fewer people abandon their first session"

Subscribe now

7pm Rewrite → 5-Step Transformation Process

When you catch yourself about to send that lifeless update, stop. Take 2-3 minutes and run through these steps to move from boring announcement to compelling story:

This isn't about transforming announcements into better stories that get remembered.

What Best Companies Actually Do

Companies are evolving their announcements to include more narrative.

OpenAI's ChatGPT Search Announcement:

"Getting useful answers on the web can take a lot of effort. ChatGPT can now search the web in a much better way than before. You can get fast, timely answers with links to relevant web sources, which you would have previously needed to go to a search engine for."

🪄 Analysis: They start with the user pain point ("Getting useful answers on the web can take a lot of effort") before explaining the solution.

Anthropic's Artifacts Launch:

"When a user asks Claude to generate content like code snippets, text documents, or website designs, these Artifacts appear in a dedicated window alongside their conversation. This creates a dynamic workspace where they can see, edit, and build upon Claude's creations in real-time, seamlessly integrating AI-generated content into their projects and workflows."

🪄 Analysis

• User-centered: "When a user asks Claude to generate..."

• Visual: "appear in a dedicated window alongside their conversation"

• Outcome-focused: "seamlessly integrating AI-generated content into their projects and workflows"

From Feature Factory to Problem Solver

When you use the 7pm Rewrite, something interesting happens.

Instead of thinking like a feature factory ("We built thing X"), you start thinking like a problem solver ("We helped person Y with struggle Z") - It’s named “A Psychological Shift” .

→ Your stakeholders stop seeing you as someone who ships features and start seeing you as someone who solves problems.

→ Your team stops feeling like they're building in a vacuum and starts feeling like they're making real impact.

→ Your customers connect emotionally with your product updates instead of just scanning them.

Subscribe now

When! to Use 7PM Rewrite

• Slack updates about new features

• Email announcements to stakeholders

• Product briefs for leadership

• Release notes for customers

• Progress reports to investors

• Internal presentations about roadmap wins

Basically, anytime you're about to communicate something important but your brain is too fried to think creatively.

What! Common Mistakes to Avoid

Don't start with technical specs - Lead with the human problem, not the solution architecture.

Don't bury the impact at the end - Put the outcome upfront where people will actually see it.

Don't make it about you - Avoid phrases like "We're excited to announce..." Focus on what changes for your users.

How! To Measure Success

You’ll know the 7pm Rewrite is working when people start replying to your announcements instead of ignoring them.

Look for more questions, shares, and references to your updates.

Over time, you’ll see faster feature adoption and fewer confused “what does this actually do?” follow-ups.

The real goal is turning announcements people scroll past into stories they remember.

Resources and Further Reading

• Slack Updates and Changes - Examples of product communication in action

• OpenAI Feature Announcements - Study how AI companies frame their features

• Anthropic's Artifacts Launch - Master class in feature storytelling

• Product Update Best Practices - Comprehensive guide to effective product announcements

Unlock Storytelling In Product Full Course

Want more like this? Subscribe to unlock the full “Storytelling in Product” course.
7 parts, hands-on, and made for product people like you.

Be A Prime Voyager

A 7-part, hands-on course that turns everyday communication into powerful mini-narratives.

When Data Fails to Speak

Some time ago, a senior business leader — let’s call her Anna — invited us to a meeting to present her refreshed strategy. It was a big moment: she had just taken over a team that had been drifting without clear direction. The meeting was meant to align product, design, engineering, and business on a new path forward.

Before the session, she shared a deck as a pre-read. Curious, I opened it right away. After scrolling through the first few slides, I glanced at the sidebar.

Ninety slides? Really?

Still, I gave it a shot.

The beginning covered business performance, including how different markets were doing, what looked promising, and where things were lagging.

However, I got lost quickly in the flood of numbers. Page after page of charts, percentages, A vs B vs C vs D… all without a clear takeaway.

I hoped the live presentation would bring it to life. It didn’t.

Anna walked us through the deck, slide by slide, until a senior engineering leader finally said what many of us were thinking:

I don’t understand how to read these numbers.
What are they telling us, and what should we prioritize?

The moment was honest and devastating. The alignment goal dissolved into silence. Anna took on the challenge, answered some questions and wrapped up the call saying, It seems we’re aligned. But in reality, we weren’t.

What Went Wrong?

Anna believed that “you can’t argue with data.” In theory, she was right. In practice, it was a mess.

Her slides were packed with:

• 1–2 sentence long headlines and numbers

• Tables comparing multiple variables

• Dozens of graphs without clear conclusions

There was no main message. Just data, detached from story, impact, or decisions.

Unfortunately, I’ve seen this happen in many product presentations. Product managers often have the data. What they lack is the story.

So let’s talk about how to fix that.

Start Here: The 3 Golden Rules of Data Storytelling

If you remember one thing from this article, let it be this: your job is not to present data — it’s to make it stick.

Subscribe now

Here are three golden rules to help you do that:

🥇 1. Choose Three Numbers. Repeat Them Relentlessly.

Pick the three most important numbers you want your audience to remember. These numbers should tie directly to:

• A real problem

• A clear opportunity

• A decision that needs to be made

And then? Repeat them.

Say them early (in your intro), reinforce them through the body of your deck, and say them again at the end. A good product story doesn’t bury the lead — it drives it home.

📌 Example:

42% of new users drop off before completing onboarding. That’s nearly half of our potential customers walking away before they even see the product — which is why simplifying onboarding is our top priority this cycle.

Only 9% of orders use the new reordering feature — despite it being built for 60% of our most frequent users. That gap shows we have a discoverability problem, not a functionality one — which is why we’re testing new entry points this month.

🥈 2. Tell a Story, Not a Spreadsheet

Data without structure is noise. Frame your narrative using a simple arc:

• Problem — What’s broken or painful for users?

• Pattern — What’s the data telling us?

• Opportunity — What can we do about it?

Drop the temptation to go slide-by-slide through analysis. Lead people through a journey.

Bonus tip: Pair your data with a moment. For example:

Imagine trying to order baby food at 2am, and the app shows dog food instead. That’s what 22% of new parents are experiencing.

Now your numbers have a heartbeat.

🥉 3. Tailor the Story to Your Audience

Different people care about different things.

• Your VP wants to know: how does this impact revenue, users, or strategic direction?

• Your engineers want: what’s technically feasible and what tradeoffs are involved?

• Your designers want: what’s the user behavior and pain?

Don’t deliver the same story to every stakeholder. Reframe the same data based on who’s in the room.

🎯 Tip: Before presenting, ask yourself:

What does this person care about? What decision do they need to make?

From Raw Data to Resonant Narrative

Let’s break down the craft of building your data story.

1. Start with a Hypothesis

Before diving into the data, be clear on what you’re looking for. Data is endless. Direction is not.

Ask:

• What am I trying to prove, disprove, or explore?

• Which data points help me do that?

📌 Example:

Hypothesis: Users abandon cart due to surprise fees.
Data: Drop-off rates at fee step, feedback comments, impact of free shipping tests.

2. Highlight Your Methodology (Even Briefly)

Especially when working with experimentation, mixed data sources, or limitations — tell people how you got the data. This builds credibility and keeps the room grounded in reality.

Even a simple line can help:

We ran this A/B test across 12 markets, holding constant for delivery zones.

Or:

This data excludes one market due to tracking gaps — but the pattern is consistent across all others.

3. Blend Quant with Qual

Some insights need numbers. Others need a voice. Use support tickets, user quotes, or screen recordings to reinforce key patterns. This gives texture to your story.

📌 Example:

Only 3% of users who start filtering by dietary preferences end up placing an order. One user told us: ‘I couldn’t tell what’s vegan and what’s not. I gave up and used a different app.’

4. Be Honest About Gaps and Contradictions

Sophisticated data storytellers don’t hide weak spots —t hey highlight them thoughtfully.

📌 Example:

Interestingly, while conversions improved 12%, average order value dipped. We believe it’s due to the placement of promotional items, but we need to investigate further.

This builds trust. It also invites collaboration.

5. Use Storytelling Beyond Presentations

Data storytelling isn't just for fancy decks. You can (and should) apply it in:

• Roadmaps: Use data to justify priorities

• PRDs: Anchor your feature rationale in observed patterns

• Decision logs: Summarize trade-offs clearly with numbers

• OKR reviews: Reflect on progress with a story arc, not just a table

Wherever decisions are made — storytelling belongs.

Final Thoughts: Your Data is only as Good as the Story it Tells

As product managers, we don’t just work with data. We advocate with it.

The best stories don’t overwhelm. They clarify.

So next time you prepare to “present data,” ask yourself:

• What are the 3 numbers I want everyone to remember?

• How does this story unfold?

• Who am I speaking to — and what do they care about?

Data is powerful. But only when it’s felt, not just seen.

Share

You’ve just read Part 5 of our 7-part Storytelling Sprint 🤌
If this clicked, don’t stop here. Catch up on what’s already dropped 👇 and get ready for what’s next: the tools, tactics, and our full storytelling cheat sheet 🧠

Be A Prime Voyager

… Storytelling Sprint 🤌