Build for an advantage, buy for parity

Before considering the implications of a selected approach, it’s vital first to understand the end goal. Is there a need to address a standard business workflow? Is the goal to distinguish the organization with a niche offering? In reality, enterprises need to offer a healthy blend of products that account for both.

Build to address a unique issue or process.

Efficiencies at scale, advantages for revenue retention, and market share acquisition become evident through a custom product strategy. For example, the largest industrial supply distributor in the world creates a custom platform giving users the ability to sift through a rich, multi-dimensional catalog of five million unique SKUs. Minor adjustments in the eCommerce experience generate millions of dollars in additional revenue.

Buy when an available product addresses a standard workflow or business process.

An enterprise needs tools to support standard operational functions like accounting, purchasing, HR, and others. Redesigning and rebuilding custom applications for a standard workflow is highly inefficient, and this leads many to buy off-the-shelf products. Implementing an off the shelf product like a content management or accounting system comes with minimal risk, low cost, efficiencies, and short time-to-market.

Customize a product’s workflow to address a unique need or user experience.

Another option to explore is purchasing and customizing various aspects of an existing product. For example, a law firm purchases an eDiscovery platform and then retrofits the product to account for unique processes or businesses they serve.

To fully realize the impact of a new product on an enterprise, it’s important to:

• Define desired outcomes.

• Evaluate impacted processes.

• Compare the capabilities and limitations.

• Understand industry alignment.

• Estimate investment for customization and ongoing support.

Defining desired outcomes

Start by creating a product charter for the opportunity. Task the product leader with identifying the benefits and risks associated with the introduction of new software, as well as investigating the technical readiness, feasibility, and overall portfolio priority for the investment.

A product charter formalizes:

• outcomes

• roles

• users

• context

• challenges

• risks

• system roles

• alternatives

• integrations

• dependencies

An opportunity qualifies for investment as long as it is feasible, technically ready (from an enterprise standpoint), and there’s quantifiable value.

The illustration shows an overview of the product’s domain.

Then, evaluate portfolio priorities. Focus on the business value and implementation complexity. Identify the highest to lowest value initiatives ranked additionally by the level of complexity and risk.

Quadrant 1 and quadrant 3 have the highest value, with complexity increased on the X-axis.

Next, establish the opportunity metrics for success. Picking the right KPIs to measure throughout the planning and implementation phase significantly increases the probability of success. Anticipate a gradual shift to desired outcomes throughout the lifecycle of an implementation. The shorter the cycles between measurements, the more likely the initiative finishes successfully.

Evaluating impacted processes

All software implementations affect existing roles, workflows, and dependencies. During legacy re-platforming efforts, the business is often complacent with the embedded workflow. It’s common for teams to struggle to consider alternatives with a shorter path to value and deliver outcomes. To maximize the value of a unique process, determine whether it’s better to design a process around a limitation of an existing product, or to build an application to support it. It’s critical to map out the impact of the product on back-office workstreams.

The investment necessary for change management for a new process and tool adoption is often overlooked. Service design is an extremely useful discipline for change management planning. Many activities within the discipline net higher adoption.

A great tool supporting service design is a service blueprint. The document maps out all impacted systems, departments, user roles, and workflows across the organization and how they connect. Acknowledging the complexities of the technology ecosystem isn’t always easy. Regardless, enterprises need to unpack how a new product impacts the current and future systems.

Some businesses are well-positioned to adopt pre-defined workflows that maintain productivity and require minimal onboarding. Other businesses struggle to adapt because deviating from the existing workflow impacts a critical service offering. Consider buying an off-the-shelf application and customizing it to enhance an existing process. This approach can unlock opportunities to distinguish the enterprise from market peers, driving revenue, or add efficiency.

Comparing capabilities & limitations

Investigating existing product offerings is the most logical starting point. The software is already built and ready for use. Compile a detailed analysis of the solutions, feature sets, and pricing. This information provides insight into the landscape and capabilities pertaining to the objectives framed in the organization’s product charter. Explore the past and future roadmaps to spot shortcomings or opportunities for additional features to drive revenue for your company. Being aware of a products’ evolution helps inform an enterprise’s roadmap.

Understanding industry alignment

Look at existing products that address a specific industry need or process. Think strategically about the use case. Is buying the same industry-focused tools as competitors a safer and faster path to value, or is it a risk of mirroring inefficiencies of competitors? Is there an opportunity to create something more transformative or tailored to the industry?

If the product’s origin and use cases are similar to the product charter, it may be a good fit. For industry-specific applications, it’s common for the product to include a richer feature set and close alignment with a business’ workflows. One great example of this is Relativity. As a global leader in the eDiscovery space, the Relativity platform helps legal teams solve complex data problems during litigation, investigation, and compliance projects. The product integrates with third party solutions, allowing the creation of custom workflows. Ultimately, the product addresses an industry-specific solution while offering the flexibility to customize to address the specific needs of a company.

Adding a new tool that requires an organization to adopt new processes or alter behaviors to align with the product’s general use case can cause inefficiency. One example of this is Salesforce. The product is infinitely customizable, and covers use cases relevant across many industries. While it’s a leader in the market, a poor Salesforce implementation results in reduced usability, extensive customization necessary to meet organizational needs, and exhaustive impacts on the IT ecosystem. What appears to be an economical buy ends up a costly and time-consuming implementation effort.

Estimating the investment

All products require continued investment. The lifecycle of technology starts accumulating product and technical debt the day implementation finishes. Craft investment roadmaps to reflect support and maintenance costs. Plan to pay down this debt and modernize over time.

While many market-ready products offer different levels of customization, they aren’t a one-time buy. Beyond the initial additional investment, products require additional dollars, hours, and expertise to maintain the modifications as the software and business evolve. Furthermore, each new version release requires further integration and upgrade efforts. There are several factors to consider before shelling out cash for a new product.

NOTE: If it’s not a cloud solution, include hardware costs similar to an internal build.

Build vs. buy: Mock cost analysis

In this hypothetical, buying appears to be the fiscally responsible decision. In reality, all software products require continual investment. When a new major version goes live, the initial customizations retrofitted to an organization’s service design, inevitably require rework.

The anticipated cost does not sync up with reality. When factoring the costs for customization rework and integrations for new releases at 25% of the overall Year 0 spend, the lines between building and buying get blurry very quickly. The bottom line becomes less of a factor. Instead, focus on the business value and cost associated with unused features—as well as the per-seat licensing fees, which inevitably increases as the organization grows.

BUILD SOFTWARE PRODUCT

BUY COTS/SAAS SOFTWARE PRODUCT

Buyer beware. Some customizations and integrations void or exceed standard support contracts—leaving troubleshooting up to the internal teams. Failing to maintain customizations delays critical enterprise security upgrades and core platform enhancements needed to preserve custom functionality. In these instances, a build approach lowers risk and increases the ability to respond to incidents.