Buy! Buy! Buy! The Pros and Cons of Building Everything Yourself
"But it's fun to build stuff!" - Oh, my sweet summer child!
There are many classic debates out there that can inflame tensions amongst even the most reasonable people: Pepsi versus Coke, iPhone versus Android, or cream on the scone before or after the jam. There is no right answer to any of these questions, and so much depends on preference and context. That said, I would like to add one more to the mix:
Build versus Buy
You’ve probably all been in this scenario:
You’re busily building some cool new stuff that’s going to help your company hyperscale (maybe, possibly).
Some orthogonal requirement comes up for some supporting tech or platform that you don’t have (examples I’ve seen include: SSO, analytics platforms, taxonomy management systems and entire BI suites!)
There are off-the-shelf solutions that do most of the job, but no one seems to be prepared to invest either time to investigate them or money to buy them.
A random stakeholder brings up a niche edge case that no off-the-shelf platform could ever handle (and we’ve always done it like that here).
Eventually, someone pipes up and says “Hey, let’s just build it ourselves! How hard could it be?”
You can probably guess what happens next. While you’re guessing, consider subscribing so you don’t miss any more issues of this newsletter:
Why Building Seems Like a Great Idea
We all love building cool stuff. For many of us, that’s why we got into this game in the first place. Whatever it is we’re building for whatever problems we’re solving, building things is simply what we do. So, when it comes to deciding whether to build some new capability, we might default to rationalisations like:
How hard could it be?
I mean, seriously! We’ve got loads of great developers, and we’re building all this other cool stuff, and this new thing is pretty straightforward, and we can probably just squeeze it in.
Building stuff is fun!
We’ve had some developers working on some tech debt or re-platforming for a while and they’re kind of bored of that, plus we can finally start learning about graph databases now. And who doesn’t love a greenfield project? Hey, maybe we can finally try setting something up in Kubernetes.
It’ll be cheaper!
“Build” discussions often don’t come with new, fully loaded development teams as part of the package, so you’ll likely be working with existing teams. And, hey, we’re already paying those people. They can just fit it in! And that commercial SaaS is really expensive and our CFO will never sign it off anyway, so we might as well not ask.
We have such unique requirements!
Every company is its own special flower, and it’s impossible that any generic, mass-market solution could ever contain our multitudes! We absolutely need doohickey X and widget Y to work exactly as we want, otherwise it won’t fit into this legacy operational process that we absolutely can’t change, even though no other company in the universe works like that.
We maintain complete control!
Why would we offload all this stuff to some faceless nobodies at some company where we’re just 1 of 10,000 customers, even though we expect our customers to do exactly the same thing with us? And, hey, if our requirements change, we don’t need to get onto anyone’s backlog; we can fit any changes into the next Sprint.
Why Building is Probably a Bad Idea
Building isn’t definitely a bad idea. There are some reasons it might make sense, but you should bear a few things in mind:
Everything’s harder than it sounds
It doesn’t matter how easy you think something is… the reality is always harder. There’s always room for positivity and a “can do” attitude, but think about whatever solution you currently offer to the market. Imagine someone needed that and decided to build it themselves. Knowing what you know about your product, would you recommend they do that? Now imagine asking a vendor-side product manager the same question.
You should be building other stuff!
Presuming that you’re not staffing up an entirely new development team to handle this new work, which will almost certainly be more expensive than the SaaS subscription you’re trying to avoid, you’re doing this work with existing people. That’s great, but shouldn’t these people be working on something else that delivers direct value for your customers? What’s getting left behind?
Once you’ve built it, you have to maintain it
The problem with “easy” solutions is that you soon start to reach the limits of what they can do. If you’re rushing it through as a side-of-desk project, people are going to cut corners. If it’s using technology your team has had to learn on the spot, they’re quite likely to have missed something important. There will be servers to maintain and patches to patch and library upgrades to upgrade. No software is one-and-done.
Your version is probably going to suck
One of the biggest advantages of paying a company that builds this sort of thing for a living is that they build this sort of thing for a living. I’ve seen some “build” efforts take 6 months or more. The end result is, at best, a platform that’s functionally equivalent to the commercial platform you’re avoiding using… but functionally equivalent from 6 months ago. Meanwhile, they’re still building, iterating and improving based on feedback from a vast array of customers. Aside from your special, niche use case, you’re never going to catch up.
With control comes expectations
I’ve never seen a single “build” solution that did all the things it needed to do forever. There’s always something that either got accidentally missed, purposefully left out, or was never a requirement but now absolutely is. Maybe some new data privacy legislation came in. Maybe you merged with another company. It’s impossible to future-proof a solution, so you’re going to be committed to enhancing this thing forever.
Should I Build or Buy?
Given the above, and my own long experience of everlasting “build” projects, my general advice is generally to strongly consider “buying” unless:
… the thing you’re building is fundamental intellectual property
It’s possible that you are doing something so totally different or crafted to your use cases that it legitimately makes sense to build your own solution. What you want to avoid building are things that are fairly commoditised. It’s perfectly fine to build a general-purpose commodity platform, but it makes a lot more sense if that’s your entire business.
… It’s a differentiator for your business and gives you a competitive advantage
Even if you are doing something different, you want the differences to actually help you, rather than boxing you into a bespoke corner. Sometimes it’s worth taking a step back and trying to understand why your needs are different. Are they really, or are you just victims of status quo thinking? That said, maybe existing solutions are really quite bad. If you have really found an edge, it can make sense to press on and build.
… The price of external offerings is incredibly high and you have no bargaining power
If there are very few vendors in a particular, uncompetitive space, or de facto solutions that you’re expected to use, you can end up paying quite a premium. It’s also fair to say that no one really appreciates vendor lock-in. I’d argue that, in many cases, you’re still going to save money in the long run with a commercial solution, but some solutions are really expensive for the value they deliver.
… It’s something you could potentially sell as a customer offering in future
After all, look at Amazon Web Services! It’s absolutely fair enough to assess the landscape for this new solution and work out if it’s something that could actually unlock value not just for you, but for your customers. Your mileage may vary, depending on the type of thing you’re building or buying, but it’s important to take a big-picture view and try to understand if your “build” is the first stage in a true product offering or just an internal cost of doing business.
These days, there are a wide variety of commercial options out there to cover most use cases. If yours is so unique and you have no other option, build away! But, be careful.
A bonus tip is to consider “buying” a platform that covers the majority of your work but has an SDK, API or other integration capabilities that allow you to build your legitimately special stuff. This gives you the best of both worlds, and you can still use the standard functionality for the vast majority of use cases.
Please Fill In My Course Survey
Saeed Khan and I have gotten great feedback on our B2B product management course, but some people are asking for something a little more targeted.
Because of this, we're considering launching a shorter course focused entirely on "Mastering the Relationship between Product Management & Sales"
If this sounds like the sort of thing you might be interested in, please help us shape the course by filling in this short survey. There’s no obligation to attend, but we’ll let you know when it’s live and also offer you a tasty discount if you decide to sign up for the course proper.
Exciting, Thrilling Podcast Updates
My first exciting, thrilling podcast update is that I have a new episode that I recorded with Denise Tilles and the returning Melissa Perri. They both co-authored “Product Operations”, a relatively new book that you can probably guess the topic of. We spoke all about the book, why PROCESS is seen as such a dirty word, and how you might start getting a Product Operations team set up.
This episode is also a benchmark because it’s the first time I’ve recorded with video! Yes, now you get to see my face and the faces of my disappointed guests as they wait for me to finish my questions. Check out the YouTube channel, but never fear audio lovers! I’m also still available on your favourite podcast platform and the podcast website.
My second exciting, thrilling podcast update is that I’ve started experimenting with a new podcast format. When I started out the podcast, I intentionally cast my net far and wide to get all different sorts of people on from all over the world. That’s been great, but it sure is easy to get starstruck by all these authors who I know these days. In an attempt to rebalance, I’ve started up “One Knight in Product: Hot Takes” - super-focused, super-targeted 15-minute episodes on one topic with all comers. Don’t worry, I’ll still do the big names too, but this additional format helps me go wide again.
The first episodes will be dropping soon but, in the meantime, if you have a hot take you can grab a recording slot.
Some of my other content
Here are some things I’ve written or been involved in from the few weeks since my last newsletter (I’m trying to get into the writing habit more, I’m trying!):
My video interview with Mark Long from Numi- we talked all about fractional leadership and my own journey
Product Conversations: Differences in Product Management - a round table video chat I did with Product Growth Leaders about the differences between B2B, B2C and B2B2C.
Your first "I'm a consultant now!" post is always your most popular - the trouble with extrapolating consultant/market fit from your announcement post.
"We think strategically but we act tactically" - how people get prevented from doing strategic work, but why they should do it anyway.
What you want/What leadership wants - how to start thinking about driving change in your organisation if things aren’t they want you want them to be
Book Recommendation: Flawless Consulting - I really enjoyed this book, and recommend it both to consultants and anyone trying to affect systemic change.
Front-load your presentations - if there’s something that you know people are going to complain about lurking in the middle of your presentation, consider putting it right up front to get it out of the way.
Other People’s Stuff
Here are a few other things I’ve seen around and about in my travels that caught my eye.
How does ChatGPT work? As explained by the ChatGPT team - an excellent article from
going deep on how our new robotic overlord works under the hood.The Humane AI Pin: A Case Study in Poor Strategy and Poor Execution - crappy AI products that are more hype than substance are all the rage at the moment. Dare Obasanjo goes deep into what went wrong.
Why it's time to update our language about bad design patterns - it’s important to avoid manipulative design patterns, but let’s not call them “dark” says Amy Hupe.
Count the Digits - Numeric prioritisation frameworks can be a mess, but sometimes you need something to get started, and Rich Mironov recommends getting dirty and imprecise.
The Man Who Killed Google Search - I found this article by
fascinating - a deep dive into the product decisions that can enshittify once-mighty products.Your strategy (probably) sucks - Martin Eriksson has worked with hundreds of companies, and so many of them don’t have any strategy at all. What should they be doing differently?
Playing to Win & Agile - I’ve been reading a lot of strategy stuff these days, and I came across this interesting article by Roger Martin (Playing to Win) about whether “strategy” and “agile” are mutually exclusive.
Thanks for reading
As ever, it's been a pleasure. Here are some ways you can keep in touch with the conversation:
Join my Virtual Networking weekly calls
Join my real-life London meet-ups
If you have any comments, questions or complaints about this newsletter, please feel free to reach out! The same goes for any topics you’d like covered in future issues.
I’m still averse to charging for Substack subscriptions but, if you find my work valuable, please consider a one-off or recurring donation.
Thanks!