It’s one of the most frustrating things in the world.

You invest time and resources finding that perfect software product. And you finally find a solution that does 99% of what you want.

But you need that last 1% – that missing feature. And you’re not alone. Many others are requesting similar functionality. There’s even sometimes a feedback page where users can vote on improvements.

Not to worry. The vebdor “promises” that it’s coming out soon. It’s in the pipeline and you just have to wait.

And wait….

And wait….

Soon becomes someday. And someday becomes never.

There is no official announcement or public declaration. But you eventually come to the sad realization that the vebdor has no intention of ever adding this highly requested feature.

Now you have to decide whether to stay with this tool or invest time and resources finding another.

Drawing a Line between the Definite, Probable, and Impossible

Obviously, you can’t deliver everything under the sun. There are legitimate reasons why certain feature requests go unfulfilled. And even a developer understands how repetitive feature requests can become overwhelming.

But successful developers realize that:

  • End users are not annoyances. They’re assets.
  • Feature requests aren’t hindrances. They’re opportunities.

At Testuff, a main part of the business model revolves around this simple concept.

Admittedly, it wasn’t always like that.

When we first started out, we had a vision of what we wanted to offer. After verifying proof of concept, we developed that vision and launched a truly stable product that met our goals.

But as our software testing platform evolved, all future improvements closely mirrored what users wanted. In fact, our internal development cycle and external feature request list are nearly identical.

If enough people want it, it is worth doing. And we bend over backwards to deliver – often soliciting additional feedback along the way.

Call it whatever you want. The point is, there is no way we could possibly anticipate every single use or need out there. No one could. Fortunately, we don’t have to be clairvoyant. The community tells us what it needs. And we focus all of our resources on developing:

  • Whatever features are the most achievable (i.e. the low-hanging fruit)
  • Whatever features are the most requested (i.e. the sweetest-tasting fruit).

And we do this to the exclusion of countless pet projects that we’d like to develop. Pursuing features that enjoy zero demand is a waste of resources. Worse still, such an approach would slow down our faster-than-normal (and eerily consistent) development cycle.

What Happens When We Confront the Impossible?

Every problem has a solution. But that doesn’t mean we’ll always be the ones to find it.

There are times when we simply cannot fulfill a feature request.

So what do we do?

Whenever we get stuck, the first course of action is to ask users why they want that feature. Quite often, there is a workaround that delivers the desired result using a slightly different approach.

But what happens when this doesn’t work?

Simple. We let our users know what to expect. No overpromising. No unnecessary waiting.

This is not simply good business. It’s common courtesy.

Do Honest Feature Deadlines Hurt Business?

When we can’t deliver, we can’t deliver. And we let our users know upfront.

But does this approach lose us customers?

Yes. Yes it does.

However, if a “must have” request is beyond our ability, we won’t be able to hold onto that business anyway. Being upfront simply allows the relationship to end on good terms.

But more often than not, the relationship doesn’t end. Once users receive the bad news, they sometimes come up with ingenious solutions that never even occurred to us.

When that happens, everyone wins.

We’re a bit confused why more software vendors don’t do the same.

  • Do what you can.
  • Admit when you can’t or won’t.
  • Ask for help.

It’s not rocket science.