At every turn in the product lifecycle, PMs lead teams in a variety of decision-making processes. Naturally, there are times when PMs and teams have differing ideas of what will lead to success. Nowhere is this more prevalent than in the seemingly simple decision to build or buy software. Nuanced circumstances influence which choice is best, but even then, developers may be itching to start from scratch while Product Managers call for off-the-shelf software trials. This situation can undoubtedly be frustrating for PMs, but the build-versus-buy debate should never lead to a free-for-all; instead, PMs can leverage the discussion to explore which option is best, and why.
Define Your Core Competency for Customers
Almost every contemporary article on building or buying software brings up the importance of core competencies. This unique factor does more than set a business apart from the rest—it also carries weight in the build-versus-buy decision.
Imagine being the PM for a fashion app development team. The app’s goal is to serve as a social network, where users can interact, share the latest fashion trends, and rate the looks they see. This app’s core competency, or unique market niche, is to provide a social network for fashion-savvy users. The question, then, is whether or not any existing software exists that can be customized to serve this purpose.
MyDoc CTO Mark Ridley describes “the lure of building software” in an article for Medium. The piece explores the many reasons that PMs should encourage buying software above building it. He draws a thick line in the sand as he writes, “Unless you are genuinely a ‘tech’ company you should almost always buy rather than build.” After all, building and maintaining a product’s software is often a much more costly investment than buying it commercially and tweaking where needed. That building cost skyrockets when teams inevitably cut corners to meet deadlines, and may not be mitigated by sales if equivalent products are already popular on the market.
Still, Ridley points out, buyers should remember that off-the-shelf software is not a “one-and-done investment.” Maintenance costs are integral to software, no matter if it’s an in-house production or not.
Define the Core Value for Your Team
A perceived lack of flexibility in customizing and maintaining pre-purchased software could be one reason why developers are so hooked on building products from the ground up. By definition, engineers are creators—artists, even, according to Logi Analytics VP of Products Brian Brinkmann. It is the beauty of problem-solving and creative thinking that lets these professionals thrive. However, it takes the logical direction of a Product Manager to determine the best course of action for the product. On this matter, Brinkmann echoes the sentiments of other Product professionals, explaining that a developer’s vision may deviate from that of the customer. Engineers may be excited to launch that software, but what happens when customers demand more capabilities and expansions? Does the team have the time, energy, and resources to maintain that software? When security and licensing are thrown into the mix, how can organizations adequately serve the needs of customers without spreading themselves thin?
To combat all this uncertainty, Product Managers must take the lead in determining the core values of the company and the team. A simple pro-con list or Venn diagram creates a quick mock-up of potential outcomes, and it can organize company and product values to ensure that PMs understand the overarching implications of building or buying.
In a piece for HR.com, Deborah Henken and Norma Watenpaugh identify four core values that companies may have for their product. Leadership falls solely under the build category. After all, build provides developers and PMs complete creative control over the product and its source code. Alternatively, time to market, or time sensitivity, pairs well with the buy category, which reduces much of the technical complexity time-crunch that build teams see.
However, both build and buy are valid options for the core business value, meaning that either path suits a product that is central to a company’s success.
Defining Partnership
The fourth value that Deborah Henken and Norma Watenpaugh put forth is that of reduced risk. Naturally, a company that has built software or customizes pre-existing software will experience plenty of risks should troubles arise. For this reason, Product Managers may posit a third option, one that eliminates the difficulty in choosing between purchase and production—partnership.
The partner strategy boasts the shortest time to market, the lowest switching costs, and the most significant conservation of resources. At the same time, it offers the least amount of control and results in shared gross margins. Also, partnering is a good strategy for projects that require long-term monitoring. Product Management Specialist Cliff Gilley advocates for partnership; he writes, “It’s far cheaper in the long run to leverage someone else’s knowledge and skill than it is to train your own resources up.”
Defining Success
Remember that the Product Manager is a vessel through which all ideas flow. The suggestions of marketing, engineering, and purchasing stakeholders must be heard and integrated, but Product Managers must do more than listen. Half of the job is communication. To communicate successfully, PMs need to be confident in their analyses and encouraging in regards to the product. Tech Executive Rich Mironov warns PMs that short-term build solutions may stretch on for longer than intended, in part due to the fear of sunk costs.
Product Managers must let teams know that all investments work towards a great future for the organization and product. Developers, in turn, must recognize that client-facing value is what truly matters when it comes to products.
Ultimately, the decision of whether to build or to buy depends on the situation, circumstances, and capabilities of team members, as well as the availability of resources such as finance, manpower, and know-how. Above all else, Product Managers need to direct efforts to the end-point of satisfying customer needs, which requires unity across all involved teams.
In one of my previous roles, I had to build a calendar integration tool. It did not make sense to go about figuring out how to integrate an application’s calendar with MS outlook. There are experts out there who provide this service and it was best to integrate and leverage their know-how instead of setting out to build. Again, this illustrates just how vital it is to understand not only your audience, but also your company’s capabilities. If you’re going to build an asset, so long as it is your core competency and you have the necessary tools and resources, you’re set!