The Killer Feature

Scott Francis
Next Post
Previous Post

The BP3 All Hands Meeting has turned into a mini conference, aka BPMCAMP. What I love about a conference of this size is that talks turn into discussions and discussions spill out into the hallway afterward.

One conversation in a session today reminded me of something I’ve often preached in the past.  We were talking about legacy system and process replacement, and how you avoid just recreating the old system again (this is often what users ask for).  The answer of course, is partly to think about your killer feature(s)…

The Killer Feature

When building a BPM solution, we are often integrating with and/or replacing parts of legacy systems.  Often one of the first requirements from the business will be that the new system does everything the old system does in order to be accepted.  This is generally a bad start to a project – because of course most of the things the old system does really don’t matter anymore, or could be rendered obsolete by a fresh perspective on the same problem, with new context.

However, one of the best tactics to deal with this challenge is to figure out what the two or three killer features are.  The killer features are key NEW capabilities your solution will bring to the business that are so compelling that they overcome minor discomfort over less important details, and drive adoption in the user community.  You could call this marketing, but it is truly understanding where the real value opportunities are in your project.  And while a big part of your value proposition is to the management and process owner, another value proposition needs to be made to the end-user – in the form of killer features.

Sometimes these capabilities are things the users will clamor for, sometimes things that the management team will clamor for, and sometimes, things that IT will clamor for.  Make sure that at least one of your major stakeholder groups is squarely behind a few of the wow features of your BPM project.

When killer features are driving your adoption and usage, you’ll know you have the opportunity to return to the process to take care of the more important bells and whistles.  But no need to build them until you prove the product-user fit is there!