Even when product backlogs are groomed well, there is a type of donkey work or feature black hole that swallows up team time. This kind of grunt work slowly creeps in and before you know it, a significant amount of the team time gets sucked up into it. It could come in as requests from powerful folks in leadership. It could come as a result of frustration with operational tools. It even creeps in as spillovers from heavy processes. For instance, if every request for new hardware, infrastructure, stationery, and so on has to go through an elaborate approval process, then the amount of time the team spends just waiting on approvals to be processed can be a process waste. So, the teams may end up using suboptimal solutions to work around the approval rules.

Such feature black holes are nonenabler and nondifferentiator work, which serve only to assuage the structural and cultural needs of internal teams. For instance, when we're a co-located small team and when the product is in the early stages of development, we may start off by tracking customer support requests using simple sticky notes on a wall. The information and backlog are visible to everyone, and we can co-ordinate without the need of any digital tools.

However, when the product evolves, the customer base and the team expand, and the sticky notes on the wall won't suffice. We may need a digital solution that can handle incoming requests, prioritize them, assign requests to specific folks, and track them. We may easily find a popular tool in the market that can serve this need. When teams start building an internal solution to meet the customer support tracking needs, it becomes a feature black hole. There is no compelling reason for the team to build it other than their own prejudices or lack of awareness about existing solutions. Any amount of work spent on building such a feature is taking the team away from the goal of meeting key business outcomes. Even when the key business outcome of the business is about sustainability and reducing internal operational costs, we need to critically evaluate our impact scores, success metrics, and doable / not doable cost decisions to decide whether to build or buy.

Now, the limitation of a tool in the market (also a product) is that it works well for most cases across a broad spectrum of needs. So, expecting that an off-the-shelf tool will align to every quirky need of our business is neither reasonable nor practical. Naturally, there will be a learning curve or an adoption period, where we have to unlearn our existing ways of working and adapt to the ways of the new tool. I agree, in principle, that allowing a tool to dictate our ways of working doesn't sound very appealing.

On the other hand, building our own version of a support request tracking tool, that reaps us no business benefits, isn't the smartest usage of our time, is it? So, when should we invest time, mindshare, and resources into building anything? The answer is that only when what we build creates justifiable business impact or when it offers a value proposition to the customer that can differentiate our business or when no such product exists that will meet our needs should we consider building an enabler. We build something only if not building it would cause serious detriment to the product/business. This is a need that must be justified to invest in as a key business outcome. To go back to our example, is the value proposition so compelling that the business wants to invest in building a customized ticketing system that meets our internal needs?

It is also natural that we may outgrow the potential of an off-the-shelf solution. Transitioning to another solution will come with its own cost. We may also discover that there exists no solution in the market that addresses our specific needs. Off-the-shelf products may not meet our pricing criteria or our scale. Such instances make a great case for evaluating whether this niche compelling internal needs or problems can give rise to a new line of products that we can create. Would this product even have a long-term impact and serve as a secondary channel of revenue? Can such a need become a differentiator for us?

If we arrive at such a compelling pitch, it makes absolute sense to pursue this. For instance, Amazon's AWS services today has a $10 trillion run rate and overshadows the e-commerce business of Amazon. Amazon Web Services (AWS) started as a by-product when trying to meet the specific scaling needs of Amazon's e-commerce business. The internal teams created a common set of infrastructure services to meet the scaling needs. These services laid the foundation of today's AWS. Amazon had a compelling solution to a problem that a lot of other companies were facing and they were all probably trying to build their own solutions to address their needs. Amazon saw the opportunity to make this a compelling business proposition too.

However, nonenabler and nondifferentiator work is also not to be confused with research or innovation. Exploring technology possibilities, building proofs of concepts, and finding innovative ways to deliver value, which cannot be addressed by off-the-shelf solutions (or even custom-built solutions), are the pure value that a technology team can offer to the product. They are essentially experiments into which a business is willing to invest. This is akin to the car makers devoting a lifetime to the innovations around internal combustion engines (as we saw in Chapter 6, Manage the Scope of an Impact-Driven Product). We cannot put a timeline to research and development. Unlike building products that have a proven technology viability, research cannot be a time-bound activity, or have specifications for meeting Key Business Outcomes. It cannot be part of the core product building team's focus. On the other hand, for building an Impact Driven Product, it is of utmost importance to ensure that the product team channels all of its energies only toward what can maximize the impact.

Every product manager needs to keep asking these questions:

The following flowchart is a quick reference for taking a build versus buy versus not to build: