During the first few months at my start-up, we built an early version of an event app platform to engage conference audiences. We sold our product to a few conference organizers. One of our ideas was that event organizers would love the ability to make changes to schedules on the fly and they would want to notify the attendees about these changes. We had two parts to our solution: an admin console that could be used only from a laptop and an end user-facing mobile app. The problem was that our customers (the event organizer) wanted only a well-designed, visually-appealing, and white-labeled app. They were willing to pay us only for the solution that would amplify the value they were providing to their customers. The event organizers rarely used the admin console. They sought our help whenever they needed to use any functionality in the admin console.

When we sat down as a team, we observed with dismay that the organizers never or rarely used real-time notifications. We jumped to the conclusion that they were not using them because they were accessible on a laptop and not on their mobile phones. I remember we spent three hours having a heated debate about the best way to solve this. We wanted our platform to be a DIY platform. We came up three ideas: building a mobile admin console, creating a WhatsApp-like chat, or notifying the attendees using SMS. All our ideas were based on two big assumptions:

After our three hours of healthy discussion in our start-up team, we realized that none of our customers had complained about not being able to send notifications to attendees themselves so far. We didn't know if it was because they didn't know about the feature or they didn't use it because it was available only on the desktop admin console. We, once again, jumped to the conclusion that the customers actually needed the ability to send notifications but weren't complaining. So far, our customers had always called us a day before the event and relied on us to make the necessary changes from the admin console. So, we threw open more ideas to somehow build this into the product so that it could become a DIY (Do-It-Yourself) value proposition. We could never reach a consensus on what that solution would look like. There was other functionality that customers were asking for, and we had limited resources. So, we decided to wait it out, while gathering data, observing, and talking to our customers, before we decided on an approach. In retrospect, this was one of the smartest things we did.

Over the following eight months, we had one or two occasions where conference organizers wanted the ability to send notifications themselves. They told us that they couldn't bring a laptop to the venue. On those occasions, we charged them extra, and sent in an intern and a laptop to help during the event. We eventually built the feature enabling notifications for more than a year, and 40 conferences, later. We built it mainly to reduce our operational costs rather than as a benefit to the customer. It was not sustainable to send an intern and a laptop anymore. So, the feature was built in with an unpolished UI and with just enough functionality that we had seen used in the past year. All along, event organizers had expected us to support them with last-minute schedule changes.

We thought that by making it easier for our customers to send notifications and the feature accessible on mobile we could increase our revenue, because event organizers would be willing to pay more for a DIY feature. While they were willing to pay more for the functionality (of making real-time changes), they weren't really keen on the DIY aspect. If anything, it added more to their workload, and they were extremely stretched and the time constrained during the days of the event already.

We realized that this feature was not a revenue generator, but a cost saver. Since the organizers were always leaning on us to help with last-minute changes, we had to find the best way to optimize our costs and time in responding to their requests. We would have had to take a very different approach had we wanted to turn this into a revenue generator, and that could have been an undertaking that we as a team may have been unprepared for.

There was nothing wrong with the ideas that we had. What we didn't know was the impact our ideas could deliver. A reflective pause is essential between an idea and finding the best way to implement the idea. The reflective pause should help us to understand our users. It should also help us to understand what we would gain as a business from our idea and make it possible to define and plan for the success of your idea.

Often, we tend to look at the product features in isolation. We prioritize features based on relative merit, rarely questioning if a feature is needed at all. In the case of my start-up, we could have made the mistake of evaluating if SMS notifications were more valuable than the mobile admin console. However, the more important questions were: do we need this feature? Is there a better way to deliver the value proposition without building anything more than what we already have? Should we instead build something else more valuable? For us, customer acquisitions and conversions were the most important business outcomes. One way we could have validated the value of this feature was by explicitly creating pricing plans, which excluded/included the notification feature and validated if it impacted our acquisitions. We could then have asked: are our leads converting because we have this feature? Are our customers opting for the plan that includes notifications? We hadn't been very smart about this, but at least we learned an important lesson! Prioritizing features requires finding that fine intersection between "why," "what," and "how." Let's begin with identifying the product features.

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.

Once we have a backlog of user features, we need to estimate the impact of those features on invested business outcomes. I use the word "estimate," since we're only trying to guess the extent of the impact that a feature could have on our business outcomes. Even when we have data and insights about usage patterns and needs, we may not be able to accurately pinpoint our product's performance. Since businesses (and products) operate under high ambiguity, we may have little control over what could influence our product's performance. So, in order for us to plan ahead, we have to rely on past data, our business aspirations, our resources, our capabilities, our strengths, and our weaknesses:

Deriving value scores

In Chapter 2, Invest in Key Business Outcomes, we discussed using the Investment Game. We were able to capture the amount that business stakeholders would be willing to invest in the Key Business Outcomes. For the ArtGalore digital art gallery, we considered an investment as follows:

Business outcome
Engagement	Generated revenue
Invested amount	300	200

Based on our preceding user story map, we can create a sample list of feature ideas (given as follows). I am calling them ideas because these are not yet confirmed to be product features:

Feature ideas that meet business outcomes:

1. Premium art buyers can sign up to receive a newsletter with details of upcoming art shows, artists, and artworks
2. All art buyers can choose one or more artworks listed in the newsletter and purchase them
3. Smart recommendations for artworks to include in newsletter (internal)
4. Existing buyers can enter a lucky draw to meet an artist of the month
5. Auto-create newsletter content instead of having to prepare newsletter manually (internal)

Now, how do we prioritize these features based on value? Are features one and two equally important to build? What if we could determine the exact value for each feature? This can be determined using educated guesses! We can try to get all scientific about estimations, but that's exactly what they are—estimates. So why not estimate the value of a feature's impact on business outcomes?

Here's how to go about making a feature impact estimation: product managers, along with business stakeholders, estimate the impact of each feature on the Key Business Outcomes. They rate each feature on a scale of 0-10. The rating indicates the extent of the impact each feature can have on each invested business outcome. For instance, what impact will "existing buyers can enter a lucky draw to meet an artist of the month" have on engagement and generated revenue?

Stakeholders evaluate this based on how they envision the feature to be delivered. We could base our evaluation on data, insights from past user feedback, behavior, market trends, or even gut feeling! The key thing here is the conversations that happen at this stage. This is when stakeholders are actively discussing how to take a feature to market. They discuss the value that this feature can offer to the users. They are doing this without being constrained by the costs involved. So, let's say that stakeholders agree that we can predict that personalized, well-curated art catalogs would impact acquisitions at a 1 on the scale. Similarly, we can arrive at an estimated impact of this feature on engagement and generating revenue:

		Engagement	Generated revenue
Premium art buyers can sign up to receive a newsletter with details of upcoming art shows, artists, and artworks.	Estimated impact	7	3

This is an indicative rating. There are no right or wrong values for the estimated impact. We will be able to validate if our estimated ratings met the mark only when we generate outcomes by meeting defined success criteria. We will see more about success criteria in Chapter 4, Plan for Success.

So, the preceding table is showing what the digital art gallery business thinks the estimated impact for "premium art buyer can sign up to receive a newsletter with details of upcoming art shows, artists and artworks" will be. They expect this idea to create a lot of engagement (ranked 7 for estimated impact on the scale of 0 to 10), and they expect it to have a little impact on generating revenue (ranked 3 for estimated impact on the scale of 0 to 10). Similarly, we can assess every feature against the business outcomes. The following is a representative illustration of the estimated impact per feature idea against each business outcome:

		Engagement	Generated revenue
Feature idea	Invested amount	300	200
#1 – Premium art buyers can sign up to receive a newsletter with details of upcoming art shows, artists, and artworks.	Estimated impact	7	3
#2 – All art buyers can choose one or more artworks listed in the newsletter and purchase them.	Estimated impact	5	3
#3 – Smart recommendations for artworks to include in newsletter (internal).	Estimated impact	5	0
#4 – Existing buyers can enter a lucky draw to meet an artist of the month.	Estimated impact	6	0
#5 – Auto-create newsletter content instead of having to prepare newsletter manually (internal).	Estimated impact	0	0

We're still one step away from arriving at a comparative value. We can now calculate weighted scores based on the invested amount (weight) and estimated impact scores. For instance, for feature one, the total value score would be (300x7) + (200x3) = 2700 points. Similarly, we can calculate the value for every feature and arrive at a table as follows:

Now, when we sort the results based on the total impact scores for each feature, we can figure out the most valuable feature. The most impactful features are the ones with the highest impact scores.

A cost-value 2 × 2 matrix is another great tool for visualizing the relative priorities of features.

A 2 × 2 matrix captures the value on one axis and the cost on the other. Together they form two quadrants, which can be depicted as follows:

Typically, the costs are a combination of development effort and technical complexity, while impact is the impact that the feature idea could have on Key Business Outcomes and customer value. However, we now have features already prioritized for us, based on the projected business outcomes represented as a number value. Also, we know that the maximum impact that a feature can have is 5000 (500 × 10, where 500 is the maximum amount that can be invested and 10 is the maximum estimated impact rating), and the lowest is zero.

We can now arrange our feature cards based on their relative impact. We don't yet know the costs associated with building each feature. The following is a representation of our feature ideas listed earlier in the 2 × 2 matrix, purely based on their impact scores:

Feature idea 5 is not in the grid since it was estimated to have zero impact on Key Business Outcomes. So, feature 5 is already out of our backlog. Now we need to find the best way to implement these four feature ideas. To do this, we need to define what success means for each feature idea, and then evaluate the costs associated with them.

In this chapter, we learned that the product backlog must include only those feature ideas that will have a significant impact on Key Business Outcomes. If a feature idea is not expected to meet Key Business Outcomes, then there is no value in spending any effort in exploring the idea. Effort here is analysis, viability testing, market research, and so on. Needless to say, we need data and insights to make a better estimate about the impact of a feature idea, but sifting through this ensures that our product backlog stays lean. We can then steer all our efforts toward the most valuable outcomes, both for the customer and for the business. Impact scores are only one aspect of determining the effectiveness of a feature. There are costs associated with implementing a feature idea.

Before we venture into the costs of building a feature, we need to define success criteria. We must define what indicators will tell us not just if our estimated value impact is correct, but also where we failed to find success. What makes us happy? Is it user experience? Is it how quickly users can access our content? Is it the quality of our content? Is it the lack of complaints about mismatched content? Let's find out more about defining success criteria in the next chapter.