Remember the KISS principle?

This morning, I had a briefing with McObject, a tech vendor that specializes in embeddable databases. From cars to set-top boxes to web sites, there's a near-universal need to put data somewhere, retrieve it, and manage it. In these use cases, the simplest database technology is the best.

Their product strategy is interesting to the readers of this blog for at least a couple of reasons. First, there's an unstated assumption in many technology companies that complexity is inescapable. If you want to keep pace with your competitors, you have to keep pace with their feature set.

Keeping the roadmap simple
Pshaw. If you look carefully at McObject's roadmap, you don't see crazy amounts of new features. Instead, their product strategy focuses on the essentials. Provide logical database devices as a layer of abstraction above the actual storage (on disk, in memory, etc.). Take advantage of the performance improvements in 64-bit architectures. Give the developer an optimistic concurrency option.

The acceptability parameters aren't too hard to figure out. Prevent database corruption. Don't screw up performance. Don't baffle your customer with new  options they can't figure out.

I'd like to think that every technology company understands these principles, but, alas, they don't. For example, I've seen product marketing materials for cloud-based data management that possess none of this clarity and simplicity. In a few extreme cases, I've been unable to decipher what the vendor was claiming they could do, even though I've been working with databases and file systems for a long, long time.

Keep it simple for your customers
Clarity in your communications starts with your own clarity about your customers. Steve Graves, the CEO of McObject, made an important observation about working with developers: they're really smart people, on average. However, they don't know everything, and they often don't understand databases.

That should be no surprise to anyone who has ever worked on a development team, which, like the Dirty Dozen, is often a collection of specialists (demolitions, build scripts, sniper, Ajax...). In no small number of cases, the team may have no one who's a seasoned hand at databases, or other important domains (performance, security, etc.). Therefore, vendors like McObjects have to be ready to educate and advise, not just sling technology at them and hope for the best.

Sure, we've all had a good chuckle at that guy who rampaged across the stage like an enraged mountain gorilla, screaming "Developers! Developers! Developers!" Unfortunately, we've behaved equally ridiculously, assuming that all developers are the same, or they're always willing to tinker with technology until it works, or that the differences in job function in the same development team don't have any effect on buying and adoption behaviors. Are you marketing to rank-and-file developers, or development managers? That can be as significant a question as, are you marketing your CRM system to salespeople or sales managers?

The simpler your product, the easier it is to understand its value.  Doing a very good job in your niche, such as embeddable databases, is far preferable to throwing in every feature that might have value, or inventing strained explanations of why your technology is part of the latest trend.

[Cross-posted at The Heretech.]

Categories: