To understand customers' pain points, needs, and their user journeys, we need to have a good grasp of the user personas in our target segment. We also need to be able to map each persona's journey into the product functionality.

User story maps are an effective way to organize user activities and to model the functionality of an application. They are valuable in identifying product features from a user's perspective, and are a great tool for visualizing and planning product releases. Service design thinking helps us to think through how a service can be delivered to meet a user's needs. It enables us to think through all the touch points and interactions with our users, helping us to identify bottlenecks, dependencies, and delays.

The following are some of the principles of service design (https://www.interaction-design.org/literature/article/the-principles-of-service-design-thinking-building-better-services):

When identifying product features, it's valuable to leverage both story maps and service design. It gives us a holistic view of user interactions, and touchpoints, instead of just isolated product features. I usually blend in service touchpoints with story maps, because it helps me to identify triggers for user actions and view offline user actions in the overall context of how a user interacts with our product.

For instance, when we think about first-time users, it helps to think through how a user would discover our product. We can then blend in supporting operational touchpoints and think about our product holistically. It also helps us to differentiate hygiene functionalities from value adds, for instance, login/authentication. Login by itself adds no value to anyone. A user does not gain any benefit by logging in to an app. Login doesn't sell, unless you're building an authentication service. Yet we need to build a login feature nevertheless, because it is a necessary functionality.

Login makes sense only in the context of defining what meets a user's goals: making features accessible based on user credentials. Then, it is important to identify how a guest user will use our product, compared to a logged in user. Login just becomes a small detail in an end-to-end product experience. It also helps us to think about the user's context when using the feature. Will the user access our app from the comfort of their home, or are they on the road when using our app? Is there connectivity? These questions can have a bearing on how we design the functionality.

There is a big difference in perspective between task-oriented thinking and goal-oriented thinking. Jeff Patton's User Story Mapping – User Story Mapping, Discover the Whole Story, Build the Right Product (also descried in Chapter 2, Invest in Key Business Outcomes) is a great tool for keeping our focus on a user's goals without getting distracted by the application's features. I was fortunate enough to attend one of Jeff's workshops on user story mapping many years ago. It was one of the most valuable leaps in product thinking for me. At that time, the prevalent way of product backlog and scope management was still a very system-centric view, but user story mapping showed how effective it can be when we visualize the product backlog and align it with a user's context. It changed the way I thought about prioritization and scope management.

The following is a sample story map for the digital art gallery case study introduced in Chapter 1, Identify Key Business Outcomes. It represents a part of the story map for the premium art buyers. The flow captures the need of customers to get early access and stay tuned to upcoming artworks and art shows:

In the preceding story map, there are subactivities that are not necessarily in the online product. For instance, "sign up by calling relationship manager/customer support" is not something that the product engineering team is required to build. This step may instead be implemented by the supporting functions. Yet this option for users to sign up by calling the relationship manager is an important aspect to capture on the story map. I've extended service design aspects into the story mapping itself. This presents a complete view of our product experience, rather than just a technology product's focus.

While the preceding story map captures the activities from a customer perspective, we also need to capture what happens internally to meet this customer need. The marketing team, customer relationship team, art curators, and customer support, all have a part to play in ensuring that this customer goal is met. The following is a sample story map for the marketing team:

A huge advantage of thinking through all possible interactions that a user can have with our business (product and service) early on is that it gives us alternative options for delivering a user's goal. It opens up our thinking about how we can deliver value to the user, while meeting our business outcomes, and ensuring that we don't run out of resources. This helps us to stay lean. At different stages of product maturity, we may have a task-level breakdown for subactivities. Yet, we could evaluate priorities at an activity level. This gives us the freedom to then negotiate how best to deliver value for that activity, without being bound to task-level details.

Typically, product engineering teams use MoSCoW prioritization (must haves, should haves, nice to haves, and won't have; refer to https://www.agilebusiness.org/content/moscow-prioritisation-0). Buy a Feature games also help in product feature prioritization, and 2 × 2 cost value matrices are another great way to visualize product priorities. While all of these methods seem perfectly fine in theory, there are some pitfalls when using them.

Jeff Patton compares a flat product backlog to looking at a bag of leaves instead of seeing leaves as part of the whole tree. When features/stories are presented for prioritization to stakeholders without the user context, it is hard to understand what loss of experience might occur due to their prioritization decisions. Feature A may seem like a 'nice to have' to the business, but it may be very valuable to the user. Feature B may seem like a 'must have' for the business, but it might not be easily supported, and hence might not give the user much value. A flat backlog doesn't offer this context.

Another pitfall is prioritization based on cost/effort. The need to manage scope arises out of an inability to meet timelines and budgets, based on our estimates of costs, complexity, and effort. Even if feature A costs more than feature B, it may be able to drive a much higher value to customers or bring about better business outcomes. Cost alone cannot determine priorities.

In order to increase the context for prioritizing product functionality, we need to understand its impact in terms of the following:

In my start-up, real-time changes and notifications were valuable to customers only when they had a support team that could handle these changes. DIY was not practical for them, since it only increased the workload for an already overworked team that was hard-pressed for time. It did nothing to increase our KBO of increasing revenues and acquisitions. So, it was right to not have tried to perfect or improvise on the basic functionality that we already had. However, later, when we had too many requests from our customers and when we had more events happening on the same day, it was hard to sustain costs when supporting these events. We needed the feature to be improvised to meet our needs to help us to support customer needs without burning out. Our KBO had shifted to sustain operations for a certain period of time.