The build versus buy conundrum

Recently I was making a decision about developing new functionality for the Arkivum product or buying in some capabilities that would provide most of what we needed and enable us to progress faster with other things. It’s a fairly common product management decision but it struck me as a very similar problem faced by many of our clients when deciding whether to buy an off the shelf product versus investing their valuable development resources in a home-grown solution.

As a product manager, there are a few key questions I use that can also help decision makers everywhere when faced with a build versus buy decision.

The first and most important question:

Is there an existing product in the market that already delivers similar functionality that can cover all or most of my needs?

A good rule of thumb here is the 80:20 rule. If the product you’re buying doesn’t meet 80% of your needs then it’s unlikely to be worth buying as you’ll probably still need to develop your own functionality for the missing requirements. This is where it’s worth taking the time to dig deep into the existing and planned capabilities of any products you’re considering to make sure they reflect your needs.

Would we do it better or differently?

There’s usually the “IT argument” to discuss internally. My engineering director often disagrees with my buy decisions. But that’s ok because having been in the software industry now for half of my life, and having spent over half of that time as an engineer myself, I understand that most engineers want to build software. They want to do it their way because no one else will ever do it as well as them, and even if they inherit code they will want to redevelop it. But that’s not how we make real progress – engineers don’t make groundbreaking new products by rewriting code or by redoing what you can buy off the shelf, and sometimes we, as product managers or business owners need to make those decisions to advance our products and businesses as a whole. By doing so, we can let our smart colleagues in engineering focus on developing things that will really add value to our business and buy the products that other people have already made to solve our business needs.

But then we should also ask ourselves if we actually want to develop the functionality. Sometimes it’s the right thing to do, and aside from whether we’d do it better or differently we also consider if it’s part of our core business and would add value or a differentiator to our business.

Is buying cost prohibitive?

The decision to buy needs to also be weighed up against whether you can deliver the value you need at a lower cost – taking into account not just engineering costs but also the ongoing costs post development and testing around support, deployment, maintenance, etc.

It’s also important to consider that a bought solution is likely to reduce your time to deployment and more often than not the vendor will add domain expertise and support services to support their offering which can significantly lower your costs in the long term.

Once upon a time, I worked as a developer on a system that was bought from another vendor. The project team was tasked with adding the missing functionality needed – which turned out to be a lot more than anticipated, resulting in an expensive, long running project on top of the cost of the third party software and a bespoke solution that was no longer the responsibility of the vendor to maintain. Not the best buy or hybrid example, some more due diligence in the buying process here probably would have resulted in a build decision.

The decision

All in all, the decision isn’t always a straightforward one to make. It’s worth investing the time up-front to make sure you have a clear understanding of the products you’re evaluating – bring the right decision makers to the demos, ask lots of questions to get a clear understanding of the product and its future strategy.

It’s always a good idea to discuss the business challenges you’re trying to resolve with the vendor – sometimes they may have a solution you didn’t think of or which wasn’t covered in the demo, or it may also be a challenge they’ve seen before and have already planned for a future release, or it could be a good time to provide input into the product roadmap – (us product managers love to hear from the market about challenges people are looking to resolve!) At the end of the day you’re most likely buying into a relationship with the vendor, and like every successful relationship it needs to work on both sides so make sure it’s the right one for your business.

If you’re evaluating Arkivum as part of your build versus buy discussions, I am hosting a live product demo webinar where I’ll show you our latest functionality. Of course, if you’d prefer a more tailored discussion of your requirements and our potential fit, drop me an email at sinead.mckeown@arkivum.com.