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.

We keep doing absolutely everything we’ve ever started, no matter what. A feature ships to production, a new project kicks off with enthusiasm, a meeting gets scheduled for the first time. And suddenly, almost magically, it becomes permanent and untouchable. We continue doing these things until people burn out completely or our systems collapse under the weight.

Why does this keep happening? Because continuation has become our deeply ingrained default mode of operation. We’ve invested so much time, energy, and resources already, so stopping feels like admitting failure or wasting everything we’ve done. It’s the classic sunk cost fallacy in action, and we fall for it every single time.

Stopping by default

But what if we could flip the script entirely? What if we made stopping the default instead?

Picture this scenario: every quarter or every year, everything pauses automatically without exception. Nothing continues on autopilot unless we actively and deliberately choose it. For each item we want to keep running, we need to build a completely fresh business case (or re-assess an existing one) and carefully evaluate whether it still genuinely deserves our precious time and limited resources. Only what truly matters and adds real value gets to move forward into the next period.

Some concrete examples:

• That meeting series? It automatically ends every single quarter. If you want to continue having it, schedule a new series and clearly justify why it’s still valuable and necessary for the team.

• That big strategic project everyone’s working on? It stops completely at year-end, regardless of its current state or momentum. Then you pause and ask the critical question: Is this still an actual priority for next year, or are we just continuing out of habit?

• Product features that are already live? They get removed annually unless you can provide solid, data-driven evidence that users are actively using them and they’re delivering measurable value. (Yes, I know this sounds pretty radical and maybe even scary, but you could at least freeze all development in each area and only resume working on the ones you consciously and actively choose.)

The benefits of freeing ourselves from old priorities

This approach fundamentally frees us from sunk cost thinking that holds us back. We only invest our efforts in what makes sense going forward, not in what happened to make sense three years ago when the world was different.

This requires significant cultural change and won’t be easy. People naturally resist admitting that a project they’ve worked hard on adds no real value anymore. They genuinely hate the idea of abandoning all that sunk time and effort. Creating new business cases for everything constantly feels exhausting and like extra bureaucratic work nobody wants.

But just imagine the massive efficiency gains we would unlock: Regularly pause everything, actively and thoughtfully decide what continues based on current priorities, and stop everything else without guilt.

How many completely useless features, projects, and meetings could we eliminate this way?

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:

PM Career Guide: A framework that makes career growth transparent, fair, and achievable.

Prompt Frameworks: Frameworks that create better prompts for LLMs.

Prompt Engineering Guides: A collection of Prompt Engineering Guide by OpenAI, Anthropic, Hugging Face, Google, etc.

But the work isn’t over.

What about:

• Feedback?

• Success Measurement?

• Iteration?

That is all too often forgotten.

Too often, we treat a feature launch as the finish line. In reality, it’s just another milestone. Just as it would be unwise to deliver a feature without proper discovery, it's equally problematic to launch without a post-release plan. These next steps are critical and they need to be actively planned.

What should be part of your post-launch checklist?

1. System Observation: Monitor the platform. Are there unexpected behaviors such as slow response times, performance degradation, container scaling issues, or error spikes? System metrics will give you an early signal if something’s off.

2. User Feedback: Don’t wait for issues to escalate. Proactively gather insights from your core users: interviews, targeted feedback forms, and data from customer support. These perspectives often surface usability concerns or gaps in value delivery.

3. Success Measurement: Before the launch, you (hopefully) defined what success looks like. Are you seeing the expected adoption? Is engagement up? Are workflows faster? Whatever your KPIs were: track them, analyze them, and validate if the feature delivers as intended.

4. Iteration: Based on your findings, be ready to refine. No feature lands perfectly the first time. You may need to address overlooked edge cases, polish interactions, or rework flows that didn’t land well with users.

To do all this well, plan for it. Post-launch work needs resources. That could mean reduced sprint scope immediately after a launch, technical observability baked into the implementation, or time blocked in your own calendar to lead these efforts. The better you prepare, the smoother this phase will go.

One final note on estimations: don’t treat post-launch as an afterthought. Discovery, delivery, and follow-up activities should all be part of your roadmap and effort estimation. Because launching is not the end. It's when reality begins.

I personally use a mega prompt to have a weekly market and competitive research document generated for me. It saves me so many hours of time! I provide the prompt for free: https://productmanagement.gumroad.com/l/research-agent-prompt

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:

Five Stages of Leadership: From taskmaster to visionary, discover how great leaders evolve.

The Product Operating Model Explained: A short and brilliant description of the Product Operating Model.

Job Stories: Why User Stories Are Ill-Equipped For Building Addictive Products

The pressure never stops.

This is what I've learned after years in product management: this isn't just how our jobs have to be. Much of the pressure we feel comes from organizational patterns that we can actually change. Let me walk you through why we feel so pressed and what we can do about it.

Why we feel constantly under pressure

The pressure rarely comes from just one source. It builds up. Layer by layer. Multiple organizational issues compound each other until we feel like we're suffocating.

When direction is unclear, everything becomes a battle

Picture this: your company's strategy is fuzzy. Nobody really knows where you're headed. Suddenly, every small decision turns into a major debate. Should we build feature A or feature B? Which customer segment should we focus on? Without clear direction, teams can't move quickly because they're constantly second-guessing themselves.

Are we going the right way? Should we check with leadership first? Maybe we should schedule another alignment meeting.

This uncertainty creates bottlenecks everywhere. It slows everything down and increases pressure on everyone.

Trust gaps create micromanagement hell

When trust is missing, organizations panic. They create layers of approval. Extra oversight. More checks and balances. Teams that should be moving fast get bogged down with bureaucracy.

Leaders who don't trust their teams demand constant updates. "Where are we on this project? Can you send me a status report? Let's have a quick check-in meeting."

This creates a vicious cycle. The lack of trust makes teams less effective, which then justifies even more oversight. More pressure. More stress.

Information anxiety drives meeting overload

People schedule meetings because they're scared. Scared of missing something important. Scared they don't have enough information to do their jobs properly. This fear often comes from past experiences where they needed crucial information but couldn't find it.

So they book time with you. "Can we chat about the roadmap? I need an update on the project status. Do you have 15 minutes to align on priorities?"

Before you know it, your calendar is packed. You're spending more time talking about work than actually doing it.

Control freaks slow everything down

Some leaders need to be involved in every decision. Every choice has to go through them. This control mentality spreads through the organization like a virus, creating bottlenecks at every level.

Teams wait for approvals that shouldn't be needed. Simple changes require multiple sign-offs. A two-day task becomes a two-week process because of all the checkpoints.

Practical steps to reduce the pressure

Once you identify what's creating pressure in your organization, you can take action. This is how.

Create clarity where there's confusion

Start with strategy. Make it crystal clear. Not just what you're building, but why it matters. When teams understand the direction, they can make decisions independently.

Write it down. Share it widely. Put it in your team handbook. The more clarity you provide upfront, the less people need to constantly seek guidance.

I learned this the hard way at my previous company. We had endless debates about feature priorities until we finally wrote down our strategy in plain language. Suddenly, decisions became obvious. The debates became rarer.

Build trust through radical transparency

Trust takes time to build. But you can speed up the process. Share your planning process openly. Let stakeholders see how you make decisions. When problems arise, bring them up before others discover them.

Show examples of similar work you've done successfully. Be honest about your wins and your challenges. This transparency actually builds more trust than trying to appear perfect.

But admitting problems early makes people trust you more, not less. It shows you're paying attention and being honest about reality.

Get ahead of information requests

Instead of waiting for people to ask for updates, create a rhythm. Set up dashboards that show key metrics. Send weekly summaries of progress and decisions. Make your roadmap visible to everyone who needs it.

When people know they'll get information on a predictable schedule, they stop hunting for it. This simple change can cut your meeting load in half.

I started sending a weekly "What's Up" email to all stakeholders. Five bullet points. Current progress, upcoming decisions, blockers, wins, and what I need from them. It eliminated dozens of "quick sync" requests.

Push decision-making down

Look at all the decisions that currently require your approval. How many could your team handle independently with clear guidelines?

Create frameworks. Write down decision criteria. Give your team the tools to make good choices without checking with you first.

The goal isn't losing control. It's creating systems that work even when you're not directly involved. This reduces pressure on you and empowers your team to move faster.

Embrace the unknown

You'll never have perfect information. Get comfortable with that. Help your team understand that waiting for certainty often costs more than making a good decision with incomplete data.

This doesn't mean being reckless. It means accepting that uncertainty is normal and building processes that work despite it.

Making change stick

Reducing organizational pressure isn't a one-time fix. It requires ongoing attention. Start by identifying which pressure points affect your team most. Then tackle them systematically.

One at a time.

Every organization is different. What works at Google might not work at your startup. The key is diagnosing your specific problems and addressing them thoughtfully.

Most importantly, recognize this: feeling constantly pressed and pushed isn't just "how product management works." It's often a sign of organizational patterns that can be changed.

The most effective product leaders aren't those who thrive under constant pressure. They're the ones who build organizations where good work can happen without that pressure in the first place.

You don't have to live in the pressure trap. You can build something better.

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:

Viral marketing laws: Viral marketing laws that actually move the needle.

Product Analytics Naming Conventions: Twilio's preferred approach, the object-action framework.

Prompting Techniques Every PM Should Know: An overview of several prompting techniques to work better with Generative AI.