The Culture of Adequacy: Your Customers Don't Want Minimum — They Want Magnificent

I was working with a client recently. They have one key report — the absolute beating heart of their customers’ workflow. The feature that closes deals. The feature that retains accounts. The one thing that, if you took it away, the entire product would cease to have a reason to exist.

They’d fallen behind on it. Competitors had pulled ahead. The sales team was losing deals. Everyone knew this was the problem.

So the team set about building a new version. An MVP.

And there it was — the word that’s quietly destroying product quality across our industry. Minimum Viable Product. In this case, “viable” should have meant a totally awesome, category-defining, deal-closing, competitor-crushing new capability. Instead, the team had been so deeply conditioned into doing the bare minimum that they applied the same approach to the most important feature in their entire product.

They didn’t lack talent. They didn’t lack time (well, not dramatically). They lacked ambition. And that lack of ambition wasn’t a character flaw — it was a cultural one. Years of being told to ship fast, move on, don’t over-engineer, YAGNI, keep it simple. The team had internalised “minimum” as the goal rather than the floor.

Sign up (free) to build outcome-focused roadmaps that prioritise depth over breadth

The Spectrum Nobody Talks About

The industry has settled on “MVP” as the default level of ambition for everything. But there’s actually a spectrum, and understanding where your feature sits on it is one of the most important decisions a product leader makes.

MP — Minimum Product

This is the thing most teams actually build when they say “MVP.” It’s the absolute bare minimum that technically functions. It handles the happy path. It doesn’t crash. It probably looks like a developer designed it (because a developer did design it, at 4pm on a Friday, because there wasn’t time for proper design).

An MP isn’t viable — it’s a proof of concept wearing production clothing. Nobody would pay for it. Nobody would choose it over a spreadsheet. But it exists, and that existence lets the team tick a box and move on.

MVP — Minimum Viable Product

The original definition from Eric Ries was about learning, not shipping. An MVP was the smallest thing you could build to test a hypothesis about customer behaviour. The emphasis was on viable — would someone actually use this to solve a real problem?

Somewhere along the way, the learning part got lost. MVP became shorthand for “the least we can get away with.” Teams stopped asking “is this viable?” and started asking “is this done enough that stakeholders will stop asking about it?” These are very different questions.

A genuine MVP is still a useful concept — for features where you’re genuinely uncertain about customer behaviour and need to learn before investing further. But applying MVP thinking to your crown jewels — the features that define your competitive position — is like a restaurant serving a “minimum viable meal” to food critics. You don’t learn anything useful except that you’ve lost the review.

MMP — Minimum Marketable Product

MMP raises the bar. It’s the smallest release that delivers enough value that customers would actually pay for it or choose it over alternatives. It’s not just viable in the “technically works” sense — it’s viable in the “I’d recommend this to a colleague” sense.

MMP thinking forces you to consider the competitive landscape. It’s not enough that the feature works. It needs to work well enough that a prospective customer, comparing you to three alternatives, would put you on the shortlist.

For many features, MMP is the right level of ambition. It’s thorough without being indulgent. It respects the customer without over-engineering for hypothetical scenarios.

But for your most important features — the ones that define why customers choose you — MMP still isn’t enough.

MAP — Maximally Awesome Product

This is the level of ambition that most teams have forgotten exists.

A MAP feature is one where you’ve identified that this capability is the reason customers buy your product, and you’ve decided to make it so good that competitors don’t even bother trying to match you. It’s not just functional, not just marketable — it’s magnificent. It’s the feature that makes customers say “wow” and tell their colleagues about you unprompted.

Christopher Alexander, the architect and design theorist, wrote about the “Quality Without a Name” — the elusive, deep sense of life, wholeness, and comfort found in certain buildings, places, and objects. The thing that makes you walk into a space and immediately feel that everything is right, even if you can’t articulate why.

MAP features have the Quality Without a Name. They simplify complex tasks and workflows to make them effortless. Everything the customer needs is available, but nothing overwhelms. The problem the customer came to solve is completely, beautifully, definitively solved.

Think about the products you genuinely love using. Not the ones you tolerate. The ones where a specific capability is so good that it shapes your workflow, your expectations, your standards. That’s MAP.

Sign up (free) to identify and protect the features that matter most

Why Teams Get Stuck at MP

If MAP is so obviously better, why do most teams operate at the MP level? Because the entire culture of modern software development has been optimised for breadth over depth; for saving two weeks’ of effort versus building something beautiful.

The YAGNI Trap

I’ll say something controversial: I personally hate YAGNI (You Ain’t Gonna Need It).

Not the principle itself — obviously you shouldn’t build features nobody needs. But YAGNI has metastasised from a sensible engineering heuristic into a cultural excuse for doing as little as possible. “YAGNI” gets invoked to cut corners on things you absolutely are going to need. Edge case handling? YAGNI. Proper error messaging? YAGNI. A thoughtful UX flow that anticipates how customers actually work? YAGNI — just ship the happy path.

The result is a product full of features that work if you use them exactly the way the developer imagined, and fall apart the moment you deviate. That’s not lean development. That’s lazy development hiding behind a respectable acronym.

The Feature Factory Conveyor Belt

This is the feature factory pattern at its most insidious. The team is measured on output — features shipped, stories completed, velocity achieved. Nobody measures whether any of those features actually solved a customer problem or moved a business metric.

In a feature factory, spending three months making one feature extraordinary looks like failure. The team “only” shipped one thing. Meanwhile, the team next door shipped twelve things (all of them mediocre, but who’s counting quality when you’re measuring quantity?).

The incentive structure actively punishes excellence. An engineer who says “this isn’t good enough yet, I want another sprint to make it beautiful” is seen as slow, perfectionist, unable to prioritise. The engineer who ships something half-baked and moves on is seen as productive, pragmatic, a team player.

Over time, the message is unmistakable: adequacy is the expectation. Don’t aim higher.

Nobody Blames Anybody

Here’s the really pernicious thing about the culture of adequacy: there’s no villain. Nobody decided that mediocrity was the goal. There’s no memo that says “please do the bare minimum.” The cultural malaise just becomes how things are done around here.

Engineers don’t blame product. Product doesn’t blame leadership. Leadership doesn’t blame the team. Everyone is politely, quietly, acceptingly mediocre. The roadmap gets delivered. Features get shipped. Boxes get ticked. And the product slowly, imperceptibly, becomes a mile wide and an inch deep — an agglomeration of half-baked MVPs where nothing makes customers go “wow.”

It generally takes someone new joining — a new CTO, a new product leader, a new owner — to look around and say: “Why is everything just… okay? Why is nothing great?”

The Negative Spiral

The culture of adequacy isn’t static. It’s a downward spiral, and once it starts turning, it accelerates.

What Adequacy Does to Teams

When a team is doing “just enough” on everything, something happens to their energy. They stop caring — not because they’re bad engineers or lazy designers, but because they’ve learned that caring doesn’t matter. Quality doesn’t get rewarded. Excellence doesn’t get noticed. V1 is all there’ll ever be, so why fight for V2?

The team starts turning up at 9am and leaving at 5:30pm having maybe achieved something and maybe not. There’s no urgency, no excitement, no sense that what they’re building matters. The best engineers quietly update their CVs and leave. The ones who stay are the ones who’ve made peace with mediocrity.

This is the exact opposite of what I experienced when I gave a team permission to build something beautiful. That employee who told me his entire life had changed — his energy, his relationships, his joy in coming to work — that’s what happens when you break the adequacy spiral and let people do work they’re proud of.

What Adequacy Does to Customers

On the customer side, the effect is slower but ultimately fatal. Each underwhelming feature release trains customers to lower their expectations. They stop getting excited about your product announcements. They stop trying new features. They develop a background-level scepticism about whether your product can actually deliver.

And when a competitor comes along with one feature that’s genuinely excellent — just one — customers leave. Not because the competitor’s product is better overall, but because they’ve experienced what “great” feels like and they’re no longer willing to settle for “okay.”

The research backs this up. Over 50% of consumers switch after a single bad experience. In B2B, churn runs at around 14% annually. Every adequate feature you ship is quietly increasing the probability that your customers will leave — not dramatically, not immediately, but steadily, relentlessly.

Figuring Out What Deserves MAP

Not everything should be a MAP. If you tried to make every feature maximally awesome, you’d ship nothing. The art is in knowing which features deserve obsessive investment and which are fine at MMP or even MVP level.

Start with Your North Star

Your North Star Metric tells you the single most important value your product delivers to customers. The features that directly drive that metric are your MAP candidates.

If your North Star is “number of customers who complete their quarterly planning in under a day,” then your planning interface, your capacity visualisation, your sprint allocation grid — these are MAP features. Your admin settings page is not.

Identify Your Crown Jewels

This is the crown jewels concept applied to ambition level. Your crown jewels are the two or three capabilities that disproportionately drive revenue, retention, and competitive differentiation. These are the features where “good enough” is never good enough.

Do win/loss analysis. Look at usage data. Ask your sales team which feature closes deals and which feature loses them. Ask your customer success team which capability generates the most delight — and which generates the most frustration.

Apply the Right Standard to Each Feature

The mistake most teams make is applying MVP thinking to everything uniformly. Your admin page doesn’t need to win design awards. Your crown jewel absolutely does.

Customer Intimacy Is Non-Negotiable - “Do the Damn Discovery”

You cannot build a MAP feature from your desk. You cannot synthesise a beautiful customer experience from a Jira ticket. Building something maximally awesome requires genuine customer intimacy — spending time with customers, watching them work, understanding their frustrations at a visceral level.

The teams that build MAP features are the ones where engineers have watched a customer struggle with the current product. Where the designer has sat beside a user and seen them reach for a feature that doesn’t exist. Where the PM can describe the customer’s workflow from memory because they’ve observed it dozens of times.

This is continuous discovery at its most powerful. Not discovery as a checkbox exercise, but discovery as a deep, ongoing relationship with the people you’re building for.

The Playbook: Breaking the Adequacy Spiral

If you’re a product leader and you’ve recognised the culture of adequacy in your team, here’s how to break out of it.

Step 1: Pick One Feature and Go All In

Don’t try to fix everything at once. Pick the single most important feature in your product — the one that customers care most about, the one that’s most directly tied to your North Star — and declare that this feature will be world-class.

Not “improved.” Not “refreshed.” World-class. Best in the market. The thing that makes customers say “wow” and competitors say “how?”

Step 2: Protect the Allocation

Put it on the roadmap explicitly. Show it on the squad-by-sprint grid . Allocate a squad to this feature not for one sprint but for a quarter — maybe two. Protect that allocation from the inevitable stakeholder pressure to spread the team across twelve different initiatives. Ensure that not only did you spend two quarters on it, but there’s a small burst in Q3 and another one in Q4.

This is the hardest part, because it means saying no to other things. It means telling stakeholders that their pet feature will wait. It means having the difficult prioritisation conversation that most product leaders avoid; and it’s about gathering data and educating your peers about the importance of this thing. But it’s also the most important thing you can do.

Step 3: Define “Awesome” Through Customer Eyes

Don’t let “awesome” be defined by the team in isolation. Define it through customer outcomes. What does the customer’s workflow look like when this feature is perfect? How long does it take them to accomplish their task? What information do they need that they currently can’t get? What frustrations exist that shouldn’t?

The Quality Without a Name isn’t about pixel-perfect design (though that helps). It’s about the customer’s entire experience feeling effortless. Complex tasks simplified. Everything available, nothing overwhelming. The problem completely, beautifully solved.

Step 4: Iterate Relentlessly

MAP features don’t emerge from a single sprint. They emerge from the iterative cycle of ship, listen, refine, ship again. Plan the second act. Plan the third act. Keep the squad allocated until customers are genuinely delighted — not just satisfied, delighted.

At the company where we went from 3/10 to 8/10 customer satisfaction, the pattern was exactly this. Beautiful hardcoded dashboards in month one. More reports in month two. Customisation in month three. Each iteration informed by what we’d learned from the previous one. Six months of disciplined, obsessive investment in the thing that mattered most.

Step 5: Let the Energy Spread

Here’s the beautiful thing about breaking the adequacy spiral: it’s contagious. When one squad builds something magnificent and sees the customer response — the delight, the adoption, the deals it closes — every other squad wants that feeling too.

The employee who told me his entire life had changed wasn’t an isolated case. That energy spread across the whole team. People started caring more. Quality went up everywhere, not just on the feature we’d targeted. The culture shifted from “ship and move on” to “make it great.”

Sign up (free) to allocate your best teams to your most important outcomes

The Board Conversation

If you’re presenting this to your board or executive team, frame it this way:

“We’ve been spreading our engineering capacity across fifteen initiatives, delivering the minimum viable version of each. The result is a product where nothing is great. Customer satisfaction reflects this — we’re scoring okay across the board but exceptional at nothing.

“I’m proposing we identify our two or three most important capabilities — the features that close deals and retain customers — and invest disproportionately in making them category-defining. This means doing fewer things, but doing them at a level that competitors can’t match.

“The trade-off is real: some lower-priority features will wait. But the return is a product with genuine competitive depth, higher customer satisfaction, better retention, and a team that’s energised by the ambition of what they’re building.”

If your board has been through a prioritisation exercise and agreed on which objectives matter most, this conversation is easy. You’re not asking for more resource. You’re asking to concentrate existing resource on the things the board already agreed are highest priority.

The Adequacy Test

How do you know if your team is stuck in the culture of adequacy? Ask these questions:

When did you last hear a customer say “wow”? Not “thanks” or “that’s useful.” Actual wow. If you can’t remember, your product is adequate, not awesome.

Are your engineers excited about what they’re building? Not just busy — excited. Do they talk about the product outside work? Do they show it to friends? Or do they describe their job as “fine” and change the subject?

Would you choose your own product? If you were a prospective customer evaluating your product against three competitors, would you choose yours? Honestly? Or would you choose the one where the core feature is simply better?

Is your roadmap built around outcomes or outputs? If your roadmap measures success by features shipped rather than customer outcomes achieved , you’re structurally optimised for adequacy. An outcome-based roadmap naturally pushes toward MAP because the objective isn’t “build reporting” — it’s “customers can understand their pipeline health in under five minutes.”

Do you know which features are your MAP candidates? If you can’t instantly name the two features that should be world-class, you haven’t done the strategic thinking required. Every product leader should be able to answer this question in their sleep.

Conclusion

The culture of adequacy is the silent killer of great products. Nobody decides to be mediocre. There’s no meeting where someone says “let’s aim for a 5/10.” It just happens — gradually, invisibly, as teams internalise the relentless pressure to ship fast, move on, and do the bare minimum.

The spectrum from MP to MAP exists whether you acknowledge it or not. Every feature you build sits somewhere on it. The question is whether you’re making that choice deliberately — applying MAP-level investment to the features that define your product and competitive position — or whether you’re applying MP-level investment uniformly because that’s just how things are done around here.

Your customers don’t want fifteen adequate features. They want two or three features that are so good they reshape their expectations of what software can do. Features with the Quality Without a Name — where complex tasks feel effortless, where everything they need is available but nothing overwhelms, where their problem is completely, beautifully, definitively solved.

Building those features requires customer intimacy, disciplined allocation, iterative investment, and a team that’s given permission to aim for extraordinary. It requires a product leader with the courage to say “we’re doing fewer things, and we’re doing them brilliantly.”

The reward is a product that customers love, a team that leaps out of bed in the morning, and a competitive position that’s genuinely unassailable.

Stop being adequate. Start being magnificent.