Chapter 6. Build Versus Buy

All startup growth teams are tasked with trying to acquire more new customers and growing revenues while consuming the least amount of resources. The benefit of being a startup today is that there are more robust off-the-shelf SaaS growth stack tools available to leverage to help successfully acquire, engage, retain, and monetize customers.

All startups will face the same dilemma around whether to build or buy an intelligent machine. This is an important decision for businesses of all sizes, but especially startups because they are by definition so very resource constrained. Making the wrong decision could have severe consequences to the long-term success—or even viability—of the business.

The first step is for the growth team to work with their product team to create a product requirements document—commonly referred to as a PRD—that clearly articulates all the requirements and provides a strong business case for their desire to integrate an “intelligent machine” into the product road map. This is an important document because it allows people to understand what the product should do and win internal support for the project to be prioritized. Here is a list of the typical components to include in your PRD:

  • Purpose and scope of the project from a business and technical perspective

  • Projected assumptions on the key metrics of the business (e.g., 10% lift in ROI)

  • Typical use cases on how this would help the growth team

  • Constraints (budget, time, development resource availability and expertise)

  • Any dependencies

  • High-level workflow plans, timelines, and milestones

  • Evaluation plan and performance metrics

  • Requirements would fall under:

    • Functional requirements (e.g., what the product should do)

    • Usability requirements (e.g., how the product would be used)

    • Technical requirements (e.g., data, security, network, integration, etc.)

    • Support requirements (e.g., what resources are needed to support the product)

    • Interaction requirements (e.g., how the product should work with other systems)

A PRD should be created by the growth team in close collaboration with the product team to ensure it has the right level of business and technical details. The key to success for any AI project is to get executive support early in the process and have them champion this from the top down to ensure all the teams are aligned and excited to support this cross-functionally.

Once a PRD is developed, then the next step is to share broadly with the different technical key stakeholders (e.g., data and engineering teams) who need to work together to determine the amount of time, money, skill sets, and research needed to make an educated recommendation to compare the options of whether to move forward with the build or buy. These teams are tasked with figuring out the right path that reconciles their company’s immediate needs with their strategy for long-term scalability. Each startup has different strengths and weaknesses based on their internal resources and bandwidth, so there is no universal answer to this question that can apply to all startups. This chapter will introduce you to the framework for build versus buy as well as the pros and cons to bear in mind as you are making these decisions.

Build Versus Buy Analysis

In this section, we’ll walk through the steps for analyzing whether building or buying is right for your startup.

The Problem

The first step is to clearly define the problem you are attempting to solve. Is this a common problem, or a unique one facing your company specifically?

For example, developing ways to get smarter in acquiring new customers is a common problem, but most startups don’t currently leverage an AI intelligent machine to solve this problem. The most common approach is to hire more user acquisition managers, consultants, and/or agencies so more humans can analyze the data and optimize the campaigns. This can be an expensive, high-risk proposition.

It’s always good to first look at how other startups are trying to solve the problem—are there any external third-party solutions you can leverage? If it’s a problem specific to your startup, you may have trouble finding an existing workable solution. Even if the problem is already well addressed, it’s possible your business needs fall closer to edge cases not encompassed by the products currently on the market, which could be an argument for the decision to build.

At most startups, building an AI intelligent machine isn’t a good option because they don’t have the dedicated resources available to build and support a complicated AI project of this magnitude. Most startups have a limited number of technical and data resources and need to focus on their own core products. The best viable option is to find a SaaS partner who has the solution and resources to solve this problem.

IMVU decided to partner with Nectar9 and their Athena Prime platform. Nectar9 is an AI-focused startup that was working on building an AI intelligent machine SaaS platform for growth teams, but it faced a common conundrum of startups in the AI field: Nectar9 didn’t have access to the volumes of test data to perfect the potential for it to work at scale across all the main paid media channels.

This is where IMVU collaborating with Nectar9 became a win/win partnership. We had a significant user acquisition budget and were spending a lot of money across all the main media channels (Google, Facebook, Programmatic, Apple Search, and others) in our customer acquisition efforts. This generated the data at scale to experiment with and train the Athena Prime AI machine. By offering up our existing campaign data, we gained the ability to influence Nectar9’s product road map and help them figure out how to tune Athena Prime to work for the IMVU growth team and their customers beyond IMVU.

The Budget

The next concern is budget. Do you have the necessary funds to see this project through to completion as well as extra resources in case you go over budget? Most startups do not have a big budget to invest into building their in-house AI capabilities. This is why it can often be easier to justify a monthly recurring payment or even an annual expense for a third-party SaaS product.

A good analogy to use is the decision to buy or rent a home. If you do not have the necessary funds to make a down payment on a house, then it becomes necessary to rent, even if the rental fee is equivalent to what the mortgage payment would be. When deciding if you should build a solution to your problem, the budget must include the long-term technical debt (mortgage) associated with hosting and maintaining your solution, in addition to the up-front costs (down payment).

The Timeline

The next consideration is the time horizon. Is your problem a threat to the survival of your startup or just a nagging annoyance that could be improved? What is the impact to your startup if this problem isn’t solved soon? You must consider whether or not the problem will compromise the performance of the business. If you need a solution now, it can be an easy decision. Is there a solution in existence? If yes, buy it. If no, then, well…you’re going to have to build it as soon as possible.

There are risks awaiting you at every turn as you navigate this framework and ultimately make the final decision to build or buy. Let’s discuss some of these risks so you can make the most informed decision possible.

Risks of Building an AI Solution

The end goal in building an AI intelligent machine is to help your growth team to make smarter data-driven decisions on the right optimization levers to pull to efficiently spend your budgets and resources to help accelerate growth. Some of the risks of building your own software solutions boil down to opportunity cost, quality concerns, and technical debt, among others. Here are the main ones to keep in mind:

Is marketing AI your core competency?

Most startups are not set up to have marketing AI as their core competency unless that is their main product focus. There are high costs to support AI—building teams of data scientists and machine learning engineers, building data infrastructures, and maintaining all of these resources. The reality is that you need your internal resources to focus on developing and supporting the unique product capabilities that you offer. Building an AI solution is a huge undertaking even with the right internal resources in place to support this project. Companies that build out of their circle of competence risk building inferior products compared to companies dedicated to solving the problem.

How often will it need to be updated?

The ability to dedicate resources to maintain and manage your AI project is very important because the machine learning needs oversight to ensure the right data is going in. The algorithms need to be validated to confirm they are making the right decisions to help you acquire new customers cost effectively. This isn’t going to be something you build once and never touch (as if that ever happens). It’s going to need constant updating—further taking time away from your core product development. Is it worth it? This is generally the big challenge with trying to prioritize in-house resources to maintain an AI project that isn’t the top priority for the business and getting in-house technical resources excited about maintaining it. One thing you are guaranteed is that the AI space will continue to evolve rapidly with constant innovation that will require having a team of experts dedicated to staying on top of all the research and best practices to ensure you don’t get left behind. Therefore, investing into resources in-house or externally to leverage all this knowledge to train and customize models to continue to give your startup the competitive edge is invaluable to getting the most value out of AI.

What is the opportunity cost?

The trade-off in any startup is the opportunity cost of resources being deployed to support Project A compared to Project B while considering the timeframe of either project being deployed. An example would be the costs in time and money of employees (data scientists, engineers, quality assurance, etc.) building and maintaining an AI project versus leveraging those resources to work on something else like improving your core product user experience (which is most likely the reason they joined your startup). Your decision to build may be to the detriment of other projects that will likely hurt morale and postpone any major technological breakthroughs with lost productivity. Another cost to factor in is any delays in the deployment of an AI solution (including the necessary machine learning training) that would result in your growth team not spending their budget as efficiently as possible. Taking time to think considerably about how the pricing structure of an off-the-shelf solution compares to a custom solution when considering organizational growth will allow the most effective, responsible, and successful decision making.

Technical debt

This is a common concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution. Technical debt can be taken on intentionally when a quick fix is not the ideal solution but necessary given the timeline and budget. Other times technical debt is the result of poor planning and architecture. The long-term costs associated with building and maintaining an AI solution internally can lead to expensive issues down the road with quality, performance, lost time, and money. This is bad because technical debt is one of the largest and most impactful issues affecting software development today with startups under pressure to deliver projects on time.

No economies of scale

Are you disadvantaged when it comes to sourcing tools that contribute to the AI build? Unanticipated expenses such as server fees and monthly database charges as well as hiring talent like data scientists and engineers could be a huge risk of building. Companies that service many customers are able to distribute the costs of software operations and maintenance evenly across their clients. These economies of scale can allow them to charge less for a product or service than you would be able to achieve by building it yourself. If a third party’s economies of scale and other factors put your build at a disadvantage you may strongly consider the option to buy, but not before evaluating the risks associated with buying. It’s important to look at the long-term ROI on this project that factors in the economies of scale.

Risks of Buying an AI Solution

Most AI solution partners will offer a free-trial or proof-of-concept (POC) period to give you the ability to evaluate their capabilities with your data. Before moving forward with a trial, demo, or quote, review some of the surface-level risks of buying a software solution versus building one yourself (you need to do a thorough job on the due diligence process to mitigate these risks):

Forfeiture of data

One important consideration to make when buying a software solution from a third party is data. In today’s ecosystem of privacy concerns and regulations, it’s more important than ever to ask: how will this third party use your proprietary data? Does this mean you lose access and oversight to important customer data and other business insights? It’s important to be aware that any AI partner would need access to your first-party data to help the AI be successful and you want to ensure they are fully compliant with all data privacy regulations to avoid any major issues down the road.

Security risks

Can this third party be trusted? Are they using cybersecurity best practices? Enterprise-level software companies are the targets (and often victims) of large-scale cyber-attacks leading to millions of compromised accounts. Even with security best practices, breaches do happen and it’s worth extra consideration before willingly bringing the Trojan horse into your castle walls.

Not a thorough solution

Another risk of buying software from an external supplier is whether or not their solution adequately solves your company’s problem. Let’s assume many companies face the same problem and the marketplace is saturated with options to choose from. It’s possible your particular use case has not been identified by these third parties. Some companies may be open to customer feedback about future features but if your problem is limited to your niche, it’s unlikely the company will see your problem as a worthy addition.

Exposure to partner’s market risk

It’s important to fully vet any AI solution partner you consider working with on their ability to weather a market downturn or other external factors that may impact the health of their business. For example, if you work with an AI startup that isn’t well funded then it faces a strong risk of going out of business and/or getting acquired, which could negatively impact your business.

Machine Learning as a Service

Another option to consider is what’s become known as Machine Learning as a Service (MLaaS).1 This is an umbrella definition encompassing various cloud-based platforms that cover most infrastructure issues such as data pre-processing, model training, and model evaluation, with further prediction. Amazon Machine Learning services, Azure Machine Learning, Google Cloud AI, and IBM Watson are four leading cloud MLaaS services that allow for fast model training and deployment. All of these solutions have pros and cons that differ in terms of algorithm performance as well as required skill sets and tasks to manage them, but they all require engineering resources to bring to bear on business challenges. None of these are going to fully match all your business needs and compromises need to be considered when working with them; they’ll need to be customized to meet your specific requirements.

MLaaS is only feasible if you already have access to an in-house data science team. In my experience, this is challenging because most startups can’t afford to build an in-house data science team, as these highly compensated and skilled employees are very expensive to hire and retain, especially with big technology companies like Facebook and Google competing aggressively for this type of talent.

Build or Buy…or Both?

There is an alternative to the build or buy dilemma: do both if you have some complicated niche use cases.

That’s right—do both. If you need a solution fast and there exists an external solution that would suffice, even if it does not meet 100% of your needs, consider whether it makes sense to pay the premium until your dedicated solution is built for your specific complicated niche use cases. This option depends on favorable factors such as adequate budget, time horizon, and more. For example, you must consider whether the software is a subscription-based model and the terms surrounding contract duration and cancellation. You should also consider discussing your problem with the external vendor to determine if there are already plans on their product road map to meet 100% of your needs. In that case, you can reevaluate the decision to build.

The goal in startups is to minimize cost now and cost later. Therefore, the deciding factor is delivering something of value that your growth team can leverage to start generating revenue from it. Buy if it enables you to start generating revenue sooner. Build it if it enables you to start generating revenue sooner if you have the resources to do it successfully. Once you’ve built it and validated that it delivers the expected benefits, you can optimize by replacing whatever parts you need with bought or built components until there’s no more benefit to optimizing further.

Investing in building an infrastructure for your company can be the right decision for the long term if you have complicated niche use cases as you scale and the economics of your AI solution become more favorable. When you buy software from a third party, it’s possible the pricing model does not scale quite as linearly. On the other hand, sometimes buying from a third party turns out to be the right decision in the long term. When you consider buying it’s important to fully understand whether it is capable of solving your unique problems.

Weighing It All Out

When it comes down to it, the risks, costs, and distraction factor of building intelligent, AI-powered marketing automation into your product road map will not likely outweigh the benefits of working with a SaaS partner. In addition, a partner providing an off-the-shelf solution likely has the benefit of working with and incorporating feedback and ideas from other customers that you may not have considered or explored. While there are clearly some cases where your product or business model may demand a proprietary solution, chances are you’re able to get farther faster by carefully choosing a capable partner to power your intelligent marketing automation efforts.

Regardless of your decision, you’ll still need a solid understanding of the business inputs necessary for properly instrumenting your intelligent machine. Let’s dig deeper in the next chapter.

1 “Comparing Machine Learning as a Service,” AltexSoft (blog), September 27, 2019. https://oreil.ly/SgjlO.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.224.31.41