Chapter 10. Eliminate Waste – Don't Build What We Can Buy

When arriving at a doable / not doable decision for a feature idea, product teams must not shy away for considering whether there is a need to build something at all. If there is an opportunity for teams to buy an existing solution or engage in a partnership with someone who offers a service/solution, we need to be open to considering that.

This decision of build versus buy versus partner versus nothing at all depends to a large extent upon how well our solution meets the needs of the customer and what our cost-impact comparison looks like.

This chapter addresses the following topics:

• Building what the customer values the most
• Feature black holes that eat up a team's time
• Parameters to consider to enable a build versus buy decision

Selling an idea

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." - Antoine de Saint-Exupéry

Sir Richard Branson once had to travel to the British Virgin Islands. The airline cancelled his flight because there weren't enough passengers. So, he hired a plane and wrote up on a blackboard the price of a one-way ticket to the British Virgin Islands. He went around selling tickets to the stranded passengers. This is how his airline business was launched.

Of course, it took much more investment, creativity, and business acumen to make a fully fledged airline business. However, selling tickets for the flight was the essential first step. To sell tickets, Sir Richard Branson didn't need to build his own plane. He didn't need elaborate props. A hired plane and a blackboard was enough. This was only because the sales proposition and the market need were compelling.

If we don't have a compelling solution to a market need, then it probably doesn't matter how well made our product is. Product building, therefore, needs to be as close as possible to market needs. We need to have a finger on the pulse of the market. We will explore more on this aspect in Chapter 11, Eliminate Waste – Data Versus Opinions. The metrics at this stage should drive what needs to be in the product.

Sales is one of the best ways to get a sense of what the customer is willing to pay for. It is a great way to arrive at our testable hypotheses. They tells us what is the most valuable part of the product that a customer is willing to pay for. Customer support, on the other hand, is our lens into adoption metrics. This tells us what the worst product experience is that a customer is willing to tolerate and still stay with us.

There is a reason strong enough for product teams (especially product managers) to get their hands dirty. They must sell and support the product. This does not mean that they accompany a sales person on a customer visit or look at customer support request queues. This calls for coming up with the sales pitch and driving a sales conversation with a potential customer. It also means supporting a customer when they raise issues with the product. It is this reality check that will ensure that the product teams keep their feet firmly on the ground.

Coming up with a sales pitch will help us find out what is the most compelling need of our customers. It will help us to identify which aspect of our product appeals to our customers and how our product excites or underwhelms them. It will help us to refine the value proposition to the very basics. Taking a founder's word, or a sales person's word, about what a customer wants isn't enough. We must get out of the building and find the answer for ourselves.

We also need to steel our hearts against finding out that our product isn't what our customers are willing to pay for. This insight is best derived when we haven't built much, so that a rework doesn't cost us or kill our business. Getting customer feedback early is the best part of selling. It is possible to sell without having a product. To sell, you just need a compelling solution to a pressing need. For eons now, religion had sold to us an idea that we can have a better afterlife if we pray and donate to religious causes. The afterlife isn't a product that exists. It exists only in our imagination (collective imagination, actually). Yet, so many people pray religiously and donate without question. Indeed, some amazing marketing and great influencers ensure that the idea of an afterlife is well propagated. It addresses a core emotional need for so many people; so much that they're willing to invest their time and money into a concept that has no evidence. Religion presents a compelling solution to what seems like a pressing need: we want to feel secure about what happens after death. After all, praying is a small investment to make in return for a great afterlife.

Without espousing, censuring, or condoning the strategy of religion, let's agree that selling an idea has been around for long enough now. Many months before my start-up was even set up, we had the chance to interact with many conference organizers, speakers, event sponsors, and regular conference attendees. We spent considerable time talking to every person in the events and conferences ecosystem. We tried to find out what problems they faced. What did they desire from a conference? How well did our product idea address their needs? We were able to glean patterns from the data that we had gathered by speaking to so many folks. Then, we spent a few days brainstorming about our end-to-end service design. We tried to figure out how our idea of a mobile app, that would serve as a digital agenda and networking and sponsorship medium, would fit into the ecosystem. The deciding factor for us was to figure out who was going to pay us for meeting their needs. Conference organizers and event sponsors were our biggest bets.

However, we had to test our hypothesis. So, instead of building a mobile app, we created a slick slide deck with wonderfully designed screens that highlighted the key features in the app. I'd like you to refer back to the discussion in Chapter 6, Manage the Scope of an Impact-Driven Product, about identifying the impactful product for a market where technology viability exists. In our case, the viability of building a mobile app already existed. What we had to test was whether event organizers would pay for such a solution, and, if so, how much they would be willing to pay; also, whether this amount would be enough to be a compelling proposition for us to pursue, to build a product at all. Our presentation deck had only well-designed screens of features, which we felt would get the conference organizers excited. We tried a combination of features and had different versions of the deck. We also came up with a baseline amount, which we thought the organizers would be willing to pay for such a product.

Armed with nothing but a flashy slide deck and glib talk, we set up meetings with potential customers. This deck and glib talk won us two customers who were ready to pay more than the baseline amount we had in mind. We learned an important lesson that there was a lot we could validate about our product without even having a product.

When we think of a service or a product, we tend to obsess about the service or product itself by asking: how do we improvise it? How do we make it stand apart from competitors? How do we make it appealing? What is the most impactful product to build?

What got you here won't get you there

Every stage of building a business demands a different maturity from the product. So, it would be futile to assume that we could always sell with a well-made slide deck and no real product to support it. However, the mindset about trying to gauge the pulse of the market before building anything is what we need to inculcate. How smartly can we figure out what our customers will pay for? Also, how can we figure out if we stop offering something, and will our customers continue to pay us?

At every stage of product building, we need to attempt to find the answers to both these questions, but our strategy to find these answers must evolve continually. For a well-matured product with a large customer base, it may not be possible to find out these answers merely by speaking to a few select customers (Chapter 11, Eliminate Waste – Data Versus Opinions, discusses the futility of doing this). However, we can introduce product feature teasers that can be rolled out to a large customer base and gather data from this. Pricing plans can be used to test which features or feature plans draw more interest from our target group.

In my start-up, we had, in fact, experimented with pricing quite a bit. In the early stages of product development, we didn't show our pricing plans on the website. We instead sent out customized product brochures to anyone who enquired on our website. This gave us ample leeway to try different combinations of features and different pricing sets. We also found out that our customers responded better when our price was not a round number. For instance, people responded better to a product priced as Rs. 67,700 rather than Rs 65,000. As we started getting repeat customers and referrals through customers, we figured out which pricing worked best. In the initial stages, we were talking only to small businesses and were dealing directly with the decision-makers. So, the impression that our pricing and product created on that individual mattered. However, when we started talking to bigger enterprise clients, some of these tactics didn't work. They had isolated teams that make product buying decisions, and we couldn't afford to be random in our pricing. We had to freeze on the pricing and feature bundles. We couldn't afford to waste time and experiment with pricing anymore. This is when we started to put up our pricing on the website.

Of course, these findings may have been quirky and unique to our product and market situation. Yet, the possibility that we could experiment with such aspects of the product excited us. The same mindset needs to be carried into what goes into our product at every stage of product building. Just because we have a larger customer base, it doesn't mean that we need to build a feature because we think it's useful for customers or because we feel it's a cool thing to build. Even when it is a feature that you need, you must ask if you really should build it. So if you're asking, "What should we build?", I'm going to respond with a counter question: "What would you rather not build?"

To build or not to build

Most teams tend to get carried away when seeing a product backlog that has features that offer a great opportunity to employ cool, cutting edge tech. Everyone wants to get their hands on it. It excites the team to go and build a product, even when there are so many products available on the market that can meet business needs quite well.

There are two broad categories of a product in terms of the value that it can produce. The feature can be an enabler or it can be a differentiator. We briefly discussed enablers and differentiators in Chapter 5, Identify the Impact-Driven Product. An enabler is something that can help to support the core business impact. The enabler by itself may not be core to the business, but it helps to deliver or measure business impact. A differentiator, in contrast, is the business itself. One or more core aspects of the business depend on the differentiator. This is what qualifies as the IP (intellectual property, which is the intangible value created from patents, copyright, or creativity) of a product. Without this differentiator (or secret sauce), your business has no edge over the competition. When a feature is easy to copy, then soon enough our competitors will follow suit. They will learn from our mistakes and gaps in product experience and offer better value to customers. After all, the second mouse gets the cheese.

Even enablers can give a competitive advantage to our business, purely by helping the business to respond or scale to market needs. For example, banks that undertake digital transformations are essentially looking at online banking solutions as enablers. Their core banking model hasn't changed, but they are looking at digital channels to enable their existing strength. Digital solutions help to improve customer experience and reach, while reducing the cost of operations. Mobile apps act as a channel for digital banking. They can give the first banks that adopt them, a competitive edge. The enabler acts as a differentiator for a while, but then, mobile apps are easy to replicate, and subsequent versions from competitors will improve upon user experience and customer impact.

In general, if our product feature is a differentiator, then it is best to build it in-house. This gives the business the maximum leverage of being able to shape up the product, giving us full control on what we offer and how we offer it. However, if our product feature is an enabler, then the first decision to make is whether there is an existing solution that we could leverage. The following are some of the aspects that we want to consider when evaluating an off-the-shelf solution:

• How well can it meet our needs?
• Can it deliver on all of our success criteria?
• Does it integrate well with the rest of our product?
• Does it meet our pricing needs?
• Does it have unreasonable maintenance overheads?
• Is it hard to on-board?

The chances are that if we look hard enough, there is usually a solution to be found. We need to ask these questions before we decide to build from scratch:

1. Is the feature a core differentiator for the business?
2. Are our functional flows processed as standard and can they be met by an off-the-shelf product?
3. Is it critical for this feature to be rolled out with our branding?
4. Do we have specific/unique legal, compliance, and regulatory requirements that cannot be fulfilled by an off-the-shelf product?
5. Does the commercial proposition work well for us?
6. Does it integrate well with the rest of the technology stack used in our core product?
7. Is it easy to purchase, set up, and get started with the off-the-shelf product?
8. Is there a model of support for the off-the-shelf product that can meet our needs?
9. Do we have a partner who can build this for us?
10. Do we have the time and people to provide the oversight needed in order ensure that we have the right product delivered?

Based on the answers to the preceding questions described, for a feature idea that is an enabler, we can generally interpret whether or not to build the feature from scratch:

This can serve as a guideline for deciding where to invest a product team's time.

Feature black holes that suck up a product team's time

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:

• How valuable is it for us to have this feature in our product?
• Is there a ready-made solution that can offer the same value? Should we then buy, rather than build?
• How damaging is it to not have this in our product?
• What would we rather build if not this? Is there something more valuable than this to which we should direct our time, mindshare, and resources?

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

Summary

In this chapter, we learned that not every feature idea in the product needs to be built from scratch. Pruning the product backlog requires that we remove every item that doesn't add value to the business. A perfect backlog is one which has nothing left to take away.

Now that we have a product backlog that is lean and has only the very bare necessity features, we can streamline our teams based on the nature of outcomes that the feature can deliver and the response time needed to deliver on a feature. We will review how to streamline our processes in the next chapter.