Agile Revvy CPQ Customization Part III: Developing a Prototype

CPQ is one way that the mid market uses Agile to increase focus on customer interactions, often replacing multiple processes and tools with one, simple interface. ALTAVI uses Agile principles in its CPQ specification process to deliver maximum sales effectiveness at the highest value.

The last two blogs discussed two previous stages of our Revvy CPQ integration, which applied Agile principles to save the client money, collaborate as opposed to negotiate, and plan for dynamic design. Step 1 began with a one-to-two hour conference with the client todefine the high-level requirements. This allowed us to significantly narrow the vendor pool and select a “best-hypothesis” vendor in Step 2. Revvy CPQ, by Model N, was our selection.

This article will show how we used a limited-test rollout to: a) Collaborate with the client on detailed feature identification; b) Build user buy-in; and c) Minimize the client’s risk.

REVVY CPQ LIMITED-TEST ROLLOUT

We acquired one license and set to work. The tool didn’t need to be perfectly configured, or built to quote every possible product; it just needed enough configuration to show the evaluators that the tool could handle their needs. Our process ensured we met the client’s high-level needs, but the devil is in the details, especially for B2B. We could not be certain that an aspect of their business process might eliminate Revvy CPQ from consideration.

However, we cannot emphasize enough the advantage gained by leading with a prototype instead of the vendor’s demo. Seeing the new technology applied to a familiar context (their product) helped everyone understand and envision how the tool would work. So instead of shooting off requirements into the dark, the team enjoyed a more focused, productive, and ultimately rewarding conversation. They walked away with at first-blush a positive  impression, while we were able to record meaningful and relevant requirements to take back to Model N. This was really the largest single benefit of our approach.

Each of the requirements outlined from that conversation was defined in order of importance:

·       Show Stopper: A make-or-break feature, absolutely necessary in the CPQ solution

·       Must have/Equivalent Acceptable: A required feature that could be gained through recombination or customization of other CPQ features

·       Important: A cue to the vendor to help us understand how the tool could meet the requirements and changing business processes

·       Nice to Have: Essentially, a suggestion to the vendor for future development

·       Questions: Sometimes, the “requirements” are really questions, which need to be culled from the requirements list

We collaborated with the client on the development of this list and quickly sent the list along to Model N when finished. They were able to address all our “Show Stoppers” and effectively convince the client that the tool could be configured to meet their needs. The Revvy CPQ integration proceeded to a full-scale rollout. We did not even need to play our trump card and switch to a different vendor.

ANALYSIS OF THE DYNAMIC APPROACH: IS THE GOAL PERFECTION OR ADOPTION?

The question here is simple: “Is the risk of making a misstep worth the gain in efficiency?” Although this case proved successful on the first hypothesis, there was a chance that Revvy CPQ would not have been able to accommodate all of our client’s “Show Stoppers.” Let’s start by taking a look at the risk.

What did we stand to lose if Revvy had been a wrong choice? Simple. One license, and the time spent on basic configuration for a single product. Now, what did we gain?

Defining requirements during our process was about identifying deficiencies in the CPQ tool – a much more concrete task than brainstorming requirements (and less time consuming, lasting only 3.5 hours). It is impossible to say how much time exactly we cut out, but the efficiency subtracts a substantial part of the total risk.

And if we had brainstormed in the ivory tower instead of taking the plunge early, how much would we have improved our odds of choosing the right solution? What people think they need is often different than what is actually needed. And considering the vendor pool had already been narrowed to a handful, further deliberation would only produce marginal increases in confidence.

Meanwhile, this hands-on approach begins to stoke the embers of user buy-in, as evaluators and thought leaders gain direct experience and share their real reactions to the prototype.

This dynamic framework is far more valuable to establish than attempting to uphold the “perfect paradigm,” in which every stakeholder expects every desired feature to come preloaded in every desired format. This perception sets up the CPQ to fail. But by adapting the prototype and involving key stakeholders early, we effectively communicated what the CPQ can and cannot do, as well as what can be changed versus what cannot. Everyone knew from the start that Revvy CPQ was an imperfect but improving tool. It is better than “perfect;” it is dynamic. This very real understanding eliminated preconceptions and predispositions, paving the way for positive business transformation.

After all was said and done, we knew what we thought we had known all along: agile principles simplify what can be extremely complex processes. They do this by minimizing development of materials and maximizing real value generation. It turns out that CPQ integration is merely one more case-in-point.