Why Doesn't "Continuous Improvement" Philosophy Apply to #BPM Vendors?

Scott Francis
Next Post
Previous Post
I’m tired of waiting. I think I’ve been spoiled by the pace of Web 2.0 and I’m no longer patient for each major release of enterprise software. In a world where we can receive application updates to SaaS applications daily, weekly, quarterly, I’m tired of waiting for enterprise software to release major upgrades every few years.  In particular, BPM vendors, of all enterprise software companies, should know that continuous improvement is a better method than the big-bang release.  They should be embracing incremental improvement techniques, just as their customers should when deploying BPM solutions.  Why do they talk the talk and fail to walk the walk? Every BPM vendor (every software vendor!) should read Steve Blank’s Manifesto for Customer Development. Steve Blank and Eric Ries writings should be mandatory for software developers in the BPM business.  Heck, their articles should be mandatory reading for people deploying BPM software as well.  The traditional “product development” model consists of four phases:
  1. Concept / Business Plan
  2. Product Development
  3. Alpha/Beta Test
  4. Launch / 1st Ship
And Steve Blank rips the heart out of this process:
The first hint lies in its name; this is a product development model, not a marketing model, not a sales hiring model, not a customer acquisition model, not even a financing model (and we’ll also find that in most cases it’s even a poor model to use to develop a product.) Yet startup companies have traditionally used this model to manage and pace not only engineering but also non-engineering activities.
So.  Off to a good start.  So what are the problems?
  1. Focusing on a finished product instead of minimum feature set.  Lots of resources are going to be wasted on features that won’t matter to customers.  Those resources won’t then be available to invest on features that DO matter to customers.  Guess what?  Software vendors have finite resources.   These prioritization decisions matter.
  2. Founders or Executives hand-off responsibility for validating the vision.  Marketing and Product Management now own that, and Sales.  The founders and executives aren’t hearing directly from customers which features are buying criteria.  Founders and top execs need to hear customer feedback in order to know when the ship needs to be righted.
  3. Engineering becomes so focused on their ship date execution plan, they become immune to outside input, or changing the plan, except to move the ship date further out, or cut features.
In another article, this time on GigaOm, Mike Speiser argues for the power of Continuous Improvement.  Well, he’s preaching to the choir with me, because as a BPM practitioner I’ve been advocating continuous improvement for most of a decade.  Mike argues that often the reason people (and businesses) languish at a mediocre level of performance is simple:  they lack a good feedback loop.  Without timely feedback, they can’t tell if their actions will produce exceptional, average, or mediocre results.  The learning cycle is too long to take hold. A fantastic example of what can go wrong in a big organization:
Let’s say you’re a mid-level executive — a GM or product manager of some sort. More than likely, you’re measured by how well you interact with and present to your manager and senior executives. Consequently, you optimize to managing the bureaucracy (your boss in particular) rather than delivering the right product or service to customers. And so does your boss, and her boss, and so on and so on. Here the only thing that you’re practicing and perfecting are your brown-nosing skills. How can you expect to learn in an organization with that type of feedback and incentive system? How can such an organization, by extension, possibly produce excellence?
The most telling quote of all:
The organizations that produce excellence are those that continuously improve. The more granular and frequent the improvements, the better.
Its worth reading that one twice.  Three times.  Now.  If you’re a BPM vendor, and you have an enterprise version of your product, ask yourself if this statement applies to you, your team, your product, your organization.  You may be saying to me right now- but we’re on version 5, version 6, 7, version 10, of our BPMS – so clearly we believe the gospel of continuous improvement.  But I say to you, how long was the development effort that led to this latest version?  Why was it more than 3 months?  Why is there a “major version” at all rather than a series of incremental improvements that migrate customers from old to new? Many of the BPMS vendors are now providing SaaS or ASP oriented BPM solutions – at least for modeling and collaboration, if not for execution.  These solutions seem to get revisioned on a frequent and substantial basis, much like the majority of web applications and “Web 2.0” out there.  I would now like to challenge the assumption (presumption) that Enterprise software can not be similarly improved. What’s wrong with the traditional product development model for BPMS vendors (my observations):
  1. There are large sets of features that languish without improvement for many years.  A mediocre feature was introduced in 2005, it was never revisited, except, perhaps once to fix a bug in 2006.  This “feature” might be something really important to customers:  reporting, versioning, integration with salesforce, etc.  But for whatever reason it never rises to the level of interesting for Product Management, or it gets cut in the interest of making the almighty ship date.
  2. There are large swaths of potential features that never get addressed, because the product development team imagines it knows what is going to sell when the shiny new release is finally released.  So, that PDF export you wish you had in product continues to be something professional services had to provide.  That import from Visio the customer wants isn’t available in your otherwise superior product, and the customer goes with another product that does this out of the box.
  3. Low priority defects never get fixed.  Why fix them, when the “new release” is coming.  Wait for the new release, then consider fixing these minor things on the new release.  The problem is, the new release will introduce its own set of important issues to fix, it will take time to confirm the minor issues are still issues on the major release, and by the time those minor issues are back on the table again, the answer from engineering will be: this is too low-priority as you’re on the old release – we have a new release coming that will be the one to fix this on.  So, you spend more time waiting for the Next New Thing than you do actually treating it like the tip of your product line.
If your major versions take more than 1 year to ship, you’re doing something wrong.  And that may be generous.  How do I know that?  Apple ships new versions of an operating system every 12-18 months.  That’s a much more daunting task than a new BPMS.  Much larger installed base.  So why does it work?
  1. You have to make the investment in automated update mechanisms that work. Think Windows Update, Mac Update, etc.  These programs work.  The changes they propagate have to be *contained* and backward compatible.  But they work. It puts constraints on the engineering team – but they are *good* constraints that these teams ought to operate under anyway.
  2. You have to compartmentalize your updates into components or units that can be upgraded without breaking everything else.  Think Apple replacing their legacy development framework with Cocoa – something that they did gradually over the last 10 years, piece by piece.
  3. Independent components imply that you have to have good API’s.  If you don’t have API’s defined between the internals of your product that you feel comfortable documenting and publishing internally and to partners, then you should develop and implement such API’s as part of every revision to your product.  API’s provide the lubrication that allows for change in your product without putting unaffected parts of the product at risk.
  4. You have to respect data formats.  The data is sacred and hast to be protected.  See #3 – without APIs protecting your data, you won’t be able to change the schema without breaking upstream services.  And you won’t be able to change upstream services without breaking your data.
  5. You have to believe in the evolutionary/incremental over the revolutionary.  If developers think they can depart from the past without respecting it, you will get incompatible software and unhappy customers.
  6. You have to allow for individual accountability for product.  If people don’t “own” something, they won’t have the appropriate baked-in incentives for improving it. My favorite question to find out if a company is serious about a feature set, is to ask who owns it – who’s your lead developer for this part of the product?  What are their other responsibilities?  How long have they owned it?  Can I talk to them about what they’re working on now and why?  I want to understand their thought process.
I see enterprise BPM vendors talking the talk about continuous improvement.  But I don’t see them walking the walk in their enterprise software offerings.