Chapter 5. Identify the Impact Driven Product

In the past few chapters, we saw how to evaluate the impact of feature ideas and define our success metrics. While defining success metrics, we were able to identify the different aspects of a business that need to come together to weave a delightful end-to-end product experience. This is the first step in creating a plan of execution for a feature idea, but there are many ways in which we can create the product and deliver value. Businesses strive to create products that provide lasting value for their customers. The Impact Driven Product for a business is not just about something that works. It is about what creates the most value. Product development should be open to consider, compare, and evaluate the value of building something from scratch versus buying an existing solution versus the necessity of building anything at all.

This chapter addresses the following topics:

• Value mapping
• Defining the Impact Driven Product
• Understanding the risks and costs of implementing a feature idea

Understanding product impact

"You mustn't be afraid to dream a little bigger, darling."

Eames, Inception

When I was in school, my uncle took us for a walk. He started talking about the house he was building. My dad had also just bought a house, and I was quite excited about the prospect of living in our own place. We were one of the first few people in the family who had ventured to buy a property. My uncle paused and asked me why he and my dad were able to buy a house, while our grandparents couldn't. I didn't blink before answering, "You both make more money." My uncle laughed so hard, and said, "No, we don't. We just have better access to loans." Sure enough, home loans opened up a lifetime goal for many.

Until a couple of decades ago, taking photos for pleasure was accessible only to those who could afford a camera. The alternative was to visit a photo studio. Every family had a similar looking family picture. I even read somewhere the story of parents who had taken a photo of only their firstborn. Every other child was shown the same photo as their childhood photo! Of course, mobile phones changed all that. A century ago, knowledge was restricted to a privileged few. Schools, libraries, and now the internet have democratized education.

Disruption happens when products impact people's lives in ways that were hitherto unrealized. Often, even creators cannot foresee these impacts. Visionaries can imagine a world in a way that is not bound by today's scarcity, and the disruption is a by-product of ambitious goals. Today's technological advances, infrastructure capabilities, talent, and opportunities make it possible for more of us to dream bigger. Success or failure depends on adoption and execution.

What minimum viability attempted to inculcate was a practice of building just what was enough to satisfy early adopters. The intent was to validate the riskiest hypotheses, without running out of runway. The riskiest hypotheses could be about technology viability, market adoption, revenue generation, and the overall business model itself.

We translated minimum viability to suggest that "we have limited resources. We don't know what will work. Let's build a product that is small enough to tell us if our idea works, without burning our resources." This is not at all a bad idea and is in fact the right way to approach untested waters. However, when employing market-ready technology (where technology viability has been proven and can be applied to business use cases), this mindset about building as little as possible can be limiting. We cannot build an ambitious business with a minimum product experience. Our mindset should shift to "we have ambitious goals. We don't know what will work. Let's deliver as much value to our customers, while generating as much value for the business. We find a way to make this work or we die trying!"

We need to change our mindset and leap for success, instead of bracing against failures. This does not mean that we have to build the whole gamut of functionality. It only means that we must be smart about building the most impactful functionality, without compromising on creating a delightful product experience.

Product teams must continue to explore the best way to deliver impact. This does not mean that we need to build everything from scratch. Our value is in being able to see the big picture and set up the business, customers, and the product for success. For this, we need to write the sheet music, not be the solo pianist. Defining business outcomes and the success metrics at a high level gives us a good handle on the value of a product experience. It also gives us an idea of the riskiest hypotheses we need to validate. Now we need to establish the cost of creating that product experience.

The cost of creating an impactful product experience

While business sponsors bet on business outcomes, they expect a good return on their investment (ROI). This investment was to build the most impactful product experience. Cost is a factor when evaluating the ROI, but it does not have to be a deciding factor.

Our capacity to deliver, drives the trade-offs we make. We need to the set the bar on product experience outcomes high enough, but at the same time, set ourselves up for success. Now we have to figure out how to succeed without burning all our resources (or running out of money). There is cost involved in building (people, skills, resources, support, and so on). There is also risk and we will incur risk by not building something today. It is important to have insights on missed opportunity, the cost of a rework, the cost of a repair, and so on. Once we identify our risks, we can choose to invest more to mitigate them or choose to live with the risks:

To find the smartest way to create a product experience, product teams need to consider the following:

• Value mapping
• Our Impact Driven Product
• Deciding to build, buy, or not at all
• The cost of a digital solution
• The risks of not building

Defining the Impact Driven Product

At this point, we have an idea about the functionality we need for meeting ArtGalore's Key Business Outcomes. We already have the high-level user story map defined:

We also have prioritized the features that we need to build in order to meet the business outcomes:

We have success criteria for each feature:

The next step is to detail the user journeys for each feature. For this, we need to keep in mind the success criteria we're aiming for. These success criteria need to get woven into the product experience. We also need a way to measure and validate the success metrics.

Let's take a look at the feature that marketplace visitors can sign up to receive a monthly art catalog:

The activity "subscribers should be able to read newsletters through mobile or desktop" has captured the success metrics, but signing up is not enough. Receiving the actual newsletter, and then having an option to unsubscribe, are necessary to completing the end-to-end functionality.

We do know now that the success metric is defined by the ease of signing up. At this point, we would do well to explore if we should ask the user to sign up on the website and receive the newsletter through postal mail even! We could also explore if the option to unsubscribe is legally mandated. The important aspect here is to define the user journey. For instance, if a feature is not mandated by legal compliance, then that is a negotiable card for us now. It also depends on the target segment. So, we could still choose to not build a feature now and decide to manage the risk. The risk is not just because of legal noncompliance but also about how the brand can be perceived. There is a cost of risk associated with this, which will be captured in subsequent steps.

This negotiation is possible only where our success has no direct correlation with the functionality. At this stage, we want to elaborate all possible journeys for a user to meet their goal. There are many journeys to offering this product experience. For instance, any of the following is possible:

• Users can sign up on the website (desktop and mobile) and receive the newsletter by postal mail, with no option to unsubscribe
• Users can sign up on the website (desktop and mobile) and receive the newsletter by email, with no option to unsubscribe
• Users can sign up on website (desktop and mobile), receive the newsletter by postal mail, and unsubscribe online
• Users can sign up on the website (desktop and mobile), receive the newsletter by postal mail, and unsubscribe offline (call/email)
• Users can sign up on the website (desktop and mobile), receive the newsletter by email, and unsubscribe online
• Users can sign up on the website (desktop and mobile), receive the newsletter by email, and unsubscribe offline (call/email)
• Users can sign up by email and receive the newsletter by postal mail, with no option to unsubscribe
• Users can sign up by email and receive the newsletter by email, with no option to unsubscribe
• Users can sign up by email, receive the newsletter by postal mail, and unsubscribe online
• Users can sign up by email, receive the newsletter by postal mail, and unsubscribe offline (call/email)
• Users can sign up by email, receive the newsletter by email, and unsubscribe online
• Users can sign up by email, receive the newsletter by email, and unsubscribe offline (call/email)
• Users can sign up by calling and receive the newsletter by postal mail, with no option to unsubscribe
• Users can sign up by calling and receive the newsletter by email, with no option to unsubscribe
• Users can sign up by calling, receive the newsletter by postal mail, and unsubscribe online
• Users can sign up by calling, receive the newsletter by postal mail, and unsubscribe offline (call/email)
• Users can sign up by calling, receive the newsletter by email, and unsubscribe online
• Users can sign up by calling, receive the newsletter by email, and unsubscribe offline (call/email)

So, our Impact Driven Product for this feature is the one that offers the best possible user experience including the functionality that meets the success criteria, plus metrics to measure the success criteria. Before we decide the costs of building this, we need to map the value.

Value mapping

When creating a product experience, technology can play two roles. Firstly, technology can be a business enabler, where business operations or some parts of the core business, are complemented by digital solutions. Secondly, technology can be a differentiator. Here, software technology/digital solutions drive the core business.

It is important to internalize the difference between the two roles that technology plays in our business. Business enablers can bring a great deal of value to the business, but they play only a supporting role. Businesses can still exist without a digital enabler, although they may not thrive or scale, whereas, a differentiator is the core product itself. If the digital product doesn't exist, then there is no business to run. This is where the IP (intellectual property, which is the intangible value created from patents, copyright, or creativity) of a product is created.

So, business outcomes can be driven by digital solutions that are either enablers or differentiators. It is crucial to know if the feature that we are evaluating is a differentiator or an enabler. In the case of our newsletter, the content of the newsletter (our curated artworks and so on) forms our differentiators. However, the process to receive the newsletters isn't our differentiator. So, we can choose to build the simplest digital solution or leverage what already exists. At this point, let's say that to evaluate these four journeys is our best bet for creating an Impact Driven Product experience:

• Users can sign up by email, receive the newsletter by email, and unsubscribe online
• Users can sign up on the website (desktop and mobile), receive the newsletter by email, and unsubscribe online
• Users can sign up by email, receive the newsletter by postal mail, and unsubscribe online
• Users can sign up on the website (desktop and mobile), receive the newsletter by postal mail, and unsubscribe online

Deciding to build, buy, or not at all

We don't need to start coding every feature into the digital solution. During the early stages of product development, we must assess where to spend our capacity and resources. Often, both business sponsors and engineers get carried away by the possibilities that a digital solution can offer. Since we have now methodically established the business outcomes, the most important product features, and the success metrics to achieve, we need to find the right fitment of solutions.

Once we have established a differentiator or an enabler, we need to explore the possible options available to us. The first step is to decide if there is even any value in building the feature. We could also look for solutions outside (off-the-shelf products) or use an open source tool or outsource (to a noncore product development team). If our feature is an enabler and if our success metrics can be achieved by an off-the-shelf tool, then we should just proceed with finding the optimal tool.

In our example from the preceding story map, our feature is to ship out a newsletter. We need to assess how the content of the newsletter will be created. The value of the newsletter is in the content it offers to the art buyer. This is the differentiator, and hence we might do well to invest heavily in content building, rather than in the process. In this context, if we assess sending newsletters by postal mail versus sending them by email, then email seems to be the lightweight option.

Now, we can also explore the best way to allow users to sign up. Sending an email seems simple enough for users, but for them to discover our email address, they're likely to be already on the website. Also, it takes additional effort for someone to sort through the email requests and maintain this list. In this context, building a simple sign-in section on the existing website and mailing to the subscribed list, might be efficient. So, we might arrive at the following journey as the most valuable experience:

• Users can sign up on the website (desktop and mobile), receive the newsletter by email, and unsubscribe online

We need to have a way to track the success metrics. So, this also forms our digital solution. This tracking will be not just for the metrics related to signing up, but also for us to track how many of the users who signed up converted to enquiries or sales. Again, this is an assessment about an enabler/differentiator. While the data itself is privy to us, the process of capturing the metrics may not be our differentiator. So, there is an opportunity for us to explore off-the-shelf tools that can help us to capture and report metrics.

The cost of a digital solution

We get to this step only if we have established whether a feature is a differentiator or an enabler, but with no options or suboptimal options, for ready-made solutions. We need to assess if we can build this functionality in the time frame that we have (refer to Chapter 6, Managing the Scope of an Impact-Drive Product).

This will help us to arrive at the costs that include (but are not limited to) the following:

• The development cost (time and people)
• Resources (software, assets, and hardware)
• Hosting
• Support and maintenance
• Training

Now we can drill down to the specifics of cost numbers. A quick-and-dirty solution might require higher maintenance. Compromise on user experience might require higher training investment. In some cases, pricing for hosting, an off-the-shelf solution needs to be worked out. However, our cost assessments can also be relative. So, we can box our feature costs into small, medium, or large buckets, or even rank them on a scale of 1-10 in terms of complexity (determined based on the preceding aspects).

Risks of not building something

In some cases, we may end up not meeting some functionality, because the cost of building is too high. Yet not building something might have a negative effect on the product experience. For instance, providing an unsubscribe option in a user's profile might involve higher development effort. This might increase the rank of this card from three to five (on a scale of ten). So, we decide that this is not the most critical functionality to build at the moment. The success criteria are not dependent on the ability to unsubscribe, but compliance requires us to offer the option. So, we are incurring a risk by not providing this option. We have to agree to invest in the cost of building this option the perfect way, or decide to incur the risk, or find a simpler way to do this. We further refine our journey as the most valuable experience, as shown here:

• Users can sign up on the website (desktop and mobile), receive the newsletter by email, and unsubscribe offline (email/call)

Risks are the items that can meet all success criteria needed today, but may incur a future cost. This could be due to any of the following reasons:

• Extensibility (can we build on this later?)
• User experience consistency
• User experience completeness
• Branding consistency
• Rework due to future scale/functional/compliance needs

This is not to be confused with a scope negotiation. This risk is an indication of the compromises we are making today, in the context of current internal and external constraints, in order to meet the Key Business Outcomes and success metrics. It would help to capture these risks as trackable cards in our risk backlog. We can revisit these risks later.

The items on the risk potential list should be reviewed, based on the impact they could have on the business outcomes. We can then choose to factor them into our cost of building or continue to keep them as open risks.

What if our costs are too high if we have to meet all success metrics? Should we attempt to deprioritize any success metric? This is a business decision to make. If the ratio of cost to impact isn't acceptable to the business, then we need to explore what is increasing our costs. Is it a technical approach we have taken, or are the goals so ambitious that we cannot achieve them? This means that the business needs to see so much value in the feature, in order to justify our costs. This then feeds back to the defining success metrics phase. We need to always set up and plan for success. It's all or nothing.

Estimates form a small part of this activity. Effort involved in building this feature will also add to the cost, but there is no reason for us to get precise numbers of the exact number of hours we would spend on building this, and compare them with past feature building and so on. This aspect about estimates and staying lean about our development processes is discussed in the third part of this book.

The cost-impact matrix

The cost -impact matrix can help us visualize the trade-offs and advantages we get by investing in a product feature. This can help us prioritize and prune our product backlog.

Based on the cost and previously determined business value scores, we now have a clear view of our prioritization matrix. The features in quadrant one are the quick wins (low cost / high value). Anything in quadrant four should not be picked up. Risk backlog, which exists outside of the quadrant, should include functionality or tasks that haven't been picked up now, but are likely to have an impact later. Also, this gives a clear view to the business sponsors of the costs they will incur when we need to build this functionality in the future.

Summary

All the analysis involved in defining the Impact Driven Product experience and ensuring that all business functions are aligned toward meeting the same Key Business Outcomes, as well as a view of costs, comes together in the Cost Impact matrix. The Cost Impact matrix offers a visually compelling view of how a feature's value compares to the cost of building it. This can enable decision-making around which feature ideas to pursue for immediate benefits and which ones to invest in, for longer-term strategic benefit. It also helps in analyzing trade-offs and functional scope, and therefore in determining whether a feature idea can be trimmed down or whether it's worth investing in a feature idea even though the costs are higher. Once the cost-impact comparison is done, the feature ideas can make it to the product backlog.

Now, we have our backlog ready, so let's go and build our product in the next chapter!