Loyalty design - Treat it "lean" keep them keen

I was on a training course the other week learning about Agile Scrum which is a "lean" software development methodology that looks to develop software people actually want and need.

The traditional approach to software development (known as waterfall) requires users to provide their input up front. This is then used develop requirements that are passed to developers who write the software. The written software is then passed to testers to make sure it works.  The completed, tested software is then installed and unveiled to users - possibly 12-18 months later... who then say "that's not what I wanted".

Using Scrum changes this in a number of ways.

Firstly, it mandates that the business (as represented by the Product Owner) and developers work closely together (daily) on the development of the product.  Next, it stipulates that software is developed in chunks or sprints (no more than 4 weeks long).  This short time frame allows for a small number of important features to be developed, but ensures that if anything is going in the wrong direction it is caught early.

After the sprint is finished, there is a review which allows the team to show off what they have built so far as a releasable product to the wider business/users.  This then allows for comments and feedback so that subsequent sprints/releases can incorporate this.

Using this methodology allows us to ensure that what we build is always based on something useful and allows us to fail fast - and learn from this.  Most importantly though, it allows us to build something the users actually want and need in shorter timescales.

This approach though shouldn't just be limited to software development.

Within loyalty programme development the approach can be the same.  We speak with users initially; carrying out research studies and focus groups to understand what they want (or think they want).  Programmes are then designed, developed, implemented and launched - at which point we involve the users again, hoping they might actually participate.

The problem with this approach is the same as with waterfall software development - the potential for an incorrect perception of what consumers actually want and an inability to separate out what they say from what they do.

For example, a recent WorldPay Report entitled Perfect Passenger Payments highlighted the misalignment between what factors airlines think are important to consumers and what consumers feel are important.

Within the report, airlines stated that the #1 factor for customers was the "Overall speed of the online booking process" (96%), closely followed by the "Website functionality" (80%).

Customer however sited "Ease of finding flights" (89%), "Clear, upfront pricing" (88%) and "Confirmation/After-Sales support" (85%).  Overall, "Speed" ranked 7th and "Website Design" was down at 12th position.  Worryingly, while 85% of customers said after-sales support was important, only 18% of airlines felt this was important to customers.

This disparity between what customers want and what airlines think they want is reflected in how customers are consulted.  Within the research, less than 40% of the airlines spoken to said they consulted customers on the booking experience - and even then, only "periodically".

Sometimes we think we know what's best for our customers when really, we're simply thinking about what's best for our business.  Using "lean" methods is one way to join these two requirements together.  Building and launching a small number of features and functions, quickly and cheaply provides a way to test and learn with customers.

In a recent article on Tech Crunch called "How to create a minimum viable product", Emre Sokullu, founder and Chief Architect of GROUP.PS said:-

"Perhaps the biggest mistake I’ve made at GROU.PS at its initial phase was to add way too many features onto it. [..] The result? An unstable product which was trying to do too much and poor user experiences due to an overwhelming set of functionalities."

Whether you have an mature loyalty programme or are just starting out, using "lean" methods to develop, deploy and decide on features and functions will help your programme become innovative and forward thinking; letting you learn quickly, fail fast and keep customers keen.