5 Myths Driving a Build vs Buy Decision

O k “myths” might have been clickbaity…really, we’re talking about assumptions which have truth to them, but ultimately don’t always lend themselves to the best outcomes.

New Market, Growing Pressure

The need for data-driven audience insights is relatively new to the online video market, but it is exploding now, thanks to shifting consumer attention and spending. This has placed some urgency on this new category of business intelligence as it has quickly elevated in strategic importance within media companies. Given the recent nascence in this arena and the attendant lack of established incumbent vendors, it is not surprising that internal teams are working through build versus buy decisions that typically tilt towards leveraging third-party purpose-built products and services in more mature markets.

Below are some of the most common assumptions we hear expressed by teams who are leaning towards building internally, which in this case means pulling together multiple products and technologies to create a solution. All of them have merit, but there are reasonable, market-tested counter-arguments for each and we hope that the conclusion is clear: leveraging more comprehensive products will deliver better ROI and free up internal teams to pursue unique challenges.

1 – We Need Total Roadmap Control

This tends to be about flexibility and changing priorities, which are hallmarks of life in emerging markets. Internal teams want the ability to turn on a dime and place a lot of emphasis on this capacity. This is an alluring proposition, but it often does not deliver on its promise. The main reason for this is that priorities shift pretty constantly, and urgency often trumps importance, especially when there is only one customer for a product. This is an expensive way to develop software solutions, because of the inefficiency introduced by shifting priorities.

A market-driven software development approach can be much more efficient, and effective if responsiveness and predictability are well-balanced. This depends on the idea that customers are afforded influence on the roadmap. At Wicket Labs, we have committed to this concept. We believe in presenting a strong point of view through our product roadmap that reflects market responsiveness while leaving room for our customers’ needs. Our job is to transform specific requirements into solutions that will work for the market. By adopting our product, customers are giving up total roadmap control in exchange for a rapidly evolving product that has a significant baseline of functionality, and flexibility to address new requirements.

Historically this kind of trade-off works great in mature markets, and our job is to make it work in an emerging one. This, of course, takes trust, and the founders of Wicket Labs have a long track record of delivering this exact sort of balance to the same market that we are serving now. This alignment is made possible because of our market focus. We are not providing generic solutions that require modification to meet specific market needs. Instead, we are focused on meeting the needs of a specific market – online video.

2 – We Need to Own the Intellectual Property

We hear this refrain most often when software and data that is created/stored by that software are conflated together. These need to be separated to look at this logically. There is no doubt that data should be owned by our customers. We add value by ingesting, and harmonizing data from many sources, and are clear in our contracts and practices that accessibility to and ownership of data benefits our customers. With respect to owning the software, this is an outdated philosophy as long as there is good roadmap alignment.

Sometimes this mentality comes down to a company believing that they can develop a competitive advantage that they want to protect. In truth, it is rare that this happens through the tools that a company employs, and more about how they use these tools.

Finally, there can be tangible benefits to utilizing a multi-tenant product, beyond the economies of scale that keep pricing reasonable. The first is that advanced models for key metrics like lifetime value and churn, that better reflect the future revenue of each customer cohorts, can be employed. The second is that machine learning can leverage intelligence gained from running against each customer’s data set and improve the overall model for all customers.

3 – Our Needs are Unique

At first glance, this is often true. There are almost always aspects of a business that are different than their peers. But in reality, this usually accounts for less than 10% of the overall requirements. Most video businesses have the same basic financial, engagement, and reporting mechanics.

All businesses have slight variations in how they do things, but good product teams (like ours!) account for this as they gather requirements from their customer base and define new features to address them. For truly unique requirements that are not addressed through our Wicket Scorecard, we make sure to expose our customers’ data to them in an accessible way that lends itself to inquiry and visualization. This approach creates high leverage for all the functional requirements that can be resolved into product features and flexibility for the areas where that isn’t practical.

4 – It is Cheaper/Faster to Build than to Buy

The underlying assumption here is that an internal team will only build exactly what is needed, nothing less, nothing more and that focus will deliver more quickly and/or less expensively than paying to use a product. This view has two flaws that often crop up over time.

First, software products are priced based on the assumption that the development cost will be amortized across many customers. This justifies bigger investments in the development of the software and informs the roadmap with many more inputs. This generally means a bigger development team, with a broader set of requirements. While this can seem like a less efficient path than building internally at first, it’s hard to argue that building is less expensive in the long run, and over time it trends towards being less efficient.

The reason for this is that internal build projects often fail to contemplate the total cost of ownership, which needs to include maintenance, ongoing roadmap requests, and eventually re-factoring as technology ages. These are all built into the models of software companies and again amortized across many customers.

5 – This is too strategic to outsource

This is perhaps the most compelling argument for building internally, in that it speaks to building up native capabilities in an arena that will have definite impacts on business success. We actually agree that building up internal expertise makes sense, but as you can tell, we’d argue that building internal products does not. The difference is important. By leveraging commercial products, internal teams are freed up to move past the development and maintenance of all the industry standard insights that a product can provide, and instead focus in on the unique questions and challenges faced by every company in the very dynamic and competitive OTT market.

Final Thoughts

Building new stuff is fun and when the results are mission-critical, it’s easy to see why some companies lean in this direction. At Wicket Labs, we believe our job is to build a product that actually frees up internal teams to work on more interesting challenges, by automating the ingest and harmonization of data and presenting a really well-curated scorecard that is always up-to-date and actionable. So instead of chasing down data sources, running queries for marketing, and building reports over and over again for executives, data teams can actually go find the answers to the unique, complicated questions facing their business. It’s a win/win scenario for all.

 

Tags: