Virtually every development and product leader will face numerous build vs. buy decisions throughout their product lifecycle. The explosion of packaged point solutions, open source code, and frameworks means that there are multiple options for just about every component of a software project.
Your choices will have immediate and long-term impacts on revenue, resources, customer satisfaction and even employee morale. All too often, these decisions are made without the advantage of a holistic consideration process.
CONFESSION: I have witnessed, and unfortunately been guilty of, making important product decisions based on casual off-hand comments made in hallway conversations. I imagine I’m not the only one who has heard or participated in conversations that went something like this, for example:
Stephanie : “Hey, have you looked into using [packaged solution name] to solve our [feature gap or performance issue] problem?”
Steve: “Nah, it would probably take just as long integrate [packaged solution name] with our application as it would to just build/fix it ourselves.”
Dave : “Hey, I saw a REALLY great demo of [packaged solution name] the other day and I think it will solve our [feature gap or performance issue] problem. I went ahead and purchased/downloaded the product. I’ll send the details. Let me know when you can get it integrated.”
Danielle : “Oh, ok. I’ll let you know.”
These examples are admittedly oversimplified but illustrate a few common tendencies:
- Decisions are made with very narrow criteria – often forgetting to consider things like documentation and support, the impact to resources and the potential of lost opportunities, the return on investment, and the fit of the solution to the real problem.
- Developers tend to want to build things themselves (and have occasionally been known to underestimate time and effort) while Business people tend to want to buy “quick” solutions to problems (and have occasionally been known to force ill-fitted solutions upon their development teams and customers).
- Decisions are made without facts to back them up. Not everything can be known or estimated with 100% confidence, but the more complete the criteria and data, the smarter the decision.
- The long-term impact is left out of the conversation. Ongoing support, development and the evolution of customer needs can’t be understated when making build vs. buy decisions that you’ll be living with for years.
We have something to help!
Windward Studios Build vs. Buy white paper is a decision-making framework that can be used for just about any software build vs. buy decision.
This is our second edition of the popular white paper, with more illuminating questions you’ll want to answer and a built-in worksheet that will allow you to score and weight the criteria to arrive at an informed recommendation. It will be equally helpful, whether you’re making the decision yourself or as a team.
Many of our customers and prospects have found the previous version both unbiased and valuable as they’ve considered their options. We believe the Windward Studios solution offers the best of both worlds, so our interest is only in helping you make the smartest build vs. buy decision possible. The white paper is free to download and share!
Author: Robert Nendza
Other posts by Robert Nendza