Implementing CRM software using the concept of the Minimum Viable Product

January 21, 2012 Richard Boardman

There are a number of challenges and unknowns when implementing CRM technology. No matter how thorough your requirements gathering, one or many of the following may occur:

• Users fail to engage with the system
• Additional functional needs are identified to support business processes
• Users use the system in a different way to what was envisaged
• The organisation’s processes have changed since requirements were initially defined
• Capabilities are developed that are found to be redundant when the system goes live

Though to some extent these issues may be mitigated through an agile approach to CRM implementation, where potential users have heavy involvement in the design and development of the system, the concept of ‘minimum viable product’ is also critical, and this can be used regardless of whether an agile or waterfall implementation methodology is used.

At this point, I need to own up and say I borrowed this terminology from Eric Ries’s Lean Startup approach which is documented in his Startup Lessons Learned blog, and recently released book ‘The Lean Startup: How Constant Innovation Creates Radically Successful Businesses’. The concept of minimum viable product is based on the notion that the best way to test if there’s a market for a new product or service is to release a basic version which is used to test the concept in the marketplace. If it gains traction additional capabilities can be added, safe in the knowledge there appears to be demand, if it doesn’t the company can develop a revised approach based on what it has learned from the market, and without having spent too much money or time pursuing the original vision.

While I’m reframing the concept, it has value in terms of implementing CRM technology. A highly effective implementation approach, in my opinion, is to release a lean initial version of the system that meets a key organisational need. The much loved 80/20 rule comes into play here, in that a small amount of development effort will often deliver a larger portion of the benefit of the system. It’s often trying to deliver that last 20%, where most of the time and costs arise.

Once the system is in, and hopefully adding the intended value, further capabilities can be added safe in the knowledge that the organisation is benefiting from the technology. This approach has a number of benefits:

• It reduces deployment lead time
• It reduces initial costs
• It minimises the down-side if the system doesn’t gain traction
• It reduces the risk of ‘white elephant’ capabilities being produced which seemed like a good idea in the design phase but didn’t prove useful in a live situation
• It encourages further investment in the system because the payback is more apparent
• It reduces the stress on internal resources because of the limited scale of the initial deployment
• It gives the organisation the flexibility to adapt its approach based on real-world feedback

That said, the approach is perhaps not as easy to pull off as it might sound, for a number of reasons. Firstly, facilitating the design of a lean initial system needs a ruthless approach to avoiding additional padding which can often arise for reasons of political expediency – keeping an influential person or department happy by ensuring their pet needs are met.  Secondly it requires a commitment to multiple phases of development, which as I pointed out in this post, is something that few organisations seem to be comfortable with. The key to making it work is that users believe that future phases of work will happen and can as result be persuaded to wait for non-core requirements.

The word viable is also an important part of this approach. Success relies upon an initial system that makes a significant difference. That means there as much emphasis on clear operational objectives, supporting processes, and effective user adoption as with any other effective implementation strategy. The minimal viable product approach is not a euphemism for throwing a few CRM software licences out there and seeing if someone uses them. While this might give the CRM software vendors a quick hit, it pretty much guarantees the project won’t progress.

While it might seem to be an unlikely source, I think the lean start up movement has a lot to teach us about implementing CRM systems, and Eric’s book is a perfect starting place.