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

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

Understanding desirability vs. viability

Desirability is all about the value your product creates for customers and users. It answers the question: "Do people actually want this?" When you focus on desirability, you're thinking about user needs, pain points, and the benefits your product delivers.

Viability, on the other hand, centers on your business model and whether you can build a sustainable business around your product. It's the financial reality check that determines if your product can actually make money and keep the lights on.

Your decisions influence desirability and viability

Both desirability and viability are directly influenced by the decisions we make every day.

• Product decisions typically drive desirability

• Pricing strategies (which affect revenue) and internal organizational choices (which impact costs) usually influence viability.

Time allocation: Where are you focusing?

Take a moment to reflect on your recent weeks. Are you dedicating time to enhancing customer value? Or are you caught up in endless discussions about internal process changes?

For every internal change you're considering, ask yourself this fundamental question: Will this improve our business viability, or will it actually make our viability worse?

The double standard in business cases

Many companies require detailed ROI calculations and comprehensive business cases for new software features. Yet when it comes to internal process changes, they often skip this step entirely. This is a mistake they really should address.

I've seen companies spend countless hours or days debating internal process changes that ultimately make their operations slower. What's the business case for that? Shouldn't we be making decisions as quickly and efficiently as reasonably possible?

The hidden costs of control

Many organizations tend to implement processes designed for control, gatekeeping, and reporting purposes. These initiatives are usually well-intentioned and sometimes genuinely necessary. However, there's something that's frequently forgotten in these discussions: these processes often weaken the business case.

Think about it this way: anything that slows down your teams, adds unnecessary bureaucracy, or requires additional time to complete increases your costs. Higher costs directly translate to a worse business case. And we haven't even touched on opportunity costs yet, which can be even more significant.

A simple framework for decision-making

When you're considering implementing internal changes, use this straightforward framework: Will this make us faster and therefore increase our viability?

If the answer is no, you need to have a compelling reason for choosing to lower your viability. Sometimes there are valid reasons, such as compliance requirements, risk mitigation, or long-term strategic positioning. But these decisions should be made consciously, with full awareness of their impact on your business viability.

The key is being intentional about these trade-offs rather than accidentally stumbling into processes that slow you down without providing corresponding value.

Every internal process decision is ultimately a business decision that affects your product's viability. Make sure you're treating it with the same rigor you'd apply to any other business-critical choice.

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:

Digital Culture Compass: Helping cultural organisations approach, assess and improve your digital activities.

Competitors are telling you their strategy: A product manager’s guide to reading between the pricing tiers.

Understanding why your company is organized and designed the way it is: And how to survice, thrive and hack the system.

Recognize that not every disagreement warrants a confrontation. Some issues may be minor or inconsequential, while others could have a significant impact on your work, your team, or your values. To help you stay clear of these situations, here are some guidelines to consider when deciding whether to engage in a disagreement or let it pass:

1. Assess the Consequences

Start by evaluating the potential outcomes of the disagreement. Ask yourself: How far does the proposal or idea deviate from your core convictions or principles? Even if you disagree with the approach, is it something you can live with? Or do you believe it would be a significant mistake to proceed in that direction? Consider the worst-case scenario: What is the most serious consequence if the other person’s perspective prevails? If the potential impact is minor or manageable, it may not be worth the effort to argue. However, if you believe the decision could lead to major problems, it might be a battle worth fighting.

2. Evaluate Personal Integrity

Another key factor to consider is whether your personal integrity or the integrity of someone on your team is at stake. If the disagreement challenges your ethical standards or compromises the values you stand for, it’s likely worth addressing. Protecting your integrity and that of your team is essential for maintaining trust and credibility in the workplace.

3. Consider Energy and Time

Disagreements can be time-consuming and emotionally draining. Before engaging, think about how much energy and time you are willing to invest in the issue. Is the disagreement significant enough to justify the resources it will require to resolve? If the matter is relatively minor or unlikely to have a lasting impact, it may be more productive to conserve your energy for more important challenges.

4. Align with Goals

Ask yourself whether the disagreement is directly related to your current objectives or priorities. If the issue does not align with your goals, it may simply be a distraction. Staying focused on your goals is crucial for long-term success, and if the disagreement does not affect your ability to achieve them, it might be best to let it go. Remember, not every battle is relevant to your overall mission.

5. Assess Win Probability

Consider the likelihood of success before engaging in a disagreement. Can you realistically win? Think about the power dynamics and influence of the other person involved. For example, it is much easier to win a disagreement with a peer or co-worker than with a CEO or senior leader. While it’s important to voice your opinion to higher-ups when necessary, you must also be prepared to accept their decision if they choose a different path. Similarly, even at the same level, someone else may have more influence or support than you, which could make it harder to prevail.

6. Track Your Battles

Reflect on how many disagreements you have engaged in recently. If you find yourself constantly disagreeing with others, it may indicate a deeper issue, such as fundamental differences in beliefs, values, or workplace culture. Frequent conflicts can damage your reputation and relationships, so it’s important to pick your battles carefully and avoid being seen as overly combative or difficult to work with.

7. Escalate When Necessary

If you cannot resolve a disagreement on your own, consider escalating it to a manager or neutral third party. This can provide a fresh perspective and help facilitate a resolution. However, escalation should be a last resort, used only when all other attempts to resolve the issue have failed.

8. Manage Emotions

Emotions can run high during disagreements, and it’s important to recognize when you or the other person may be reacting emotionally. If tensions are high, it might be better to delay the discussion until both parties have had time to cool off. Approaching the disagreement with a calm and rational mindset will increase the chances of reaching a constructive resolution.

Maintain Relationships

Finally, keep in mind that you are not fighting actual battles but resolving disagreements. The personal relationships you have with your colleagues matter and will continue to matter long after the disagreement is resolved. Make it clear that your dispute is about the subject matter, not a personal issue with your colleague. By maintaining a professional and respectful approach, you can preserve trust and collaboration, even when you don’t see eye to eye.

Use all major chatbots (LLMs) for 10$ per month and save the subscriptions to ChatGPT, Claude etc.: 👉 Abacus ChatLLM . If you use the link and 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:

1-measure-3-1: A guideline for presenting proposals.

Productivity Versus Alignment: One of the many trade-offs companies face.

Operational visibility from afar without micromanaging: Staying updated on the details of the work happening around you.

What's Causing the Slowdown?

There are a couple of common reasons. Not all of them will apply to your company, but you may recognize one or the other.

Fuzzy strategy: When nobody's clear on where the company's headed, every little change turns into a debate. Without a solid direction, teams can't make quick calls because they're constantly checking if they're on the right track.

Trust issues: Teams that trust each other zoom ahead. When trust is missing, you get bogged down with extra checks and approvals just to make sure people aren't messing up.

Report-itis: Related to the trust issues: Having to document every step for higher-ups adds a ton of non-productive work. This usually happens when leadership doesn't fully trust the team to deliver without constant updates.

Control freaks up the chain: Sometimes it's not your boss but their boss who needs to loosen the grip. This control mentality trickles down and slows everyone.

Process Overload: Old processes that hang around unquestioned. Both too much and too little process can slow you down, but excessive process is the usual culprit.

Big Company Hangover: Leaders from large corporations often bring heavyweight processes to smaller companies where they just don't fit (as much).

Poor Change Management: Rolling out changes without proper support is like launching a boat without teaching anyone to sail. The emotional side matters too!

Share

How to Speed Things Up

Start by figuring out your specific speed bumps, then tackle them head-on. Some measures are obvious:

1. Get crystal clear: Make sure everyone knows what's expected and why it matters.

2. Loosen the reins: Show your team you trust them to make good calls.

But there are more things you can do to make things quicker. Not all of them will work for you, but you may have a look at these:

3. Make the call: Sometimes you just need to decide and move forward rather than waiting for perfect consensus.

4. Map out changes: Create a roadmap so people can see what's changing and when, giving them time to mentally prepare.

5. Embrace some uncertainty: You'll never have all the info, so get comfortable making calls with what you've got.

6. Share the big picture: The more folks understand the strategy, the less they'll need to check in before taking action.

7. Write it down: A team handbook can save endless repeated conversations about how things should work.

Every slow organization has its own unique issues. Find yours and fix them, and you'll be amazed at how much faster things can move!

Related Articles

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 Product Manager Glossary: 80+ key terms across 12 categories critical for AI Product Managers, AI engineers, and AI builders.

One Minute Pitch: How to craft a 1 minute elevator pitch

AI Product Strategy, The AI Strategic Lens Framework: A proven AI product strategy framework with examples.

1. Advocate for them in the right conversations

When you have the opportunity to speak with someone who could influence their career, such as a future manager, highlight your colleague’s accomplishments. Don’t assume others see what you see. Share specific examples of their contributions and explain why they’re a great fit for the new role.

2. Assign easy-win tasks

Set them up for success by assigning manageable tasks or projects that showcase their strengths. These “easy wins” provide an opportunity to demonstrate their potential while building confidence and credibility.

3. Offer coaching and feedback

Provide guidance and mentorship. This doesn’t need to be formal. Often, well-timed feedback and discussions can make a big difference. Offer to review their work or brainstorm solutions together. Sharing your insights will help them grow and prepare for new challenges.

4. Share valuable information

Keep them informed about relevant updates, opportunities, or even office rumors. Staying in the loop can give them a competitive edge and help them navigate the organization more effectively.

5. Facilitate connections

Help them build relationships with key stakeholders, especially their potential future manager. If you have a strong relationship with that manager, consider arranging a casual introduction or finding ways for them to collaborate informally. These connections can pave the way for their promotion.

6. Advocate directly

Sometimes, the most effective approach is the simplest. If you believe in their abilities, tell their manager directly. Come prepared with solid arguments and specific examples to support your recommendation.

Why should you help someone else get promoted?

The most important reason is that you genuinely believe they are the right person for the role. Helping someone who isn’t the best fit does no favors to them or the organization. Beyond that, supporting your colleagues is simply good practice. Collaboration and mutual support foster a positive workplace culture, and you’d likely appreciate the same advocacy if you were seeking a promotion yourself.

By taking these steps, you can play a crucial role in unlocking someone’s potential and advancing their career while contributing to a stronger, more supportive team.

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:

CTO’s Hidden Notebook: Capture and structure your thoughts.

Networking For People Who Don't Network: Good results by following a few easy habits.

Impression Management: How Effective People Balance Perception and Reality.

While researchers have questioned the exact "10,000 hour rule," the basic idea makes sense: the more you practice, the better you get. This happens because you:

• Build mental and physical skills through repetition

• Face different challenges and learn to solve them

• Work with various people and learn their methods

• Teach others, which gives you new insights

This should also hold true for product management.

I counted for myself: Throughout my career, I spent nearly 30,000 hours working as a product manager, product owner, product lead, etc.

Am I a triple master now?

Certainly not. This is why:

1. First, my career path has changed many times. I've worked as an individual contributor and as a people manager. I've been a technical product owner and handled business aspects like pricing and portfolio management. Each role partly reset my learning curve.

2. Second, the product field itself keeps changing. We moved from shipping software on DVDs to cloud applications, from yearly releases to continuous deployment, and from adopting Scrum to exploring newer methods like Shape Up.

However, some skills remain valuable throughout these changes:

• Working well with people

• Understanding and managing risks

• Clear communication

• Spotting potential problems early

• Focusing on customer needs

• Adapting to change

• (This list is not exhaustive)

True growth comes from mastering these lasting skills while keeping up with new methods.

You want to speed up your path to mastery?

Try these approaches:

• Experience many different situations, either in one company or by changing jobs

• Work in fast-changing industries where you learn more quickly

• Learn from others through conferences, books, and mentoring

Product management mastery isn't just about time spent—it's about making the most of your learning opportunities.

Which LLM? → All of them!

When I use a chatbot AI, I use whatever fits best to my use case. With Abacus ChatLLM, I choose between ChatGPT-5, Claude 4, Gemini, Perplexity, Grok, Llama… whatever I need, for less than a ChatGPT subscription.

[I am not affiliated with Abacus, but I am a convinced subscriber. If you use the link and 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:

Guide on Which AI Model to Use: A practical guide to choosing between ChatGPT, Claude, Gemini, Grok, and Perplexity

Architecture of High-Performing Teams: The key components and how to use them to build a strong team or transform one that’s struggling.

Collaboration: Interest Based Conflict Resolution: It is crucial to develop a good understanding of the interests of all the stakeholders.

Four Questions That Make a Difference

When communicating with colleagues, consider:

1. What makes this information important?

2. What are the implications?

3. Why share this now?

4. What actions (if any) are needed?

Think about it from both sides. When a teammate asks for your input, you naturally want to understand the purpose before investing your time. Similarly, as a busy product leader scanning through messages, you value knowing whether something requires immediate attention or is simply informational.

Putting It Into Practice

Compare these two approaches:

Basic message:
"Usage metrics declined 15% during February."

Improved message:
"FYI: February usage dropped 15% month-over-month. This appears to follow our typical holiday-season pattern, similar to last year. No immediate action needed, but worth keeping in mind for our planning discussions."

By providing context, you respect your colleagues' time and increase the likelihood that your communication will achieve its intended purpose. This small adjustment makes a significant difference in how your messages are received and acted upon.

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:

Delegation Matrix for High Performance Teams: A matrix that provides four types of decisions/actions for high-performance teams.

RAG, Agentic AI, and MCP: Good explanation of the principles.

Capture authentic customer voices from the web with AI: How to get real user voices from across the internet with backlinks to the discussions.

Treat your career like a product

A common piece of advice is to treat your career like a product. But how do you put this into practice? Let's explore some key questions.

1. First, define the problem you solve. Think in terms of "Jobs To Be Done" (JTBD). What specific job will you be hired for? Go beyond the title "product manager." Consider what challenge the employer aims to address by bringing you on board.

2. Next, what value do you deliver? What unique contributions do you bring to the table? How do you make a difference?

3. Consider your go-to-market strategy. How can potential employers find you? Is your online presence optimized? Are you networking effectively?

4. Determine your pricing. Research appropriate salary ranges for your experience and location. Also, consider your preferences for benefits, work-life balance, and company culture.

5. How will you continuously improve and learn? Identify resources, courses, and mentors to help you stay ahead of the curve.

6. Experimentation is crucial. Try different approaches to your work and job search. Analyze what yields positive results and what doesn't. This iterative process will refine your strategy.

7. Feedback is essential for growth. Seek feedback from colleagues, mentors, and supervisors. Use this input to identify areas for improvement and refine your approach.

Bonus Tip: Mentor others by encouraging them to view their careers as products. These same questions can guide your mentoring sessions. You don't need all the answers, but asking the right questions can empower your mentees to take ownership of their career development. This approach works well in both formal mentoring relationships and with team members.

Share

Which LLM? → All of them!

When I use a chatbot AI, I use whatever fits best to my use case. With Abacus ChatLLM, I choose between ChatGPT-5, Claude 4, Gemini, Perplexity, Grok, Llama… whatever I need, for less than a ChatGPT subscription.

[I am not affiliated with Abacus, but I am a convinced subscriber. If you use the link and 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:

How to Challenge People in Power (Without Making Enemies): A good way to act to influence and convince executives.

Roman Estimation: A Simple, Easy and Quick Alternative to Story Points.

Product Management Communication Toolkits to Lead with Impact: Communicate with Clarity, Influence Decisions, and Get Things Done.

• proof of concepts

• planning

• concept development

• backlog refinement

• spike solutions

• prototyping

• MVPs

They all serve as risk management tools, helping teams identify and mitigate potential issues. While we practice risk management constantly in software development, I encourage you to approach it with greater intentionality.

Random experimentation isn't effective. Don't build prototypes merely to gauge general reactions or create MVPs simply to collect unspecified feedback. Instead, be deliberate about what risks you're addressing and how you'll measure success.

To implement intentional risk management:

1. Clearly identify specific risks

2. Assess each risk's severity and probability

3. Develop targeted strategies for high-priority risks using appropriate methods

4. Explicitly acknowledge lower-priority risks you're willing to accept

Risk management shouldn't be an afterthought or side activity. Risk Management deserves dedicated attention and planning as a core element of your development process. By approaching risks systematically rather than haphazardly, you'll make more informed decisions and deliver better products.

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:

Framework Jobs: Different reasons why to choose a framework.

Strategy Questions That Actually Matter: Use these questions to cut through the noise of strategy.

Coaching, Mentoring, Counseling, Consulting: Know When and How to Apply these Roles in Leadership

In my years of leading product teams, I've seen something again and again: many people find it hard to think about outcomes. When teams write user stories, plan their roadmaps, or set their OKRs (Objectives and Key Results), they often struggle to define good outcomes. Instead, they usually end up writing lists of things they want to build.

I recently found one of the best ways to think about outcomes in the book called "Who does what by how much?" by Jeff Gothelf and Josh Seiden (Sense & Respond Press, 2024). They explain it very simply:

"An outcome is a change in customer behavior."

This helps us understand what an outcome is NOT:

• It's not something you deliver or build

• It's not just launching a new feature

• It's not just doing tasks on your list

An outcome is about how your users or customers actually change the way they do things when using your product.

The authors make an important point about OKRs too: every Key Result should be an outcome. If your Key Results are just about building things (outputs), you're missing the real goal of product development - creating meaningful change for your users.

Which LLM? → All of them!

When I use a chatbot AI, I use whatever fits best to my use case. With Abacus ChatLLM, I choose between ChatGPT-5, Claude 4, Gemini, Perplexity, Grok, Llama… whatever I need, for less than a ChatGPT subscription.

[I am not affiliated with Abacus, but I am a convinced subscriber. If you use the link and 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:

Software engineering laws: Parkinson's law, Conway’s law, Zawinski's law, and 10 others, all in one place!

Deep Dive Into MCP and the Future of AI Tooling: What MCP is, how it changes the way AI interacts with tools, what developers are already building with it, and the challenges that still need solving.

B2B Customer Segmentation: How B2B product teams can segment their customer data.

In all these cases, however, I believe that Jira is not the problem. You designed a complex, rigid, or time-consuming process and ruleset, independent of the software tool.

Therefore, the solution lies not in replacing Jira, but in designing a useful process and implementing it in whichever tool you prefer.

Read the full article here:

Leading in Product

Jira is not the problem. Your Process is the problem.

A lot of people complain about Atlassian Jira. They claim it is too complex, hard to understand, and generally a pain to use…

Read more

3 years ago · 6 likes · 1 comment · Benedikt Kantus

Next week, I’ll be back with a new topic and the usual list of helpful links.