Buy It. Don’t Build. Or You May Violate Product Management’s Golden Rule.

This post is intended for corporate product managers in big companies, and the executives who fund them. It comes with a few helpful rules for the latter.

Lee Fischman
Product Coalition

--

Don’t put this guy in charge

Years ago, a book called The Inmates are Running the Asylum described how engineers get in the way of good design. With the arrival of product management you’d think that problem was solved, but it might not be. If you’re building products that don’t define competitive advantage for your firm, ask yourself these questions:

  • Do you like delivering a steady stream of new features to your users?
  • Can everything you’re doing be bought?

If the answer to both questions is yes, you must talk to your boss. The product management golden rule is treat your users as you would expect to be treated, if you were them. You’re not satisfying that rule by constantly delivering features that users love, if you could instead drop something wonderful into their laps all at once.

Delaying (the delivery of features while you build them) destroys value.

Camille Fournier wrote a great post called Why is it so hard to decide to buy but what’s also needed are rules. If you are an executive, and an investment proposal for an internal product lands in your inbox, demand that it answers three questions:

  1. Is an off-the-shelf alternative available at any price?
  2. Is a more comprehensive solution available at any price?
  3. Why favor this investment over an off-the-shelf alternative?

Questions 1 and 2 add “at any price” to account for:

  • Optimistic assessments by your engineers.
  • The purchased solution probably being way more polished.
  • The fact that a leading vendor — subject to competition — is probably far more agile and pressured to improve than your team ever could be. And they probably have a bigger team.

Question 2 shuts down the rationalization, “We are using a vendor (or open source!) and we just need to build out some functionality.

Question 3 gives people the opportunity to put forward their best argument. To be fair, I tried to overcome my strong bias on this topic by asking a knowledgeable authority (ChatGPT) for counterarguments:

  • Customization: A built system allows greater customization to specific business needs.
  • Unique Requirements: A built system ensures a perfect fit for unique requirements driven by domain- or industry-specific regulations.
  • Cost: The initial expense of building an internal system can lead to long-term cost savings by eliminating licensing fees, maintenance costs, and customization charges associated with off-the-shelf software.
  • Competitive Advantage: A built system may sometimes enable differentiation and innovation, while a purchased solution could not.
  • Integration: In a modernization compromise, a built solution may be needed to reduce disruption or risk, by being grafted onto existing systems and processes.
  • Security and Privacy: A built system in regulated industries ensures better control over data handling, encryption, access controls, and compliance.
  • Long-Term Ownership and Support: Internal system ownership allows for enhancements and modifications without relying on external vendors’ schedules or roadmaps.
  • Lock-In: A vendor may make it exceedingly difficult to back out, for example, by holding your data in a way that cannot easily be migrated.

Evaluate these counterarguments by asking:

  • What do our peers do?
  • How much value is destroyed while we wait for something to be built?

A more nuanced approach may be warranted when the various use cases for a product serve to differentiate the buy vs build decision. Some of these could be expeditiously handled using an off-the-shelf system, while others might require a custom approach. Or maybe the economics of some needs favor a purchase, while that of others favor building. In situations like these, it might be sensible to advocate for a bifurcated approach: both purchased and built solutions. In purchasing a solution for some use cases, staff are freed to focus on edge cases.

Even if all the counterarguments above can be discounted, you may still run into vociferous opposition against buying by anyone whose resume will look far better if they or their reports built something, or who just loves the journey. Advocating for buying instead of building demands heroism. Just remember who signs your paycheck.

Images

--

--

Founder of the Worldwide Map of Love (wherewemet.org) and also open to Product Manager job offers :)