Economic necessity: the tyranny of “good enough”

12 05 2009

Bumper stickers say that life isn’t about having what you want, but wanting what you have.  Most companies just want what they have to work.

Yet, during an economic crunch, settling for less functional software can become compelling if the perceived costs are dramatically lower than a purpose-built application.  It seems “good enough” may be as good as it gets.

Outcomes of the “good enough” tactic can vary from letting deployed apps lie fallow to decommissioning an existing installation in favor of adapting something else to take its place.  It all depends on the severity of circumstances.

The enemy is everywhere

For vendors, the danger of the “good enough” threat is its non-specific nature.  Adapting one application to function like another comes with assumption that it is probably not designed for the task at hand.  Cost savings have a way of sweeping all these issues aside.

Additionally, this non-specific threat to an existing installed base knows no boundaries.  The “attack surface area” on an established product may be shallow in terms of feature delivery, but pervasive in that these powerful, extensible alternatives will attack a unique, haphazard feature set at each customer site.  This can leave a vendor in an indefensible position against these guerilla, home grown, highly tailored applications.

This is not about direct competition – it’s death by 1,000 cuts. Accidental feature overlap and customer creativity are all that’s needed.

Consult your friendly neighborhood product manager about the threats and opportunities that ebb and flow near your feature spectrum.

But why?

Maybe the customer needs something more than the vendor has delivered or the existing app is too hard to use.  Maybe there is a new IT staff bent on “standardization” or they declare an existing app “legacy” either because of ignorance of its function, or because of costs.

All we need to know is that a “good enough” alternative makes custom software development attractive.  If Microsoft Office is “good enough”, then maybe you don’t need Adobe’s Creative Studio.  If MySQL is “good enough”, maybe you don’t need to use SQL Server (or Oracle, etc.).  If SharePoint is “good enough”, maybe you don’t need to use Documentum.

Adapting an application to the task may leverage another vendor’s existing contract.  Additionally, that contract might be paid out of another division’s pocket.  Plus, innovative users at the customer site may be rewarded by working on a high value customization project.

When tactics attack – a study of what not to do

Resorting to fear, uncertainty and doubt is a tried and true pastime in almost every industry.  Today we see advertisements for a cholesterol drug because their patent (which was recently extended) expires in 2011.  Their message is “if it’s working for you now, then why switch to something else that could be less effective?”  They even sponsored a study which concluded that their name brand was better than a generic alternative (which was later retracted).

This tactic feels greedy to customers – the vendor apparently needs a price premium to stay afloat.  They’re threatened purely on a cost basis (no one switches to a generic because it’s better, right?).

A hands on, benefits based approach

A similar argument could be made that switching to a “more generic” piece of software will cost the customer more in the long run due to support costs, customization, and ultimately getting painted into a corner when the next big technology wave hits.

Customers are aware of all these things, so any move away from something proven is driven from economic dire straits or an expectation (or hope) that the move is either a short term measure or that the new vendor will grow into their application space.

The first step is to know if you have a problem.  Understanding your customer’s situation and objectives opens a dialog that isn’t about license or maintenance fees – it’s about benefits.  Most of this we’ve discussed in previous posts.

Exercise collaborative creativity.  Perhaps the delivery or activation of a new, desirable feature enables a customer to meet their objective using an existing product.  Offering more guidance and training that addresses their specific issues could also result in meeting their objectives.

While very little of this feels like rocket-surgery, it may be hard to remember in the midst of the fray to stay focused on the customer’s goal and avoid settling for what’s “good enough”.



3 responses

12 05 2009

So when is “Good Enough” good enough?

12 05 2009

While I’m not advocating anyone to over-buy or to keep a square peg in a round hole, the decision of when something is “good enough” really comes down to actual and projected use and utility rather than speculative use cases.

A lot of software is sold on potential. Like the prestige of a car – the high end model may get raced, but most people can afford the four banger with steel rims. The car’s heritage and potential makes it attractive to buyers.

The software potential under scrutiny pertains to understanding its application and actual use.

If you can stretch a generic app 10% and do everything you need, that’s great. If you end up writing custom software in Excel, then you’ve got a problem. If you have an application in place that no one uses, then maybe it’s time to shut it down.

22 05 2009
Flexibility is not strategy (part 3) « Spackle

[…] For current niche-occupiers, that means new threats won’t necessarily come from outside (but maybe from homegrown innovation). […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: