Your pragmatism kills good ideas

Fast. Efficient. Pragmatic.

These are the qualities many product teams pride themselves on. But there's a dangerous pattern I've observed repeatedly: What teams call "pragmatic decisions" are often just the path of least resistance. And now that AI coding makes this path even more attractive, “pragmatic” can become the synonym for “dangerous”.

Let me explain the crucial difference...

The Harmony Trap: When "Pragmatic" actually means "Comfortable"

What most teams call "pragmatic decision-making" often translates to:

• Taking the path of least resistance

• Avoiding painful conversations

• Making compromises to create harmony

• Choosing what's easy over what's impactful

But hey I have to disappoint you: High-impact solutions rarely lie in the path of least resistance. By prioritising harmony and comfort, you're systematically avoiding the very conversations that could lead to breakthrough products.

True pragmatism isn't about avoiding discomfort, it's about finding practical ways to solve high-impact problems.

For example, is a real estate marketplace’s JTBD to help you find a house that you’d like to buy? Then why would you want to build in an automated notary service? You could partner with notaries and leaver their contacts, yes, but that’s the maximum you should do.

If you’d avoid this conversation and if you didn’t discuss the hell out of it why this is a bad idea, you will end up making a bad decision for the whole product.

On a daily level, when you say “we work on X” and the team decides in the cycle to work on a completely unrelated topic, and you don’t have the tough talk, then this is not “pragmatism” or “flexibility”. Nor is it “agile”. It’s simply anarchy in an absence of a clear direction and clear priorities (yes, plural because reality isn’t theory).

And now that AI allows us to build very fast, it’s tempting to let the argument “let’s just build it, it’s going to be super quick, why bother” become the new pragmatism excuse. Be careful to not let your critical decision making be sabotaged by quick AI coding and delivery. Only because we can build things faster now we don’t have to build everything and avoid difficult conversations.

(AI costs tokens btw, light-speed coding not for free 😉)

What REAL ‘pragmatic decision-making’ looks like

A genuinely pragmatic product decision happens when:

• You've identified a high-impact problem for a specific target group

• You understand the desired outcome for this target group

• Your initial solution seems too big or complex to build

• You explore alternative solutions that achieve the same outcome with less effort

The key difference? Real pragmatism starts with the problem and outcome, then finds practical ways to deliver value. False pragmatism starts with what's easy and tries to justify it afterward.

Let’s get practical.

Here are three scenarios that reveal random decision-making and what to do about them.

And yes, I've really seen in teams who talk this way and think they're being pragmatic:

Scenario 1: The "Always Think Small" Trap

When companies consistently push for "low effort solutions," teams eventually stop thinking big altogether. They get stuck in small iterations that never amount to meaningful change.

The solution? Pause and ask: "What would a high-impact solution look like?" Then work backward to find the smallest version that still delivers the same value.

Scenario 2: The Solution-Jumping Pattern

If your team constantly jumps between solutions ("Why don't we build X?" "No, let's build Y!") without a clear rationale, you're making random decisions, not pragmatic ones.

The solution? When someone suggests a new direction, ask: "Based on what information, data, or evidence are you suggesting this?" If the answer is just an opinion, you need alignment, not "pragmatism."

Scenario 3: The Assumed Dependencies Excuse

Teams often avoid high-impact solutions because "there are too many dependencies," without actually investigating if those dependencies are truly blockers.

The solution? Ask "How can we make this happen despite the dependencies?" and “What if it was easy?” and explore whether your assumptions about dependencies are accurate before abandoning the high-impact path.

How to break free from random decision-making

3 practical steps to take immediately:

1. Define what pragmatic really means for your team (Hint: it's not "easiest" or "fastest")

2. When someone says "let's just do X instead of Y," respond with: "Based on what information, data, or evidence - other than opinions - should we do X?"

3. When you hear "we're being pragmatic," dig deeper to understand if they mean "avoiding discomfort" or "finding practical ways to solve important problems" or if it really matches your team’s definition of pragmatism.

The next time someone in your team proudly describes a decision as "pragmatic," pause and consider whether they're actually talking about taking the path of least resistance.

Real pragmatism isn't being afraid of difficult conversations if they lead to better products.

I'm curious: Do you recognise any of these patterns in your team? Which scenario resonates most with your experience?

Get in touch and share your experience – I'd love to hear from you!

—

This article was edited by Viktoria Jancurova