Modern product development is witnessing a drastic shift. Disruptive ideas and ambiguous businesses conditions have changed the way that products are developed. Product development is no longer guided by existing processes or predefined frameworks. Delivering on time is a baseline metric, as is software quality. Today, businesses are competing to innovate. They are willing to invest in groundbreaking products with cutting-edge technology. Cost is no longer the constraint—execution is. Can product managers then continue to rely upon processes and practices aimed at traditional ways of product building? How do we ensure that software product builders look at the bigger picture and do not tie themselves to engineering practices and technology viability alone? Understanding the business and customer context is essential for creating valuable products.
This chapter addresses the following topics:
- Defining our business model and unique value proposition
- Deriving inputs for product development
- Understanding key business outcomes
- Defining our Impact Driven Product
Honeycombs are an engineering marvel. The hexagonal shape of honeycombs is optimized to reduce the amount of wax needed to construct the hive, while maximizing the storage capacity. However, building wonderfully crafted honeycombs isn't the raison d'être of the bees. The goal of their existence is to maximize their chances of survival, to keep their lineage alive. Every bee activity is centered around this.
The need to maximize chances of survival is true for nearly every living species, but that does not mean that the queen of the ants should ask her ant army to construct ant hills with wax in hexagonal tubes. It doesn't work that way. Every species has an integral DNA that defines what it eats, how it socializes, how it defends or attacks, how it adapts, and how it survives.
The engineering that went into the honeycomb contributes to a specific way of life that is suited to the bees. It is important to realize that the very first bees didn't initially build wax hexagonal tubes. They iterated over many generations and responded to feedback from nature (which is often harsh and can result in extinction). Bees have pivoted to this model and it seems to have worked rather well for them. Heck, they've even managed to find channel partners in humans!
In the product world, understanding outcomes and user goals is essential to building successful products. A product's success always relates to the end goals it meets. Engineering in isolation adds no business value. The same can be said about marketing or sales. Business functions acting in isolation, without the context of business outcomes or creating value to the customer, are not sustainable. The sooner we define end goals, the better for the business as a whole. After all, we don't want to end up building honeycombs for ants.
"Universal law is for lackeys. Context is for kings."– Captain Lorca, Star Trek: Discovery.
When the Agile manifesto was created in 2001, software practitioners were calling for a change in the way that software was delivered. The waterfall model of software development, which was predominant, required that software specifications and business requirements were frozen upfront. There was very little room for change. Change had to be avoided because changing anything midway would increase costs and timelines. Waterfall had evolved as a way to handle software development processes based on the limitations of the software technology of that time. Much of software development then was about automating manual processes or building bespoke technology solutions. Technology has since evolved a lot. It has become increasingly flexible and inexpensive to build technology solutions with direct consumer impact. The focus for software builders has expanded to include customer satisfaction and is no longer about just meeting budgets and timelines.
There are many frameworks (Scrum, XP, and so on.) that offer a methodology for software teams to focus on user experience and customer value. They foster team collaboration and enable teams to respond to change. The guiding principles behind these frameworks are noble, but failures always happen in how these principles are put into practice.
Without context, intent, and outcomes being defined, even well-meant advice can go waste. This is because we're humans and not honeybees. We are driven by purpose, we are lazy and we are imaginative. People can conjure up images of success (or failure) where there is none. They plan, speculate, and adapt. They try to optimize for imagined future situations. We know that a sense of purpose is crucial to rallying a group of diverse, independent, and creative people to come together and effect change (or even build great products). The problem is this is exactly where we seem to fail time and again.
We fail because we focus on the wrong stuff. We try to predictably measure productivity in a creative profession. We over-engineer solutions to nonexistent use cases. Software engineering is an interesting field of work. It's like an artist and a mathematician coming together to generate business value! Yet, we treat software engineering like automobile manufacturing. I know amazing software engineers who can churn out beautiful and working software, but their pace of delivery is not predictable. Every person has their own pace, and style of working, which is a problem for project managers. When we have strict timelines and budgets to meet, how do we commit if there is so much subjectivity? Software teams have spent a lot of time inventing processes to accurately predict engineering efforts. Estimations, planning activities, functional scoping, and progress reporting have gained a lot of visibility in this context. We focus too much on engineering practices.
Software product development is missing out on a great opportunity here. By carrying over software delivery frameworks of meeting timelines, budgets, and customer satisfaction, we are in a way restricting ourselves to looking at outputs instead of outcomes. It is time that we changed our perspective on this. Product management shouldn't be about measuring effort or productivity. Product management shouldn't be about measuring output. Instead we should focus on product outcomes. What value are we creating for the customer? What outcomes is the product helping the business to meet? How can we execute a plan to achieve this in the smartest way possible? So how do we measure these outcomes?
In the good old days of business process automation (until late 1990s), measuring success seemed much simpler. Software teams could say, "There is an existing way of doing things. Let's automate that, but stick to budgets, timelines and quality metrics." Goals were simple and measurable. Software design was never discussed. User experience was nonexistent. Business impact was purely profitability based and no behavior changes were hinted at. Even as we moved into the era of Agile, business folks would give us weird looks when we asked to speak to end users. A client once told me, rather dismissively, "We're building this (app) for accountants. They don't have an eye for color. I don't know why you're worried about user interface or design." He may have made total sense a decade ago.
Today, you'll easily hear a CEO say things like, "We need to create stickiness, and to ingrain in our users a desire to engage with our apps." Many a product manager will roll their eyes and think, "Whatever that means." Success for a product is no longer about meeting budgets or timelines. The narrative of software development has changed. Can product management afford to lag behind?
Understanding business goals and evaluating risks and costs have always been essential for driving trade-off decisions. Business goals today are multidimensional and so are risks. How we make trade-off decisions depends on what aspects of product success we want to consider. Today, a product manager has to handle many facets of goals and risks, before defining the right product to build and driving trade-off decisions. According to the management consulting firm, McKinsey & Company, "Product managers are the glue that bind the many functions that touch a product—engineering, design, customer success, sales, marketing, operations, finance, legal, and more. They not only own the decisions about what gets built but also influence every aspect of how it gets built and launched."
Traditional project planning isn't going to help anymore. Product managers are in the driver's seat. We have to steer the product to meet ambiguous business goals. When building disruptive products in ambiguous business conditions, there is no "existing way" to refer to. All we have is a bunch of glorious ideas. So, the first step to demystifying goals is to articulate intent.
Impact Driven Product development needs to consider four key pieces of input that influence and guide product success:
- Business outcomes that a product can deliver. Why is this product important for the business?
- Value that a product can create for a customer. What should we build in order to deliver the maximum value to users?
- Execution plan. When there are many ways to implement the same functionality, how do we decide upon the best way forward?
- Internal business constraints and external market influences.
A business as a whole has its own value creation goals outlined. A product may address some or all of a business' goals.
A business model is a starting point for identifying a product idea and drawing up a plan. The desired outcome of this plan is to identify the unique value proposition that our business intends to deliver to the users/customers. In order to arrive at this, we need to define who our users are, what problems we're trying to solve, what channels we can leverage, who our competition is, how we plan to make our revenues, and what costs we might incur.
For start-ups, or businesses in the early stages of development, Lean Canvas, or any other framework that can help to visualize the market, business ecosystem, unique value proposition, and target segments, is a great place to start. Even for a product manager joining a team midway through product development, understanding the vision, market and target groups, and so on is key. After all, context is king. If the business model hasn't yet been laid out, then I recommend that you do that first.
Lean Canvas is a fantastic tool for capturing the business model around a product. Product Vision Board is also another tool to help us to visualize the product vision. Defining the business model around the product is a great way to define the target customers, the problems we're trying to solve for them, and the unique value proposition that we can offer. This can form the basis of how we want to run our business. Not every aspect of our business needs to be productized. Also, not every user segment may value every product feature with equal merit.
The business model can help us to visualize these target segments and capture which segments we want to go after in the current phase of business. However, Lean Canvas stops at the business model level. When investing in technology, we need to be clear about the outcomes we seek and the trade-offs we need to make. Building a product requires that we understand the larger business context, but we iterate on a product strategy that helps us to deliver a solution that meets business outcomes and provides value to customers. Software technology is extremely flexible. We can build quick and dirty solutions, or we can build robust, long-lasting solutions. However, every product must be based on business and customer motivations, and not on technology preferences.
The following is the Lean Canvas model proposed by Ash Maurya:
The overall business plan may also vary depending on the stage of the business. Business context and constraints have a bearing on what is achievable. For instance, at early stages, a business may be interested in creating value for early adopters. Some businesses may not attach importance to revenue generation until there is sufficient traction. As a business scales, other goals may become important. Value creation becomes more comprehensive.
This relationship between business outcomes, a customer value proposition, and an execution plan can be represented as shown in the following diagram:
Throughout this book, we will use a sample business case to illustrate concepts. We will use an imaginary business called ArtGalore, which is an art gallery specializing in curating premium works of art. The company now wants to venture into creating a digital art viewing and purchasing experience for premium art buyers.
Let's look at the Lean Canvas model created for ArtGalore. The following is a sample representation:
In the preceding Lean Canvas model, the unique value proposition describes the concept of a digital art buying experience, the success metrics define the business goals, and the solution describes how the business intends to deliver the value proposition to its clientele. At the stage of problem/solution fit, the actual execution plan of how this digital experience will be created is not yet finalized. Even the value proposition, target segment and solution are yet to be validated. The Lean Canvas model represents the big hypothesis that the business is making about its growth in the next two years. The Lean Canvas model, in a way, also represents a slightly longer-term view for the business. Along the way, as the business discovers more about the customer's perception of value and actual growth indicators, the canvas could change and ArtGalore could pivot to a different business model if the hypotheses are proven wrong.
From a product development perspective, we need to identify the three aspects of product success discussed earlier in this chapter.
What does the business hope to achieve by investing in a digital art gallery? The success metrics shown in the Lean Canvas model are a broad indicator of long-term goals. Building a brand and doubling revenue are long-term goals. In order to work toward those goals, the business needs to make some product investments in the short term.
The unique value proposition, and the solution concept, coupled with the customer segments, as described in the Lean Canvas model addresses this. It is natural for us to jump into ideas about product features, but before we even arrive at features, we need to think about user personas in our customer segment, and define how the solution will help to deliver the unique value proposition to them. Eventually, the features get refined into product functionality.
There can be many ways to deliver the value proposition to the customer and to meet business outcomes. The execution plan for delivering the value proposition and business outcomes can depend on the ease of execution, cost of execution and, potential to create a positive impact on business outcomes. While the preferred solution for ArtGalore is a digital art gallery, not all aspects may need to be built in upfront. The execution plan must factor in the strengths of all the business functions that exist in ArtGalore. The focus must not be just about how technology can solve all customer problems/meet business outcomes. The focus must be about how to work seamlessly with business functions and ensure that the end-to-end product experience is satisfying.
Business constraints includes factors such as the time available to go to market and the potential to raise investments. Governing policies, regulations and compliances (if any), technology potential, capabilities, skills available, and so on can also influence business goals and the product experience. These factors will determine the key goals to focus on, the product features to offer, and the best way to implement them. In addition to constraints, the intrinsic business intent is important. What are our uncompromising principles? What do we value more? What values drive our decisions? What is our appetite for risk? These factors will decide how we deliver value.
A product can impact the business or the organization that is creating the product. It can also impact the customers who will adopt the product. An Impact Driven Product therefore is one that finds the best way to deliver value to customers and meet business outcomes under internal and external constraints.
Based on the unique value proposition and the business context and business outcomes prioritized for a specific time-bound milestone, the following is a sample illustration of the inputs for product development for ArtGalore:
This is quite a simplified representation of the product development inputs at a given point in time. The diagram illustrates how business constraints may influence what the Impact Driven Product may deliver to the user.
The preceding illustration indicates that the most important outcome for ArtGalore is to become the first choice for art among its target segment. The most important aspect of the value proposition is offering tastefully curated art collections for existing buyers who don't have this information today. The most effective plan to execute this solution is to offer digital newsletters, provide an online sign-up for upcoming art shows, follow up on the sign-up with invites, and announce the website. This has been identified based on the business constraints of being ready for the upcoming art show, not compromising on the existing buyer experience, and so on. The other solutions, value propositions, and execution plans are also great, but given the business constraints, the Impact Driven Product is where we want to steer all our resources to.
Minimum Viable Product (mvp) is a concept that is quite prevalent in the software development scene. There are different interpretations of the concept of an mvp and Chapter 6, Managing the Scope of an Impact Driven Product dives into the interpretations of minimum viability.
At a basic level, an MVP intends to test the riskiest proposition of a business idea or a technology, without running out of resources. This is very helpful when testing an unproven technology or when building under tight business constraints. However, an mvp falls short in terms of delivering an end-to-end product experience to the consumers. The problem with how we define an mvp is that we tend to view technology viability as a value driver operating in isolation. An mvp is great in the problem/solution fit stage, but in the product/market fit stage, there are many other aspects to consider. When launching a new product, there are umpteen activities that need to be orchestrated to ensure success. Marketing, sales, support, and other operations need to come together to ensure a product's success. Testing viability of a product in isolation isn't going to ensure success for the business.
In my start-up, we had built up a platform for businesses to design and build mobile apps for client engagement. We had started out in the events and conferences domain, where app creation lead times were pretty low, audience engagement was critical, and last-minute changes to a schedule were quite common. Our platform was geared toward addressing those needs, but we soon started seeing interest from other business verticals who saw the potential that our platform had in driving customer engagement. One such business asked us to enhance our platform with the bespoke functionality.
We were in early stages in our start-up and naturally we got quite excited about the opportunity. The possibility of opening up our platform to another domain was quite lucrative. While we didn't see much value in creating a custom solution for a single client, we realized that we could enhance our platform to cater to the entire business vertical. This would also give us a great opportunity to launch our product into the B2C space. So, we carved out an mvp for this, and our engineers got busy with re-architecting the platform to make it flexible across business verticals. After spending more than a month on this, we were more or less ready with the revamped software.
Our revamped product was technologically viable. Yet, was the revamped software impact-driven? No. Why? We hadn't looked at the end-to-end value of the product. Our business model was different. Our target audience was new. A B2C market needed a very different approach. We hadn't planned for marketing, content creation, and promotions. We realized that we had neither the right skills nor the investment to drive this product to success. We hadn't really defined to ourselves what the new product would deliver. After all, we had just one customer who was interested. We hadn't looked at an end-to-end product experience.
Our rookie mistake cost us a month. We ended up shelving the product and didn't even close our sale with the one customer who showed interest. From the software perspective, we had it all covered, but we had not given any thought to the whole product experience or to the outcomes it could generate for our business. We are much better off today having learned and recovered from that mistake quickly, instead of having gone down that path, purely riding on the viability of our platform. We had looked at one customer's request and created a hypothesis about the problems our new platform could solve and the needs it could satisfy for that customer segment. We were confident that the product would address their needs and it could have. However, we hadn't given any thought about what it meant for our business, the stage we were in, our internal capabilities, and our weaknesses.
I know many developers who take great pride in how their software is built. The prevalent thinking is that if you build your software right, it will take care of itself. I've seen very smart engineers express deep disregard for supporting functions. They look down upon marketing, promotions, and sales saying, "People will adopt our product because my software is great." However, success isn't in and of the technology process itself. This is a core difference between task-oriented thinking and goal-oriented thinking.
Businesses make the same rookie mistake when going after early adopters. We want to get our business model validated quickly and cost-effectively. So, we build an mvp with a lot of loose ends on experience, revenue generation, and operations. Then we identify a safe pilot group from our family, friends, and well-wishers, or we offer our product for free to anyone who agrees to try it. Early adopters need to be potential (paying) customers who will risk adopting a product with partial experience, because it solves their most pressing needs. They will risk an incomplete product as long as their needs are met.
However, if we don't choose our early adopters right, we may end up validating the wrong product, which then tanks in the product/market fit stage. For instance, when we offer our product for free, how do we know if the customers are adopting our product because they see real value in it or because it's free? We feel happy with the validation we get for our software, but as we move out of that pilot group, we realize that our product doesn't have many takers. This is because we may have chosen our pilot group safely and they told us what we wanted to hear. The real test for a product is in testing out the riskiest propositions. The riskiest propositions are not just about how our product can create customer value, or about the technology viability in delivering that value, but also about the business capabilities.
If we're building a business, then we need to have a plan for how to make it grow, create impact, and be sustainable. Good software is never a replacement for a sound business model and vice versa. A product entering the product/market fit stage should have validated the viability of the riskiest business/technology propositions. Product/market fit should focus on offering an end-to-end product experience that offers the most value to the consumer and meets the business outcomes. The learnings that we have had right from product ideation and beyond have to continuously feed into the product experience. We need to think about a holistic product experience, rather than the feature set or technology.
If we don't realize that a product experience is a result of many technical and operational parts coming together, to meet a larger goal, then we're just missing the point. After all, we're not just laying the bricks; we're building a cathedral, a hospital, or a school.
An Impact Driven Product is the one that combines the technical and operational aspects of a product to create a holistic product experience. It comprises the entire product experience, across all touchpoints, for the customer. The Impact Driven Product ensures that we carve out a product, knowing full well what business outcomes to target. We factor in the support and co-ordination we need from business functions. We identify the smartest way to deliver value to customers under given business constraints. Knowing Key Business Outcomes is also a critical input to product development, and this should not be a one-time activity.
Case study
Throughout this book, we will use a sample business case to illustrate concepts. We will use an imaginary business called ArtGalore, which is an art gallery specializing in curating premium works of art. The company now wants to venture into creating a digital art viewing and purchasing experience for premium art buyers.
Let's look at the Lean Canvas model created for ArtGalore. The following is a sample representation:
In the preceding Lean Canvas model, the unique value proposition describes the concept of a digital art buying experience, the success metrics define the business goals, and the solution describes how the business intends to deliver the value proposition to its clientele. At the stage of problem/solution fit, the actual execution plan of how this digital experience will be created is not yet finalized. Even the value proposition, target segment and solution are yet to be validated. The Lean Canvas model represents the big hypothesis that the business is making about its growth in the next two years. The Lean Canvas model, in a way, also represents a slightly longer-term view for the business. Along the way, as the business discovers more about the customer's perception of value and actual growth indicators, the canvas could change and ArtGalore could pivot to a different business model if the hypotheses are proven wrong.
From a product development perspective, we need to identify the three aspects of product success discussed earlier in this chapter.
What does the business hope to achieve by investing in a digital art gallery? The success metrics shown in the Lean Canvas model are a broad indicator of long-term goals. Building a brand and doubling revenue are long-term goals. In order to work toward those goals, the business needs to make some product investments in the short term.
The unique value proposition, and the solution concept, coupled with the customer segments, as described in the Lean Canvas model addresses this. It is natural for us to jump into ideas about product features, but before we even arrive at features, we need to think about user personas in our customer segment, and define how the solution will help to deliver the unique value proposition to them. Eventually, the features get refined into product functionality.
There can be many ways to deliver the value proposition to the customer and to meet business outcomes. The execution plan for delivering the value proposition and business outcomes can depend on the ease of execution, cost of execution and, potential to create a positive impact on business outcomes. While the preferred solution for ArtGalore is a digital art gallery, not all aspects may need to be built in upfront. The execution plan must factor in the strengths of all the business functions that exist in ArtGalore. The focus must not be just about how technology can solve all customer problems/meet business outcomes. The focus must be about how to work seamlessly with business functions and ensure that the end-to-end product experience is satisfying.
Business constraints includes factors such as the time available to go to market and the potential to raise investments. Governing policies, regulations and compliances (if any), technology potential, capabilities, skills available, and so on can also influence business goals and the product experience. These factors will determine the key goals to focus on, the product features to offer, and the best way to implement them. In addition to constraints, the intrinsic business intent is important. What are our uncompromising principles? What do we value more? What values drive our decisions? What is our appetite for risk? These factors will decide how we deliver value.
A product can impact the business or the organization that is creating the product. It can also impact the customers who will adopt the product. An Impact Driven Product therefore is one that finds the best way to deliver value to customers and meet business outcomes under internal and external constraints.
Based on the unique value proposition and the business context and business outcomes prioritized for a specific time-bound milestone, the following is a sample illustration of the inputs for product development for ArtGalore:
This is quite a simplified representation of the product development inputs at a given point in time. The diagram illustrates how business constraints may influence what the Impact Driven Product may deliver to the user.
The preceding illustration indicates that the most important outcome for ArtGalore is to become the first choice for art among its target segment. The most important aspect of the value proposition is offering tastefully curated art collections for existing buyers who don't have this information today. The most effective plan to execute this solution is to offer digital newsletters, provide an online sign-up for upcoming art shows, follow up on the sign-up with invites, and announce the website. This has been identified based on the business constraints of being ready for the upcoming art show, not compromising on the existing buyer experience, and so on. The other solutions, value propositions, and execution plans are also great, but given the business constraints, the Impact Driven Product is where we want to steer all our resources to.
Minimum Viable Product (mvp) is a concept that is quite prevalent in the software development scene. There are different interpretations of the concept of an mvp and Chapter 6, Managing the Scope of an Impact Driven Product dives into the interpretations of minimum viability.
At a basic level, an MVP intends to test the riskiest proposition of a business idea or a technology, without running out of resources. This is very helpful when testing an unproven technology or when building under tight business constraints. However, an mvp falls short in terms of delivering an end-to-end product experience to the consumers. The problem with how we define an mvp is that we tend to view technology viability as a value driver operating in isolation. An mvp is great in the problem/solution fit stage, but in the product/market fit stage, there are many other aspects to consider. When launching a new product, there are umpteen activities that need to be orchestrated to ensure success. Marketing, sales, support, and other operations need to come together to ensure a product's success. Testing viability of a product in isolation isn't going to ensure success for the business.
In my start-up, we had built up a platform for businesses to design and build mobile apps for client engagement. We had started out in the events and conferences domain, where app creation lead times were pretty low, audience engagement was critical, and last-minute changes to a schedule were quite common. Our platform was geared toward addressing those needs, but we soon started seeing interest from other business verticals who saw the potential that our platform had in driving customer engagement. One such business asked us to enhance our platform with the bespoke functionality.
We were in early stages in our start-up and naturally we got quite excited about the opportunity. The possibility of opening up our platform to another domain was quite lucrative. While we didn't see much value in creating a custom solution for a single client, we realized that we could enhance our platform to cater to the entire business vertical. This would also give us a great opportunity to launch our product into the B2C space. So, we carved out an mvp for this, and our engineers got busy with re-architecting the platform to make it flexible across business verticals. After spending more than a month on this, we were more or less ready with the revamped software.
Our revamped product was technologically viable. Yet, was the revamped software impact-driven? No. Why? We hadn't looked at the end-to-end value of the product. Our business model was different. Our target audience was new. A B2C market needed a very different approach. We hadn't planned for marketing, content creation, and promotions. We realized that we had neither the right skills nor the investment to drive this product to success. We hadn't really defined to ourselves what the new product would deliver. After all, we had just one customer who was interested. We hadn't looked at an end-to-end product experience.
Our rookie mistake cost us a month. We ended up shelving the product and didn't even close our sale with the one customer who showed interest. From the software perspective, we had it all covered, but we had not given any thought to the whole product experience or to the outcomes it could generate for our business. We are much better off today having learned and recovered from that mistake quickly, instead of having gone down that path, purely riding on the viability of our platform. We had looked at one customer's request and created a hypothesis about the problems our new platform could solve and the needs it could satisfy for that customer segment. We were confident that the product would address their needs and it could have. However, we hadn't given any thought about what it meant for our business, the stage we were in, our internal capabilities, and our weaknesses.
I know many developers who take great pride in how their software is built. The prevalent thinking is that if you build your software right, it will take care of itself. I've seen very smart engineers express deep disregard for supporting functions. They look down upon marketing, promotions, and sales saying, "People will adopt our product because my software is great." However, success isn't in and of the technology process itself. This is a core difference between task-oriented thinking and goal-oriented thinking.
Businesses make the same rookie mistake when going after early adopters. We want to get our business model validated quickly and cost-effectively. So, we build an mvp with a lot of loose ends on experience, revenue generation, and operations. Then we identify a safe pilot group from our family, friends, and well-wishers, or we offer our product for free to anyone who agrees to try it. Early adopters need to be potential (paying) customers who will risk adopting a product with partial experience, because it solves their most pressing needs. They will risk an incomplete product as long as their needs are met.
However, if we don't choose our early adopters right, we may end up validating the wrong product, which then tanks in the product/market fit stage. For instance, when we offer our product for free, how do we know if the customers are adopting our product because they see real value in it or because it's free? We feel happy with the validation we get for our software, but as we move out of that pilot group, we realize that our product doesn't have many takers. This is because we may have chosen our pilot group safely and they told us what we wanted to hear. The real test for a product is in testing out the riskiest propositions. The riskiest propositions are not just about how our product can create customer value, or about the technology viability in delivering that value, but also about the business capabilities.
If we're building a business, then we need to have a plan for how to make it grow, create impact, and be sustainable. Good software is never a replacement for a sound business model and vice versa. A product entering the product/market fit stage should have validated the viability of the riskiest business/technology propositions. Product/market fit should focus on offering an end-to-end product experience that offers the most value to the consumer and meets the business outcomes. The learnings that we have had right from product ideation and beyond have to continuously feed into the product experience. We need to think about a holistic product experience, rather than the feature set or technology.
If we don't realize that a product experience is a result of many technical and operational parts coming together, to meet a larger goal, then we're just missing the point. After all, we're not just laying the bricks; we're building a cathedral, a hospital, or a school.
An Impact Driven Product is the one that combines the technical and operational aspects of a product to create a holistic product experience. It comprises the entire product experience, across all touchpoints, for the customer. The Impact Driven Product ensures that we carve out a product, knowing full well what business outcomes to target. We factor in the support and co-ordination we need from business functions. We identify the smartest way to deliver value to customers under given business constraints. Knowing Key Business Outcomes is also a critical input to product development, and this should not be a one-time activity.
Defining business outcomes that the product can deliver (why?)
What does the business hope to achieve by investing in a digital art gallery? The success metrics shown in the Lean Canvas model are a broad indicator of long-term goals. Building a brand and doubling revenue are long-term goals. In order to work toward those goals, the business needs to make some product investments in the short term.
The unique value proposition, and the solution concept, coupled with the customer segments, as described in the Lean Canvas model addresses this. It is natural for us to jump into ideas about product features, but before we even arrive at features, we need to think about user personas in our customer segment, and define how the solution will help to deliver the unique value proposition to them. Eventually, the features get refined into product functionality.
There can be many ways to deliver the value proposition to the customer and to meet business outcomes. The execution plan for delivering the value proposition and business outcomes can depend on the ease of execution, cost of execution and, potential to create a positive impact on business outcomes. While the preferred solution for ArtGalore is a digital art gallery, not all aspects may need to be built in upfront. The execution plan must factor in the strengths of all the business functions that exist in ArtGalore. The focus must not be just about how technology can solve all customer problems/meet business outcomes. The focus must be about how to work seamlessly with business functions and ensure that the end-to-end product experience is satisfying.
Business constraints includes factors such as the time available to go to market and the potential to raise investments. Governing policies, regulations and compliances (if any), technology potential, capabilities, skills available, and so on can also influence business goals and the product experience. These factors will determine the key goals to focus on, the product features to offer, and the best way to implement them. In addition to constraints, the intrinsic business intent is important. What are our uncompromising principles? What do we value more? What values drive our decisions? What is our appetite for risk? These factors will decide how we deliver value.
A product can impact the business or the organization that is creating the product. It can also impact the customers who will adopt the product. An Impact Driven Product therefore is one that finds the best way to deliver value to customers and meet business outcomes under internal and external constraints.
Based on the unique value proposition and the business context and business outcomes prioritized for a specific time-bound milestone, the following is a sample illustration of the inputs for product development for ArtGalore:
This is quite a simplified representation of the product development inputs at a given point in time. The diagram illustrates how business constraints may influence what the Impact Driven Product may deliver to the user.
The preceding illustration indicates that the most important outcome for ArtGalore is to become the first choice for art among its target segment. The most important aspect of the value proposition is offering tastefully curated art collections for existing buyers who don't have this information today. The most effective plan to execute this solution is to offer digital newsletters, provide an online sign-up for upcoming art shows, follow up on the sign-up with invites, and announce the website. This has been identified based on the business constraints of being ready for the upcoming art show, not compromising on the existing buyer experience, and so on. The other solutions, value propositions, and execution plans are also great, but given the business constraints, the Impact Driven Product is where we want to steer all our resources to.
Minimum Viable Product (mvp) is a concept that is quite prevalent in the software development scene. There are different interpretations of the concept of an mvp and Chapter 6, Managing the Scope of an Impact Driven Product dives into the interpretations of minimum viability.
At a basic level, an MVP intends to test the riskiest proposition of a business idea or a technology, without running out of resources. This is very helpful when testing an unproven technology or when building under tight business constraints. However, an mvp falls short in terms of delivering an end-to-end product experience to the consumers. The problem with how we define an mvp is that we tend to view technology viability as a value driver operating in isolation. An mvp is great in the problem/solution fit stage, but in the product/market fit stage, there are many other aspects to consider. When launching a new product, there are umpteen activities that need to be orchestrated to ensure success. Marketing, sales, support, and other operations need to come together to ensure a product's success. Testing viability of a product in isolation isn't going to ensure success for the business.
In my start-up, we had built up a platform for businesses to design and build mobile apps for client engagement. We had started out in the events and conferences domain, where app creation lead times were pretty low, audience engagement was critical, and last-minute changes to a schedule were quite common. Our platform was geared toward addressing those needs, but we soon started seeing interest from other business verticals who saw the potential that our platform had in driving customer engagement. One such business asked us to enhance our platform with the bespoke functionality.
We were in early stages in our start-up and naturally we got quite excited about the opportunity. The possibility of opening up our platform to another domain was quite lucrative. While we didn't see much value in creating a custom solution for a single client, we realized that we could enhance our platform to cater to the entire business vertical. This would also give us a great opportunity to launch our product into the B2C space. So, we carved out an mvp for this, and our engineers got busy with re-architecting the platform to make it flexible across business verticals. After spending more than a month on this, we were more or less ready with the revamped software.
Our revamped product was technologically viable. Yet, was the revamped software impact-driven? No. Why? We hadn't looked at the end-to-end value of the product. Our business model was different. Our target audience was new. A B2C market needed a very different approach. We hadn't planned for marketing, content creation, and promotions. We realized that we had neither the right skills nor the investment to drive this product to success. We hadn't really defined to ourselves what the new product would deliver. After all, we had just one customer who was interested. We hadn't looked at an end-to-end product experience.
Our rookie mistake cost us a month. We ended up shelving the product and didn't even close our sale with the one customer who showed interest. From the software perspective, we had it all covered, but we had not given any thought to the whole product experience or to the outcomes it could generate for our business. We are much better off today having learned and recovered from that mistake quickly, instead of having gone down that path, purely riding on the viability of our platform. We had looked at one customer's request and created a hypothesis about the problems our new platform could solve and the needs it could satisfy for that customer segment. We were confident that the product would address their needs and it could have. However, we hadn't given any thought about what it meant for our business, the stage we were in, our internal capabilities, and our weaknesses.
I know many developers who take great pride in how their software is built. The prevalent thinking is that if you build your software right, it will take care of itself. I've seen very smart engineers express deep disregard for supporting functions. They look down upon marketing, promotions, and sales saying, "People will adopt our product because my software is great." However, success isn't in and of the technology process itself. This is a core difference between task-oriented thinking and goal-oriented thinking.
Businesses make the same rookie mistake when going after early adopters. We want to get our business model validated quickly and cost-effectively. So, we build an mvp with a lot of loose ends on experience, revenue generation, and operations. Then we identify a safe pilot group from our family, friends, and well-wishers, or we offer our product for free to anyone who agrees to try it. Early adopters need to be potential (paying) customers who will risk adopting a product with partial experience, because it solves their most pressing needs. They will risk an incomplete product as long as their needs are met.
However, if we don't choose our early adopters right, we may end up validating the wrong product, which then tanks in the product/market fit stage. For instance, when we offer our product for free, how do we know if the customers are adopting our product because they see real value in it or because it's free? We feel happy with the validation we get for our software, but as we move out of that pilot group, we realize that our product doesn't have many takers. This is because we may have chosen our pilot group safely and they told us what we wanted to hear. The real test for a product is in testing out the riskiest propositions. The riskiest propositions are not just about how our product can create customer value, or about the technology viability in delivering that value, but also about the business capabilities.
If we're building a business, then we need to have a plan for how to make it grow, create impact, and be sustainable. Good software is never a replacement for a sound business model and vice versa. A product entering the product/market fit stage should have validated the viability of the riskiest business/technology propositions. Product/market fit should focus on offering an end-to-end product experience that offers the most value to the consumer and meets the business outcomes. The learnings that we have had right from product ideation and beyond have to continuously feed into the product experience. We need to think about a holistic product experience, rather than the feature set or technology.
If we don't realize that a product experience is a result of many technical and operational parts coming together, to meet a larger goal, then we're just missing the point. After all, we're not just laying the bricks; we're building a cathedral, a hospital, or a school.
An Impact Driven Product is the one that combines the technical and operational aspects of a product to create a holistic product experience. It comprises the entire product experience, across all touchpoints, for the customer. The Impact Driven Product ensures that we carve out a product, knowing full well what business outcomes to target. We factor in the support and co-ordination we need from business functions. We identify the smartest way to deliver value to customers under given business constraints. Knowing Key Business Outcomes is also a critical input to product development, and this should not be a one-time activity.
Defining the value proposition that the product will create for the customer (what?)
The unique value proposition, and the solution concept, coupled with the customer segments, as described in the Lean Canvas model addresses this. It is natural for us to jump into ideas about product features, but before we even arrive at features, we need to think about user personas in our customer segment, and define how the solution will help to deliver the unique value proposition to them. Eventually, the features get refined into product functionality.
There can be many ways to deliver the value proposition to the customer and to meet business outcomes. The execution plan for delivering the value proposition and business outcomes can depend on the ease of execution, cost of execution and, potential to create a positive impact on business outcomes. While the preferred solution for ArtGalore is a digital art gallery, not all aspects may need to be built in upfront. The execution plan must factor in the strengths of all the business functions that exist in ArtGalore. The focus must not be just about how technology can solve all customer problems/meet business outcomes. The focus must be about how to work seamlessly with business functions and ensure that the end-to-end product experience is satisfying.
Business constraints includes factors such as the time available to go to market and the potential to raise investments. Governing policies, regulations and compliances (if any), technology potential, capabilities, skills available, and so on can also influence business goals and the product experience. These factors will determine the key goals to focus on, the product features to offer, and the best way to implement them. In addition to constraints, the intrinsic business intent is important. What are our uncompromising principles? What do we value more? What values drive our decisions? What is our appetite for risk? These factors will decide how we deliver value.
A product can impact the business or the organization that is creating the product. It can also impact the customers who will adopt the product. An Impact Driven Product therefore is one that finds the best way to deliver value to customers and meet business outcomes under internal and external constraints.
Based on the unique value proposition and the business context and business outcomes prioritized for a specific time-bound milestone, the following is a sample illustration of the inputs for product development for ArtGalore:
This is quite a simplified representation of the product development inputs at a given point in time. The diagram illustrates how business constraints may influence what the Impact Driven Product may deliver to the user.
The preceding illustration indicates that the most important outcome for ArtGalore is to become the first choice for art among its target segment. The most important aspect of the value proposition is offering tastefully curated art collections for existing buyers who don't have this information today. The most effective plan to execute this solution is to offer digital newsletters, provide an online sign-up for upcoming art shows, follow up on the sign-up with invites, and announce the website. This has been identified based on the business constraints of being ready for the upcoming art show, not compromising on the existing buyer experience, and so on. The other solutions, value propositions, and execution plans are also great, but given the business constraints, the Impact Driven Product is where we want to steer all our resources to.
Minimum Viable Product (mvp) is a concept that is quite prevalent in the software development scene. There are different interpretations of the concept of an mvp and Chapter 6, Managing the Scope of an Impact Driven Product dives into the interpretations of minimum viability.
At a basic level, an MVP intends to test the riskiest proposition of a business idea or a technology, without running out of resources. This is very helpful when testing an unproven technology or when building under tight business constraints. However, an mvp falls short in terms of delivering an end-to-end product experience to the consumers. The problem with how we define an mvp is that we tend to view technology viability as a value driver operating in isolation. An mvp is great in the problem/solution fit stage, but in the product/market fit stage, there are many other aspects to consider. When launching a new product, there are umpteen activities that need to be orchestrated to ensure success. Marketing, sales, support, and other operations need to come together to ensure a product's success. Testing viability of a product in isolation isn't going to ensure success for the business.
In my start-up, we had built up a platform for businesses to design and build mobile apps for client engagement. We had started out in the events and conferences domain, where app creation lead times were pretty low, audience engagement was critical, and last-minute changes to a schedule were quite common. Our platform was geared toward addressing those needs, but we soon started seeing interest from other business verticals who saw the potential that our platform had in driving customer engagement. One such business asked us to enhance our platform with the bespoke functionality.
We were in early stages in our start-up and naturally we got quite excited about the opportunity. The possibility of opening up our platform to another domain was quite lucrative. While we didn't see much value in creating a custom solution for a single client, we realized that we could enhance our platform to cater to the entire business vertical. This would also give us a great opportunity to launch our product into the B2C space. So, we carved out an mvp for this, and our engineers got busy with re-architecting the platform to make it flexible across business verticals. After spending more than a month on this, we were more or less ready with the revamped software.
Our revamped product was technologically viable. Yet, was the revamped software impact-driven? No. Why? We hadn't looked at the end-to-end value of the product. Our business model was different. Our target audience was new. A B2C market needed a very different approach. We hadn't planned for marketing, content creation, and promotions. We realized that we had neither the right skills nor the investment to drive this product to success. We hadn't really defined to ourselves what the new product would deliver. After all, we had just one customer who was interested. We hadn't looked at an end-to-end product experience.
Our rookie mistake cost us a month. We ended up shelving the product and didn't even close our sale with the one customer who showed interest. From the software perspective, we had it all covered, but we had not given any thought to the whole product experience or to the outcomes it could generate for our business. We are much better off today having learned and recovered from that mistake quickly, instead of having gone down that path, purely riding on the viability of our platform. We had looked at one customer's request and created a hypothesis about the problems our new platform could solve and the needs it could satisfy for that customer segment. We were confident that the product would address their needs and it could have. However, we hadn't given any thought about what it meant for our business, the stage we were in, our internal capabilities, and our weaknesses.
I know many developers who take great pride in how their software is built. The prevalent thinking is that if you build your software right, it will take care of itself. I've seen very smart engineers express deep disregard for supporting functions. They look down upon marketing, promotions, and sales saying, "People will adopt our product because my software is great." However, success isn't in and of the technology process itself. This is a core difference between task-oriented thinking and goal-oriented thinking.
Businesses make the same rookie mistake when going after early adopters. We want to get our business model validated quickly and cost-effectively. So, we build an mvp with a lot of loose ends on experience, revenue generation, and operations. Then we identify a safe pilot group from our family, friends, and well-wishers, or we offer our product for free to anyone who agrees to try it. Early adopters need to be potential (paying) customers who will risk adopting a product with partial experience, because it solves their most pressing needs. They will risk an incomplete product as long as their needs are met.
However, if we don't choose our early adopters right, we may end up validating the wrong product, which then tanks in the product/market fit stage. For instance, when we offer our product for free, how do we know if the customers are adopting our product because they see real value in it or because it's free? We feel happy with the validation we get for our software, but as we move out of that pilot group, we realize that our product doesn't have many takers. This is because we may have chosen our pilot group safely and they told us what we wanted to hear. The real test for a product is in testing out the riskiest propositions. The riskiest propositions are not just about how our product can create customer value, or about the technology viability in delivering that value, but also about the business capabilities.
If we're building a business, then we need to have a plan for how to make it grow, create impact, and be sustainable. Good software is never a replacement for a sound business model and vice versa. A product entering the product/market fit stage should have validated the viability of the riskiest business/technology propositions. Product/market fit should focus on offering an end-to-end product experience that offers the most value to the consumer and meets the business outcomes. The learnings that we have had right from product ideation and beyond have to continuously feed into the product experience. We need to think about a holistic product experience, rather than the feature set or technology.
If we don't realize that a product experience is a result of many technical and operational parts coming together, to meet a larger goal, then we're just missing the point. After all, we're not just laying the bricks; we're building a cathedral, a hospital, or a school.
An Impact Driven Product is the one that combines the technical and operational aspects of a product to create a holistic product experience. It comprises the entire product experience, across all touchpoints, for the customer. The Impact Driven Product ensures that we carve out a product, knowing full well what business outcomes to target. We factor in the support and co-ordination we need from business functions. We identify the smartest way to deliver value to customers under given business constraints. Knowing Key Business Outcomes is also a critical input to product development, and this should not be a one-time activity.
Defining the execution plan (how?)
There can be many ways to deliver the value proposition to the customer and to meet business outcomes. The execution plan for delivering the value proposition and business outcomes can depend on the ease of execution, cost of execution and, potential to create a positive impact on business outcomes. While the preferred solution for ArtGalore is a digital art gallery, not all aspects may need to be built in upfront. The execution plan must factor in the strengths of all the business functions that exist in ArtGalore. The focus must not be just about how technology can solve all customer problems/meet business outcomes. The focus must be about how to work seamlessly with business functions and ensure that the end-to-end product experience is satisfying.
Business constraints includes factors such as the time available to go to market and the potential to raise investments. Governing policies, regulations and compliances (if any), technology potential, capabilities, skills available, and so on can also influence business goals and the product experience. These factors will determine the key goals to focus on, the product features to offer, and the best way to implement them. In addition to constraints, the intrinsic business intent is important. What are our uncompromising principles? What do we value more? What values drive our decisions? What is our appetite for risk? These factors will decide how we deliver value.
A product can impact the business or the organization that is creating the product. It can also impact the customers who will adopt the product. An Impact Driven Product therefore is one that finds the best way to deliver value to customers and meet business outcomes under internal and external constraints.
Based on the unique value proposition and the business context and business outcomes prioritized for a specific time-bound milestone, the following is a sample illustration of the inputs for product development for ArtGalore:
This is quite a simplified representation of the product development inputs at a given point in time. The diagram illustrates how business constraints may influence what the Impact Driven Product may deliver to the user.
The preceding illustration indicates that the most important outcome for ArtGalore is to become the first choice for art among its target segment. The most important aspect of the value proposition is offering tastefully curated art collections for existing buyers who don't have this information today. The most effective plan to execute this solution is to offer digital newsletters, provide an online sign-up for upcoming art shows, follow up on the sign-up with invites, and announce the website. This has been identified based on the business constraints of being ready for the upcoming art show, not compromising on the existing buyer experience, and so on. The other solutions, value propositions, and execution plans are also great, but given the business constraints, the Impact Driven Product is where we want to steer all our resources to.
Minimum Viable Product (mvp) is a concept that is quite prevalent in the software development scene. There are different interpretations of the concept of an mvp and Chapter 6, Managing the Scope of an Impact Driven Product dives into the interpretations of minimum viability.
At a basic level, an MVP intends to test the riskiest proposition of a business idea or a technology, without running out of resources. This is very helpful when testing an unproven technology or when building under tight business constraints. However, an mvp falls short in terms of delivering an end-to-end product experience to the consumers. The problem with how we define an mvp is that we tend to view technology viability as a value driver operating in isolation. An mvp is great in the problem/solution fit stage, but in the product/market fit stage, there are many other aspects to consider. When launching a new product, there are umpteen activities that need to be orchestrated to ensure success. Marketing, sales, support, and other operations need to come together to ensure a product's success. Testing viability of a product in isolation isn't going to ensure success for the business.
In my start-up, we had built up a platform for businesses to design and build mobile apps for client engagement. We had started out in the events and conferences domain, where app creation lead times were pretty low, audience engagement was critical, and last-minute changes to a schedule were quite common. Our platform was geared toward addressing those needs, but we soon started seeing interest from other business verticals who saw the potential that our platform had in driving customer engagement. One such business asked us to enhance our platform with the bespoke functionality.
We were in early stages in our start-up and naturally we got quite excited about the opportunity. The possibility of opening up our platform to another domain was quite lucrative. While we didn't see much value in creating a custom solution for a single client, we realized that we could enhance our platform to cater to the entire business vertical. This would also give us a great opportunity to launch our product into the B2C space. So, we carved out an mvp for this, and our engineers got busy with re-architecting the platform to make it flexible across business verticals. After spending more than a month on this, we were more or less ready with the revamped software.
Our revamped product was technologically viable. Yet, was the revamped software impact-driven? No. Why? We hadn't looked at the end-to-end value of the product. Our business model was different. Our target audience was new. A B2C market needed a very different approach. We hadn't planned for marketing, content creation, and promotions. We realized that we had neither the right skills nor the investment to drive this product to success. We hadn't really defined to ourselves what the new product would deliver. After all, we had just one customer who was interested. We hadn't looked at an end-to-end product experience.
Our rookie mistake cost us a month. We ended up shelving the product and didn't even close our sale with the one customer who showed interest. From the software perspective, we had it all covered, but we had not given any thought to the whole product experience or to the outcomes it could generate for our business. We are much better off today having learned and recovered from that mistake quickly, instead of having gone down that path, purely riding on the viability of our platform. We had looked at one customer's request and created a hypothesis about the problems our new platform could solve and the needs it could satisfy for that customer segment. We were confident that the product would address their needs and it could have. However, we hadn't given any thought about what it meant for our business, the stage we were in, our internal capabilities, and our weaknesses.
I know many developers who take great pride in how their software is built. The prevalent thinking is that if you build your software right, it will take care of itself. I've seen very smart engineers express deep disregard for supporting functions. They look down upon marketing, promotions, and sales saying, "People will adopt our product because my software is great." However, success isn't in and of the technology process itself. This is a core difference between task-oriented thinking and goal-oriented thinking.
Businesses make the same rookie mistake when going after early adopters. We want to get our business model validated quickly and cost-effectively. So, we build an mvp with a lot of loose ends on experience, revenue generation, and operations. Then we identify a safe pilot group from our family, friends, and well-wishers, or we offer our product for free to anyone who agrees to try it. Early adopters need to be potential (paying) customers who will risk adopting a product with partial experience, because it solves their most pressing needs. They will risk an incomplete product as long as their needs are met.
However, if we don't choose our early adopters right, we may end up validating the wrong product, which then tanks in the product/market fit stage. For instance, when we offer our product for free, how do we know if the customers are adopting our product because they see real value in it or because it's free? We feel happy with the validation we get for our software, but as we move out of that pilot group, we realize that our product doesn't have many takers. This is because we may have chosen our pilot group safely and they told us what we wanted to hear. The real test for a product is in testing out the riskiest propositions. The riskiest propositions are not just about how our product can create customer value, or about the technology viability in delivering that value, but also about the business capabilities.
If we're building a business, then we need to have a plan for how to make it grow, create impact, and be sustainable. Good software is never a replacement for a sound business model and vice versa. A product entering the product/market fit stage should have validated the viability of the riskiest business/technology propositions. Product/market fit should focus on offering an end-to-end product experience that offers the most value to the consumer and meets the business outcomes. The learnings that we have had right from product ideation and beyond have to continuously feed into the product experience. We need to think about a holistic product experience, rather than the feature set or technology.
If we don't realize that a product experience is a result of many technical and operational parts coming together, to meet a larger goal, then we're just missing the point. After all, we're not just laying the bricks; we're building a cathedral, a hospital, or a school.
An Impact Driven Product is the one that combines the technical and operational aspects of a product to create a holistic product experience. It comprises the entire product experience, across all touchpoints, for the customer. The Impact Driven Product ensures that we carve out a product, knowing full well what business outcomes to target. We factor in the support and co-ordination we need from business functions. We identify the smartest way to deliver value to customers under given business constraints. Knowing Key Business Outcomes is also a critical input to product development, and this should not be a one-time activity.
Business constraints and market influence
Business constraints includes factors such as the time available to go to market and the potential to raise investments. Governing policies, regulations and compliances (if any), technology potential, capabilities, skills available, and so on can also influence business goals and the product experience. These factors will determine the key goals to focus on, the product features to offer, and the best way to implement them. In addition to constraints, the intrinsic business intent is important. What are our uncompromising principles? What do we value more? What values drive our decisions? What is our appetite for risk? These factors will decide how we deliver value.
A product can impact the business or the organization that is creating the product. It can also impact the customers who will adopt the product. An Impact Driven Product therefore is one that finds the best way to deliver value to customers and meet business outcomes under internal and external constraints.
Based on the unique value proposition and the business context and business outcomes prioritized for a specific time-bound milestone, the following is a sample illustration of the inputs for product development for ArtGalore:
This is quite a simplified representation of the product development inputs at a given point in time. The diagram illustrates how business constraints may influence what the Impact Driven Product may deliver to the user.
The preceding illustration indicates that the most important outcome for ArtGalore is to become the first choice for art among its target segment. The most important aspect of the value proposition is offering tastefully curated art collections for existing buyers who don't have this information today. The most effective plan to execute this solution is to offer digital newsletters, provide an online sign-up for upcoming art shows, follow up on the sign-up with invites, and announce the website. This has been identified based on the business constraints of being ready for the upcoming art show, not compromising on the existing buyer experience, and so on. The other solutions, value propositions, and execution plans are also great, but given the business constraints, the Impact Driven Product is where we want to steer all our resources to.
Minimum Viable Product (mvp) is a concept that is quite prevalent in the software development scene. There are different interpretations of the concept of an mvp and Chapter 6, Managing the Scope of an Impact Driven Product dives into the interpretations of minimum viability.
At a basic level, an MVP intends to test the riskiest proposition of a business idea or a technology, without running out of resources. This is very helpful when testing an unproven technology or when building under tight business constraints. However, an mvp falls short in terms of delivering an end-to-end product experience to the consumers. The problem with how we define an mvp is that we tend to view technology viability as a value driver operating in isolation. An mvp is great in the problem/solution fit stage, but in the product/market fit stage, there are many other aspects to consider. When launching a new product, there are umpteen activities that need to be orchestrated to ensure success. Marketing, sales, support, and other operations need to come together to ensure a product's success. Testing viability of a product in isolation isn't going to ensure success for the business.
In my start-up, we had built up a platform for businesses to design and build mobile apps for client engagement. We had started out in the events and conferences domain, where app creation lead times were pretty low, audience engagement was critical, and last-minute changes to a schedule were quite common. Our platform was geared toward addressing those needs, but we soon started seeing interest from other business verticals who saw the potential that our platform had in driving customer engagement. One such business asked us to enhance our platform with the bespoke functionality.
We were in early stages in our start-up and naturally we got quite excited about the opportunity. The possibility of opening up our platform to another domain was quite lucrative. While we didn't see much value in creating a custom solution for a single client, we realized that we could enhance our platform to cater to the entire business vertical. This would also give us a great opportunity to launch our product into the B2C space. So, we carved out an mvp for this, and our engineers got busy with re-architecting the platform to make it flexible across business verticals. After spending more than a month on this, we were more or less ready with the revamped software.
Our revamped product was technologically viable. Yet, was the revamped software impact-driven? No. Why? We hadn't looked at the end-to-end value of the product. Our business model was different. Our target audience was new. A B2C market needed a very different approach. We hadn't planned for marketing, content creation, and promotions. We realized that we had neither the right skills nor the investment to drive this product to success. We hadn't really defined to ourselves what the new product would deliver. After all, we had just one customer who was interested. We hadn't looked at an end-to-end product experience.
Our rookie mistake cost us a month. We ended up shelving the product and didn't even close our sale with the one customer who showed interest. From the software perspective, we had it all covered, but we had not given any thought to the whole product experience or to the outcomes it could generate for our business. We are much better off today having learned and recovered from that mistake quickly, instead of having gone down that path, purely riding on the viability of our platform. We had looked at one customer's request and created a hypothesis about the problems our new platform could solve and the needs it could satisfy for that customer segment. We were confident that the product would address their needs and it could have. However, we hadn't given any thought about what it meant for our business, the stage we were in, our internal capabilities, and our weaknesses.
I know many developers who take great pride in how their software is built. The prevalent thinking is that if you build your software right, it will take care of itself. I've seen very smart engineers express deep disregard for supporting functions. They look down upon marketing, promotions, and sales saying, "People will adopt our product because my software is great." However, success isn't in and of the technology process itself. This is a core difference between task-oriented thinking and goal-oriented thinking.
Businesses make the same rookie mistake when going after early adopters. We want to get our business model validated quickly and cost-effectively. So, we build an mvp with a lot of loose ends on experience, revenue generation, and operations. Then we identify a safe pilot group from our family, friends, and well-wishers, or we offer our product for free to anyone who agrees to try it. Early adopters need to be potential (paying) customers who will risk adopting a product with partial experience, because it solves their most pressing needs. They will risk an incomplete product as long as their needs are met.
However, if we don't choose our early adopters right, we may end up validating the wrong product, which then tanks in the product/market fit stage. For instance, when we offer our product for free, how do we know if the customers are adopting our product because they see real value in it or because it's free? We feel happy with the validation we get for our software, but as we move out of that pilot group, we realize that our product doesn't have many takers. This is because we may have chosen our pilot group safely and they told us what we wanted to hear. The real test for a product is in testing out the riskiest propositions. The riskiest propositions are not just about how our product can create customer value, or about the technology viability in delivering that value, but also about the business capabilities.
If we're building a business, then we need to have a plan for how to make it grow, create impact, and be sustainable. Good software is never a replacement for a sound business model and vice versa. A product entering the product/market fit stage should have validated the viability of the riskiest business/technology propositions. Product/market fit should focus on offering an end-to-end product experience that offers the most value to the consumer and meets the business outcomes. The learnings that we have had right from product ideation and beyond have to continuously feed into the product experience. We need to think about a holistic product experience, rather than the feature set or technology.
If we don't realize that a product experience is a result of many technical and operational parts coming together, to meet a larger goal, then we're just missing the point. After all, we're not just laying the bricks; we're building a cathedral, a hospital, or a school.
An Impact Driven Product is the one that combines the technical and operational aspects of a product to create a holistic product experience. It comprises the entire product experience, across all touchpoints, for the customer. The Impact Driven Product ensures that we carve out a product, knowing full well what business outcomes to target. We factor in the support and co-ordination we need from business functions. We identify the smartest way to deliver value to customers under given business constraints. Knowing Key Business Outcomes is also a critical input to product development, and this should not be a one-time activity.
Minimum Viable Product versus Impact Driven Product
Minimum Viable Product (mvp) is a concept that is quite prevalent in the software development scene. There are different interpretations of the concept of an mvp and Chapter 6, Managing the Scope of an Impact Driven Product dives into the interpretations of minimum viability.
At a basic level, an MVP intends to test the riskiest proposition of a business idea or a technology, without running out of resources. This is very helpful when testing an unproven technology or when building under tight business constraints. However, an mvp falls short in terms of delivering an end-to-end product experience to the consumers. The problem with how we define an mvp is that we tend to view technology viability as a value driver operating in isolation. An mvp is great in the problem/solution fit stage, but in the product/market fit stage, there are many other aspects to consider. When launching a new product, there are umpteen activities that need to be orchestrated to ensure success. Marketing, sales, support, and other operations need to come together to ensure a product's success. Testing viability of a product in isolation isn't going to ensure success for the business.
In my start-up, we had built up a platform for businesses to design and build mobile apps for client engagement. We had started out in the events and conferences domain, where app creation lead times were pretty low, audience engagement was critical, and last-minute changes to a schedule were quite common. Our platform was geared toward addressing those needs, but we soon started seeing interest from other business verticals who saw the potential that our platform had in driving customer engagement. One such business asked us to enhance our platform with the bespoke functionality.
We were in early stages in our start-up and naturally we got quite excited about the opportunity. The possibility of opening up our platform to another domain was quite lucrative. While we didn't see much value in creating a custom solution for a single client, we realized that we could enhance our platform to cater to the entire business vertical. This would also give us a great opportunity to launch our product into the B2C space. So, we carved out an mvp for this, and our engineers got busy with re-architecting the platform to make it flexible across business verticals. After spending more than a month on this, we were more or less ready with the revamped software.
Our revamped product was technologically viable. Yet, was the revamped software impact-driven? No. Why? We hadn't looked at the end-to-end value of the product. Our business model was different. Our target audience was new. A B2C market needed a very different approach. We hadn't planned for marketing, content creation, and promotions. We realized that we had neither the right skills nor the investment to drive this product to success. We hadn't really defined to ourselves what the new product would deliver. After all, we had just one customer who was interested. We hadn't looked at an end-to-end product experience.
Our rookie mistake cost us a month. We ended up shelving the product and didn't even close our sale with the one customer who showed interest. From the software perspective, we had it all covered, but we had not given any thought to the whole product experience or to the outcomes it could generate for our business. We are much better off today having learned and recovered from that mistake quickly, instead of having gone down that path, purely riding on the viability of our platform. We had looked at one customer's request and created a hypothesis about the problems our new platform could solve and the needs it could satisfy for that customer segment. We were confident that the product would address their needs and it could have. However, we hadn't given any thought about what it meant for our business, the stage we were in, our internal capabilities, and our weaknesses.
I know many developers who take great pride in how their software is built. The prevalent thinking is that if you build your software right, it will take care of itself. I've seen very smart engineers express deep disregard for supporting functions. They look down upon marketing, promotions, and sales saying, "People will adopt our product because my software is great." However, success isn't in and of the technology process itself. This is a core difference between task-oriented thinking and goal-oriented thinking.
Businesses make the same rookie mistake when going after early adopters. We want to get our business model validated quickly and cost-effectively. So, we build an mvp with a lot of loose ends on experience, revenue generation, and operations. Then we identify a safe pilot group from our family, friends, and well-wishers, or we offer our product for free to anyone who agrees to try it. Early adopters need to be potential (paying) customers who will risk adopting a product with partial experience, because it solves their most pressing needs. They will risk an incomplete product as long as their needs are met.
However, if we don't choose our early adopters right, we may end up validating the wrong product, which then tanks in the product/market fit stage. For instance, when we offer our product for free, how do we know if the customers are adopting our product because they see real value in it or because it's free? We feel happy with the validation we get for our software, but as we move out of that pilot group, we realize that our product doesn't have many takers. This is because we may have chosen our pilot group safely and they told us what we wanted to hear. The real test for a product is in testing out the riskiest propositions. The riskiest propositions are not just about how our product can create customer value, or about the technology viability in delivering that value, but also about the business capabilities.
If we're building a business, then we need to have a plan for how to make it grow, create impact, and be sustainable. Good software is never a replacement for a sound business model and vice versa. A product entering the product/market fit stage should have validated the viability of the riskiest business/technology propositions. Product/market fit should focus on offering an end-to-end product experience that offers the most value to the consumer and meets the business outcomes. The learnings that we have had right from product ideation and beyond have to continuously feed into the product experience. We need to think about a holistic product experience, rather than the feature set or technology.
If we don't realize that a product experience is a result of many technical and operational parts coming together, to meet a larger goal, then we're just missing the point. After all, we're not just laying the bricks; we're building a cathedral, a hospital, or a school.
An Impact Driven Product is the one that combines the technical and operational aspects of a product to create a holistic product experience. It comprises the entire product experience, across all touchpoints, for the customer. The Impact Driven Product ensures that we carve out a product, knowing full well what business outcomes to target. We factor in the support and co-ordination we need from business functions. We identify the smartest way to deliver value to customers under given business constraints. Knowing Key Business Outcomes is also a critical input to product development, and this should not be a one-time activity.
In early 2000, I worked as a business analyst. We were following the waterfall methodology, and I used to maintain huge 500-page requirements documents. Waterfall methodology assumes that software development happens in stages. The first phase is to understand business requirements. It is followed by designing and architecting the solution. Solution development starts only after the architecture is signed off testing begins only after development is complete, and so on.
Interactions with business stakeholders happened primarily at the requirements gathering phase. When building a large solution, that phase could run into months. There wasn't much interaction with businesses, or customers, after this phase. In my case, most of my interactions used to be confined to the analysis team. We used to be isolated from developers and testers. I mean, we actually sat on different floors, and in one instance, testers were in a different building altogether!
For the entire solution to be delivered, it could take many months, or even years. By then, a lot could have changed on the business scene. My first experience of understanding the impact of this came by chance. I was asked to fill in for my manager on a year-end prioritization call. I had to read out a one-line status update about a project we had been working on for six months at that point. I had no inkling about what the call was about. As a rather naïve junior analyst, I had no idea that all the regional business heads were going to be on the call. Toward the end of the two-hour long call, the facilitator read out a list of projects that were ongoing and in the pipeline for the next year. Every regional head made a go/no go decision, indicating whether they were willing to sponsor that project or not.
To my shock, an application that one of the teams had been building for two years got rejected. Poof! Just like that, two years of software development turned to ash. I was intrigued. How could this be? Why would they waste so much money building something and then scrap it on a whim? Was this only a problem with waterfall? How could we have anticipated business priorities?
I have witnessed many Agile projects shutting down not because we weren't building things right, but because the business context had changed. In some cases, the business ran out of money. Product teams were not closely aligned with business and while the business context had been shifting for a while, the previously identified backlog was still being built. In other cases, the product wasn't rolled out to users until much later, and adoption went downhill. Agility helps in responding to changing business context, but what if we could predict the trends of where the business is heading? The problem also occurs when business functions don't collaborate and work toward the same business outcomes. Even when the situation isn't calling for something as drastic as a shutdown, product teams are often taken by surprise about how a feature is perceived by a business. Business priorities need to align with every aspect of product building.
I know many a software engineer who is confounded by the idea of a quick-and-dirty working code, even when the code meets customer needs and business outcomes. I have seen business stakeholders fuss over the exact hue and shade of the brand colors in the user interface, and not really care so much about how performant the system is. Sometimes, this is due to an incorrect frame of reference. Some stakeholders don't really understand the effort that goes into optimizing a page load for an image-heavy website that is used by a million users. So, they may just brush it off and say, "Of course, that's to be expected. Why would it be otherwise?" This is because we make some assumptions about product outcomes. We treat a business outcome as a one-time requirement that is frozen for the lifetime of a product. We then iterate only on a product plan to deliver product features. We make assumptions about which customer value proposition is important. The business (as a whole) should determine trade-off decisions, the value proposition, and what customer feedback to act upon. Understanding business outcomes should also be iterative.
What value proposition do we need to deliver in our product? What business outcomes are we trying to meet? Isn't it wasteful for developers to build a highly performant system, when product differentiation is what we're going after? Isn't it just as wasteful for marketing teams to strategize about reach and engagement, when what we're really looking for are a few early adopters? These questions require collaboration and collective decision-making.
As shown in the preceding illustration, each of us holds a certain view of the business potential. Each of us is right in our own way. Brand messaging, sales follow-up, integrations to ease operational activities, and planning for scale are all good, but is it the right time now to address them? What determines this?
Where we direct our efforts depends on the present context of the business. This should not be a choice that business functions make in isolation. Business functions (product, marketing, sales operations, and so on) should collaboratively make this decision. Why we choose one way to execute over another, or what trade-offs we make, depends on the intrinsic organizational makeup. The combination of context and this choice determines business intent.
At every stage in a product's development (and especially at the start) we need to identify what drives the business intent. How do we plan on delivering the unique value proposition of our product to the customers/market? What would tell us that we're doing the right thing for the business? What aspect of our value delivery is most important for us? What trade-offs are we making?
Growth, sustainability, and impact are pretty much the goals for every business (nonprofits and socio-political organizations may align better with impact than profitability). Yet if the business is not making money sustainably, or influencing sustainable change, can it exist? Should it exist? With this business goal, we can come up with a list of outcomes that are pertinent to the present business context. These outcomes can help us to align our product value propositions. They are the Key Business Outcomes we want to track. Each business outcome would have its own success metrics, which we can measure.
Some of these Key Business Outcomes are listed as follows. This list is indicative and generic. We may be able to identify other outcomes based on the context of our business. Typically, aim for not more than one to three outcomes:
- Growth
- Acquisitions (new registrations)
- Marketing (branding, reach, visibility, and virality)
- Scale (gearing up exponential growth)
- Sustainability
- Revenues (sales)
- Investments (fundraising)
- Costs (reduction/control)
- Streamlined operations (improved SLAs)
- Influence
- Retention (churn)
- Engagement (active users, support, and content)
- Adoption (training, access, and user experience)
As you may note, some of these outcomes are tangible and easily measurable, for instance, acquisitions. Others are quite abstract, such as customer satisfaction or marketing reach. In the next few chapters, we will try to define the criteria for measuring every business outcome.
Every business is unique and goes through different stages of maturity. Therefore, some business outcomes are likely to be more important than others, depending on which stage of business we are at, and what type of organization we are. Also, it's nearly impossible to go after everything listed earlier. We may spread ourselves too thinly trying to achieve success in every aspect. We will need to make trade-offs, and those trade-offs need to translate into the product.
The unique value proposition from our business model and the Key Business Outcomes form the basis for defining the Impact Driven Product. The following representation indicates the various steps in the Impact Driven Product development cycle:
We will review each step in the Impact Driven Product cycle in the following chapters.
Practice trumps theory. While software methodologies and frameworks can guide us, our interpretation and adoption of these frameworks in our unique context matters a lot. The focus needs to remain on measuring outcomes and not the output. Product development needs to factor in business outcomes, customer value, an execution plan, and internal and external constraints to ensure that a holistic end-to-end product experience can be created. Identifying the Key Business Outcomes is an important input to product development, and this should not be a one-time activity. Being cognizant of the business constraints, and staying aligned on Key Business Outcomes, can ensure that we don't lose focus of the metrics that will make our business succeed.
Identifying Key Business Outcomes is the first step towards getting the organization aligned on goals. In the next chapter we will find out about why and how we can invest in these outcomes.
In the previous chapter, we defined our business model and identified Key Business Outcomes. However, this cannot be a one-time activity. We need to continually evaluate and invest in the outcomes that matter. Responding to change is not the onus of just product development. Agility in business decisions is equally importantgility in business decisions is important. Product development must work in conjunction with these business decisions and every business function must be aligned to the changes that the business is responding to.
Accordingly, this chapter will address the following queries:
- How can product development include business agility as part of the development cycle?
- How to play the Investment Game and capture the value for each Key Business Outcome?
The best time to plant a tree was 20 years ago. The second best time is now. – Chinese proverb
Planning for success in life generally involves making investment decisions. We must decide how to invest our time, which people to invest in, where to invest our money, and so on. We need to start some investments today to reap the benefits a year, or even 20 years, from now. Some investments return immediate benefits, such as winning a game or preparing for an interview to get into a job. Some investments need much longer time, but spreading out an investment could make it last a lifetime.
Trudging through school, for instance, will eventually pay off. Some investments burn your money, and create no monetary value, but they bring a lot of joy. These could be a nice vacation, buying a car, or throwing a party. When we don't understand what benefits we should be reaping from an investment, we tend to have unrealistic expectations. We also need to be realistic about how long it will take for an investment to return benefits. Needless to say, everything comes with its own risks.
Building products is no different. Some features take a long time to build and will return investment in the long term. Some features give immediate benefits. Building products without understanding business benefits is wasteful and expensive?. This is why we start with identifying the Key Business Outcomes for our product. Product building depends on available talent, capital, and other operating constraints. So, if we have unlimited time, money, and favorable conditions, then yes, we can build anything, but that never happens. Product building, like everything else in life, operates under constraints.
We need to identify, as a business, where to focus our efforts and capital. We also need to set realistic expectations about benefits and timelines. We must know how our past investments have performed. This information will help us plan our product funnel.
To create the best product experience, we must align product-building and business operations. To do this, we need to find the most important (one to three) business outcomes for a definite timeline. The reason I'm saying one to three outcomes is because in early stages of product development, it is best to steer our resources toward fewer outcomes. Going after too many goals can be counter-productive and can result in a loss of focus.
Quoting Eric Ries, author of The Lean Startup, here:
"There is no reason why a product cannot have both high margins and high retention. However, in my experience, successful startups focus on just one engine of growth, specializing in everything that is required to make it work."
Even when we focus only on growth, sustainability, or influence as our high-level goals, we may still need to refine to one to three outcomes within these high-level goals, to ensure that we direct our efforts constructively. Based on the Key Business Outcomes, we can determine which product functionality to pursue and which functionalities are likely to be the most impactful.
Setting a time limit helps us to define realistic product backlogs. We can then track success metrics and evaluate whether or not the product is working/successful. This is typically the time needed to excute a plan and start seeing results. We need to be able to assess whether the product is meeting desired goals or not. An indefinite timeline may lead to overengineering. Why? Let me recount an experience from a software engineer who left his day job to start up a business in online music streaming. He had started with a great idea and immense passion. When I met him, he told me that he had been working on his product for a year.
When I asked him how many users had signed up, he said, "None!" I was quite curious to know why this was the case. When I probed further, he explained that he wanted his product to be perfect. He kept adding tweaks and subtleties, trying to make his product good enough to be showcased to the world. He hadn't set himself a time-bound goal, nor a milestone so that he could meet specific goals. He kept pursuing perfection, and this pursuit was limited to his choice of features (functionalities) in the product. His pursuit of perfection in how the product was being built was not supported by an equal zeal to meet any outcomes. He hadn't thought of how many users he wanted to acquire, whether he wanted to make revenues from his product or not, or what users might want in the product. He was running out of money in about three months and was desperate to find takers for his product. He hadn't laid the groundwork for anything other than the functional aspects of the product. He had been running on an indefinite timeline and overengineering a product that had neither users nor a business model.
Ash Maurya, in his book Running Lean, describes the three stages of a start-up:
- Problem /solution fit
- Product /market fit
- Scale
The development of a product follows the same stages. The problem /solution phase must be less about product development, and more about validating the unique value proposition.
Once we have validated the unique value proposition, we have a clear idea of what the product is, who our customers are, what alternatives we trying to replace, and so on. This is the phase where we're trying to see if our product meets the needs of our customers. Product /market fit is the stage where we figure out if our product can meet the market's needs. Does the market see value in our product? If yes, then how do customers value our product? How does that translate into a business outcome for us? The third stage of scale happens after we have established the product /market fit and have found a business model that is repeatable, and the quest is to accelerate growth.
The Impact Driven Product, as we saw in Chapter 1, Identify Key Business Outcomes, is a combination of the why, what, and how under the influence of internal and external factors. An Impact Driven Product, therefore, is one that finds the best way to deliver value to customers and meet business outcomes under internal and external constraints.
During the problem/solution fit and the product/market fit stages, we define the product, measure its success, and iterate on our learnings. It is important that we keep the build-measure-learn loop short. It must be short enough to ensure that we don't overengineer our product and long enough to be able to deliver something of value.
Typically, a few weeks to a one or two-month period can work well when we're in these early stages of product development. It helps us to keep our validation cycle shorter and keep our focus on identifying our Impact Driven Product. As our product matures (gains traction), we start seeing evidence of success in business outcomes. We then decrease the frequency of this validation cycle or increase the duration of the validation cycle. We could extend the frequency of investing in Key Business Outcomes to four to six months, depending on the nature and maturity of the product.
There is of course the question of what if we cannot implement an idea in three months? What if we don't have the right skills, or the resources, to meet the business outcomes? We still need to understand realistic implementation and validation timelines. This is what we will establish in later stages in the development cycle described in the next two chapters.
When implementing software, there will be trade-offs that we need to make. The product trade-offs might be about speed, quality, performance, reliability, or scalability. Typically, we categorize them under nonfunctional requirements. Some get classified as technical tasks and never make it onto the radar of nontechnical folks. This is where most of the disconnect between the technical and nontechnical teams arises.
When we're in the early stages of product development, we tend to have a narrow product focus. We target a limited set of early adopters. We may also look at a limited feature set. One of the main reasons we want to do this is to iterate through the build-measure-learn loop swiftly. We want to validate our product assumptions at the earliest opportunity, so sometimes the quick-and-dirty code may just work. The problem here is that the product could have defects. It might not work well for all use cases, it might not scale or be very responsive, and so on. Yet these trade-offs are being made at the product engineering level. Without understanding what measurable outcomes that we seek from the product at this stage, we cannot make educated trade-off decisions.
For instance, what is our idea of early adopters? How many users are we targeting? If a product works well for the early adopters, how soon do we want to scale to the next level? What if we started with 50 customers, and now we have 200 sign-ups? What trade-off is the business willing to make? Is it OK if we lose customers because of limiting performance or defects? Should product teams decide this in isolation? Don't other business functions have a stake/say in this?
When making trade-off decisions in isolation, technical teams build defensive code. They are unclear about success metrics. They assume that the business will come back with more sales, so they build less features, but more robust software. Nontechnical folks, when making trade-off decisions may do so with a poor frame of reference about technology. Evaluating the benefits of the effort involved in building quick-and-dirty software versus robust scalable software, can be hard. The end result of this disconnect is the loss of experience for customers and the loss of value to a business.
In some cases, there may be immediate benefits. Defining the timelines for realizing product benefits in terms of actionable metrics is required to define what to build now and what not to build now.
Trade-offs in time-bound planning
When implementing software, there will be trade-offs that we need to make. The product trade-offs might be about speed, quality, performance, reliability, or scalability. Typically, we categorize them under nonfunctional requirements. Some get classified as technical tasks and never make it onto the radar of nontechnical folks. This is where most of the disconnect between the technical and nontechnical teams arises.
When we're in the early stages of product development, we tend to have a narrow product focus. We target a limited set of early adopters. We may also look at a limited feature set. One of the main reasons we want to do this is to iterate through the build-measure-learn loop swiftly. We want to validate our product assumptions at the earliest opportunity, so sometimes the quick-and-dirty code may just work. The problem here is that the product could have defects. It might not work well for all use cases, it might not scale or be very responsive, and so on. Yet these trade-offs are being made at the product engineering level. Without understanding what measurable outcomes that we seek from the product at this stage, we cannot make educated trade-off decisions.
For instance, what is our idea of early adopters? How many users are we targeting? If a product works well for the early adopters, how soon do we want to scale to the next level? What if we started with 50 customers, and now we have 200 sign-ups? What trade-off is the business willing to make? Is it OK if we lose customers because of limiting performance or defects? Should product teams decide this in isolation? Don't other business functions have a stake/say in this?
When making trade-off decisions in isolation, technical teams build defensive code. They are unclear about success metrics. They assume that the business will come back with more sales, so they build less features, but more robust software. Nontechnical folks, when making trade-off decisions may do so with a poor frame of reference about technology. Evaluating the benefits of the effort involved in building quick-and-dirty software versus robust scalable software, can be hard. The end result of this disconnect is the loss of experience for customers and the loss of value to a business.
In some cases, there may be immediate benefits. Defining the timelines for realizing product benefits in terms of actionable metrics is required to define what to build now and what not to build now.
The following representation shows the stages of product development for creating our Impact Driven Product:
We have initiated our first step in the product development. This first step is Invest in Key Business Outcomes. At this stage, the business indicates an inclination to build a solution that will impact certain business outcomes. Now, we may be able to build some functionality in this solution faster and therefore we can meet outcomes sooner. Some other functionality may take longer to build and may take a longer time to meet outcomes. We may have to make conscious technology and experience trade-offs to meet time-bound priorities.
As we iterate through the build-measure-learn loop of the product, it is likely that we will discover customer insights, feedback, gaps in product experience, and so on.
Product teams should not answer this questions in isolation. Since a product's success influences business outcomes (and vice versa), it is important to understand what risks, trade-offs, and goals the business is willing to consider. These decisions influence how business functions and product development should spend their resources. We could, of course, ask for different priorities on a case-by-case basis. However, it will be ineffective to look at a bunch of disparate data, insights from live functionality, and a backlog of potential functionality and then prioritize without context.
This is same comparison that Jeff Paton uses when describing how user stories are managed in a product backlog. The preceding image illustrates this perspective. He says, "We spend lots of time working with our customers. We work hard to understand their goals, their users, and the major parts of the system we could build. Then we finally get down to the details – the pieces of functionality we'd like to build… after all that work, after establishing all that shared understanding I feel like we pull all the leaves off the tree and load them into a leaf bag – then cut down the tree. That's what a flat backlog is to me. A bag of context-free mulch." (https://jpattonassociates.com/the-new-backlog/)
This is exactly what happens when we draw up a business model, then forget about the business drivers, and execute a product plan focused only on the product backlog. So, when business stakeholders are asked to prioritize a backlog without context, we can't expect to get the inputs we seek. Also, this type of prioritization (which essentially indicates the value (or ranking) that a business attaches to a product functionality or to a customer experience) cannot be quantified. Prioritization also needs to start with Key Business Outcomes and the business constraints that determine product strategy. Key Business Outcomes must be measurable.
In order to assign a value/rank to the business drivers, we need to understand what significance the business attaches to it. Instead of this being a random number or something we rank on a scale of one to ten, we can match it closely to how the business actually operates. Businesses make bets on outcomes. Each bet comes with its risk and will take a certain amount of time to reap benefits. When planning personal financial investments, to make a comparison, we're likely to plan based on our risk appetite and financial goals. This is similar to predicting a certain rate of interest/growth on our investments, at a certain time in future. Just asking business stakeholders about their investment priorities doesn't usually help, so I recommend that we play an Investment Game!
So how do we know which trade-offs are worth making?
As we iterate through the build-measure-learn loop of the product, it is likely that we will discover customer insights, feedback, gaps in product experience, and so on.
Product teams should not answer this questions in isolation. Since a product's success influences business outcomes (and vice versa), it is important to understand what risks, trade-offs, and goals the business is willing to consider. These decisions influence how business functions and product development should spend their resources. We could, of course, ask for different priorities on a case-by-case basis. However, it will be ineffective to look at a bunch of disparate data, insights from live functionality, and a backlog of potential functionality and then prioritize without context.
This is same comparison that Jeff Paton uses when describing how user stories are managed in a product backlog. The preceding image illustrates this perspective. He says, "We spend lots of time working with our customers. We work hard to understand their goals, their users, and the major parts of the system we could build. Then we finally get down to the details – the pieces of functionality we'd like to build… after all that work, after establishing all that shared understanding I feel like we pull all the leaves off the tree and load them into a leaf bag – then cut down the tree. That's what a flat backlog is to me. A bag of context-free mulch." (https://jpattonassociates.com/the-new-backlog/)
This is exactly what happens when we draw up a business model, then forget about the business drivers, and execute a product plan focused only on the product backlog. So, when business stakeholders are asked to prioritize a backlog without context, we can't expect to get the inputs we seek. Also, this type of prioritization (which essentially indicates the value (or ranking) that a business attaches to a product functionality or to a customer experience) cannot be quantified. Prioritization also needs to start with Key Business Outcomes and the business constraints that determine product strategy. Key Business Outcomes must be measurable.
In order to assign a value/rank to the business drivers, we need to understand what significance the business attaches to it. Instead of this being a random number or something we rank on a scale of one to ten, we can match it closely to how the business actually operates. Businesses make bets on outcomes. Each bet comes with its risk and will take a certain amount of time to reap benefits. When planning personal financial investments, to make a comparison, we're likely to plan based on our risk appetite and financial goals. This is similar to predicting a certain rate of interest/growth on our investments, at a certain time in future. Just asking business stakeholders about their investment priorities doesn't usually help, so I recommend that we play an Investment Game!
How do we decide which learning, feedback, or customer insight is important?
Product teams should not answer this questions in isolation. Since a product's success influences business outcomes (and vice versa), it is important to understand what risks, trade-offs, and goals the business is willing to consider. These decisions influence how business functions and product development should spend their resources. We could, of course, ask for different priorities on a case-by-case basis. However, it will be ineffective to look at a bunch of disparate data, insights from live functionality, and a backlog of potential functionality and then prioritize without context.
This is same comparison that Jeff Paton uses when describing how user stories are managed in a product backlog. The preceding image illustrates this perspective. He says, "We spend lots of time working with our customers. We work hard to understand their goals, their users, and the major parts of the system we could build. Then we finally get down to the details – the pieces of functionality we'd like to build… after all that work, after establishing all that shared understanding I feel like we pull all the leaves off the tree and load them into a leaf bag – then cut down the tree. That's what a flat backlog is to me. A bag of context-free mulch." (https://jpattonassociates.com/the-new-backlog/)
This is exactly what happens when we draw up a business model, then forget about the business drivers, and execute a product plan focused only on the product backlog. So, when business stakeholders are asked to prioritize a backlog without context, we can't expect to get the inputs we seek. Also, this type of prioritization (which essentially indicates the value (or ranking) that a business attaches to a product functionality or to a customer experience) cannot be quantified. Prioritization also needs to start with Key Business Outcomes and the business constraints that determine product strategy. Key Business Outcomes must be measurable.
In order to assign a value/rank to the business drivers, we need to understand what significance the business attaches to it. Instead of this being a random number or something we rank on a scale of one to ten, we can match it closely to how the business actually operates. Businesses make bets on outcomes. Each bet comes with its risk and will take a certain amount of time to reap benefits. When planning personal financial investments, to make a comparison, we're likely to plan based on our risk appetite and financial goals. This is similar to predicting a certain rate of interest/growth on our investments, at a certain time in future. Just asking business stakeholders about their investment priorities doesn't usually help, so I recommend that we play an Investment Game!
The Investment Game needs to be played as a collaborative exercise with representation from all stakeholders. A stakeholder is one of these:
- Anyone who is likely to influence product decisions
- Anyone who is impacted by product outcomes
- Anyone who is involved in product implementation
The Investment Game draws inspiration from the Buy a Feature game. If you have played Buy a Feature (http://www.innovationgames.com/buy-a-feature/), then you may be familiar with the format of this game. The idea of the game is to help stakeholders to get a sense of how costly a product feature is. The trigger for getting stakeholders to "buy a feature" is when we have a product backlog that has been estimated by developers, and we know that within the give time/budget we may be unable to deliver the backlog. The Buy a Feature game is an effective way of asking stakeholders to indicate feature priorities. It is also quite effective when asking stakeholders to indicate "must haves" and "should haves" on the product backlog.
The cost for each feature is determined on roughly sizing the feature cost in terms of the effort needed to build it. The game is very practical and has a dramatic influence on how business stakeholders view features. It's like stakeholders are shopping for features with limited money, and that brings in a real-world view of operating under financial constraints.
The Investment Game is different in that it does not require costs to be derived upfront. It is essentially following the format of using real money and using a limited amount of money, but that's where the similarity with the Buy a Feature game ends.
This is what we need for playing the Investment Game:
- A list of Key Business Outcomes
- Data (market trends, customer insights, feedback, and success metrics) that can influence business decisions
- Limited amount of real money (capital to invest)
What we don't need for playing the Investment Game is this:
- Product functionality/features/backlog items
- Costs
We limit the amount of capital that is allowed to be invested. While it may be possible to raise money for the business, the reality is that product building does operate under constraints. Limiting the money available to play this game helps us to artificially enforce that constraint and forces people to critically evaluate their choices. We are not concerned about the costs or actual product functionality for playing this game. This is an iteration on the business model thinking and an attempt to capture the risk and investment appetite of the business.
We ask stakeholders to plan their investment priorities, by indicating how much money they are willing to invest on delivering a solution (the Impact Driven Product) that meets a business outcome. At this point, we're not yet defining how the product will contribute to that value, or how to measure the benefits from this investment. We will do that in the next step in the Impact Driven Product development cycle.
During the early stages of product development, we may or may not have many data points to back up our decisions. If the product has not yet been launched, then insights from problem interviews with customers can feed into this activity. Typically, we may invest in outcomes that correspond to our product's core value propositions or those that validate our riskiest propositions. Also, since this is a collaborative activity, it forces stakeholders to actively discuss and debate their investments. This can quickly get into a war of opinions, and it is best kept in check by presenting any data available.
"If we have data, let's look at data. If all we have are opinions, let's go with mine." – Jim Barksdale, Netscape
Let's look at our list of business outcomes again:
- Growth
- Acquisitions (new registrations)
- Marketing (branding, reach, visibility, and virality)
- Scale (gearing up exponential growth)
- Sustainability
- Revenues (sales)
- Investments (fundraising)
- Costs (reduction/control)
- Streamlined operations (improved SLAs)
- Influence
- Retention (churn)
- Engagement (active users, support, and content)
- Adoption (training, access, and user experience)
Let's consider this is the initiation of product development for the ArtGalore digital gallery, introduced in Chapter 1, Identify Key Business Outcomes. We have our business model (Lean Canvas). We also have insights from problem interviews with customers. We are ready to determine what solution to build in order to meet the business constraints of launching this before the Big Art Show (refer to the business outcomes, business context and constraints, and market factors in the following image). We have a high-level idea of the solution from the Lean Canvas model.
The question we're trying to answer here is: what business outcome should we try to meet within the one-month timeline dictated by the business/market constraint? Should we look at brand building? Should we look at revenues?
As you may observe, the one-month timeline is only to launch the solution. It is not a timeline for creating a brand presence or making revenue. Those will come into effect only after the solution is launched. However, given the time constraints our lack of digital marketing expertise, and based on insights we have from problem interviews and existing customers, and so on, the business needs to decide which business outcome to invest in.
From the list of business outcomes under growth, sustainability, and influence, we may determine that acquisitions, revenue, engagement, and marketing, all seem to be geared toward doubling the revenue in two years. Among these, is there a relative priority? Each stakeholder could have a different perspective of what we need to invest in, based on what we know today. They also need to gauge relative priorities between these outcomes. As in, how valuable is getting a good number of qualified leads (marketing)? Is it more valuable than converting these leads into registered users (acquisitions)? Is that less valuable than getting customers to pay (revenues)? However, since the amount of money to play the Investment Game is limited, they will have to carefully choose where they want to invest.
So, let's say that the stakeholders collectively determine that they want to invest in engagement (of existing customers) and revenue. Now, this decision is based on the people and the unique context of the business. No two businesses are alike, and hence the choice of where they want to invest may be different:
The ArtGalore business may choose to invest as shown in the following figure:
There is no right or wrong way to make an investment, but this nature of input allows the product team to focus on building a solution that is driven by business context. It is indeed possible that a decision could backfire. It is also possible that a business may lose customers due to poor user experience. That is the risk that the business is willing to take when stakeholders indicate their preference.
In a product that is already being used, we are likely to have insights from customers. We may have data on engagement, adoption, revenue, reach, and so on. This is also the right forum to highlight our critical metrics and see if that influences business inclination to invest. For instance, customer support could highlight the rise in customer complaints due to a feature that we recently launched. The stakeholders may consider this data, but they might feel that it does not impact our primary goals of revenue and growth. This also means that the business is willingly making a trade-off by prioritizing revenue over adoption.
The important thing at this stage is to enable conversations between stakeholders. This activity helps the stakeholders to pitch to each other what business outcome they feel is critical. It gives them an opportunity to evaluate their priorities as a group. It is worthwhile spending as much time as needed having discussions, especially when there are conflicting points of view. This is also the main reason for ensuring that all stakeholders participate in this activity, since it allows them to get a sense of the overall priorities and provides a forum for pitching the priorities of their individual business functions.
When I ran this activity in a nonprofit, there were about seven stakeholders who participated. In the lead-up before the session, I had individual conversations with many business stakeholders. I listened to a lot of passionate ideas about influencing the community they were trying to serve. I also listened to a lot of ideas that floated around the visibility of their brand and how to increase their reach. It was noteworthy that the engineering team had a different mandate altogether. They had been working on performance fixes and automating operation tasks! Eventually, when the group got together, fundraising for the organization came out as their top priority. Nearly no money was invested in marketing, community impact, or operational efficiency!
This was the first time that the group got together to discuss and review their priorities. They could establish that the lack of visibility surrounding funding was their biggest bottleneck in delivering impact. Unless they raised funds, they would be unable to reach any of their milestones that were planned for later that year. While there were other areas that needed attention, the group agreed that fundraising needed the most attention. This then set the tone of product development. Product managers should ideally be a key stakeholder in this type of activity and also facilitate this activity since the output from the activity feeds into product priorities.
The final output from the Investment Game captures the business outcomes that were prioritized (for a specific timeline) and the amount invested against each of them. These values will be used in the subsequent prioritization of product functionality/value proposition and trade-offs.
The following table captures the amount that, in our example, ArtGalore stakeholders invested in their Key Business Outcomes. We now have a value for the most important business outcomes.
|
Business outcome |
Engagement |
Generate revenue |
|---|---|---|
|
Invested amount |
300 |
200 |
At the end of one month, once we have launched our first version of the product experience, we need to get all the stakeholders back together to review any other insights we have and determine the next milestone. Once again, we will evaluate the business context and the investment that we are making in Key Business Outcomes. For instance, it is possible that either our competitor beat us to the market, we raised new investments, or we signed up a celebrity artist since the last time we evaluated our business context. These factors can influence how we want to steer our product and our investment decisions.
Iterating through business priorities in the language they speak is important when we're setting the stage for product development. It can help to guide product development in a tangible, measureable, and iterative model. This also helps us to avoid surprises later, as we proactively think about where the business is headed to and make an implementation plan that can align with the business direction, while still delivering maximum value to customers. Being proactive in identifying and investing in Key Business Outcomes can help us to avoid situations where we have built a product that is no longer useful for the business.
Buy a Feature game
The Investment Game draws inspiration from the Buy a Feature game. If you have played Buy a Feature (http://www.innovationgames.com/buy-a-feature/), then you may be familiar with the format of this game. The idea of the game is to help stakeholders to get a sense of how costly a product feature is. The trigger for getting stakeholders to "buy a feature" is when we have a product backlog that has been estimated by developers, and we know that within the give time/budget we may be unable to deliver the backlog. The Buy a Feature game is an effective way of asking stakeholders to indicate feature priorities. It is also quite effective when asking stakeholders to indicate "must haves" and "should haves" on the product backlog.
The cost for each feature is determined on roughly sizing the feature cost in terms of the effort needed to build it. The game is very practical and has a dramatic influence on how business stakeholders view features. It's like stakeholders are shopping for features with limited money, and that brings in a real-world view of operating under financial constraints.
The Investment Game is different in that it does not require costs to be derived upfront. It is essentially following the format of using real money and using a limited amount of money, but that's where the similarity with the Buy a Feature game ends.
This is what we need for playing the Investment Game:
- A list of Key Business Outcomes
- Data (market trends, customer insights, feedback, and success metrics) that can influence business decisions
- Limited amount of real money (capital to invest)
What we don't need for playing the Investment Game is this:
- Product functionality/features/backlog items
- Costs
We limit the amount of capital that is allowed to be invested. While it may be possible to raise money for the business, the reality is that product building does operate under constraints. Limiting the money available to play this game helps us to artificially enforce that constraint and forces people to critically evaluate their choices. We are not concerned about the costs or actual product functionality for playing this game. This is an iteration on the business model thinking and an attempt to capture the risk and investment appetite of the business.
We ask stakeholders to plan their investment priorities, by indicating how much money they are willing to invest on delivering a solution (the Impact Driven Product) that meets a business outcome. At this point, we're not yet defining how the product will contribute to that value, or how to measure the benefits from this investment. We will do that in the next step in the Impact Driven Product development cycle.
During the early stages of product development, we may or may not have many data points to back up our decisions. If the product has not yet been launched, then insights from problem interviews with customers can feed into this activity. Typically, we may invest in outcomes that correspond to our product's core value propositions or those that validate our riskiest propositions. Also, since this is a collaborative activity, it forces stakeholders to actively discuss and debate their investments. This can quickly get into a war of opinions, and it is best kept in check by presenting any data available.
"If we have data, let's look at data. If all we have are opinions, let's go with mine." – Jim Barksdale, Netscape
Let's look at our list of business outcomes again:
- Growth
- Acquisitions (new registrations)
- Marketing (branding, reach, visibility, and virality)
- Scale (gearing up exponential growth)
- Sustainability
- Revenues (sales)
- Investments (fundraising)
- Costs (reduction/control)
- Streamlined operations (improved SLAs)
- Influence
- Retention (churn)
- Engagement (active users, support, and content)
- Adoption (training, access, and user experience)
Let's consider this is the initiation of product development for the ArtGalore digital gallery, introduced in Chapter 1, Identify Key Business Outcomes. We have our business model (Lean Canvas). We also have insights from problem interviews with customers. We are ready to determine what solution to build in order to meet the business constraints of launching this before the Big Art Show (refer to the business outcomes, business context and constraints, and market factors in the following image). We have a high-level idea of the solution from the Lean Canvas model.
The question we're trying to answer here is: what business outcome should we try to meet within the one-month timeline dictated by the business/market constraint? Should we look at brand building? Should we look at revenues?
As you may observe, the one-month timeline is only to launch the solution. It is not a timeline for creating a brand presence or making revenue. Those will come into effect only after the solution is launched. However, given the time constraints our lack of digital marketing expertise, and based on insights we have from problem interviews and existing customers, and so on, the business needs to decide which business outcome to invest in.
From the list of business outcomes under growth, sustainability, and influence, we may determine that acquisitions, revenue, engagement, and marketing, all seem to be geared toward doubling the revenue in two years. Among these, is there a relative priority? Each stakeholder could have a different perspective of what we need to invest in, based on what we know today. They also need to gauge relative priorities between these outcomes. As in, how valuable is getting a good number of qualified leads (marketing)? Is it more valuable than converting these leads into registered users (acquisitions)? Is that less valuable than getting customers to pay (revenues)? However, since the amount of money to play the Investment Game is limited, they will have to carefully choose where they want to invest.
So, let's say that the stakeholders collectively determine that they want to invest in engagement (of existing customers) and revenue. Now, this decision is based on the people and the unique context of the business. No two businesses are alike, and hence the choice of where they want to invest may be different:
The ArtGalore business may choose to invest as shown in the following figure:
There is no right or wrong way to make an investment, but this nature of input allows the product team to focus on building a solution that is driven by business context. It is indeed possible that a decision could backfire. It is also possible that a business may lose customers due to poor user experience. That is the risk that the business is willing to take when stakeholders indicate their preference.
In a product that is already being used, we are likely to have insights from customers. We may have data on engagement, adoption, revenue, reach, and so on. This is also the right forum to highlight our critical metrics and see if that influences business inclination to invest. For instance, customer support could highlight the rise in customer complaints due to a feature that we recently launched. The stakeholders may consider this data, but they might feel that it does not impact our primary goals of revenue and growth. This also means that the business is willingly making a trade-off by prioritizing revenue over adoption.
The important thing at this stage is to enable conversations between stakeholders. This activity helps the stakeholders to pitch to each other what business outcome they feel is critical. It gives them an opportunity to evaluate their priorities as a group. It is worthwhile spending as much time as needed having discussions, especially when there are conflicting points of view. This is also the main reason for ensuring that all stakeholders participate in this activity, since it allows them to get a sense of the overall priorities and provides a forum for pitching the priorities of their individual business functions.
When I ran this activity in a nonprofit, there were about seven stakeholders who participated. In the lead-up before the session, I had individual conversations with many business stakeholders. I listened to a lot of passionate ideas about influencing the community they were trying to serve. I also listened to a lot of ideas that floated around the visibility of their brand and how to increase their reach. It was noteworthy that the engineering team had a different mandate altogether. They had been working on performance fixes and automating operation tasks! Eventually, when the group got together, fundraising for the organization came out as their top priority. Nearly no money was invested in marketing, community impact, or operational efficiency!
This was the first time that the group got together to discuss and review their priorities. They could establish that the lack of visibility surrounding funding was their biggest bottleneck in delivering impact. Unless they raised funds, they would be unable to reach any of their milestones that were planned for later that year. While there were other areas that needed attention, the group agreed that fundraising needed the most attention. This then set the tone of product development. Product managers should ideally be a key stakeholder in this type of activity and also facilitate this activity since the output from the activity feeds into product priorities.
The final output from the Investment Game captures the business outcomes that were prioritized (for a specific timeline) and the amount invested against each of them. These values will be used in the subsequent prioritization of product functionality/value proposition and trade-offs.
The following table captures the amount that, in our example, ArtGalore stakeholders invested in their Key Business Outcomes. We now have a value for the most important business outcomes.
|
Business outcome |
Engagement |
Generate revenue |
|---|---|---|
|
Invested amount |
300 |
200 |
At the end of one month, once we have launched our first version of the product experience, we need to get all the stakeholders back together to review any other insights we have and determine the next milestone. Once again, we will evaluate the business context and the investment that we are making in Key Business Outcomes. For instance, it is possible that either our competitor beat us to the market, we raised new investments, or we signed up a celebrity artist since the last time we evaluated our business context. These factors can influence how we want to steer our product and our investment decisions.
Iterating through business priorities in the language they speak is important when we're setting the stage for product development. It can help to guide product development in a tangible, measureable, and iterative model. This also helps us to avoid surprises later, as we proactively think about where the business is headed to and make an implementation plan that can align with the business direction, while still delivering maximum value to customers. Being proactive in identifying and investing in Key Business Outcomes can help us to avoid situations where we have built a product that is no longer useful for the business.
In this chapter, we learned that we need to know what to build when iterating through the build-measure-learn loop. Determining what to build cannot be an isolated decision made by the product teams. The direction on product strategy needs to be based on the Key Business Outcomes. Investments made provide us with a way to measure the value that a business places on Key Business Outcomes. Doing this in shorter focused iterations, with insights from the market, product metrics, and the current business context and constraints, enables us to make informed decisions and respond effectively to changing trends.
In the next chapter, we will figure out what solution to build in order to deliver the most value to customers and what the best way is to meet business outcomes.
Ideation is a wonderfully creative process that can help us to take leaps into solutions. When building products under ambiguous conditions, we don't know how customers will adopt our product, how to deliver the best experience, or even which problems are more important to solve. Ideas can help us to navigate ambiguity by throwing open possibilities that we couldn't see earlier. At the same time, ideas can distract us from our goals. Product managers must be able to take ideas in their stride and be able to differentiate between ideas that add value and those that sound important but create no value. However, this does not have to be an individual's judgment. This happens best when we collaborate with business functions and stakeholders to estimate the impact and ensure that we share the same definition of success. This chapter proposes a framework for evaluating the impact of ideas on Key Business Outcomes.
The framework will ensure that we carry over only the most impactful feature ideas into the product backlog. Our backlog can then be lean, and we can focus all our resources on delivering the most value both to the customer and to the business.
In this regard, this chapter addresses the following points, describing how to do these:
- Finding the right problem to solve
- Creating an end-to-end view of the user and business (product/service) interaction
- Identifying feature ideas
- Estimating impact on Key Business Outcomes and derive value scores
- Prioritizing feature ideas based on value scores
"An idea is like a virus. Resilient. Highly contagious. And even the smallest seed of an idea can grow. It can grow to define or destroy you."- Cobb, Inception
A friend recently observed that any conversation in Bengaluru (India) sooner or later steers toward traffic woes. Invariably, everyone claims to have a solution for Bengaluru's traffic woes. You get to hear all sorts of ideas: fix all the potholes, build flyovers, introduce more public transport, and get those hyperloops or even flying cars. There are so many ideas, but our traffic woes persist.
We are creatures of imagination and ideas. We love fantasy. We dream up a reality that doesn't exist today, but that is also our biggest strength. Ideas can motivate us to strive for the impossible, but that is also the bane of ideas. There is a very fuzzy line between difficult and impossible. We end up chasing our tails trying to pursue ideas that sound important. Why is that? Is it because we don't understand our problem well enough? If we don't know what problem we're solving, how can we find the right solution?
In many cases, the problem is ubiquitous, for instance, the Bengaluru traffic problem. You only need to drive on Bengaluru roads twice to come up with a laundry list of issues. The traffic problem is real, unique, and personal to each of us. So, of course, everyone has a solution. Just because everyone has an idea, it doesn't mean those solutions are viable and valuable. Some ideas just aren't practical. Some ideas need way more investment. Some ideas are culturally bound to fail and some won't even take off because of political or social reasons. Some ideas will take a really long time before they start making a difference. Meanwhile, we find our own little ways to circumvent the problem. We work from home, take the bus, drive in off-peak hours, carpool, work in shifts, move closer to workplaces, take de-stressing yoga classes, and so on.
When we know enough about the problem, it is more valuable, effective, and fun to ideate. People love to ideate even about seemingly hard-to-solve problems. Sometimes, viability or the lack of viability of a solution can help us understand the problem better. When operating under uncertainty (where we are yet to fully grasp the potential of the market or what our customers value), we need to make ideas our friends. Finding ideas for a product isn't the hardest part, because ideas come cheap. The hard part is always finding the idea that will deliver our unique value proposition and business outcomes. By the way, ideas often come disguised as implementation specifics. So, product management also has to deal with sorting out the "how" from the "what."
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:
- Our customers needed real-time notifications
- They needed to send notifications from their mobile phones
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):
- Services should be designed based on customer needs rather than the internal needs of the business
- Services should be designed to deliver a unified and efficient system rather than component-by-component, which can lead to poor overall service performance
- Services should be designed based on creating value for users and customers and to be as efficient as possible
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:
- The features that increase value to customers
- How a user feature impacts Key Business Outcomes
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:
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:
- Premium art buyers can sign up to receive a newsletter with details of upcoming art shows, artists, and artworks
- All art buyers can choose one or more artworks listed in the newsletter and purchase them
- Smart recommendations for artworks to include in newsletter (internal)
- Existing buyers can enter a lucky draw to meet an artist of the month
- 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.
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:
- Premium art buyers can sign up to receive a newsletter with details of upcoming art shows, artists, and artworks
- All art buyers can choose one or more artworks listed in the newsletter and purchase them
- Smart recommendations for artworks to include in newsletter (internal)
- Existing buyers can enter a lucky draw to meet an artist of the month
- 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.
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:
- Premium art buyers can sign up to receive a newsletter with details of upcoming art shows, artists, and artworks
- All art buyers can choose one or more artworks listed in the newsletter and purchase them
- Smart recommendations for artworks to include in newsletter (internal)
- Existing buyers can enter a lucky draw to meet an artist of the month
- 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.
Until now, in the Impact Driven Product development cycle, we have arrived at a shared understanding of Key Business Outcomes and feature ideas that can help us to deliver value to our customers and maximize the impact on the KBOs. The next step is for us to identify what success means to us. For the kind of impact that we predict our feature idea to have on the KBOs, how do we ensure that every aspect of our business is aligned to enable that success? We may also need to make technical trade-offs to ensure that all effort on building the product is geared toward creating a satisfying end-to-end product experience.
When individual business functions take trade-off decisions in silo, we could end up creating a broken product experience or improvising the product experience where no improvement is required. For a business to be able to align on trade-offs that may need to be made on technology, it is important to communicate not just what is possible within business constraints but also what is not achievable. It is not necessary for the business to know or understand the specific best practices, coding practices, design patterns, and so on, that product engineering may apply. However, the business needs to know the value or the lack of value realization, of any investment that is made in terms of costs, effort, resources, and so on.
This chapter addresses the following topics:
- The need to have a shared view of what success means for a feature idea
- Defining the right kind of success criteria
- Creating a shared understanding of technical success criteria
"If you want to go quickly, go alone. If you want to go far, go together. We have to go far — quickly."Al Gore
Planning for success doesn't come naturally to many of us. Come to think of it, our heroes are always the people who averted failure or pulled us out of a crisis. We perceive success as 'not failing,' but when we set clear goals, failures don't seem that important. We can learn a thing or two about planning for success by observing how babies learn to walk. The trigger for walking starts with babies getting attracted to, say, some object or person that catches their fancy. They decide to act on the trigger, focusing their full attention on the goal of reaching what caught their fancy. They stumble, fall, and hurt themselves, but they will keep going after the goal. Their goal is not about walking. Walking is a means to reaching the shiny object or the person calling to them. So, they don't really see walking without falling as a measure of success. Of course, the really smart babies know to wail their way to getting the said shiny thing without lifting a toe.
Somewhere along the way, software development seems to have forgotten about shiny objects, and instead focused on how to walk without falling. In a way, this has led to an obsession with following processes without applying them to the context and writing perfect code, while disdaining and undervaluing supporting business practices. Although technology is a great enabler, it is not the end in itself. When applied in the context of running a business or creating social impact, technology cannot afford to operate as an isolated function. This is not to say that technologists don't care about impact. Of course, we do.
Technologists show a real passion for solving customer problems. They want their code to change lives, create impact, and add value. However, many technologists underestimate the importance of supporting business functions in delivering value. I have come across many developers who don't appreciate the value of marketing, sales, or support. In many cases, like the developer who spent a year perfecting his code without acquiring a single customer (refer to Chapter 2, Invest in Key Business Outcomes), they believe that beautiful code that solves the right problem is enough to make a business succeed. Nothing can be further from the truth.
Most of this type of thinking is the result of treating technology as an isolated function. There is a significant gap that exists between nontechnical folks and software engineers. On the one hand, nontechnical folks don't understand the possibilities, costs, and limitations of software technology. On the other hand, technologists don't value the need for supporting functions and communicate very little about the possibilities and limitations of technology. This expectation mismatch often leads to unrealistic goals and a widening gap between technology teams and the supporting functions. The result of this widening gap is often cracks opening in the end-to-end product experience for the customer, thereby resulting in a loss of business. Bridging this gap of expectation mismatch requires that technical teams and business functions communicate in the same language, but first they must communicate.
In order to set the right expectations for outcomes, we need the collective wisdom of the entire team. We need to define and agree upon what success means for each feature and to each business function. This will enable teams to set up the entire product experience for success. Setting specific, measurable, achievable, realistic, and time-bound (SMART) metrics can resolve this.
We cannot decouple our success criteria from the impact scores we arrived at earlier. So, let's refer back to the following table that we derived in Chapter 3, Identify the Solution and its Impact on Key Business Outcomes, for the ArtGalore digital art gallery:
The estimated impact rating was an indication of how much impact the business expected a feature idea to have on the Key Business Outcomes. If you recall, we rated this on a scale of 0 to 10. When the estimated impact of a Key Business Outcomes is less than five, then the success criteria for that feature is likely to be less ambitious. For example, the estimated impact of "existing buyers can enter a lucky draw to meet an artist of the month" toward generating revenue is zero. What this means is that we don't expect this feature idea to bring in any revenue for us or put in another way, revenue is not the measure of success for this feature idea. If any success criteria for generating revenue does come up for this feature idea, then there is a clear mismatch in terms of how we have prioritized the feature itself.
For any feature idea with an estimated impact of five or above, we need to get very specific about how to define and measure success. For instance, the feature idea "existing buyers can enter a lucky draw to meet an artist of the month" has an estimated impact rating of six towards engagement. This means that we expect an increase in engagement as a measure of success for this feature idea. Then, we need to define what "increase in engagement" means. My idea of "increase in engagement" can be very different from your idea of "increase in engagement." This is where being S.M.A.R.T. about our definition of success can be useful.
Success metrics are akin to user story acceptance criteria. Acceptance criteria define what conditions must be fulfilled by the software in order for us to sign off on the success of the user story. Acceptance criteria usually revolve around use cases and acceptable functional flows. Similarly, success criteria for feature ideas must define what indicators can tell us that the feature is delivering the expected impact on the KBO. Acceptance criteria also sometimes deal with NFRs (nonfunctional requirements). NFRs include performance, security, and reliability.
In many instances, nonfunctional requirements are treated as independent user stories. I also have seen many teams struggle with expressing the need for nonfunctional requirements from a customer's perspective. In the early days of writing user stories, the tendency for myself and most of my colleagues was to write NFRs from a system/application point of view. We would say, "this report must load in 20 seconds," or "in the event of a network failure, partial data must not be saved." These functional specifications didn't tell us how/why they were important for an end user. Writing user stories forces us to think about the user's perspective. For example, in my team we used to have interesting conversations about why a report needed to load within 20 seconds. This compelled us to think about how the user interacted with our software.
Some years ago, a friend of mine, who was working as part of a remote delivery team with little access to the real end users, narrated an interesting finding. Her team had been given a mandate to optimize report performance. One of her team members got an opportunity to travel to the location of some customers and observed how they used their software. The prime functionality of their software was to generate reports. The users would walk in at the beginning of the day, switch on their computers, launch the software, initiate a report, and step out for their morning coffee. The software took a good 15 minutes to generate a report! By the time the users had their coffee and had come back, the reports were ready. The customers had changed their habits to suit the software! The real question was how were we to react to this finding? Should we fix the reports to run faster? Should we leave them as is and focus on building other valuable functionality for the customers? Should this be a decision that technology must make in isolation?
It is not uncommon for visionary founders to throw out very ambitious goals for success. Having ambitious goals can have a positive impact in motivating teams to outperform. However, throwing lofty targets around, without having a plan for success, can be counter-productive. For instance, it's rather ambitious to say, "Our newsletter must be the first to publish artworks by all the popular artists in the country," or that "Our newsletter must become the benchmark for art curation." These are really inspiring words, but can mean nothing if we don't have a plan to get there.
I've heard many eager founders tell product engineers that their product should work like Facebook or Twitter or be as intuitive as Google. This expectation is there from the first version of the product! What do we do when the first release of a product is benchmarked against a product that took 10 years in the making and is a million iterations in? This is what I meant earlier when I mentioned expectation mismatch. It is important to get nontechnical stakeholders on board to meet the ambitious goals they prescribe to their teams. For instance, one of the things I do in ideation workshops is to not discount an ambitious (and impossible) goal such as the one stated earlier. I write it up as an outcome to achieve, and press for stakeholders to lay out their plans for how they intend to support making this happen. For example, at the level of responsiveness, performance, intuitiveness, and feature richness they expect from the product in its first release, we would need a sufficiently large user base and source of revenue to justify the costs/effort that go into building it. What is the business team's plan to source revenue in time for the first release? How do they plan to get the user base again in time for the first release?
Even when a product's technology is its main differentiator, other supporting business functions need to also come together in order to amplify the effectiveness of the technology. Successful products are a result of a lot of small things that come together to create impact.
The general rule of thumb for this part of product experience planning is that when we aim for an ambitious goal, we also sign up to making it happen. Defining success must be a collaborative exercise carried out by all stakeholders. This is the playing field for deciding where we can stretch our goals, and for everyone to agree on what we're signing up to, in order to set the product experience up for success.
For every feature idea we came up with in Chapter 3, Identify the Solution and its Impact on Key Business Outcomes, we can create feature cards that look like the following sample. This card indicates three aspects about what success means for this feature. We are asking these questions: what are we validating? When do we validate this? What Key Business Outcomes does it help us to validate?
The criteria for success demonstrates what the business anticipates as being a tangible outcome from a feature. It also demonstrates which business functions will support, own, and drive the execution of the feature. That's it! We've nailed it, right? Wrong.
Success metrics must be SMART, but how specific is the specific? The preceding success metric indicates that 80% of those who sign up for the monthly art catalog will enquire about at least one artwork. Now, 80% could mean 80 people, 800 people, or 8000 people, depending on whether we get 100 sign-ups, 1000, or 10,000, respectively!
We have defined what external (customer/market) metrics to look for, but we have not defined whether we can realistically achieve this goal, given our resources and capabilities. The question we need to ask is: are we (as a business) equipped to handle 8000 enquiries? Do we have the expertise, resources, and people to manage this? If we don't plan in advance and assign ownership, our goals can lead to a gap in the product experience. When we clarify this explicitly, each business function could make assumptions.
When we say 80% of folks will enquire about one artwork, the sales team is thinking that around 50 people will enquire. This is what the sales team at ArtGalore is probably equipped to handle. However, marketing is aiming for 750 people and the developers are planning for 1000 people. So, even if we can attract 1000 enquiries, sales can handle only 50 enquiries a month! If this is what we're equipped for today, then building anything more could be wasteful. We need to think about how we can ramp up the sales team to handle more requests. The idea of drilling into success metrics is to gauge whether we're equipped to handle our success. So, maybe our success metric should be that we expect to get about 100 sign-ups in the first three months and between 40-70 folks enquiring about artworks after they sign up. Alternatively, we can find a smart way to enable sales to handle higher sales volumes.
In Chapter 3, Identify the Solution and its Impact on Key Business Outcomes, we created user story maps that addressed how internal business functions tie in to the feature idea. We don't take an outside-in view alone. We also need to define metrics for our inside-out view. This means that to chart a product experience strategy for this feature idea, we need more than just the software product specs. Before we write up success metrics, we should be asking a whole truckload of questions that determine the before-and-after of the feature.
We need to ask the following questions:
- What will the monthly catalog showcase?
- How many curated art items will be showcased each month?
- What is the nature of the content that we should showcase? Just good high-quality images and text, or is there something more?
- Who will put together the catalog?
- How long must this person/team(s) spend to create this catalog?
- Where will we source the art for curation?
- Is there a specific date each month when the newsletter needs to go out?
- Why do we think 80% of those who sign up will enquire? Is it because of the exclusive nature of art? Is it because of the quality of presentation? Is it because of the timing? What's so special about our catalog?
- Who handles the incoming enquiries? Is there a number to call or is it via email?
- How long would we take to respond to enquiries?
- If we get 10,000 sign-ups and receive 8000 enquiries, are we equipped to handle these? Are these numbers too high? Can we still meet our response time if we hit those numbers?
- Would we still be happy if we got only 50% of folks who sign up enquiring? What if it's 30%? When would we throw away the idea of the catalog?
This is where the meat of feature success starts taking shape. We need a plan to uncover underlying assumptions and set ourselves up for success. It's very easy for folks to put out ambitious metrics without understanding the before-and-after of the work involved in meeting that metric. The intent of a strategy should be to set teams up for success, not for failure.
Often, ambitious goals are set without considering whether they are realistic and achievable or not. This is so detrimental that teams eventually resort to manipulating the metrics or misrepresenting them, playing the blame game, or hiding information. Sometimes teams try to meet these metrics by deprioritizing other stuff. Eventually, team morale, productivity, and delivery take a hit. Ambitious goals, without the required capacity, capability, and resources to deliver, are useless.
The following is a sample success metric for the same feature, now revised to include internal operational metrics, and who owns each metric:
In the preceding sample, there is one success metric (grayed out) that we cannot link to desired business outcomes. So, this deprioritizes those metrics automatically. While these goals may be desirable to achieve, they are not something we have invested in for the current plan. For instance, the goal of putting together content in less than two days is an operational metric, which has not been invested as a Key Business Outcomes. So, we can discard that from our list of metrics to validate. We can further refine this to indicate success metrics as follows:
Now, we have yet to decide whether this feature idea, shown in the preceding image fully or partially, will be part of a digital solution. This will be decided based on cost (time, effort, money, capabilities, and so on).
Every business function needs to align toward the Key Business Outcomes and conform to the constraints under which the business operates. In our example here, the deadline is for the business to launch this feature idea before the Big Art show. So, meeting timelines is already a necessary measure of success.
The other indicators of product technology measures could be quality, usability, response times, latency, reliability, data privacy, security, and so on. These are traditionally clubbed under NFRs (nonfunctional requirements). They are indicators of how the system has been designed or how the system operates, and are not really about user behavior. There is no aspect of a product that is nonfunctional or without a bearing on business outcomes. In that sense, nonfunctional requirements are a misnomer. NFRs are really technical success criteria. They are also a business stakeholder's decision, based on what outcomes the business wants to pursue.
In many time and budget-bound software projects, technical success criteria trade-offs happen without understanding the business context or thinking about the end-to-end product experience.
Let's take a couple of examples: our app's performance may be okay when handling 100 users, but it could take a hit when we get to 10,000 users. By then, the business has moved on to other priorities and the product isn't ready to make the leap.
We can also think about cases where a product was always meant to be launched in many languages, but the Minimum Viable Product was designed to target users of one language only. We want to expand to other countries, and there will be significant effort involved in enabling the product, and operations to scale and adapt to this. Also, the effort required to scale software to one new location is not the same as the effort required to scale that software to 10 new locations. This is true of operations as well, but that effort is more relatable since it has more to do with people, process, and operations. So, the business is ready to accept the effort needed to set up scalable processes, and hire, train, and retain people. The problem is that the expectations of the technology are so misplaced that the business assumes that the technology can scale with minimal investment and effort. The limitations of technology can be sometimes perceived as lack of skills/capability of the technology team.
This depends on how each team can communicate the impact of doing or not doing something today in terms of a cost tomorrow. What that means is that engineering may be able to create software that can scale to 5000 users with minimal effort, but in order to scale to 500,000 users, there's a different level of magnitude required. The frame of reference can be vastly skewed here. In the following figure, the increase in the number of users correlates to an increase in costs:
Let's consider a technology that is still in the realm of research, such as artificial intelligence, image recognition, or face recognition. With market-ready technology (where technology viability has been proven and can be applied to business use cases), in these domains, it may be possible to get to a 50% accuracy in image matching with some effort. Going from 50% to 80% would require an equal amount of effort as that which was needed to get to 50% accuracy. However, going from 80% to 90% accuracy would be way more complicated, and we would see a significant increase in costs and effort. Every 1% increase after 90% would be herculean, or just near impossible, given where the current technology is in that field. For instance, the number of variations in image quality that need to be considered could be a factor. The amount of blur, image compression quality, brightness, missing pixels in an image, and so on can impact the accuracy of results (https://arxiv.org/pdf/1710.01494.pdf). Face recognition from video footage brings in even more dimensions of complexity. The following figure is only for illustrative purposes and is not based on actual data:
Now, getting our heads around something like this is going to be hard. We tend to create an analogy with a simple application. However, it's hard to get an apple-to-apple comparison of the effort involved in creating software. The potential of software is in the possibilities it can create, but that's also a bane because now that the bar is set so high, anything that lowers our expectations can be interpreted as: "Maybe you're not working hard enough at this!"
Sometimes the technology isn't even ready for this business case, or this is the wrong technology for this use case, or we shouldn't even be building this when there are products that can do this for us. Facial recognition technology with a 50% accuracy may suit a noncritical use case, but when applied to use cases for identifying criminals, or missing people, the accuracy needs are higher. In an online ads start-up that was built to show ads based on the images in the website content that a user was browsing, the context of the images was also important. The algorithm to show ads based on celebrity images worked with an accuracy that was acceptable to the business. The problem was that in some cases, the news item was related to a tragedy regarding a celebrity or an event where a celebrity was involved in a scandal. Showing the ads without the context could impact the image of the brand. This could be a potential threat for the online ads start-up looking to get new business. With a limited amount of resources and with a highly-skewed ratio of technology costs/viability, it remains a business decision on whether or not investment in technology is worth the value of the business outcomes. This is why I'm making the case that outcomes need to justify technology success criteria.
There is a different approach needed when building solutions for meeting short-term benefits, compared to how we might build systems for long-term benefits. It is not possible to generalize and make a case that just because we build an application quickly, that it is likely to be full of defects or that it won't be secure. By contrast, just because we build a lot of robustness into an application, this does not mean that it will make the product sell better. There is a cost to building something, and there is also a cost to not building something and a cost to a rework. The cost will be justified based on the benefits we can reap, but it is important for product technology and business stakeholders to align on the loss or gain in terms of the end-to-end product experience because of the technical approach we are taking today.
In order to arrive at these decisions, the business does not really need to understand design patterns, coding practices, or the nuanced technology details. They need to know the viability to meet business outcomes. This viability is based on technology possibilities, constraints, effort, skills needed, resources (hardware and software), time, and other prerequisites. What we can expect and what we cannot expect must both be agreed upon. In every scope-related discussion, I have seen that there are better insights and conversations when we highlight what the business/customer does not get from this product release. When we only highlight what value they will get, the discussions tend to go toward improvising on that value. When the business realizes what it doesn't get, the discussions lean toward improvising the end-to-end product experience.
Should a business care that we wrote unit tests? Does the business care what design patterns we used or what language or software we used? We can have general guidelines for healthy and effective ways to follow best practices within our lines of work, but best practices don't define us, outcomes do.
In the nonprofit where I was leading the product team, we launched a self-service kiosk to approve loans for people from rural India, after they clear an assessment on basic financial concepts, which was also offered through the kiosk. The solution involved so many facets of complexity. It had to be multilingual (there are 22 languages spoken in India, and an even greater number of dialects) and work in a low internet bandwidth (including literacy education videos and assessments). Many of the target users were illiterate or semiliterate and had not actively used touchscreens.
In addition, we had to ensure that we could remotely monitor, maintain, and support our kiosk software since we had no people or budgets to afford any travel. We also had to worry about security, our devices being tampered with, and that the devices had to be installed in buildings without climate control. We used Aadhar biometric authentication for our users and there were fingerprint scanners, thermal printers, and iris scanners, along with an Android tablet that served as the kiosk. On top of this, we employed machine learning to approve loans for people from rural India.
With so many moving parts, we had to prioritize our product launch. If we had to take a call on this from an isolated technology perspective, we would call out a minimal viable product with support for one language using manual approvals for loans, targeting Tier II cities with better internet and so on. However, the business context was that the nonprofit was trying to change the ecosystem of micro and peer-to-peer financing in a market that was being grossly neglected or abused by mainstream players (https://www.rangde.org/swabhimaan). The success of the solution was in how the rural folks adopted the self-service model, and how the nonprofit could get a foothold in areas where mainstream players weren't willing to venture. Our Impact Driven Product included all of these technical success criteria stated earlier.
We mercilessly cut down on functional flows, simplified our designs without remorse, and put in a lot of effort in understanding and learning about our target users. The product had the support for multiple languages, remote monitoring and maintenance, hardware that could secure our devices, software that worked in low internet bandwidth, a user interface that included audio prompts in multiple languages, and a machine learning algorithm that focused on reasons to approve a loan rather than to find reasons not to. We built all this in four months and launched it in three rural villages in different parts of India.
This would have not been possible if we had not looked at an end-to-end experience, including operations, recording audio messages, finding hardware and device partners and advisors, and ensuring every moving part moved toward the same Key Business Outcomes—adoption and sustainable operations.
Success metrics discussions are the best forums for adding value, not just by communicating what's possible but also by bringing out the opportunity cost of not building something. Product engineering needs to own the 'how' of the product. In some cases, this means taking a longer-term view on core technology foundations. There isn't a real choice between building fast and building right; sometimes, we need to do both simultaneously.
We should stop viewing engineering as an isolated function that does what it's told to do. Today, implementation decisions are either being forced down by a business that doesn't understand tech possibilities or those decisions are being made in isolation by technology without understanding business context. We should also stop getting fixated on coding practices and processes or lamenting about being unable to refactor code. If quick-and-dirty code can amply meet business outcomes, then there is no reason for us to fix it. Similarly, if the core of a technology-driven product needs a lot more attention, then technologists should find the best way to meet business outcomes with the least wasteful effort. At the same time, they should be able to own, steer, and set the direction for the business outcomes through the most valuable interventions.
So, in our art marketplace example, we can think of a couple of metrics that can be owned by product technology. For instance, ease of sign up or thinking of a mobile-first experience.
In this chapter, we learned that before commencing on the development of any feature idea, there must be a consensus on what outcomes we are seeking to achieve. The success metrics should be our guideline for finding the smartest way to implement a feature. The conversations at the stage of defining the success metrics should enable a shared understanding of what success means, how we see all the parts coming together to meet the same Key Business Outcomes, and our limitations and possibilities. This is true of not just technical success criteria, but for every business function.
In the next chapter, we will figure out the smartest way to meet success metrics.
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
"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.
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
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.
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
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.
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).
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 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.
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!
