I’ve been working in software product development companies for nearly 20 years.
Until 4 years ago I’d always been involved in “enterprise” software.
You know – the monolithic systems with great reporting capabilities that sell well to managers and (at least historically) poor UX for the real users. Those same products that promise the moon during slick demos, require 6-12 month sales cycles where complex pricing structures are worked through and year-long implementations are agreed.
I’ve helped set up demos, I’ve watched amazing presales engineers work all night to rewrite chunks of an application to demonstrate to a prospect that it’ll meet their unique requests.
And then during implementation you discover some of it just doesn’t work.
I implemented one company’s products internally. Dogfooding from the day V1.0 was released. In 6 months I raised over 50 showstopper bugs (almost all were found by their first real customer not long after us). On a visit to HQ in San Francisco, after a fair bit of wine at a great Italian restaurant in Burlingame (the House of Garlic if I remember correctly) I challenged the then VP of Development for that application on why they shipped blatantly unfinished software.
His answer was simple, logical and for a young, inexperienced graduate analyst programmer my first window into the commercial realities of product development. He said;
“Market timing”
“If we released when the software was actually finished, we’d be beaten to market by our competitors.”
“It’s acceptable business practice because it takes 6 months to sell and we can’t start selling until the product is released and in our price books.”
“Even after the sale it takes months to implement so by the time users are ready to go live we’ve fixed all the major issues because you guys are dogfooding it for us”.
It made a whole lot of sense but it wasn’t something they ever told us on the project!
The thing is, everyone else is on the same bandwagon and the escalation games start rolling.
Products are brought to market earlier and earlier in their maturity with the knowledge that “nobody trusts a v1.0 version of a product anyway.” It continues today. Many large banks won’t touch an x.0 version of a product until the first major maintenance release is shipped.
My experience was the same. In most companies I worked for; when a new release of the DB platform shipped, we’d plan on adopting it sometime after the first 6 months out in the wild when we knew it was stable.
The game has moved on. It’s no longer just products that take a year to sell and implement so our exposure to early releases is increasing and in general so is the entire industry tolerance (there are obvious exceptions in safety-critical systems).
In my time at Oracle in the late ’90s I saw them try to change this world. They had a vision known as”Gray Iron”. It seemed brilliant – for business, development teams and customers. The idea was that based on a playbook of “best practice” business processes a customer could buy a server entirely preconfigured and working out of the box to support their entire financial, ERP and CRM set of processes. They could simplify the pain of users, ensure quality was high and radically reduce implementation times. Obviously this also offers a great potential competitive advantage.
Sadly it didn’t take off. Competitors were still playing the “ship early” escalation game so we had to play too – the poor system fed itself.
The surge of change brought about by Eric Ries’ book The Lean Startup has fanned the flames of this mentality. Ship early, get customer feedback and adjust.
The sad thing is this used to be only in the enterprise market but the world has turned. Consumer electronic devices now face the same market timing escalation issues as this article from December on Forbes highlights.
It’s now common for us to expect our phones to need a reboot or crash and even for consumer software to have significant glitches.
It’s great for the pace of innovation but spare a thought for the end users and customer support teams.
It’s a commercial reality we can’t avoid but let’s make sure we’re not sacrificing the end user experience. If you must use your customers as lab-rats, let them opt in or out of your experiments. Let them decide if they want “bleeding edge”, “new” or “stable” and honor their wishes.
If your product is even remotely valid you probably have enough early adopters willing to validate the bleeding edge without sacrificing laggards on the altar of possible futures.
What’s your “ship early” policy like?