When Everything Looks Like a Priority

Posted: November 18, 2025 | Author: | Filed under: Product, Wisdom | Tags: | Comments Off on When Everything Looks Like a Priority

There’s a peculiar trap in knowledge work: everything can be justified.

Every meeting has a reason. Every initiative has a case. Every feature solves a real problem. So how do you choose what actually matters when you can make a compelling argument for almost anything?

I used to think the answer was better frameworks. Clearer OKRs. Sharper roadmaps. But I’ve learned it’s something else entirely.

The Attraction Problem

Priority isn’t always rational. Sometimes we chase things because they’re attractive, not because they’re important.

A stakeholder gets excited. The team aligns on an idea. Something feels sexy – modern, innovative, exactly what a great company would do. And suddenly you’re allocating resources to it.

I’ve done this. Multiple times. Chased things because they had alignment and energy behind them, not because they were on the critical path. And when there’s no traction, when reality doesn’t match the excitement, you abandon it. Weeks gone. Delivery target missed.

The cost isn’t just time. It’s the opportunity cost of what you didn’t do because you were doing the attractive thing instead.

Here’s what I’ve realized: attraction is a signal, not a strategy. It tells you something has energy, but energy doesn’t equal priority.

The Busy Trap

We confuse presence with contribution.

You get invited to meetings because you’re a key person. So you show up. You sit there. You listen. But deep down, you know you’re not adding much. The meeting would go on without you. The decisions would be the same.

But saying no feels wrong. It feels like abandoning your responsibility. Like you’re not being a team player.

The truth is harder: being available to everything means being useful to nothing.

Every hour in a meeting that doesn’t need you is an hour not protecting what actually matters. It’s not about being selective – it’s about being honest about where your contribution lives.

The Emotion Tax

Here’s the uncomfortable part: we make resource decisions emotionally more often than we admit.

Something excites us, so we prioritize it. A stakeholder is passionate, so we accommodate it. An idea feels right, so we commit to it.

But emotion is expensive. Not because emotion is bad – it’s not – but because it clouds what’s actually blocking progress.

I’ve had to learn to take emotion out. To be neutral when investing resources. To ask: “Does this move us forward, or does it just feel good?”

That question is brutal. Because often, the answer is uncomfortable.

If Everything is Priority, Nothing Is

The hardest thing I’ve learned: you can’t hold everything at once.

I worked on a marketplace with three sides, double-digit user roles, everything interconnected. Every side felt critical. Every role needed attention. Every feature had a case.

But we couldn’t do it all. So we made a choice: focus on one side first. The operator side. Let everything else wait.

That decision felt wrong. Like we were abandoning important work. But here’s the thing – we weren’t abandoning it. We were sequencing it. And sequencing requires admitting some things matter more right now.

If everything is a priority, nothing is a priority. It’s not a cliché. It’s physics. You can’t be in two places at once.

The 1% Philosophy

The reality of modern work is messy. Priorities shift monthly. Stakeholders have needs. Markets move. Resources change. It feels like biting glass every week.

I’ve stopped pretending there’s a perfect system that eliminates this. There isn’t.

Instead, I’ve embraced something simpler: 1% improvement every day. Not perfection. Not fixing everything. Just slightly better than yesterday.

That philosophy extends to priority itself. You don’t need to nail it every time. You need to keep asking: “What matters most right now?” And then protect that thing.

A Different Question

Maybe the real question isn’t “What are my priorities?” but “What am I willing to let fail?”

Because you can’t succeed at everything. Something will slip. Something will be late. Something will be good enough instead of great.

The question is: what are you choosing?

When you say yes to everything, you’re not choosing. You’re reacting. And reactive work feels like drowning, not shipping.

So here’s what I’ve learned to ask myself:

  • If this slips, does the critical path slip?
  • Am I doing this because it matters, or because it’s attractive?
  • Where is my contribution actually irreplaceable?

These aren’t easy questions. But they’re honest ones.

The Practice

Being neutral about priority is a practice, not a destination. I mess it up regularly. I still get pulled toward shiny things. I still feel the guilt of saying no.

But I’ve realized something: being vulnerable about limits isn’t weakness. It’s clarity.

You can’t do everything. I can’t do everything. And pretending otherwise just makes us tired.

So we do what we can. 1% better every day. Protect the critical path. Be honest about what matters. Let the rest wait.

That’s not resignation. That’s wisdom.

Pilot Priority List – https://xkcd.com/2675

Critical Path First

Posted: November 13, 2025 | Author: | Filed under: Product | Tags: | Comments Off on Critical Path First

We had double-digit user roles, three sides of a marketplace, and stakeholders who wanted the user journey to be perfect. I was confident we could do it all.

Spoiler: we couldn’t.

Here’s what I learned about actually shipping things.

The Perfect Journey Nobody Took

I was working on a re-platforming project – migrating users to a new system. We’d agreed on the feature set, built the roadmap, and everything looked good. Then stakeholders started emphasizing user experience. They wanted the journey to be perfect before launch.

Makes sense, right? Great UX is important.

So we spent weeks trying to find the right talent to nail the user experience. We had meetings about the journey. We discussed flows. We obsessed over details.

Meanwhile, the real problem was sitting right in front of us: we had no users to onboard. We had no one to even test the system with.

I knew this. Deep down, I knew. But I held onto the UX focus because… well, it felt like the “right” thing to prioritize. Stakeholders wanted it. It sounded smart.

Then I got stuck. Really stuck. And I finally had to voice it out.

“Look,” I said, “there’s a thousand problems we could look at. But we need to hyper-prioritize what we’re actually trying to do here.”

The reality? We needed users. We needed core development done. We couldn’t polish a journey if nobody was on it.

I expected pushback. Instead, the stakeholders got it immediately once we talked about reality and focus. It was easy – almost too easy. The hard part was admitting I’d been chasing the wrong thing.

Back to the Drawing Board

That moment forced us to go back to basics. We had a chicken-and-egg situation: a complex marketplace with three sides, and everything felt critical.

So we asked ourselves two questions:

  1. What’s the lowest hanging fruit we can learn from?
  2. What’s the 20% of effort that’ll give us 80% of the impact?

The answer was uncomfortable: focus on the operator side first. The internal users and partners who could actually run the platform. Get them onboarded. Get them operating. Let everything else wait.

If everything is a priority, nothing is a priority.

We channeled all our resources toward that one user group. Not three sides at once. Not the perfect journey for everyone. Just the shortest path to something that works.

What This Looks Like Now

Every Monday, we align. Every Friday, we do show and tell. Every month, we adjust to reality – market changes, stakeholder needs, resource constraints.

It’s not comfortable. It feels like biting glass every week, honestly. Monthly priorities shift. We’re constantly firefighting.

But we’re getting better. 1% every day. We’ll try our best.

The ritual that keeps us honest: We keep asking those two questions. Lowest hanging fruit? 20% for 80%? And we protect the path to that outcome ruthlessly.

Real Talk

Look, you don’t need to be perfect at this. I’m not. I still get pulled into things that don’t matter. Just last week, I had to say no to meetings I kept getting roped into – meetings where I couldn’t contribute anything meaningful.

But here’s what I keep coming back to: focus isn’t about doing everything. It’s about doing the right thing first.

Look at your sprint right now. Your roadmap. Your backlog. What’s actually blocking you from shipping? What’s the critical path?

Start there. Let the rest wait.

Trust me – the perfect user journey will still be there next week. But if you don’t have users, it doesn’t matter anyway.

Spec Debt vs Tech Debt

Posted: October 12, 2025 | Author: | Filed under: Product | Comments Off on Spec Debt vs Tech Debt

We keep blaming “tech debt” for slow delivery.

SDD made a big entry in 2025; but a lot of what hurts velocity isn’t code—it’s spec debt.

Spec debt = ambiguity, contradictions, and missing decisions in the PRD/one-pager that ripple into design, estimates, and code. It compounds just like tech debt—only earlier and nastier.

Symptoms you’re calling tech debt but aren’t:

  • Engineers “blocked” waiting on copy, edge cases, or API shapes.
  • Designs reworked because constraints surfaced late.
  • QA finding “bugs” that are actually unmade decisions.
  • Analytics can’t measure success because metrics weren’t specified.

The hidden cost: every unclear line in a spec becomes 3x rework later—design tweaks, code churn, test rewrites, launch delays.

Antidote: Spec QA (5 minutes, zero ceremony)
Before any ticket leaves “Define,” run this checklist:

  1. Problem & Outcome – What user behavior must change? What metric moves?
  2. Scope Boundaries – What’s explicitly out? (Name one thing you’ll say no to.)
  3. Interfaces & Contracts – Events, API shape, states, empty/error cases.
  4. Constraints – Perf, security, legal, platform limits; acceptable tradeoffs.
  5. Telemetry – What to log, how we’ll know it worked; guardrail metrics.
  6. UX Acceptance – Screens, copy, and the “good enough” criteria.
  7. Rollback – Pre-agreed revert conditions and kill switch owner.

Workflow tweak that pays off:

  • PM/Designer drafts the spec → Spec QA huddle (15 min) with EM + 1 Eng → estimates.
  • Anything failing the checklist returns to “Define,” not “In progress.”

What you’ll notice in 2 sprints:

  • Fewer “quick clarifications.”
  • Cleaner PRs, smaller diffs.
  • QA writing tests against intent, not vibes.
  • “Tech debt” tickets shrink because the code finally had a clear contract.

Call it what it is: most “tech debt” starts life as spec debt. Fix the spec; the code will thank you.

ROI Over Use Cases

Posted: February 13, 2025 | Author: | Filed under: Product | Tags: , | Comments Off on ROI Over Use Cases

I’ve often found myself in what I now call “researcher’s syndrome” – that relentless urge to cover all angles, explore every possibility, and chase down every use case. As a PM, it felt natural: the more I knew, the better decisions I could make. Or so I thought. This is the story of how I learned that sometimes, less truly is more.

The Realization

In my early PM days, I was that person with sticky notes everywhere and a roadmap that looked like a tangled web of possibilities. I believed success meant creating products that solved every conceivable user need. My research was exhaustive, my feature sets were bloated, and honestly? My team was exhausted.

It wasn’t until a mentor @chuazm bluntly told me I was “trying to boil the ocean” that something clicked. The truth hit hard: in trying to solve everything, I was solving nothing particularly well. I also pickup new approach to first principal thinking with our EM @lsshawn.

Why Less Is More

Here’s what I’ve learned about focusing on what truly matters:

  1. Clarity Over Clutter
    When we focus on fewer features, we gain clarity about what our product actually stands for. It’s not about doing less work – it’s about doing better work. Apple’s approach to product design has been my north star here. Their relentless pursuit of simplicity isn’t just aesthetic; it’s strategic.
  2. Depth Over Breadth
    Think about Slack. They could’ve tried competing with full project management tools or email clients, but instead, they focused on one thing: making team communication seamless. This laser focus allowed them to excel where it mattered most.
  3. Strategic Alignment with ROI
    The shift from “What else can we add?” to “What will deliver the highest impact?” transformed my decision-making process. Not all features are created equal – some might delight users but barely move the needle on business metrics. Learning to differentiate between “nice to have” and “need to have” became crucial.

The Philosophy in Practice

Here’s how I’ve integrated this mindset into my work:

  • Start with Why: Every feature needs a clear purpose tied to user needs or business outcomes.
  • Kill Your Darlings: Regular roadmap audits are essential. Be ruthless about removing features that don’t add significant value.
  • Focus on Outcomes: Shift your thinking from features shipped to problems solved.

One of my proudest moments was when our team chose to improve an existing workflow used by 80% of our users instead of building a flashy new feature. The result? A 30% increase in user satisfaction. Sometimes the best solutions aren’t the most exciting ones.

A Closing Thought

Minimalism in product management isn’t about taking shortcuts – it’s about making deliberate choices that amplify impact. It’s recognizing that our resources are finite and choosing to use them wisely.

If you’re feeling overwhelmed by possibilities or paralyzed by options, remember this: success isn’t measured by how many features you ship, but by how well you solve real problems. Sometimes, doing less is the bravest – and smartest – choice we can make.

I’ve learned that my initial instinct to cover every base wasn’t just about thoroughness – it was about validation. But true impact comes from focusing on what matters most and executing it exceptionally well.

What could you achieve by doing less, but doing it better?

P/S: I got inspiration to write this after watch Arseny Shatokhin video on AI agent development.

From Coding to Customer Focus

Posted: December 11, 2022 | Author: | Filed under: Product | Comments Off on From Coding to Customer Focus

Juggling between a development role and product management can be challenging. I have seen many developers make the transition to become product managers over the years. However, it’s important to understand that project management and product management are very different disciplines.

As a project manager, you’re focused on delivering defined requirements and managing scope, schedule, and resources. But product management is all about understanding customer needs, defining strategy, and delivering value. The mindsets are almost opposites.

When I first started spending part of my time on product management responsibilities, I really struggled with the differences. I often fell back into thinking like a software engineer focused on technical solutions. I had to go through an unlearning and relearning process:

Unlearn:

  • Viewing requirements primarily through a technical lens. I was used to focusing on elegant architectural solutions rather than customer needs.
  • Jumping to technical architecture without gathering actual user needs. I had to stop assuming I knew what users wanted.
  • Getting excited about new technologies that didn’t offer clear value to customers. I had to shift my mindset to prioritize customer ROI over tech for tech’s sake.

Relearn:

  • Looking at requirements from the customer’s perspective first. I needed empathy to understand what users really needed.
  • Communicating with customers to gather requirements that address real problems or desires. This knowledge was powerful in defining valuable products.
  • Driving products forward based on functionality and experience, not technical implementation. I focused on the “what” first, then the “how.”
  • Considering how every product decision could improve value to the customer and business. I learned to think bigger picture about product strategy.
  • Influencing without formal authority by storytelling and selling vision. Technical excellence was no longer enough.

The unlearning and relearning were challenging but ultimately helped me evolve into a much more well-rounded product manager.

For example, I initially got excited about using new bleeding-edge frameworks and technology, even if they didn’t align with our user needs. I had to train myself to always link back to concrete value for customers, rather than just what was innovative. This meant developing skills like user empathy, storytelling, and selling vision – very different from my past specialized technical work.

The transition was especially tricky because I was still embedded in the same development team. If I could do it over again, I would try to switch products or join a different company when making the shift. Getting outside of my existing engineer mindset would have been easier.

Overall, moving from development to product management required me to fundamentally change how I thought about requirements and prioritization. I had to learn to put customer’s perspective first, and then think about technical implementation. It was a challenging but rewarding shift that made me a much more well-rounded contributor over time.

A dwarf miner sitting at stone craved desk @SomberSaurus