Build, buy…or rent? How to effectively execute on product strategy using all available options.
Background
“Build vs Buy” is one of the most written about business concepts out there with plenty of convergence on the key tenets including (but not limited to):
Build what’s core to your competitive advantage
Buy when you need something complex, mature, and in a very different field than your core
Buying is “usually” faster” than building
I think there is a lot of potential benefit for product leadership to consider a less-discussed 3rd option, “renting”, to the list, and break out the full spread of options to a more granular list when dealing in a SaaS environment:
Build
In house
Outsource (contractors or full service shop)
Buy
Acquire - either buy the whole business or rights to use such that you have no on-going relationship with the original owner
Rent
OEM, whitelabel, etc - you use some portion or all of another’s offering as part of your own, but the other company maintains control and ownership.
The rise of SaaS delivery models and subscription businesses have made it more important for product managers to consider all available options when making key decisions about how to deliver on the components of their product strategy. Specifically, the cost of acquiring new customers and the dynamics of having a growing renewal base over time make it more compelling to add more to the offering and get a higher share of wallet out of your existing customers to both drive revenue growth and increase lock-in. The value of getting more customers earlier or retaining existing ones may make time to market a larger consideration if the opportunity is right in front of you.
Where are you going?
Before we get too far into the weeds on which approaches work in which situations, it’s important to say up front how key it is to have a stable product strategy that is well informed by customer insights. Pretty much all decisions at this level have the potential to either drive meaningful new revenue or completely distract half the business for several years. Pick a framework, personally I like this one, and make sure you’ve got a roughly 1-2 year sequence of how you want to get from where you are to the “end state” in the strategy.
Looking at strategy and the elements you need to achieve you can start to look at the elements through a few filters:
What’s core to our differentiation and what’s table stakes to participate in the market?
Does the value of delivering on a particular element diminish if we are “late” in delivering this capability vs the competition?
What’s complicated and hard to replicate vs what is simple and straightforward?
What can we accomplish with current (and projected) staffing? What is going to require incremental staffing? How early do we need to hire to hit the rough timing?
With a good handle on what’s important and why on the path to achieving your product strategy, you can then figure out the range of options and contingencies necessary for each item.
It’s Really “Build or Buy” vs “Build vs Rent”
The first big fork in the decision tree is to figure out how critical it is to own and control whatever it is you are talking about. It’s not really build vs buy yet, so much as build/buy vs rent. If you build it you own it, but that is also true if you acquire it. So for the sake of simplicity I’m going to say “buy” = “acquire.” If the capability is going to be key to your long term growth and differentiation the decision should really be between building vs acquiring. If you know enough to say it’s critical, you’re only debating how you end up owning it.
Now that it’s squarely “build vs buy'“ but either way with the goal of ownership, then I would say lean on the existing content that is out there and lay out all of the considerations. Do you staff up ahead of a big build out. Hire a contract team to start now in parallel while you hire? Buy a smaller company focused on this one thing? There’s never a perfect answer, but it starts to tighten in around a few factors including ROI, time to market, and suitable options (for acquisition targets).
If it’s something you’ve determined is needed but not a core part of your long term success or a differentiator, you still have the option to build, but the alternative should be versus renting. Frame the decision as what is the highest return and lowest-impact way to achieve the outcome you’re looking for. The hard part is doing the framing to appropriately capture the full costs of either path, which we will discuss more in a moment.
What is “renting” and when is it the right thing to consider?
If you’ve decided you need something but you don’t need to own and control it to achieve your goals, that opens up your options to what I call “renting,” which includes:
License agreements / OEM
Revenue sharing agreements
Co-Marketing / Marketing Bundle Solutions*
In short you don’t own the thing, you may have some control over the roadmap (usually not as much as you’d like) and you are entering into a long-term agreement with another company to maintain this connection between your two products. You are buying access rights to someone else’s property for you and your customers. OEM and license agreements are typically for software “parts,” which an be anything from actual source to machine instances, to executables (in the ancient times). Revenue sharing agreements are more common when you are renting a complete product, especially when you are charging incrementally for the capability. I include Co-marketing and Marketing bundles for completeness, but the asterisk is there to suggest it’s not the same as the other two. There are lots of cute terms to describe “selling two completely separate things as at the same time to make it look like a complete solution.” This a completely valid approach when two companies actually need each other to completely meet the user’s needs. Think of Microsoft Windows and PCs before Microsoft was building their own. This can work in SaaS too, and it can be a safer way to test your way into a deeper integration. Can we sell the combined story and do people find that compelling? If not, then integrating the experience won’t fix that.
I want to highlight renting as it can be a way to break a logjam for companies who think the answer always has to be build or buy (usually always build). Renting is less “final” than building and buying, and while not always easy, it should have less sunk cost or real cost to untangle than a build or acquire path. Time and focus are precious and don’t divide evenly - there’s always overhead. Building can take a long time, especially if you are not presently staffed for it. It’s too tempting to try to build too much that is simply not critical to your long term success because it looks easy. Acquisitions can be great, but also have a long and intricate integration period for years following the deal. Integrating well to realize the value takes A LOT of effort from the entire company, and away from something else they would be doing so it has to be worth the distraction factor. It’s critical to keep your internal resources pointed at the stuff that really matters. It’s tough to get there mentally sometimes, but once you acknowledge the rental option, decisions that have been stuck ping ponging between build and buy may be able to move forward much more quickly.
What Problem are you Solving?
Let’s say you want to add a particular feature to your existing SaaS offering that will be one of 5 major capabilities. You started with one and over time built out the next three. You don’t charge for each one individually, they are all included in the same plan and this fifth one is a top request and the lack of it is leading to some churn at renewal time. Many other companies that you don’t directly compete with offer this same capability. Given the the “commodity” status you didn’t focus on it as it wasn’t key to building your advantage, but now it’s hard to look like a complete solution to the customer because they have to go get this common thing from someone else.
What kinds of features fall into this “needed but not core” category. A helpful guide is the Kano model for assessing capabilities and customer needs. Attractive qualities are the delighters, the likely source of some of your competitive advantage (assuming it’s the product and not service or some other element). Must-be qualities are “table stakes,” and without them your product is considered incomplete. One-dimensional qualities have a linear “the more you do the more credit you get” feel about them. If the pictures upload 20% faster, customer are 20% more satisfied, and the same in reverse. As long as they can upload and you’re above some minimum, “how much” is a tradeoff. Good rental opportunities are for increasing the one-dimensional aspects to give yourself an edge where it may not be cost effective for you to go beyond what you’ve already done on your own (or are willing to), and for “new” must-be qualities. New Must-Bes can pop up in a couple ways, but most commonly the market moves and suddenly there are more basic expectations that are needed to stay relevant, but as everyone has them, they are not necessarily worth owning. The other common situation is if your product set expands from an initially narrow focus to a broader set of capabilities. Suddenly entering a new problem space is not so far away, but to actually enter there are some new basic requirements that you never addressed.
Assuming you’ve been doing customer discovery well and have a good sense of what a solid solution should include, then you can do a gap analysis with where you are currently.
Do you have some elements of what’s required already built or are you starting from scratch?
Does this require technology or IP that you have no experience with?
Is it a feature that others offer as part of their core and you are offering it as a filler? How mature is this offering in the other places? Are you building v1 of something that everyone else has as a v5?
How urgently do you need to address this? Do you have time to build something out or do you need this solved in a very short period of time?
Based on your answers to the questions above, you can look at the menu of available rental options that best suit your needs:
Code - Source / library
Service - API
Feature - Whitelabel
Product - Whitelabel / co-market
Business - Lead sharing, acquisition
Let’s say for the example of adding a 5th offering to our SaaS lineup, we assess that:
“We are starting from scratch, and while it’s not technically complicated, it would take a PM, a UXD, and 4 devs roughly six months to get to a place where we could roll out some early version. As an alternative, 2-3 companies offer something today that is more fully featured than what we’d ever need and could likely build in 2 years.”
Again, with the assumption that this capability is something you need to maintain the value of the platform but is not core to your differentiation, renting in this case gets you a few things:
Product & Engineering Discovery - you’re eliminating the risk of “figuring out the right way to do it” both from a user and technical perspective. Whatever estimate you have for building is probably missing some amount of iteration required to get it right. Renting a mature offering will dramatically reduce if not eliminate discovery risk that may not be captured in your estimates.
Might be cheaper or faster time to market (might not be) - Depending on what you are renting the one-time integration costs can vary widely. Connecting to a well defined API to be able to automate picture upload, cleanup, and cropping probably requires a lot less development work and little to no UX changes over the “Upload” button currently in place. This would obviously be a lot faster and cheaper than building your own image recognition software if you are in a completely different industry. On the flip side, if the only way to get access to the feature is to effectively connect your SaaS product to another’s, rebrand their solution, hide certain capabilities, and figure out authentication, data and privacy sharing concerns, etc might end up taking just as long as building internally and cost the same.
Cheaper over the lifecycle - do the math, but the cost of building eventually flips to owning and maintaining. Can you structure a licensing deal that is cheaper than having that team of 3 own this forever? Even in the case above where we had to join another SaaS product to ours to get access to a feature, it didn’t save time or money to get to the starting line, but it might still be cheaper than maintaining an internal team focused on something that is not core to your business. If it’s not core, it will also be the first team to get hit when resources are tight. It may be safer to not create an unmaintained zombie.
What’s the Catch?
Renting can offer a useful 3rd alternative to build vs buy, but it also can come with its own unique set of challenges. It’s not an easy button by any means, and while it may end up being the best option, it can still be risky. As you are looking at rental partners, here’s a few things to consider:
Business health and stability - smaller partners mean you probably have more leverage and can get better terms, but that also means they are potentially less stable businesses and could potentially be sold
Change of Control Considerations - jumping off from the last point, this can be a big thing you want to consider. You can usually only get these terms in the contract with smaller companies but it’s not uncommon to have a clause that specifies what happens to the agreement in the event of an acquisition or change of control. These types of clauses can also be nasty surprises for acquirers, potentially leading them to drop the price of the deal so it’s no surprise that these are hard to get included. Negotiate for something, if even just a six month grace period to exit.
Do they have other deals like this? - it’s not an automatic fail if they don’t, but it certainly reduces risk if they do. Mainly this will help on the technical side and suggest that they’ve had to deal with integration pains before and have likely addressed many issues already vs trying to “open up” some part of their product that was never meant to touch the outside world.
Is the revenue stream you will give them important enough to keep them interested? - You don’t want to be paying your partner a fortune as that means you probably should have tried to own the capabilities, however you don’t want to pay them so little that you mean nothing to them. There’s no right answer here, but keep in your mind what % of their annual revenue you are likely to become if this deal is successful.
What happens if the deal goes south for any reason? You don’t want to go in assuming failure, but you also don’t want to go to sea with the only functional boat for 1000 miles in all directions. Are there other players you could switch to if needed? How much of the work can be reused? If your partnership is (publicly) successful it’s very likely some of the other players will seek you out and try to displace the original player anyways. It’s worth keeping warm relationships with everyone and knowing what your options could be if you need it. This is also helpful when it comes time for contract extension negotiations. Think about setting trigger conditions up front for what would cause you to end of life the feature, switch to an internal build out, or bailing out in a hurry. Have a basic plan with contingencies for each that you discuss up front and not when it’s panic time.
How important is it for the partner to incrementally improve the product? Are you fine with the way it is today and aside from a few small things here and there, you’re good? If they don’t keep up with new offerings from AWS or GCP will their value diminish? The more dependent you are on them extending the product or keeping current with someone else’s releases the riskier the relationship can be. If they seem to do a good job of staying ahead, that’s nice. This risk can be minimized by making sure you’re on the primary code base and not some other branch. If they have to do something special for you to receive the latest and greatest then there will likely be some tense moments when things are slow or don’t work properly.
How smooth is the process for you to receive updates? This is something you can evolve over time, but based on your answers to prior question you’ll want to think about A) what’s required to get to the latest version of the rented asset B) how quickly that can happen and C) depending on how manual it is, how often do you want that to happen. Dropping in code or adopting a new API means a new release and your side, but it gets rolled out on your terms. If you’ve linked to SaaS products via rebrand then it’s often harder to hold back on one side - they will release as they do, and you need to be more on top of any potential breaking changes. Between the two. On the plus side, you know you always have the latest and greatest. Either one can work depending on the situation, you just need to be aware and build the right communication processes in up front.
Who owns the relationship? It should be someone in the product team on your side. That can either be a product manager or director of product who owns associated parts of the experience, or if you do this often enough it can make sense to have a dedicated person who manages 3rd party agreements. If you get past two of these type of agreements, it makes a lot of sense to have a single person keep an eye on the relationships and the contracts. Assuming things go great, it’s easy for a PM to get pulled into all the other stuff that’s going on and ignore the successful and well-working partner component at some level. A dedicated resource can keep the relationship active and warm, and keep an eye on opportunities to optimize cost via contract or product tweaks.
How do escalations and customer support work? - Not insurmountable, but you need to think about the support flows and how to train up your reps and how escalations will eventually jump to the partner when they get to a certain point. There’s an escalation SLA in every OEM contract. It looks very formal and typically has time to respond by severity level. In practice the severity levels are always subject to a bit of interpretation and the SLAs are hard to enforce as you are “stuck” with them whether they help fast or slow. Moving off an unhelpful partner will take months and won’t help you in the moment with an escalation so focus on a very well defined process and try to maintain a close working relationship with the technical contacts on the other side. You want them to want to help you because you’ve all been in the trenches together not because your CEO waved the contract in front of their boss.
Summary
When companies are deciding how to execute on their product strategy, some form each of these two biases will come into play along with many others:
Dunning-Kruger Effect - basically the less we know about a topic, the more confident we are
Not Invented Here: Our tendency to avoid using or buying products, research, or knowledge developed outside the group
It’s tempting to start down a path of building something that looks easy only to find out that it’s not. This can be especially painful when the scope explodes on something that is not core to your business but is non the less still required. which can be more painful when it’s not something core to your business. Generally, we just don’t trust people outside the walls of our company to do things as well as we do. Ultimately it’s needing a sense of control and risk. I’d argue you can actually learn a lot by working with other companies, especially if you are serving different ends of the same market.
Historically OEM agreements were common in enterprise hardware and software companies where a “vendor management” mentality ruled. If someone calls you a vendor, they see you as a cost to manage and a distraction to minimize. When I say rent, I mean partner. Renting is simply too risky to do it in an adversarial way. Secondly, renting can be a good way to de-risk an eventual acquisition. I wouldn’t rent something you know up front is core to your business in most circumstances, but as things evolve you may find an acquisition could make sense. Maybe you and the partner have complimentary go to market channels or your products evolve from far apart to two parts of what customers see as one solution.
Sometimes there is no good option for building or buying in the time or cost constraints before you. Sometimes time to market is more important than straight up one-time development costs. Keep renting as an option to help you execute on your product strategy more quickly and effectively.
