Editor’s note: The following is a guest post from Logi Analytics. If you’re interested in becoming a guest blogger, please contact email@example.com.
Nearly every product team, at some point, is faced with the build verses buy decision. And nearly every product manager knows the answer to the question—buy. And every product manager works with an engineering team who would answer oppositely—build. Why is that and who is right? Before we discuss the logical pros and cons, let’s talk about the emotional motivators behind this debate. Perhaps when we understand these better, the product managers and engineers can come together for an optimal decision.
Product managers, for all their good traits—and there are numerous (I’m one, too)—are motivated by fear. Fear the product won’t make revenue targets, fear the customers won’t like the product, fear they will let down their development, and perhaps most importantly, fear their product will be second-rate. Paranoia has been a product manager’s friend for decades.
Engineers, for all their numerous good traits, are driven by art. Yes, art. They are artists and creators; they are complex problem solvers; they are our modern-day Thomas Edisons—inventors. Today’s raw materials are digital, not mechanical. They see a challenge and want to create an elegant solution they can be proud of—and one their peers will admire (aka “cred”).
So, the debate then become less about our emotions and more about delivering a winning product.
Let’s dive into the logic of the build verses buy debate. Here’s the simplest rule on when to build: is it a part of your company’s core competence? If your answer is anything other than “yes,” start looking for a solution to buy.
Building is often the first step on the way to a new capability. But product teams that stay on the “build” track commit to staffing significant resources over time—resources in development and support, and resources to keep up with evolving technology. The long-term costs of building—even with the help of components—are astronomical compared to buying the right tool for the job.
There are hidden costs of building, especially when you build with the help of components (as any good dev team will inevitably do). Consider these drawbacks of building with components.
Effect on Core Application Development
Any time that you spend building something outside of your core competence is time taken away from your application development. Your development team will spend a significant amount of time gathering requirements, then mapping those requirements to components. You end up replicating capabilities you could have easily purchased from a vendor.
Evan Quinn, who oversees product at QAD, a software company that offers ERP and supply chain software to global manufacturers, faced this dilemma when they needed to update the dashboards and reports in their software. “The first decision we had to make… was build or buy. This turned out to be an easy answer. QAD is a manufacturing ERP and supply chain software company—not an analytics specialist. So, we began searching for a partner that could help us provide what our customers were looking for.”
Managing a Maturing Product
The first instinct for many developers is to build exactly what they want with the help of open source code libraries and charting components. This works for some organizations, especially those that think their users don’t have complex requirements. But as your application becomes more successful, your users will want more capabilities. If you build, you’ll be forced to research and develop each new capability one at a time, which delays every product update.
Remember that every component you use supports theming on an individual level. Any changes to the brand means individually applying the new themes to each component. The risk here is breaking one or missing a key component altogether.
Building also means implementing and maintaining security for every single component you use. This takes significant effort and introduces unnecessary security risks. When you buy, certain vendors globally reuse your existing security policies to ensure your security is always up to date and consistently applied for every tenant throughout the entire application.
Relying on third-party components libraries also introduces risk when it comes to integration and upgrades. You have no guarantee all the components libraries you choose will work together forever or have consistent versioning, and a single upgrade may lead to regression issues.
Many components come with complicated pricing structures that can hinder your application growth. If one component prices on a per-user basis, costs can quickly skyrocket as your business grows. Also, keep in mind that using multiple libraries means managing multiple different licensing policies. On the other hand, certain platforms have predictable and easy-to-understand licensing structures that will scale with your business needs.
Some of your developers will inevitably leave the company. What happens when they have all the institutional knowledge of your built solution? It will have a serious impact on your ability to maintain or make upgrades. Unlike components, platforms are thoroughly documented, so anyone can build, maintain, and enhance with minimal disruption.
Every time a product team gets caught up in the “build vs. buy” debate, it stalls projects and delays time to revenue. Product managers and engineers need to come together and realize that practicality and creatively yields the market leader—and everyone can agree on being #1.
About the Author
Brian has over 15 years of analytics and BI software experience. Prior to joining Logi Analytics, he held senior product strategy, management, and marketing positions with MicroStrategy, creating BI applications for marquee customers such as Nike and Franklin Templeton. Brian holds an MBA and an MEM from Northwestern University, as well as a Bachelor of Electrical Engineering from the University of Dayton.