People like ice cream. That seems a fairly reasonable statement to make; but on that knowledge alone, would you then stock your store with hotdog and wasabi flavored offerings? Probably not.
Why?, Because it’s not what your customer wants. It’s surprising then that when it comes to large infrastructure and technology based customer impacting projects that they are being built upon technical requirements that focus on functionality and system integration rather than what the customer really wants.
The methodology is flawed.
What’s missing is a deeper acknowledgment and understanding of why the project exists in the first instance. The customer experience shouldn’t be premised on the bells and whistles the project will provide, but on the ‘jobs’ that need to be delivered, more specifically the product or service to perform. In short, your customer should be defining the scope of your project, not your technical team.
Take Google+ for example. Its aim was to make sharing on the web more like sharing in real life however buy-in has been negligible. In an open letter to Google employees (that accidently went public), Google engineer Steve Yegge criticised management stating: “Our Google+ team took a look at the aftermarket and said: ‘Gosh, it looks like we need some games. Let’s go contract someone to, um, write some games for us.’ Do you begin to see how incredibly wrong that thinking is now? The problem is that we are trying to predict what people want and deliver it for them.”
This reactive mentality meant Google missed the opportunity to explore customers’ sentiment and understand the functionality required by users to willingly adopt the newer platform; a mistake that is made far too often.
As soon as the project is dictating to customers; you’ve failed. Find out what your customers actually want then work back to establish your system requirements and implementation strategy.
Once you’ve established the jobs your product or service needs to perform, it’s time to map and test the desired experience against your capabilities. Pressure test different scenarios and factor in the possibility of exceptions. Like every project, there will be many.
With a road toll transaction for example, what happens if there is a delay in an online top-up reaching the customers account and they continue to travel? What will the customer experience be like? Is that an acceptable experience? If not, can the process be improved without blowing out your costs and credit exposure? If the answer is no, you need to go back to the drawing board and re-work the process until it meets both the customer and your companies requirements. It is only once your handling of exceptions reflects the experience your customer desires that the specific piece of functionality should form part of the system. If at any stage this deviates from the experience you’re trying to provide, you need to stop, re-focus and start again.
Never compromise or take for granted the intelligence customers provide you on their desired experience. It is those very customers after all, that will determine the success of your project and its longevity.
So before you get bogged down in scope setting and defining technical parameters, ask your customer and yourself:
- What “job” does my service or product need to offer?
- What experience do I need to offer to customers for them to become an advocate of my product/service?
- What happens to that experience if something goes wrong and needs to be treated through an exception process?
- How can I build the customer voice into the development and review points of the project and beyond?
In closing, standard project methodologies are sound and appropriate to use, but only after the customer experience is understood and provides a foundation for your offering. Don’t dismiss it as an intangible requirement; their happiness is actually your only requirement.