How to Prioritize Features Without Fighting About It - Part 1

TL;DR

A couple of years ago, we nearly missed a flagship launch because we let ‘must‑have’ chatter drown out real risk and this article shares what we learned in the aftermath.

Prioritization isn’t a power play. Frameworks are helpful, but mindset matters more. WIARA's approach? Clarify needs, explain trade‑offs, protect product health. And yes, we count tech debt and refactoring as features, too.

1. How We Do Prioritization at WIARA

Prioritizing features sounds simple enough, until you're actually in the project.

Imagine this scenario: One person wants to fix bugs, another wants a shiny new feature for the next investor call, and your lead engineer insists the backend needs an overhaul before anything else ships. Everyone has their reasons, and somehow, everything ends up in the “must‑have” column.

Sounds familiar, doesn’t it? Even in Agile teams, where flexibility is part of the process, prioritization often turns into a tug‑of‑war. It’s rarely about the idea itself. It’s about urgency, risk, visibility, ego, and sometimes... fear. So what can we do about it? We can make space for those factors without letting them drive the roadmap.

At WIARA, here’s how we do it:

• We meet clients where they are, but we don’t necessarily say yes to everything.
• If the foundation is shaky, we say: “Let’s pause features, fix the base first.”
• We explain the why: open‑source evolves fast, dependencies shift, and unpatched systems burn.
• Refactoring isn’t an apology, it’s a foreseen and planned part of the process.

A good PM becomes a translator:

Dev says: "This needs a week to refactor."

Client says: "We need this done by Friday."

PM says: “Let’s revisit the scope. Here’s what we can deliver and what we’d be trading off.”

You won’t win every argument, and things won’t always go as expected. But you’ll earn trust. And over time, that’s what unlocks real velocity.

“We once worked with a Head of Customer Success who pushed back on removing an underused feature. When we explained that the time saved would go toward improving onboarding speed leading to better activation and higher retention, they immediately agreed.”

2. Why Prioritization Is So Hard (and Can Get Emotional)

So far, so rational ..until emotions walk into the meeting. Let’s look at why prioritization so often turns into a feelings-first battlefield.

Every product decision sits at the intersection of competing goals:

• Growth vs. stability
• Shiny roadmap vs. fixing what’s broken
• Going fast vs. staying sane

What makes it worse? The dysfunctions:

• "Let’s just ship now and clean up later."
• "Why are we rebuilding something that already works?"
• "Why are timelines slipping?" (Spoiler: tech debt got ignored.)

Notice none of these tensions are purely technical; they’re human, and they surface fast when deadlines loom. The problem here isn’t disagreement. It’s when teams don’t talk honestly about why exactly something matters. Or when PMs over‑promise. Or when devs underscope just to get a green light.

3. Frameworks That Fit Agile Realities

When the space starts buzzing with tension, it helps to pull the debate out of feelings and into structure. That’s where prioritization frameworks can really help. As long as you don’t treat them as gospel.

4. Frameworks in Action (Mini How‑Tos)

Lists and tables are great in our line of work, but frameworks only come alive when you put them to work. Let’s zoom in on how each model translates from bullet points to day-to-day product decision:

• RICE: Score Reach, Impact, Confidence, Effort. Helpful when you have the data.
• MoSCoW: Define musts, shoulds, coulds, and won’ts. Only works if everyone agrees on the rules.
• Kano: Ask users what delights vs. what frustrates. Use it for roadmap planning, not backlog grooming.
• WIARA Model: We score by Impact, Alignment, Risk, Ability, and Resource Load, then talk it out.

Frameworks are only half the story; the real test is what happens when smart people disagree. Here’s how to keep the debate clean and productive instead of it getting personal.

5. How to Actually Avoid Feature Fights

• Agree on what “value” means before scoring anything.
• Use a facilitator, not a boss, in roadmap sessions.
• Limit “must‑haves” if you need more than one hand to count them, you’re doing it wrong.
• Revisit past decisions. Priorities shift.
• Document the why, not just the what.
• Always leave space for maintenance. Skip cleanup too long, and estimates balloon while morale dips.

Tactics stop the fights, which can be true, but principles keep them from flaring up again. This is where WIARA’s philosophy really shows its teeth.

6. WIARA Commentary: What Actually Works

Frameworks organize. People decide.

If debate becomes too long, we pause and remind everyone:

“We’re here to solve the user’s problem, not to win an argument”.

• We blend models RICE for clarity, WIARA for reality.
• We advocate for regular cleanup sprints, not last‑minute rewrites.
• A good PM holds the line between “what could ship” and “what should.”
• Prioritization without communication is just guessing.

Boil it all down, and prioritization is a trust exercise. Let’s close this trail of thoughts by zooming out to the bigger picture and understanding the cost of getting it wrong.

7. Conclusion

Prioritization is where product trust is built or lost.

It’s not about saying no. It’s about showing why “no” is the right call, right now. We’ve even had to make the hard call to step away from accepting a project when the team wouldn’t face its tech‑debt reality building on quicksand helps no one, least of all the user. The hard conversations are worth having early. Because in product, like in code, what you ignore doesn’t disappear. It compounds with time.

And at WIARA, we’d rather deal with the friction now than dig out from a backlog of regret later.