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.