You've been asked to own an AI feature. Maybe you raised your hand. Maybe it landed on your plate because nobody else wanted it.

Now you're responsible for something that feels like product management, but occasionally behaves like something else entirely.

Most PMs approach AI tools the same way they’d approach any other software. That works, until it doesn’t. And when it doesn’t, the failure mode is usually the same: you built something technically functional that nobody trusts, produces wrong answers at the wrong moments, or falls apart the second it faces a situation nobody anticipated.

Petra Wille wrote an article that stuck with me. Four ideas in particular. Here they are.

How would a human do this task?

Before you think about AI, reverse-engineer the human workflow. What information would a person look at? What judgment would they apply? In what order? When would they do the task, and when wouldn’t they?

This matters more than it sounds. If you skip it, you end up automating a process you don’t fully understand. That’s a recipe for an AI tool that works in demos and breaks in practice.

What context does the AI need, and how does it get there?

AI tools don’t just need instructions. They need a context delivery system. A system prompt is part of it, but only part. Think about retrieval: when does the tool search for additional information, and how? What other tools can it access? What should it remember between interactions, and what should it intentionally forget?

These are product decisions. Not engineering decisions. Most PMs underestimate how much design work lives here, and then wonder why the tool behaves inconsistently.

Who’s in the loop, and when?

Full automation isn’t always the right answer. There’s a spectrum: human in the loop, human on the loop, fully automated. Where you land depends on how much users trust the machine, how costly mistakes are, and how easy it is to correct the tool when it gets something wrong.

This is a deliberate product choice. Don’t let it become a technical default.

How do you measure if it’s actually working?

This is where AI diverges most clearly from traditional software. Iteration for AI includes evaluations. You need to measure accuracy, latency, and cost. Hallucinations are an accuracy problem. Slow responses are a latency problem. Both affect whether users trust the tool enough to keep using it.

Search for “evals” and you’ll find a growing body of practice. Get familiar with it before you need it.

AI product management is familiar enough to feel approachable. Different enough to catch you off guard. These four ideas are a useful place to start.

Subscribe now

Did I write the exact opposite recently ? No! Read again, there is no contradiction.

What I read

As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >900) at https://www.digital-product-management.com. These are today’s picks:

New Manager: Now the team is your product: Transition from individual product delivery to coaching and developing high-performing teams as a core leadership responsibility.

The Multiplier: What Leaders Are Actually Paid For: Leaders must generate returns above baseline expectations by designing systems and coaching teams rather than maintaining technical superiority.

Laws of Software Engineering: Collection of principles and patterns shaping software systems, team structures, and technical decision-making processes.

Benefits

Save 20 USD when subscribing to Proton: Secure, end-to-end encrypted email, calendar, drive and more.

Save 10% on the first month when subscribing to Krater.ai: Every AI You Need.
One Subscription.

There is a document sitting in your inbox right now. Fifteen pages. Maybe twenty. Someone spent time on it, or at least, something did. You know you need to read it. You know you probably won’t. And somewhere, the person who sent it is wondering why nobody responded.

This is the quiet crisis nobody is talking about loudly enough.

The document inflation epidemic

AI has made it effortless to generate text. Beautiful, structured, confident-sounding text. And people are using that power generously. Too generously. Documents that could fit on one page now arrive as fifteen. The bar for “done” has shifted, and not in a good way.

More pages feel like more effort. More effort feels like more value. But that feeling is a trap. Length is not depth. Volume is not thinking.

The irony nobody mentions

Here is where it gets truly absurd.

I now use AI to summarize the documents that others used AI to write. We have built a closed loop: a document laundering machine where AI inflates on one end and AI compresses on the other. No human is actually reading anything in full anymore. The content bounces between two machines while the real thinking quietly evaporates. And yet we keep sending each other novels.

What this actually costs us

The deeper cost is clarity. When real decisions are buried under pages of padding, accountability disappears. Nobody can point to the argument because nobody can find it.

A long AI-generated document can hide the fact that the author never thought deeply about the problem at all. Length becomes a disguise, and a very convincing one.

Just show me the prompt

It sounds simple, but it carries real weight. If you used AI to write a document, your prompt is the truest artifact of your thinking. A sharp, specific prompt shows that you understood the problem. A vague prompt shows that you did not. Asking for the prompt cuts straight to what matters, faster than reading twenty pages ever could. It is not rude. It is the most respectful thing you can do with someone’s time.

What good looks like

Set expectations early. One page is almost always enough. Two pages should be a conscious choice. If someone sends you twenty pages, ask for a one-page summary before you invest your time. That is not laziness, that is good judgment.

When you use AI yourself, prompt it explicitly for brevity. And reward teammates who communicate with precision. Volume for its own sake helps nobody.

Reclaim your attention

Your attention is the scarcest resource you have. Do not hand it over to documents that were generated for the appearance of effort rather than the transfer of ideas.

Push back. Demand clarity. And the next time a massive document lands in your inbox, try asking one simple question.

Just show me the prompt.

Subscribe now

What I read

As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >900) at https://www.digital-product-management.com. These are today’s picks:

Cross-Functional Teams vs. Teams of Functions: Distinguish between superficial functional silos and high-performing cohesive units.

AI Menu: Definition of Prompts, Skills, Workflows, and Agents: Categorize AI capabilities by autonomy levels to avoid building the wrong products and ensure measurable financial returns.

Irrational Intelligence: The Shadow Organization and AI: Explores the structural similarities between organizations and AI. Highlighting the informal human dynamics that drive actual decision-making.

Benefits

Save 20 USD when subscribing to Proton: Secure, end-to-end encrypted email, calendar, drive and more.

Save 10% on the first month when subscribing to Krater.ai: Every AI You Need.
One Subscription.

You have probably heard it by now: AI is coming for the PM role. Some say it will shrink the job. Others say it will eliminate it entirely. And if you are honest with yourself, there is a part of you that wonders whether they might be right.

Let’s settle this. Because the answer is not complicated. It is just buried under a lot of hype.

What actually changed, and what didn’t

Generative AI is a new tool. A genuinely powerful one. It can help you synthesize research faster, draft documents in minutes, and surface patterns you might have missed. Smart PMs are already using it, and they should be.

But what didn’t change is the thinking. The carpenter who gets a better saw still needs to understand what the customer wants built. The saw makes the work faster. It does not replace the judgment behind it. The same logic applies to every PM who picks up an AI tool today.

What is the PM job, actually?

Strip away the jargon and the frameworks. The job looks the same whether you are building a traditional SaaS product or an AI-powered one:

• Understand your customer deeply. Not just their stated needs, but the problems they cannot always articulate. That requires real conversations, careful observation, and genuine curiosity. No model does this for you.

• Create value for that customer. Value means enabling something they could not do before, or solving a problem that was costing them time, money, or frustration. Vague value propositions don’t ship.

• Create value for your company. A product that delights users but destroys margins is not a success. The business side is just as much your job as the customer side.

• Make it usable. Great ideas that nobody can figure out how to use are just expensive experiments.

• Build a business model that works. How does this product make money? Who pays, when, and why? These questions do not answer themselves.

• Define your go-to-market strategy. Who are you selling to, through which channels, with what message?

• Know your ICP. Trying to build for everyone is the fastest way to build for no one.

Why the “AI will kill PM” argument falls apart

This claim comes up constantly. On LinkedIn, on Reddit, in Slack channels. It sounds plausible at first. And then you think it through.

The job still needs to be done. Someone still needs to talk to customers, make sense of what they hear, decide what to build next, align stakeholders who disagree, and take responsibility when the call turns out to be wrong. AI does not do any of that. It assists. It accelerates. It surfaces information. But it does not decide, and it does not own the outcome.

Saying AI will eliminate the PM role is like saying GPS eliminated the need for drivers. Navigation got easier. The driving still requires a human making real decisions in real time.

What does a PM actually look like in an AI world?

More powerful. Not obsolete.

AI handles the repetitive and the mechanical. The summarizing, the drafting, the first pass at analysis. That frees up time and mental energy for the work that actually moves products forward.

What fills that space? The things AI cannot replicate. Taste: knowing what good looks like, even when the data is ambiguous. Differentiation: making choices that are not obvious, that competitors have not made. Courage: committing to a direction when reasonable people disagree and the outcome is uncertain. Judgement: knowing which signal to trust and which to ignore.

These are not soft skills. They are the job. They always were.

The PMs who will struggle are not the ones replaced by AI. They are the ones who never understood what the role actually required in the first place.

Subscribe now

What I read

As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >900) at https://www.digital-product-management.com. These are today’s picks:

The Leadership Leap We Don’t Talk About: The Leadership Domains framework distinguishes between functional and organizational leadership work.

Why your team keeps shipping products nobody buys: Aligning go-to-market strategy with product discovery prevents the gap between shipping features and achieving market success.

Displacement of Cognitive Labor and What Comes After: Artificial intelligence fundamentally shifts human identity, productivity ratios, and the nature of intellectual work through iterative collaboration.

Benefits

Save 20 USD when subscribing to Proton: Secure, end-to-end encrypted email, calendar, drive and more.

Save 10% on the first month when subscribing to Krater.ai: Every AI You Need.
One Subscription.

A while ago, Benedikt published a post, “The Scrum decline: It’s three years later, and I was right”, about Scrum dying but Agile being alive. I agree with both, and especially the latter. Through the 2010s, Scrum became the default tool, and in most people’s heads, the two fused: Scrum = Agile. Kanban was around, too, but it felt more exotic. So the logic ran: if you want to be Agile, you do Scrum.

Back in the day, Scrum was revolutionary. We don’t need a full project plan; we can show progress and get feedback straight from the client. Hell yeah! But over time, the standard two-week sprint and the heavy ceremony started to feel like a chore rather than a source of flexibility. Then there’s the familiar failure mode: all the rituals in place, none of the agility. The classic situation — a fixed scope executed in sprints toward a fixed deadline.

My point is that Agile isn’t limited to Scrum. And Scrum only rarely, in my experience, very rarely, earns the name.

Benedikt proposes Shape Up as the alternative. I don’t think it’s a better one for most organizations.

Let’s start with the good. I see Shape Up as Agile for engineers: a small team, low meeting overhead, a six-week window to do real product work (design and code), plus dedicated time for technical debt and cleanup. Engineers get a long, uninterrupted stretch to focus, and they’re actively encouraged to keep the codebase clean. What’s not to like?

Quite a few things.

First, key product decisions sit with the shapers, not the team. Brief writing, evaluation, and betting all happen without the implementation team in the room. Scrum, for all its faults, keeps the product decision-maker inside the team’s loop: the Product Owner is present, reachable, and able to reprioritize mid-sprint. Shape Up pushes that decision upstream and freezes it: the bet is locked at the betting table, and the team then goes dark for six weeks. Yes, many Scrum implementations drift toward the same thing: the team is handed a feature, and the PO’s job is to slice it into stories and drop them in Jira. But even then, the decision-maker stays close and continuous, rather than upstream and frozen. Forced to choose, I pick Scrum, because the person who owns the “what” sits close enough to change course when reality does.

An ideal Agile team owns a value stream, not a feature or a brief. It has agency over what it delivers and how. Shape Up prescribes the what, and to some extent the how. I don’t like that.

My second problem is prescriptiveness. Shape Up is what 37signals built through years of iteration, and it fits their size, culture, and ownership structure. The key decision-makers are the company’s owners, and they sit at the betting table; they decide what gets done and how. The product is mature, the business is stable: no aggressive VC growth targets, no three-month runway, no shareholder pressure. They can afford eight-week cycles and a deliberate pace. More to the point, they can afford not to be able to redirect a bet mid-cycle, because they rarely need to. An early-stage company does. And yet this is exactly where the process keeps getting adopted, in companies where the ability to pivot on a week’s notice matters far more than a clean six-week block of focus.

None of this means Shape Up has nothing to offer. It introduces genuinely new concepts and gives them snappy names. The cooldown and the fixed-time / flexible-scope appetite may fit your context well. Or not. What I’d resist is blindly swallowing the whole process, shapers and eight-week cycles included, just because it works for 37signals.

I’m a fan of Agile as a principle. Adapting to internal and external feedback is the core of it, which is why I find it ironic when Agile coaches scold teams for not doing Scrum right. Isn’t that the whole point? Take what works, drop what doesn’t, fill the gaps.

Frameworks are a good starting point, nothing more. Adapt them to how you work; don’t bend the organization to fit the framework. The Agile Manifesto put it best: “Individuals and interactions over processes and tools.”

Thank you, Roman, for this response to my article! I‘m glad for our discussion.

Everyone who enjoyed this perspective: I deeply suggest you subscribe to Roman!

High-Impact Engineering

How to build and lead high-impact engineering teams

By Roman Nikolaev

Best,

Benedikt

Please like ❤️ and restack 🔁 this article so others can find it, too. Thank you!

Something is wrong, but you can’t quite name it. The frameworks are in place. Roadmaps are clean. You’ve read the books, done the conferences, and you genuinely know what good product work looks like. And yet it’s not working. The culture isn’t shifting. The org isn’t changing. And somewhere in the back of your mind, quietly, a question has been growing: is it me?

It isn’t. But the honest answer is more uncomfortable than simple reassurance.

Stephanie Leue, a respected voice in product leadership, put it plainly: you’re not doing it wrong. You’re playing a different game than the one the books describe. And until you understand which game you’re actually in, no amount of effort, good intentions, or borrowed frameworks will get you where you want to go. This thought stuck with me, so let’s elaborate a little.

The advice wasn’t written for you

Pick up almost any book on product transformation and you’ll find the same story told in slightly different words. A company decides to change. Leadership commits. Teams restructure. Culture shifts. Results follow. It sounds logical, because in the right conditions, it is. But those conditions are almost never named, because the people writing those books didn’t have to think about them. They were already there.

Most transformation stories come from companies that had some product mindset baked in from the start. The advice that grew from those stories sounds universal. Restructure your org. Fix the processes. Align the incentives.

It gets repeated at conferences, packaged into frameworks, sold in consulting decks. And it works, in those companies, because the soil was already prepared. What you’re doing is applying a perfectly good recipe in the wrong kitchen. And then blaming yourself when the dish doesn’t come out right.

What you’re actually trying to do

You are not failing at product transformation. You are trying to drive a company-wide culture shift from inside a single function, without the authority, the budget, or the mandate that a real transformation program would have. That is a fundamentally different challenge. One of the hardest things you can attempt inside a large organization, honestly. The people writing transformation playbooks mostly never worked under these constraints. They had executive sponsorship, dedicated resources, and organizations that were already leaning in.

Naming this clearly matters. Not as an excuse. As an accurate diagnosis. You can’t treat the right problem if you keep misidentifying it.

Start small, and actually mean it

The most realistic path forward is to shrink your ambition deliberately, at least at first. Not because you lack vision. Because small is what actually works in resistant environments. Pick one team. Let them operate differently than the rest of the organization. Give them clarity on what they’re trying to achieve and the space to figure out how. Bake the new culture into everyday decisions and conversations, not into big announcements or transformation programs with names and slide decks.

This will feel slow. Sometimes invisible. Your stakeholders may not notice for months. Your peers may not understand what you’re building. But quiet, consistent proof is more powerful than loud promises.

A team that delivers better outcomes, communicates clearly, and treats customers like real people becomes something rare inside a large org. It becomes a reference point. People start to notice. They start asking questions. That’s the beginning of real spread. And it’s far more durable than anything you could have announced in a company-wide kickoff.

Trust people before they’ve earned it

This one is counterintuitive, and it makes some people nervous. The idea is simple: extend trust before it has been formally earned. Not recklessly. But intentionally, and in steps. Let someone own a decision they wouldn’t normally be allowed to make. Let another person represent the team in a room they’ve never been in before. Let a junior team member talk directly to a customer without you there. Each of these moments sends a signal that no culture document ever could.

People rise to the level of trust they are given. Not the level they are tested for. When someone feels genuinely trusted, they start behaving like the culture you’re trying to build, rather than the one that already exists around them.

Build one team this way. Make it a place where people feel real ownership, genuine clarity, and enough psychological safety to say when something isn’t working.

Then step back. Let others watch. Curiosity and quiet envy are far stronger change agents than any top-down mandate, and they cost you nothing.

Don’t burn out before the culture spreads

This is the part that doesn’t get written about enough. Good culture spreads on its own. But slowly. The real danger here isn’t that your strategy is wrong. It’s that you exhaust yourself, or spend your political capital too early, before the culture has had time to take root and become self-sustaining. And once you’re out of either resource, the whole thing stalls.

So be deliberate about where you spend your energy.

Take the loneliness seriously too. Not as something to overcome, but as something to plan for. Nobody will fully understand what you’re doing until it’s already working. Colleagues will question your pace. Leadership will push for faster results. You’ll spend a lot of time explaining a vision that hasn’t materialized yet to people who are, understandably, skeptical. That pressure is real. But it doesn’t mean you’re wrong. It means you’re doing something most people around you haven’t seen done before, and haven’t yet learned to trust.

You’re further along than you think

It’s easy to measure your progress against the polished transformation stories you’ve read, and feel like you’re standing still. But those stories are told in retrospect. Clean narratives. Clear turning points. They skip the years of quiet, frustrating, invisible groundwork that made them possible. You are in that part of the story right now. It doesn’t look like progress because progress at this stage rarely does.

Start with one team. One decision you hand over. One person you choose to trust a little further than feels entirely comfortable. That is not a small or timid beginning. That is exactly how this starts. And for the kind of change you’re trying to make, it may be the only way it ever does.

Please like ❤️ and restack 🔁 this article so others can find it, too. Thank you!

Subscribe now

What I read

As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >900) at https://www.digital-product-management.com. These are today’s picks:

With AI, Ship Less: Prioritize high-impact outcomes over feature velocity as AI reduces the cost of building and increases the risk of bloat.

Product Context Driving Growth: Use AI to transform existing product documentation and decision logs into reusable, situation-ready answers that accelerate growth.

Why Estimates Fail (And Why You Still Need Them): Navigate the tension between engineering uncertainty and organizational needs by using estimation as a communication tool rather than a deadline.

Benefits

Save 20 USD when subscribing to Proton: Secure, end-to-end encrypted email, calendar, drive and more.

Save 10% on the first month when subscribing to Krater.ai: Every AI You Need.
One Subscription.

Subscribe

“Great job with the presentation! Just change [X], [Y] and [Z] and it will be ready to go.”

You noticed what could be improved and you jumped in. You demand and expect excellence from your team and excellence was that extra tweak to the slides. You have been doing this for years and you were the only one who could catch this - and that’s why you intervened.

You did the right thing.

Did you?

What happens when you intervene

No, you didn’t.

When you intervene, you steal part of the other person’s accountability for yourself, diminishing their sense of ownership.

Think of it this way: if you invite friends for dinner and they bring the ice cream, that’s fine. But if they bring the appetizer, the first and second course, the ice cream and the wine, it goes from being “your dinner” to “their dinner at your house”. Being educated, you will still go through the motions and smile, but your heart will no longer be in it.

And so he will thank you and implement the suggestion, but he will be disconnected and will withhold the discretionary effort necessary to go from average to great.

And so he will not exert any effort, because waiting for you is cheaper and safer. He will be an addict to your heroin. You will be exhausted for being everywhere and satisfied for still being the best at your craft. In reality, you are the bottleneck and the cap on what your team can achieve.

And so he will not level up, because learning happens in the last, uncomfortable, 10% and you are taking that away. He will sit comfortably, avoid stress and call it work-life balance. You will keep the team sheltered and safe, believing you are being a very good manager indeed. In reality, the team stalls and you are the culprit.

The team’s capabilities will drop and the multiplication of output you should be after as a manager will never happen.

The pushback

“I am their manager, of course I need to intervene! Otherwise, what do I do!? Should I just accept subpar output to preserve my team’s ego?”

You exist to multiply your team’s overall output, not to maximize the single unit of work.

To achieve it, the whole team needs to own whatever it is that they do, which will push them to level up; if you step in, you remove the very ownership needed to multiply.

That said, “not stepping in” differs from “abdicating any responsibility and standard” - in practice:

• instead of giving them the answer, provide them the context and the mental models to reach an acceptable solution themselves;

• instead of fixing the slides, explain why it’s important to make them a certain way and ask them to revise their work accordingly;

• instead of telling them how you would present to the group, tell them what you expect the presentation to deliver, walk them through the few key concepts necessary to present well and let them build their own script and presentation style.

So when should you intervene?

If a decision is consequential AND irreversible, then you MUST step in.

• Consequential: the decision has actual impact.

• Irreversible: the cost of reversing the decision is high.

Here you cannot afford to go wrong, because the damage is real and going back costly. In these cases, stepping in is required and to hell with the team’s sense of ownership; in any case, if you’ve let them decide on everything else, they will have enough in their ownership bank account to survive a withdrawal.

Every other decision, either inconsequential or reversible or both, should be left to the team.

If it’s consequential but reversible, it will have an impact, but it will be relatively easy to change. If it’s irreversible but inconsequential, you won’t be able to change it, but who cares anyway.

Spoiler: 90% of the decisions fall in this group.

Graphically:

The temptation to step in and improve things is always there.

And yet, every time you do it, you lower the team’s capability and ownership, creating long-term damage.

Tread carefully.

Thanks for reading,

Luca

And thank for writing for Leading in Product, Luca!

Benedikt

There’s a widespread belief in working data-driven, meaning that opinions shouldn’t dictate direction on their own. When you have data on one side and opinions on the other, conventional wisdom says data should always win.

Product Sense is a form of intuition built over time

This is largely true, yet there’s something equally powerful I’ve come to appreciate: “Product Sense”. It’s a form of intuition that’s fueled by deep customer understanding and sharpened through experience. You develop product sense by making countless decisions and carefully observing their outcomes over time. Eventually, you’ll gain the ability to predict how customers typically react, how they naturally approach problems, and which solutions are most likely to succeed in real-world scenarios.

Product sense doesn’t replace data, just as data cannot substitute for intuition. But it serves as an invaluable corrective when something doesn’t add up. Consider questioning your data-driven decisions and relying on product sense in these situations: when quantitative data feels somehow wrong or incomplete, when the data fails to provide clear direction, when you haven’t been able to test the most critical aspects, or when you’re choosing between multiple UI options that perform similarly.

How to use your product sense

1. Generally speaking, if you’re an experienced senior expert who has spent years in product management and something feels off, that’s your product sense speaking. And you should listen carefully. In my observation, time spent specifically in product roles matters more than general industry experience, because much of product intuition transfers surprisingly well across different industries and domains.

2. If you’re not yet the senior expert yourself, you can still leverage other people’s product sense effectively. When working with a seasoned colleague who seems unconvinced by your ideas or appears reluctant for reasons they can’t immediately articulate, that might be their product sense raising red flags. Dig deeper in those moments.

What if you feel a that something is off?

What should you do when you encounter this dissonance between data and intuition?

• Dig deeper into the problem.

• Conduct more experiments

• Schedule additional customer interviews

• Track specific (additional) metrics in your product analytics tool

• … and work to understand what users genuinely care about beneath the surface-level metrics.

This dissonance is a signal that shouldn’t be ignored but rather investigated until you resolve the underlying tension between what the data shows and what your experience suggests.

What I Read

As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >900) at https://www.digital-product-management.com. These are today’s picks:

One Minute Pitch: Template for creating good elevator pitches.

Communication is The Job: Communicating successfully.

Guiding the future of ethical design: How to translate philosophical theory into practical design principles and responsibility.

Benefits

Save 20 USD when subscribing to Proton: Secure, end-to-end encrypted email, calendar, drive and more.

Save 10% on the first month when subscribing to Krater.ai: Every AI You Need.
One Subscription.

You drag yourself through meetings, struggle to stay motivated, and wonder if you’ve lost your edge. But most people miss that it’s not you. It’s the mismatch between your working style and your company’s operating model.

I’ve watched brilliant engineers and product managers burn out not because they lacked skills, but because they were fighting their environment every single day. The problem? They never identified what was draining them.

Companies operate in two fundamentally different ways: relationship-driven or process-driven. Both models can build billion-dollar businesses. Both can create incredible products. But they demand completely different skills from their people. Get this wrong, and you’ll spend years pushing against a current that never stops.

What makes companies relationship-driven?

In relationship-driven organizations, your network is your operating system. Work happens through conversations, trust, and knowing exactly who can unblock you. That critical feature launch? It moves forward because you built rapport with the engineering lead over coffee, not because you filled out a request form.

These companies have processes on paper. But nobody really follows them strictly. Instead, people rely on relationships to take care of ambiguity and get things done. You pitch ideas in hallway conversations. You resolve conflicts through direct dialogue. You influence outcomes by understanding people, not by citing policy documents.

This environment rewards specific traits: social intelligence, adaptability, comfort with ambiguity, and the ability to build trust quickly. If you’re energized by spontaneous collaboration and thrive when reading between the lines, you’ll excel here. But if you need clear guidelines and structured workflows to feel secure? You’ll constantly feel off-balance.

What makes companies process-driven?

Process-driven organizations run on systems, not relationships. Clear documentation defines how work flows. Established procedures determine who approves what. Your success depends on understanding the playbook and executing it precisely.

Yes, relationships still help. Having allies makes work more enjoyable. But they won’t shortcut the process. Need a design review? There’s a form, a timeline, and specific stakeholders who must sign off. Your friendship with the design director doesn’t change that sequence.

These companies attract people who value predictability and clarity. You know exactly what’s expected. You understand how decisions get made. You can plan your work because the system is transparent and consistent.

If you’re someone who gets anxious without structure or frustrated by unclear expectations, this environment will feel like home.

The trade-off? Less flexibility. Less room for intuition. More documentation. More waiting for approvals. Some people find this reassuring. Others find it suffocating.

Why neither model is better

There are scrappy relationship-driven startups that outmaneuver corporate giants through speed and adaptability. Some of them collapse when they scale beyond the point where everyone knew everyone. Relationships don’t scale infinitely.

Conversely, I’ve seen process-driven companies achieve remarkable consistency, shipping quality products quarter after quarter through disciplined execution. I’ve also seen them become so bureaucratic that innovation died under layers of approval processes.

Success isn’t about the model itself. It’s about execution, leadership, and whether the model fits the company’s stage and market. A five-person startup needs relationships. A 10,000-person enterprise needs processes. The model must match the reality.

The real question: Where do you fit?

This isn’t about which model is better. It’s about which one matches who you are.

Your personality, your strengths, your natural working style. These determine where you’ll thrive.

Are you someone who needs structure to perform your best? Do you feel more confident when expectations are crystal clear? Do you prefer following established best practices over inventing new approaches? Process-driven companies will energize you.

Or do you come alive in dynamic environments? Do you enjoy building relationships and navigating through conversations? Does rigid structure feel constraining? Relationship-driven companies will feel natural.

The energy test never lies

The most reliable indicator is your energy level.

In the right environment, even challenging work energizes you. You finish tough days tired but satisfied. Problems feel like puzzles to solve, not walls to hit.

In the wrong environment, everything drains you. Simple tasks feel heavy. You’re constantly translating between how you naturally work and how the company expects you to work. That translation burns energy continuously.

Pay attention to this signal. It’s your body telling you something important about fit.

What this means for your career

Understanding yourself is not optional. It’s the foundation of career satisfaction.

You need honest answers to hard questions: What energizes me? What drains me? Where have I felt most alive professionally? What patterns emerge?

Then choose accordingly. Interview companies not just for role and compensation, but for operating model. Ask how decisions get made. Ask how teams collaborate. Ask what makes people successful there. Listen for clues about whether it’s relationship-driven or process-driven.

Your career is too long and too important to spend it fighting your environment. Find the fit. Your success depends on it.

What I read

As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >900) at https://www.digital-product-management.com. These are today’s picks:

Product Credibility Gap: “Moving from “”Feature Writer”“ to “”Business Partner”“ to close the gap.”

Return to the Office: What’s in It for Me? An analysis of hybrid work trends and how to design office experiences that balance flexibility with collaboration.

The “Be More Strategic” Trap: How to transition from tactical execution to strategic thinking through business-oriented storytelling and pattern recognition.

(Sorry, two links to Stephanie Leue this time, but she’s bringing too much great content to skip it!)

Benefits

Save 20 USD when subscribing to Proton: Secure, end-to-end encrypted email, calendar, drive and more.

Save 10% on the first month when subscribing to Krater.ai: Every AI You Need.
One Subscription.

You’ve been shipping. Fast. The roadmap is moving, the tickets are closing, and the team is delivering. By every visible measure, things are going well.

So why does something feel off?

Features aren’t landing the way you expected. Users aren’t behaving the way you assumed. The product keeps growing and somehow getting less useful at the same time. You’re moving in a direction. Just not sure anymore if it’s the right one.

There’s a name for what’s happening. And it’s not what your engineers bring up in sprint planning.

It’s called discovery debt. Unlike the kind of debt your team knows how to talk about, this one accumulates silently until the bill arrives.

What is discovery debt?

Discovery debt is the sum of all the assumptions you’ve made, the customer problems you haven’t validated, and the market insights you’ve kept telling yourself you’ll get to eventually.

Every time you built a feature because a stakeholder asked for it, without checking if customers actually needed it, you took on discovery debt. Every time you skipped user research to hit a deadline, you borrowed against your product’s future. Every time someone said “we know our users” in a room where nobody had talked to a user in months, you added to the balance.

Unlike technical debt, which your team feels as friction and slowness, discovery debt is invisible. It doesn’t show up in build times or sprint velocity. It shows up six months later, when a feature nobody uses is now load-bearing infrastructure. Or when a competitor quietly solves the problem you didn’t realize your users actually had.

Technical debt slows you down. Discovery debt sends you in the wrong direction entirely. That distinction matters more than most teams realize.

How does discovery debt compound?

Here’s the thing: it doesn’t accumulate linearly. It compounds.

Every unvalidated assumption becomes the foundation for the next decision. You assume users want feature A. You build it. Now you’re designing feature B to extend feature A, still without talking to users. Then feature C to fill the gap that A and B created. Three decisions deep, and the original assumption has never been tested. Not once.

Each skipped discovery session also makes the next one harder to justify. When you’ve shipped six features in a row without validation, stopping to do research feels like going backwards. The team is in delivery mode. The roadmap is full. “We can’t afford to slow down right now” becomes the default answer, even as the debt quietly compounds.

And every feature built on assumption adds complexity. Your product gets bigger, harder to navigate, less focused. You’re not just wrong. You’re expensively, intricately wrong and the product itself is now the evidence.

Why do smart teams keep accumulating discovery debt?

This isn’t a story about lazy PMs or negligent teams. Discovery debt accumulates in good teams, at well-run companies, with people who genuinely care about what they’re building.

It accumulates because the pressures are real. Deadlines are not invented. Stakeholders are not patient. The sales team needs something to demo next quarter. The CEO saw what a competitor shipped and wants a response. In that environment, visible work wins. The shipped feature, the closed ticket, the updated roadmap: these are legible. The conversation you didn’t have, the assumption you didn’t test, the user you didn’t talk to: these are invisible.

Invisible work loses. Every time.

There’s also the confidence trap. The longer you’ve worked on a product, the more you feel like you know your users. And you do, you knew them. But users change. Markets shift. The mental model you built eighteen months ago is a starting point, not a substitute for talking to people now.

The teams that accumulate the most discovery debt are often the ones moving fastest. Speed feels like signal. It isn’t.

How do you pay it down without grinding to a halt?

You don’t fix discovery debt by stopping everything and commissioning a three-month research project. You fix it the same way you fix technical debt: consistently, incrementally, built into the rhythm of how you already work.

A few things that actually help:

• Protect discovery capacity. Allocate roughly 20% of your team’s time to pure discovery work, not tied to any specific feature or milestone. This isn’t slack in the schedule. It’s the work that keeps your product pointed in the right direction.

• Question one assumption per sprint. You don’t need to validate everything at once. Pick one thing your team has been treating as established fact and actually test it. One conversation, one experiment, one data pull. Done consistently, this quietly changes how your team thinks about certainty.

• Talk to users who left, or never came. Most teams interview their satisfied customers. The real insight is in the ones who churned, never converted, or tried the product once and disappeared. These conversations are uncomfortable. They’re also the ones that matter most.

• Design experiments to prove you wrong. Most teams run experiments to confirm what they already believe. Flip it. Ask: what would have to be true for this assumption to be completely wrong? Then go look for that evidence specifically.

None of this requires a process overhaul. It requires a habit shift: treating discovery as continuous work, not a phase you completed before development started.

Which is actually more expensive?

Technical debt has a well-understood cost. It slows your team down, makes changes harder, erodes morale. Engineering leaders track it, budget for it, and eventually address it. It has a name and a place in the conversation.

Discovery debt doesn’t get the same airtime. And it has a different cost entirely. It doesn’t slow you down. It redirects you. You move fast, ship confidently, and build something users don’t need, or don’t need in the way you built it. By the time the signal arrives, the original mistake has been compounded into the architecture of the product itself.

Slow is recoverable. Wrong is expensive.

The question isn’t whether you have discovery debt. You do. Every product team does. The question is whether you’re aware of it and whether you’re paying it down before the bill comes due.

Share

Subscribe now

What I read

As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >900) at https://www.digital-product-management.com. These are today’s picks:

Storytelling as a Mechanism for Product Influence: Convert product work into influence and career growth by framing decisions through the emotional cost of inaction.

Craft a 1-Minute Elevator Pitch: Structure and deliver a concise professional introduction to communicate value and capture interest in under sixty seconds.

100-Day Action Plan for a New Role: Navigate the first hundred days of a new position by building trust through listening, observation, and intentional reputation management.

I’ve observed across so many product teams that we spend hours building dashboards that look impressive in quarterly reviews, but when it comes to real decisions, we ignore them completely. Why? Because most dashboards are designed to make us look good rather than help us think clearly.

The problem: Dashboard Theater

We’ve created a culture where dashboards serve as performance art instead of decision-making tools. In practice, this looks like this:

• Metrics selected because they trend upward, not because they reveal truth

• Lagging indicators presented as if they predict the future

• Zero connection between what the dashboard shows and what we decide daily

• Carefully chosen timeframes that conveniently hide declining trends

• Aggregated data that masks critical problems in specific segments

• Vanity metrics that feel good but drive no action

Our actual decision are based on other input

Meanwhile, our actual decisions come from completely different sources. This might be a panicked Slack or Teams message about a customer threatening to churn, anecdotal feedback from sales calls that never makes it into data, the CEO’s gut reaction to a competitor’s product launch an engineer’s warning about technical debt slowing everything down, or a support ticket that reveals a pattern nobody tracked. But all these inputs are not shown in the dashboard. In fact, you don’t use your metrics for decision making, just for showing off.

(Continued below)

The solution: Build for discomfort

Effective dashboards don’t celebrate success. They surface problems and trends early. To build one that actually matters, consider the following:

• Start with the decisions you need to make, then identify metrics that inform them

• Use the same standard metrics for all features to avoid selective bias (e.g. Feature Adoption, process runtime, Task Success Rate)

• Include leading indicators that warn you before things go wrong

• Display trends over time, not just today’s snapshot

• Make bad news visible and impossible to ignore

• In a presentation: Add context that explains why numbers moved, not just that they moved

• Review it weekly, not just during quarterly presentations

It’s not going to be easy

Building a dashboard that surfaces problems creates its own difficulties. Leadership might push back when metrics suddenly look worse because you’re tracking reality instead of vanity. Stakeholders accustomed to good news may question your competence when the dashboard shows red flags. Your team might feel demoralized seeing problems highlighted daily or weekly. There’s also the risk of analysis paralysis: When every metric screams for attention, which fire do you fight first? And maintaining a truly useful dashboard requires constant refinement as your product and business evolve, which takes time.

But still, it’s better to have a honest dashboard that is useful than a dashboard full of vanity metrics that nobody uses for decision making. The best product teams have dashboards that create productive tension. If yours always makes you feel comfortable, it’s probably not doing its job.

What I Read

As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >900) at https://www.digital-product-management.com. These are today’s picks:

Product Leadership Operating System: Shifting From Reactive Execution to Proactive Product Leadership

Therapy Tax: When Your 1:1s Feel Like Therapy: How product leaders can transition from absorbing chaos to building capability during one-on-one meetings.

Management In The Age Of AI: AI tools redefine management responsibilities, focusing on technical fluency, increased output expectations, and budget management.

When you're operating with a single product team, life is relatively simple. Your developers, product managers, and designers select Scrum, Kanban, or whatever methodology best suits their needs. With two teams, coordination becomes necessary but manageable. At three teams, the coordination overhead becomes noticeable. By the time you reach ten teams, coordination without a proper framework becomes virtually impossible.

Surprisingly, this problem remains largely unsolved, even among experienced Heads of Product and CTOs. Several frameworks claim to offer solutions, but fall short in practice:

• SAFe often functions as waterfall development in disguise, bringing substantial overhead

• LeSS improves on some aspects but ultimately suffers from similar issues as SAFe

• Nexus shows promise but doesn't scale indefinitely

Share

The Minimalist Approach to Scaling

The most effective solution I've encountered focuses on reducing overhead by creating truly independent, autonomous teams:

1. Keep teams small enough that members can directly witness the impact of their work

2. Make each team fully accountable for their success

3. Prioritize technical autonomy by minimizing dependencies between teams - can they achieve goals independently? This is absolutely critical!

4. Establish "contracts" for inter-team communication: Technical contracts (well-documented APIs) and social contracts (communication standards, meeting cadences, dedicated channels on Slack/Teams)

This approach creates the optimal foundation for scaling product and engineering organizations effectively.

When formalized, this philosophy aligns with Team Topologies or unFIX methodologies. Both discard hierarchical scaling in favor of clear agreements about responsibilities, capabilities, and communication patterns between teams.

The result? Maximum team autonomy, structured communication, and clear accountability - all without unnecessary hierarchical complexity.

What I read

As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >900) at https://www.digital-product-management.com. These are today’s picks:

How LLMs Work — A Visual Deep Dive: Visual technical walkthrough explaining the architecture, training stages, and data processing pipelines of large language models.

Things I’ve Learned as a Senior Engineer: Hard-won engineering lessons covering career growth, code simplicity, documentation importance, and the value of changing companies.

Stop Prompting Blind: Spec-Driven AI Development: Prevent AI coding errors and rework by using a structured specification template to provide necessary technical and business context.

What “Fluent Status Quo” actually means

When we made a decision last year about how to approach a feature, structure a team, or prioritize our roadmap, that choice was probably right for that specific moment in time.

But there’s a critical part that many people miss: a good decision from twelve months ago doesn’t automatically remain a good decision today, and it certainly isn’t guaranteed to be the right call for next year.

Everything around us is constantly changing

The reality of knowledge work is constant motion. Your people evolve and grow in their roles. Your organization restructures and scales. Your teams shift in composition and capability. Your software architecture matures and sometimes accumulates technical debt. Your business goals pivot based on market feedback. Your competitive environment transforms overnight. The entire world around us keeps changing, whether we’re ready for it or not.

Building adaptability into your team

This means we must adapt continuously. The status quo needs to be fluent and flexible, not rigid and unchangeable. We have to build adaptability into how we think and operate.

I’m not suggesting we should second-guess every decision we’ve ever made or create chaos by constantly changing direction. That would be equally destructive.

What I am advocating for is cultivating a specific mindset across your teams: one that embraces flexibility and stays open to evolution.

It’s about mindset, not process

What makes this challenging is that it’s not fundamentally an organizational problem that you can solve with a new framework or policy. It’s a mindset issue, which is infinitely harder to address. I want every person on my team to internalize that our future might require completely different structures, processes, and approaches than what works today. This isn’t about creating more rules or implementing heavier processes. It’s about shaping how people think about change itself.

Lead by example

And that’s precisely what makes this so difficult to implement. The encouraging part: you can embody this mindset yourself, starting today. When you consistently demonstrate this flexibility in your own decision-making, others will notice. They’ll see how you revisit past choices without ego, how you adapt when circumstances shift, and how you create space for better solutions to emerge.

Leadership by example remains one of the most powerful tools we have.

What I read

As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >900) at https://www.digital-product-management.com. These are today’s picks:

Status Rules Everything Around Me: What establishes status? And other questions.

Publishing your work increases your luck: For every snarky comment, there are 10x as many people admiring your work.

Critical AI Literacy: The difference between knowing how to operate a tool and knowing when to trust what it produces.

Three years ago, I made a controversial prediction: Scrum would die. The article gained traction. Fierce debates erupted in comment sections and Slack channels. Today, I’m not backing down. The evidence? It’s only gotten stronger.

Scrum has been around for over three decades. It’s not innovative anymore. It’s legacy. Modern engineering practices have evolved far beyond the constraints of two-week sprint cycles. Teams now deploy multiple times per day. They gather real user feedback instantly. They pivot within hours, not weeks. The sprint boundary has become an artificial limitation rather than a helpful structure.

Critics were quick to challenge me. “The Scrum Guide doesn’t forbid mid-sprint deployments,” they said. They’re correct. But here’s what actually matters: the framework’s rigid ceremonies, fixed timeboxes, and sprint-based planning mentality create psychological barriers. These barriers discourage continuous delivery. The structure itself works against modern flow-based development.

The alternatives to Scrum

So what’s replacing Scrum? Kanban offers genuine flexibility with its continuous flow model. No artificial sprint boundaries. No forced batching of work. You visualize your workflow, limit work in progress, and optimize for actual throughput. Simple. It adapts naturally to your team’s rhythm and your product’s real needs.

Then there’s Shape Up, which is gaining serious momentum. Companies are adopting its six-week cycles and hill charts because they solve real problems that Scrum doesn’t address. Meaningful project scoping. Honest progress tracking. Built-in cooldown periods. These aren’t just cosmetic differences. They represent fundamentally better ways to organize product development work.

Scrum is dead, long live Agile

The trend is undeniable: Scrum is declining. But agile thinking? That’s not going anywhere. Understanding customers deeply and adapting quickly to new insights matters more than ever. The difference is that we’re finally moving beyond outdated frameworks to embrace approaches that actually support agile values.

Original Article

That’s a bold statement, given that Scrum is the development framework used in most companies in the world. It has tens, of not hundreds of millions of users. An entire fleet of trainers and coaches is available, forming a new industry just related to a framework.

Beyond its peak

But Scrum is beyond its peak. It is a framework that with diminish in importance and will eventually die.

But wait, is Scrum not part of the new, agile way of working?

Well, no. Scrum originated in the 1980s, used in the 1990, described to the masses in 2001, and since then became more and more widely used. That means that Scrum is well-known for about 20 years now and your junior software engineer was not even born when Scrum took off! There is nothing new to Scrum by now.

Let’s not examine all the differences between Scrum as a framework and Agile as a philosophy.

But in today’s software world, Scrum is just too slow.

Engineers set up pipelines for Continuous Integration / Continuous Deployment in the meantime. Changes can be applied weekly, daily, or even hourly. That actually happens in productive systems: Companies update their products (especially in the cloud) several times a day.

What good does a Sprint Review every other week do? Why would a Product Owner wait for two weeks until looking at a feature? Why would you plan a delay when something is potentially shippable at any point in time? Scrum is just too slow for today’s software world.

Is Agile dead?

No, not at all. Agile has gotten more agile. This is why companies conduct experiment, A/B tests and other tools to generate insights. This is possible because people can segment users, update the product, learn, and merge product versions on an hourly basis.

In fact, Scrum has become a preventer of “Agile”. If you want to be agile, do not use Scrum by its book.

Recently, a nice survey showed that “Big Tech” mostly do not use Scrum. I presumed that is (partly) because they are also companies that use quick Continuous Deployment strategies. Instead, they iterate on an idea until it is ready, usually in more agile ways than Scrum.

Alternatives

Of course, you’d expect some alternatives at this point. Well, a good vision is a start. Then you may use a lightweight framework with little overhead and the ability to move fluently without fixed timeframes. There comes Kanban, but recently also Basecamp’s Shape Up methodology.

Conclusion: Ditch Scrum for software project, become more agile!

Subscribe now

What I Read

As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >900) at https://www.digital-product-management.com. These are today’s picks:

How product companies operate without BAs, Scrum Masters, Release Managers, etc: Qhy you don’t see roles like BAs, Scrum Masters, Release Managers, etc in product-tech companies - and why traditional enterprises need them.

Managing Through Reorganizations: Once leadership has committed to a change, your job is to communicate it as quickly as possible while still being thoughtful.

What do great managers actually do all day? 6 pillars the best managers consistently work on.

This article stems from a conversation I had a while ago.

Reason 1: Information Need

People schedule meetings because they feel they don't have enough information. They think they can't do their job well without updates from you, or they worry about missing important details. This worry often comes from past situations where they needed information but couldn't find it.

Solutions:

• Share information in writing before being asked - Set up a regular schedule for updates that answers questions before people need to ask, cutting down on check-in meetings.

• Build easy-to-read dashboards - Visual displays of key numbers give quick status updates that satisfy information needs without requiring talks.

• Send out regular document updates - Well-organized documents delivered on a predictable schedule build confidence that people will get important information without requesting meetings.

Subscribe now

Reason 2: Control Desire

Stakeholders want to see how work is progressing and in what direction. They need to feel sure that projects align with their goals. This feeling gets stronger during uncertain times or when projects are very important to the company.

Solutions:

• Show your planning process clearly - Open planning tools show that you're thinking carefully about priorities, reassuring stakeholders that work is moving forward in an organized way.

• Keep backlogs/roadmaps visible to everyone - Accessible priority lists let stakeholders see how their needs fit into the bigger picture without needing explanation meetings.

• Set clear goals with management - Written agreements about what success looks like create shared understanding that reduces the need for frequent alignment talks.

• Share how decisions are made - Clear frameworks for making choices build confidence in your judgment and reduce the feeling that others need to be involved in routine decisions.

Reason 3: Trust Deficit

When people don't fully trust you to deliver results, they try to keep closer watch on your work. This shows up as more frequent check-ins, detailed status requests, and involvement in decisions they might otherwise leave to you.

Solutions: While there's no quick fix, you can build trust faster by:

• Mentioning similar work you've done before ("I've done this successfully at Company X") - Real examples of your past work provide evidence that you can handle similar challenges well.

• Being open about both successes and problems - Talking about issues before others discover them shows confidence and maturity, which actually increases trust even when sharing difficulties.

• Bringing up big issues reliably - Consistently sharing problems as soon as you find them builds your reputation as someone who provides reliable information, not just good news.

By addressing the root causes of meetings - information gaps, control needs, and trust deficits - we create space for truly valuable collaboration. The most respected teams aren't those who meet constantly, but those who meet deliberately, with clear purpose and outcomes.

What I read

As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >900) at https://www.digital-product-management.com. These are today’s picks:

Think Like a VC When Evaluating a Startup Role: A venture capitalist inspired checklist for choosing your next startup role.

Public Speaking: How to prepare: Practical techniques for amplifying your presence, finding your voice, and transforming into someone who takes action and builds confidence.

Cross-functional Teamwork: Who is responsible for what in cross-functional teams?

Every product team I’ve worked with claims they have a strategy. They’ve got their vision statements, strategic pillars, and beautifully themed roadmaps. But here’s what I’ve learned after years in this field: most of these “strategies” are just feature lists wearing fancy clothes. I still laugh when I remember an executive who half-jokingly told me, “Our strategy is making money.” (That was more than ten years go, but at least he was honest!)

This newsletter is sponsored by ngram. Create polished, on-brand videos
with agentic AI!

Turn an idea, doc, link, or screencast into pro-level video. ngram handles the research, storyboarding, scripting, voiceover, and editing—with you in control.

Real strategy isn’t about what you’re planning to build or how you’ll lead your company. It’s about what you’re deliberately choosing not to build and why you’re making that choice. Those tough decisions? They’re what create your product’s unique spot in the market!

Strategy theater warning signs

I’ve spotted these warning signs, amoung others:

• Your strategy document is over 20 pages long. It lists every possible thing you might do but never mentions what you won’t do.

• The strategy changes every quarter because your competitor launched something new.

• Nobody on your team can explain it without pulling up slides.

• Every decision takes forever and involves way too many people.

• You could swap your company name with your competitor’s, and the strategy would still make perfect sense.

What real strategy looks like

Real strategy tells you where you’ll compete, but more importantly, it makes clear trade-offs that eliminate entire categories of features. It defines your ideal customer profile while explicitly stating which customer segments you’re ignoring. It outlines the problems you’ll solve and lists the capabilities you’re deliberately not building. It establishes which metrics matter more than others.

The strategy test: If your strategy doesn’t make some stakeholders uncomfortable, you don’t have a strategy. You have a wish list. Real strategy means saying no to good opportunities so you can focus on the great ones.

Canvases force you to make decision

So how do you create something tangible? There are several canvases that force you to think clearly. I have worked with them, and if you’re starting from scratch, try them all and see what clicks for your situation.

Lean Canvas

Busines Model Canvas

Play to win

They all served me well. What I love about these tools is they force you to make decisions. You can’t leave sections empty, you have to write something down. Take your time with this. Discuss every question with your management team and peers. This isn’t busy work, it’s the foundation of your success.

These decisions become your strategy! You’ll focus on what’s in your canvas and ignore everything else. Yes, you’ll have to defend those choices against stakeholders who want their pet features included. But that’s okay because now you actually have a strategy to defend.

The most successful products I’ve seen aren’t built by teams that can do everything. They’re built by teams that choose their limitations wisely.

Bonus thought

While writing this, I remembered a prioritization game called “Buy a Feature”. You give stakeholders play money to “buy” their favorite features. Whatever gets the most money wins.

The problem? You’ve just handed your roadmap over to stakeholders. There’s no strategy involved, no evidence or discovery, no value thinking. Buy a Feature is everything strategy-driven development shouldn’t be.

What I read

As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >900) at https://www.digital-product-management.com. These are today’s picks:

Harada Method: How to Achieve Ambitious Goals in a 9x9 matrix

Own A Graph: Every problem worth owning can be shown on a graph.

Questions Execs Use to Judge Your Product Roadmap: In roadmap reviews, execs evaluate: what is it, why it matters, when we get it, and how much it costs me.

Why? Because you’re watching their outputs when you should be studying their inputs.

Most product teams fall into the same trap: They focus on what competitors are doing rather than understanding why they’re doing it. This reactive approach means you’ll always be one step behind instead of one step ahead.

What most teams track

Most teams track feature releases and product updates, pricing and packaging changes, marketing campaigns and messaging, and hiring announcements. That’s usually where it stops.

But I want you to think bigger.

What teams should track to gain a competitive advantage

You should also track this:

• Customer complaints about your competitors

• Patterns in their experiments

• Changes in their success metrics

• Shifts in their target market

• Internal incentives (if you can)

Go deeper. Understand their strategic bets. Figure out what drives their decisions.

This approach gives you a real strategic advantage. When you understand the “why” behind competitor decisions, you can predict their next moves and position your product better. You’ll learn about their strategy and see their possible moves even before they ship anything. By watching your competitors’ inputs closely, you gain insights without running every experiment yourself.

Reverse engineer their actual strategy

The ultimate goal? Fill your strategy template with your competitors’ actual data. This way, you’ll understand their real strategy, not the polished version they show publicly, and compare it against your own. That’s when competitive intelligence becomes truly powerful.

What I Read

As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >800) at https://www.digital-product-management.com. These are today’s picks:

No AI without Evaluation Systems: How are we measuring if this thing actually works?

Archetypes of Product Leaders: The craftsperson (“it’s all about the product”), the operator (“it’s about scale”), and the visionary (“it’s about the future”).

Product Strategy Framework: A good set of standard documents for your product strategy.

ngram.com turns your PRD or website URL into a launch video, instantly.
Product demo, teaser, walkthrough; just tell ngram what you need. It handles everything. No editing, no timeline, no team required.

Create your first video in under 15 minutes →

[Promotional content. Anyone who signs up through this link gets 1 month of ngram Pro for free.]

Let’s check what the Scrum Guide actually says about this (even though there is no law that forces you to follow it by the letter):

The Product Owner is also accountable for effective Product Backlog management, which includes: […] Creating and clearly communicating Product Backlog items (cf. Scrum Guide)

But the Scrum Guide also says:

The Product Owner […] may delegate the responsibility to others. (cf. Scrum Guide)

So there’s no official rule making the PO a bottleneck. Yet many teams still operate this way.

Recognizing bottleneck systems

You’ll know you have a decision bottleneck when you see these warning signs:

• Development teams waiting endlessly for PO decisions

• Product Owners overwhelmed by constant stakeholder requests

• Critical product knowledge locked inside one person’s head

• Painfully slow responses to market changes and user feedback

What the best teams do differently

High-performing teams take a completely different approach:

• They distribute product ownership responsibilities across the entire team

• They create clear decision-making frameworks instead of relying on individual decision-makers

• They empower developers to make thoughtful product choices independently

• They build strong product sense in everyone, not just the designated PO

This approach keeps the Product Owner accountable for the product’s overall value, which coincidentally aligns perfectly with Scrum principles. But smart POs build systems, train their teams thoroughly, work with clear goals rather than detailed requirements, and trust their team to make sound decisions.

What makes this work? You need a smart product owner, a willing team, and strong support from the PO’s manager.

Skills over roles

Let’s step away from roles and focus on skills for a moment. The entire team shares responsibility for delivering valuable, viable, usable, and ethical products. Each team member contributes their unique strengths:

Developers excel at coding but often bring valuable user understanding. Product Owners master customer problems while sometimes having solid technical intuition. UX Designers create exceptional user experiences and frequently possess strong customer insight and stakeholder management abilities.

This creates natural specialization based on individual skills and interests. But the whole team can share responsibility and make decisions using shared goals, frameworks, constraints, and deep user understanding.

What I read

As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >900) at https://www.digital-product-management.com. These are today’s picks:

Processes should create outcomes like a product: Thinking of processes like products

Complete Guide to Building Your First Vibe-Coded App: A guide for starters - examples in Lovable, but principles applicable everywhere.

What is Product Strategy? Three pieces in a complete product strategy: Vision, Framework, Roadmap

That moment, that first spark of satisfaction, is what we call "Time to First Success" (TTFS), and I see that this is a rising trend in the past few months.

Why TTFS matters

Note: If you're in traditional B2B sales where everything happens through demos and lengthy sales cycles, you can probably skip this. TTFS is really the star of product-led growth scenarios, where customers are trying to figure things out on their own.

You probably know of the metric "time to value": it’s useful, but it's also somewhat broad. TTFS gets specific. It's that exact second when your customer stops wondering if they made a mistake and starts thinking, "Okay, this actually works."

Maybe it's when they generate their first report that doesn't look like garbage. Or when they finally complete a task successfully. Whatever it is, it's personal, it's meaningful, and it's the difference between a customer who sticks around and one who churns.

For those of us managing products, especially in the product-led world, TTFS isn't just another number on a dashboard. It's like having a crystal ball that shows you exactly where your onboarding is failing and which features actually matter to real humans.

Most imporantly, Time To First Success is a great indicator of word-of-mouth growth within an organization. If the first users get to success quickly, they will encourage others to use your software as well.

Making TTFS work for you

1. Figure out what "Success" actually means

This sounds obvious, but it's trickier than you think. Your idea of success might be completely different from your customer's. Grab coffee with your customer success team (they know things), dig into those support tickets, and actually talk to your users. What made them smile? What made them feel smart? That's your gold.

2. Stop making onboarding so painful

We've all been there: Signing up for something new only to face a setup process that makes you want to quit right away. Your customers don't have infinite patience. Make it easy, make it clear, and make it fast.

3. Focus on the features that actually matter

Not every feature is created equal, and your customers don't care about your technical masterpiece if it doesn't solve their immediate problem. Which features are your successful customers using first? Double down on those.

4. Measure, learn, repeat

Track TTFS, because your retention depends on it. Where are people getting stuck? What's working? What's making people want to cancel their subscription before their free trial ends? You can experiment if you wish.

The counter argument

TTFS isn't magic. It takes work to understand your customers deeply enough to measure this effectively. And if you get too obsessed with quick wins, you might accidentally ignore the features that create long-term value. It's all about balance, like most things in product management. Yet if you want to create word-of-mouth, even if only within your customer organization, Time To First Success will definitely help.

What's next?

TTFS feels like one of those metrics that could stick around. It gets teams focused on what actually matters to customers, and in a world where everyone's fighting for attention, that first positive experience can make or break your product.

Let’s see whether the trend is getting stronger or whether PMs will stick to Time To Value in the long run.

What's been your experience? Have you noticed patterns in when your customers have their "aha" moments? I'd love to hear what's working (or not working) for you.

Subscribe now

What I read

As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >900) at https://www.digital-product-management.com. These are today’s picks:

Rulebook of Corporate Politics: How to Use Politics to Your Advantage

Transformation Framework: How to Organize Reformation That Actually Works

Execs aren’t listening if you’re not talking about money: When you work on a product, you need to tie it to your organization’s finances.

Product management is fundamentally a people role, not a technical one.

Let me explain in a couple of thoughts:

• The value a product delivers lies in its ability to improve people’s lives. A great product makes users more efficient, reduces their effort, and enhances their overall experience. Whether it’s an individual or an organization (which is ultimately made up of people), the end goal is always the same: to create value for humans.

• At the core of every product is its user: A human being. It’s the product manager’s responsibility to deeply understand the needs, challenges, and goals of these users and to address them through the product.

• To uncover these needs, identify pain points, and define jobs to be done, product managers must engage directly with people. This means talking to users, listening to their feedback, and empathizing with their experiences.

• Even when it comes to building the product, product managers don’t work in isolation. They rely on development teams to bring their vision to life. Communicating the product’s purpose, priorities, and requirements to engineers is a critical part of the role.

• Stakeholder management is another key aspect of product management. Whether it’s aligning with leadership, collaborating with cross-functional teams, or convincing others to support a vision, success depends on understanding, communicating with, and influencing people.

While digital product managers work on technical products, and having some technical knowledge can be helpful, the essence of the role is about people. It’s about empathy, communication, and a deep understanding of human needs. The ultimate goal is to ensure that users and customers are better off because of the product.

In the end, product management isn’t just about building products. It’s about building better experiences for people.

Use all major chatbots (LLMs) for 10$ per month and cancel your subscriptions to ChatGPT, Claude, Perplexity, etc.: 👉 Abacus ChatLLM . If you use this link to subscribe, I will receive a referral fee.

What I Read

As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >900) at https://www.digital-product-management.com. These are today’s picks:

Metrics: always ask these 8 questions: Consider metrics proposals carefully and ask these eight questions.

Questions To Ask Founders When Investing at an Early Stage: Core questions on desirability, viability and feasibility for founders.

Product Activities Framework: All the product management related activities that should take place in any company.

Let me be honest about what happened here. The user story format was originally designed to build empathy and provide context. Instead, it morphed into bureaucratic theater where real customer insights hide behind formulaic language that nobody questions anymore.

I’ve personally witnessed Scrum Masters and Agile Coaches literally force teams to rewrite perfectly good requirements just because they didn’t follow the sacred template. If it didn’t start with “As a user,” it had to be redone. No exceptions, no discussion.

The warning signs

You know you’re in cargo cult territory when every single story begins with “As a user,” regardless of whether it makes sense. I’ve seen teams write from the system’s perspective while pretending it’s the user talking.

What get’s me most: Teams write “As a user, I want...” without ever speaking to actual users. They’re guessing. Or worse, they’re disguising someone’s opinion, often the HiPPO’s, as evidence-based insight.

What user stories should actually do

I always remind my teams that a user story is literally a story about real users. To make them work, you need to understand who your users actually are, through personas or research. I push teams to answer “who” and “why” before jumping to “what.” We need to build genuine shared understanding of customer value by identifying the specific problem in its context and the value our solution delivers.

In my experience, the best user stories spark conversations about alternatives and trade-offs, with everyone keeping the actual user in mind while we discuss goals and approaches. They connect features to real problems that real people face.

The shift in thinking

Of course, you should mention the user role, but please focus on jobs to be done. We’re solving problems, not building features. I encourage writing stories that capture user motivation, not system behavior. It’s called a user story for a reason. It’s about the user’s experience, not your system’s architecture.

I always ask: What problem are we solving? What happens if we don’t solve it? How does solving it genuinely improve someone’s life? I’ve found that understanding the problem deeply leads us to better solutions naturally.

Breaking free

It’s very liberating (in my view) that not everything needs to be a user story. I’ve read the Scrum Guide many times, and it never mandates that product backlog items must follow this format. There are other valid approaches worth exploring.

Have a read of Maarten Dalmijn’s great article about job stories, for example:

Maarten’s Newsletter

Use Job Stories To Hook Users

“First we make our habits, then our habits make us” — John Dryden…

Read more

9 years ago · 7 likes · Maarten Dalmijn

The reality check

If you’re writing user stories without talking to users, you’re doing it wrong. The template itself creates nothing.

Use all major chatbots (LLMs) for 10$ per month and cancel your subscriptions to ChatGPT, Claude, Perplexity, etc.: 👉 Abacus ChatLLM . If you use this link to subscribe, I will receive a referral fee.

What I Read

As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >800) at https://www.digital-product-management.com. These are today’s picks:

AI Evaluations: Four levels of AI evals

What to do when a downtime occurs: Responsibilities during a product outage and how you can turn a helpless moment into an example of strong, calm leadership.

PM Skillset: The skillset that David Pereiea uses to coach PMs and Leaders.