Pricing software initiatives are not unlike other, enterprise-wide system projects... they require the careful steps of planning, from requirements (what is the process?) through to any necessary systems implementation and ultimately user change. How then, can you better mitigate the risk that users fail to change? Best practices dictate starting small. If you apply this to software, think about all your retail, shrink-wrapped software... does it do everything you want it to? No. If Microsoft, Adobe, Intuit, and other developers waited until the software met 100% of their user needs, nothing would ever get released.
The best approach leaves users wanting more... no... the best approach leaves users demanding more because they see the immense value in what "little" they have. And "little" is not referring to the amount of work or development that goes into the software; "little" is referencing the percentage of value that the user is now envisioning. The key word in the last sentence is now. They were not receiving any value before and now envision whole new ways to go about their business. In short, simple and small releases begin the process of evolving the user into more than what they were before. Trying to predict where that evolution will take them is a worthwhile activity, but should not prevent achieving short-term value. In addition, software development is a journey that both developers and users must agree to take together. It is a partnership.
In addition, releasing smaller, value-add functionality has several key points that should not be taken for granted:
- Learn where to adjust and tweak without changing (read: wasting) efforts
- Actual software does wonders to mitigate "perceived" risks; in a battle between facts and gut feelings, facts always win
- Creating case studies out of the initial results is a great way to socialize and promote future development
One of my previous customers took the above approach to their pricing systems. Instead of requiring the system to meet 100% or even 70% of the stated needs, they asked each BU to list out their #1 pricing work flow. They narrowed down the need list from more than 50 items to 6. The pricing system was in place in 90 days, configured only to meet those 6 needs. The response was overwhelming. The users saw immense value in 90 days; ROI was more than 4x expectations; and the BUs started wanting more. This "pull" situation, where users want to adopt the system and will "pull" it from you, is much better than the alternative of a "push" situation, where users are asked to adopt because you are "pushing" it upon them.
As stated above, software development is a journey. To begin, you need to know where you are today and where you want to be tomorrow. Anything after that is completely based on what you discover along the way. You should know where you want to go, but allow for flexibility and change along the way. It is the same for software. Begin using it today to get value, discover more about your people and processes, and allow for evolution and change. It is the quickest way to an assured ROI figure and the quickest time-to-value.
For those that have been involved in pricing software implementations, what have been some of the tactics you have utilized to gain traction quickly? Any examples of when this has not had the desired results?
For those that have been involved in pricing software implementations, what have been some of the tactics you have utilized to gain traction quickly? Any examples of when this has not had the desired results?
Comment/question from LinkedIn: "Hi Michael, nice blog :)
ReplyDeleteWhat do you mean by "#1 pricing work flow" ?
I could imagine that you mean what factors influence price for each BU... but i'm not sure...
Thanks for the extra info!
We haven't implemented anything in the line of pricing software yet, but we're getting ready to start considering our options. First, we need to clarify for ourselves what we would want out of it, and whether it would be worth the investment... " - Nicolene Barnard
They went through exactly what you are mentioning you are about to embark on... clarifying what exactly they want out of the software. In my 15+ years of IT-related projects, the worst question that can be asked is typically (to a power user), "what do you want [the software] to do?" You will get 1,000 disparate answers! However, this is exactly what needs to be done. This company that I referenced did just that, but indirectly. Instead of asking what users wanted, they asked for the "most important pricing work flow" - in other words, "what process do you follow to get prices out the door 95% of the time?" they attempted to limit this to one, but did get several responses back per BU (on the average, ~5-6), which was expected. Out of these, they combined the similar processes into a higher-level, more general process that was still applicable. This helped narrow down the "wants", but at the same time allowed each BU to provide input and subscribe to the desired end-state.