A couple of weeks ago a colleague’s house burned down. An electrical fault sparked it in the next door neighbours garage, the wind turned and within minutes his house was on fire. His first priority was to get his family out of the house. He had an opportunity to run back in to grab one thing. Something. Anything.
If your house was on fire, what would be the one thing that you would save? (He saved the hard drive with all the family photographs on).
All airlines are the same. They fly the same planes to the same airports for (roughly) the same prices. What differentiates them? Attention to detail. It’s not just the functional detail – it’s the experiential detail that really makes the difference.
It’s the same with software. If the application you are building was an airline, which airline would it be? All to often developers focus on the plane, building something to fulfil the utility of getting people from A to B. Yet the customer doesn’t care about whether it’s an Airbus A330 or a Boeing 777, what they care about, and what they remember is the experience they have.
(This can be a useful exercise at the outset of a new project, ask stakeholders to imagine their finished applciation was an airline, what brand would it be? This helps anchor expectations; are you building a full service Singapore Airlines or a no-frills EasyJet?)
One of the problems with IT development is that it is tactical and piecemeal in its approach. Functionality is added in response to competitor or broader market activity. Expect to see an increasing number of brands doing something ‘social’ (and tactical) on the web, but don’t expect these new initiatives to be (strategic) seamlessly integrated into the existing digital channel offering.
This piecemeal approach extends to larger initiatives as well. In refreshing the website or developing new digital channels such as mobile and TV, IT will typically build out features and functionality prioritised upon their perceived individual business value regardless of what the sum value of the proposed release is. (Focusing all your effort of building functionality that delivers to your bottom line will seldom be as successful as you predict if it is not supported by features that meet the customers needs).
So when it comes to thinking about new features and functionality, where’s the best place to start? I’d suggest collaboratively, thinking around the customer. Collaboration is important to ensure that everyone starts with the same vision. It needs to be shared it with the broader audience, the product teams, IT; anyone whose day to life life will be touched by the project when it starts. I’d argue that you cannot start this soon enough. You don’t need to spend time doing analysis, interviewing all stakeholders individually, coming up with a document that is circulated and reviewed and re-written (with all the delays and waste that such a process incurs). Start the process getting all those stakeholders off-site for an afternoon and get the thoughts out on the table.
Commence with a presentation that introduces thinking in terms of customers and customer journeys. The below SlideShare presentation does this for the airline industry, addressing a new customer experience across channels. I acknowledge that it is pretty simple and doesn’t touch on half the ideas that airline executives may have. That is the point, it is just enough to get people thinking about different customer types and their touchpoints without getting bogged down in detail. This is what we want the participants of the off-site to share.
[slideshare id=912224&doc=airline-deck1-1231817842408345-3&w=425]
Once we’ve been through the presentation we break out into small groups a, each taking an individual customer (or persona) and build up a story; a day in the life of… (It is important not to forget the internal users of the system). These breakouts last 15-20 minutes with ten minutes for the team to play back their findings. As they build out a richer picture of the customer interactions they are asked to sketch out what the user interfaces may look like. The process is rapid, intense and iterative, but always focussing upon the customer journey; how will the customer realise their goals. When the teams tell their stories an analyst captures the essence of the requirements on index cards. The final exercise is to lay all these cards on the table and ask the team to group them into similar areas then prioritise them according to their perceived importance. In an afternoon you will have achieved four things. Firstly, you will have captured a vision for the new product in less than a day, with all stakeholders understanding not only the vision itself, but also the process that developed it and the concerns and issues that different parts of the business have with it. Secondly you will have an initial prioritised roadmap for its development. This will change, but it is a good strawman to circulate. Thirdly you will have introduced all the stakeholders together – projects succeed or fail based upon the strength of relationships and getting people engaged from the start will go a long way to creating shared ownership. And finally you will have generated energy, engagement and traction; to do the business case and to get the project started, recognising that just one part of the business having a vision is not going to bring it to the life that they dream.
Want to prove it? Take a sheet of paper. Tear it in half (under the table so I can’t see). Now show the two halves. You tore it in half side-ways didn’t you. I tore it length-ways. Same instruction, same materials, completely different result.