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?