Contrary to the dreaded requirement document from the previous chapter, the discussion is an essential part of story maps, and we create them to help facilitate a healthy communication. My best answer to why should you create user story maps? is as follows:
User story maps solve the user's problems in the form of a discussion. Your job as a product manager or user experience consultant should be to make the world better through user-centric products, essentially by solving the user's problems.
Contrary to popular belief, user story maps are not just cash cows for agile experts. They will help a product to succeed, by increasing their understanding of the system. Not just what's inside it, but what will happen to the world as a result of such a system. By focusing on the opportunity and outcomes that will enable opportunity, the team can prioritize development. In reality, this often means stopping the proliferation of features and underdoing your competition.
Wait a minute, did you just read underdoing? As in, fewer features, not making bold promises, and significantly less customizability and options? Yes, indeed. The founders of Basecamp (formerly 37signals) are the champions of building less. In their book, ReWork: Change the Way You Work Forever, they tell Basecamp's success story while giving vital advice to anyone trying to run a build a product or a start-up:
When things aren't working, the natural inclination is to throw more at the problem. More people, time, and money. All that ends up doing is making the problem bigger. The right way to go is the opposite direction: cut back. So do less. Your project won't suffer nearly as much as you fear. In fact, there's a good chance it'll end up even better.
- Jason Fried
User story maps will help you to throw less at the problem, chopping down extras, until you reach an awesome product, which is actually done. One of the problems with long product backlogs or nightmarish requirement documents is that it never gets done, literally never.
Once I had to work on improving the user experience of a bank's backend. It was a gargantuan task, as this backend was a large collection of distributed microservices, which meant hundreds of different forms with hard-to-understand functions and a badly designed multi-level menu that connected them together. I knew almost nothing about banking, and they knew almost nothing about UX, so this was a match made in heaven. They gave me a twelve-page document. That was just the non-disclosure agreement. The project had many 100+ page documents, detailing various things and how they are done, complete with business processes and banking jargon. They wanted us to compile an expert review on what needs to be redesigned and create a detailed strategy for that. I found a better use of their money than wasting time on expert reviews and redesign strategies at that stage. Recording or even watching bank employees while they used the system during their work was out of the question. So we went for the quick win and did user story mapping in the first week of the project. Among the attendees of the user story mapping sessions, there were a few non-manager-level bank employees, who used the backend extensively. One of them was quite new to her job, but fortunately, quite talkative about it. It was immediately evident that most employees almost never used at least 95% of the functionality. Those were reserved for specially trained people, usually managers. After creating the user story map with the most essential and frequently used features, I suggested a backend interface, which only contained about 1% of the functionality of the old system at first, with the mention of other features to be added later. (As a UX consultant, you should avoid saying no, instead try saying later. It has the same effect for the project, but keeps everyone happy.) No one in the room believed that such a crazy idea would go through senior management, although they supported the proposal. Quite the contrary, it did go extremely well with their senior management. The senior managers understood that by creating a simple and fast backend user interface, they will be able to reduce the queues without hiring new employees. Moreover, if they need to hire people, training will be easier and faster. The new UI could also reduce the number of human errors. Almost all of the old backend was still online 2 years later, although used only by a few employees. This made both the product and the information security team happy, not to mention the HR. The functionality of the new application extended only slightly in 24 months. Nobody complained, and the bank's customers were happy with smaller queues. All this was achieved with a pack of colored sticky notes, some markers and, more importantly, a discussion and shared understanding.
This is just one example how a simple technique, such as user story mapping, could save millions of dollars for a company.
