The QUPER model: Finding "good enough"

May 29, 2018 5 min read Pseudorandom

The QUPER model defined

QUPER stands for “Quality Performance”, and it helps you visualize your return on investment, where quality is the investment, time and energy the capital, and the ROI is how much people want to use your product.

The QUPER Model helps us visualize the progression from a useless product to a diamond encrusted one.

The three intersections of the QUPER model

As you can see in the figure, the three important intersections on our QUPER diagram are utility, differentiation, and saturation.

1. Utility

Utility is the point where our product or feature crosses the threshold between a steaming pile of refuse and something with merit, albeit decidedly imperfect.

On the low end of utility, expect to find lots of tools created for personal use. We just hack together scripts to get a job done, with little thought for things like UX or error handling.

2. Differentiation

Differentiation is the point where our feature gains a competitive advantage and stands out from the competition. It doesn’t stink anymore.

Reaching Differentiation from Utility requires a lot of effort. Think back to that barely useful tool for personal or internal use. To raise the bar to Differentiation, you’ve got to make it robust, adaptive to diverse environments, and friendly toward users of all levels of sophistication. What is more, it has to stand out from the crowd. That’s a tall order.

3. Saturation

The perfect is the enemy of the good.

Saturation is the point where further investments in improving the quality of a feature return ever diminishing dividends.

When you’ve already destroyed the competition on the quality and utility front, there’s simply no point investing more resources into further quality improvements. It’s time to drop back to maintenance mode while you generate a new product or feature. If you decide to add a new feature, just make sure it doesn’t disrupt the quality of existing features, or your product risks sliding backwards on the QUPER model.

Real world examples of QUPER in action

Dropbox

Take Dropbox as a good example of quality differentiation. When they pitched their product, many investors initially felt their target space was already “too crowded”. However, do you remember any decent file syncing service before Dropbox? Neither do I. That’s because existing products were pretty lousy. Dropbox hit the market with a solid marketing strategy and high quality, if not perfection, and its current ubiquity speaks to its success.

Evernote

Evernote has loads of features. Perhaps too many. They were so quick to ship new features that they failed to spend enough time shoring up the quality of those features. As a result, many features barely breached the Utility breakpoint. I used Evernote for a few years, but ultimately couldn’t handle the constant bugs and regressions.

Microsoft Windows

Take 1980s Windows as an interesting example of poor quality differentiation but good marketing. It was super buggy, and higher quality products existed, but their superb marketing and business strategy got it into people’s homes. With loads of capital and a few decades of hard work, they were able to breach the threshold of quality differentiation.

Application of the QUPER model to code

A nice thing about the QUPER model is that you can apply it to anything where the target is quality. Let’s think about quality performance in the following three areas:

Refactoring
Performance improvements
UX enhancements

Refactoring

Good code is clean code. Clean code is maintainable code, code you can easily grok, navigate, and modify.

How clean is clean enough? For a visual, imagine a well-kept construction site for new home or a remodel. Ahhh, that’s a relaxing visual, right? But don’t imagine a level 4 bio lab. You want your job site to be safe and tidy, with tools and safety equipment in their proper places. You don’t need to halt production to sweep every particle of sawdust that falls from your table saw.

What’s the lesson? Code you write today may well be changed tomorrow. Don’t be a perfectionist. Just keep your code straight-forward, readable, and easy to change. It’s okay if you miss a few particles of sawdust.

Performance

If your SLA promises 200ms response times, then that’s what you should deliver. If you’re already well-under that, aiming for 15ms is just wasting everybody’s money.

UX Enhancements

Good UX is super important. Just ask Hawaii . But consider app and your audience. Is the app merely run-of-the-mill CRUD widget or an internal tool of minor importance? Forgo the design studios and usability studies. Don’t reinvent the design wheel. Slap a Bootstrap theme on it and call it a day.

Takeaways from the QUPER model

The perfect is the enemy of the good. The perfectionist rarely finishes anything, and even when they do, likely someone else with less exacting standards has already beaten them to market.
On the other hand, nobody wants useless junk, no matter how quickly you get it under the consumer’s nose.
Your target is that sweet spot somewhere in between useless junk and absolute perfection.