When organizations create a new process, or overhaul an existing process, there’s one type of decision that rarely gets the consideration it should.

That decision - as you may have guessed from the topic of this newsletter - is whether to build or buy the software used to support that process.

It often seems like the folks involved don’t even realize they have a choice.

Some organizations build everything… because they can. These are typically the organizations that even though they aren’t inherently software development organizations get convinced by their software engineers that “those ERPs are pieces of crap. We can build something better than that in a week!”

Other organizations buy everything because they don’t have, or don’t trust, the software developers on staff. Sometimes, these organizations have gotten burned one too many times by over ambitious engineers.

Ok… that’s not fair to software engineers.

You always have a choice whether to build or buy, and a big factor in that should be your company’s strategy.

And this gives me a chance to talk about one of my favorite 2x2 matrices.

Build to Differentiate, Buy to reach parity

My friend and mentor Niel Nickolaisen got tired of the iron triangle failing him when his stakeholders wanted to increase scope while holding his budget and timeline constant. He realized that instead of trying to instruct his stakeholders about the delicate interplay of scope, time, and cost, he needed to break the iron triangle.

He needed to change how he defined and managed scope.

So in order to do that, he created the Purpose Based Alignment Model (aka the Nickolaisen Model).

To use the model, measure your business processes in two dimensions:

• The extent to which the process differentiates you in the marketplace
• The extent to which the process is mission-critical

You end up with your business processes in four quadrants.

Differentiating

Few of your processes are both market-differentiating and mission-critical. The purpose of these Differentiating processes and requirements is to win customers and gain market share.

To sustain our competitive advantage, you need to be better than your competitors at these processes. This is where you want to innovate and is usually the place where you build software to support these processes.

Parity

Most of your processes and requirements are mission-critical but not market-differentiating. The purpose of these Parity processes is to keep at parity with the marketplace.

There's no benefit in performing or delivering Parity processes better than anyone else does. In fact, treating Parity processes as if they were Differentiating processes has very high costs in the money you spend to make the processes better than they have to be.

Instead, design these parity processes in a simplified, streamlined, and standardized way which makes them prime candidates for buying software.

Partner

Some processes might be differentiating but not mission-critical for you. To exploit this opportunity to differentiate yourself in the marketplace, you could choose a Partner to deliver this process.

From a software perspective, rather than building your own software to enable a specific process, you partner with a company to build that software, and make ongoing changes that continue to differentiate you in the market. This differs from outsourcing the process to your partner and not having any say in how it’s done.

Who Cares?

Finally, some processes or requirements might be neither differentiating nor mission-critical. For these, who cares what we do?

What does this mean in practice?

So here’s what this all means.

Unless your process is essential for building a competitive advantage, it makes little sense to build your own software.

On the other hand, don’t buy software off the shelf to enable a process that you use to differentiate yourself for your competitors. If you buy off the shelf software to enable a differentiating activity you’re inherently throwing your competitive example away.

An Example

I should note that this model is relevant for organizations of all kinds, even if they are non profits. To see how this works, let's look at Agile Alliance.

Agile Alliance is a nonprofit organization that exists to support people who want to adopt agile methods. One of the main “services” Agile Alliance provided is an annual conference for agile practitioners.

The unique aspect of the conference is it’s process for selecting sessions for the conference. It’s a community-based process where a group of volunteers review session submissions and provide feedback, giving submitters a chance to revise their session proposals based on the feedback. This approach differs from most conferences where people submit session proposals and never hear back until they’re told whether their session proposal is accepted or rejected.

In 2016, I was part of the team that rebuilt Agile Alliance’s website, which included its membership system and event registration system. The agency we worked with to build the site built the membership and registration functionality from scratch, along with the new website. It was only after a rough year trying to use these homegrown systems that we all realized a better route was to use existing systems for membership and registration.

If found out firsthand what happens when you build systems meant to support parity processes.

At the same time, I was the product owner (we had to use that term because it was more familiar to folks in the agile community) for the conference submission system. We built this system explicitly to support the unique nature of our submission process. There were some aspects of the system that were not ideal, but it did a good job of supporting the truly unique aspects of the submission process.

I experience the benefits that come from building software to support a differentiating process. And this year I experienced what happens when an organization uses an off the shelf product to support a differentiating activity as Agile Alliance moved away from the custom-built software.

Let’s just say it wasn’t smooth.

Other factors in the Build vs Buy Decision

There are other factors that play into the Build vs Buy Decision. To get an idea of what those are, read on to see some other perspectives on build vs buy decisions.

State of Product Management 2024

ProductPlan’s ninth annual report is a data-backed exploration of how product professionals make smarter decisions and deliver on product vision and strategy.

This year, ProductPlan asked product professionals to share their experiences with adapting to uncertainty, how they imagine the future of their solutions with their product vision, and how they are delivering on their vision despite budget constraints and smaller teams. They compiled insightful responses from over 1400 product professionals worldwide and analyzed them to spot the latest trends.

​Download the report​

PS I analyzed the results and drafted the report.

Build vs buy: How to decide if you should develop your own software

High-growth companies often have to decide whether to build or buy software. Mona Akmal doesn’t hear many people talking about how to make the build vs buy decision, and believes it’s something that deserves some rigor around it. Mona starts with two anecdotes of build vs buy decisions from the time she was an engineer at OneCare, a consumer PC health/safety subscription service (firewall, antivirus, PC backup etc).

5 Step Decision-Making Processes for Build vs. Buy Software

In today’s digital age, businesses depend heavily on technology to grow and operate. In fact, 81% of digital growth businesses credit their organization’s success to innovation. When used correctly, Technology will drive rapid growth and profits. However, it still takes planning and strategy to make the most of it. One of the biggest concerns in managing business technology is whether companies should buy their technology or build from scratch. The folks at Groovy Web shared their 5 step process for deciding whether to build or buy software for your business.

The Definitive Guide to Build vs Buy Software

In today’s world of digital transformation, companies increasingly recognize the importance of efficient software solutions.

The folks at five.co aim to shed light on the key distinctions between building and buying software. Drawing from their experience as software developers, they hope this will give you insights to make an informed business decision.

Software solutions have a huge impact on how well an organization performs. They make things run smoother, help people work faster, and meet the changing demands of customers and internal teams.

Build vs. Buy Software, Which is the Better Choice?

Lena Tyson suggests it is always good to choose to build software if you have enough budget, resources, and time. This is because software building provides more control over all the elements compared to buying. Organizations often buy software in an emergency situation when they do not have the time to build software or when they have to launch a digital product right before their competitors. Lena analyzes how to choose between build vs. buy software options and which among the two is the most ideal choice.

Insurance Software Build vs Buy And Speed to Market

In the past, most insurance carriers believed their software needs were unique and required a custom build. There were very few purpose-built and ready-to-deploy solutions on the market. It was a slam dunk then to build insurance solutions from scratch that would exactly fit an insurance carrier’s special combination of processes, products, and channels — even if it took years to complete. Fast forward to the insurance industry today, where a rapidly changing digital world is making things more complex. Insurance companies have to decide a literal multi-million dollar question: should they buy or build? Market dynamics require speed to stay relevant, but packaged software could lose companies their competitive advantage. Is there a middle ground?

Karen Jain takes a look at some of the primary considerations insurance organizations have when upgrading their technology.

Thanks for reading

Thanks again for reading InsideProduct.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.

Talk to you next time,

Kent J. McDonald
Founder | KBP.Media