Software Is Built. Who Makes It a Product?

In my previous blog, AI Makes Building Easier. Should You Still Buy? I explored why building software is only part of the equation. A product is more than working code. It's the problem you're solving, the design principles behind it, the decisions that shape the experience, and the vision connecting it all.

But there's a question that follows: once you've built that product, how does the customer understand the thinking behind it? Who connects the vision of the people who built it to the decision of the person who might buy it?

I believe this is one of the most important roles of Solutions Engineering.

When Anyone Can Build Software, Why Buy?

AI is changing the economics of building software. Tools like ChatGPT and Claude make it possible to develop applications, automate workflows, and build prototypes with far less effort than before. The barrier to creating something that works is falling.

That makes the build-versus-buy decision more interesting. If a company can build an internal tool, why pay for an existing product?

The answer isn't always about features or development costs. When you buy a product, you're also buying the thinking behind it: the problems its creators chose to solve, the design principles they followed, the trade-offs they made, and the experience they've refined by working with customers.

Consider the difference between building a tool that automates one workflow and buying a product designed to manage that workflow as part of a wider business process. Both might appear to solve the immediate problem. But what about integrations, exceptions, security, maintenance, changing requirements, and the lessons the vendor has learned from hundreds of customers?

These considerations are part of the product's value, even when they aren't immediately visible in a feature comparison.

Research supports the importance of this thinking. In its Business Value of Design study, McKinsey tracked 300 publicly listed companies over five years. Companies in the top quartile of its Design Index achieved 32 percentage points higher revenue growth and 56 percentage points higher total returns to shareholders than their industry counterparts over the period. These are correlations, not proof that design alone caused better performance. But the findings reinforce an important point: the thinking and decisions behind a product can have significant business implications.

The challenge is that customers don't automatically see that thinking. They see features, pricing, product pages, and demonstrations. The reasoning behind the product can remain invisible.

A vendor may have spent years building a product with a clear vision. But unless the customer understands that vision and its relevance to their business, much of its value remains unrealised.

Who Makes the Vision Visible

Customers today can research vendors, compare products, read reviews, and use AI to explore technical documentation before speaking to a salesperson. They can often arrive at a demo knowing what the software does.

What they don't necessarily know is why it was built that way, what problems its design choices address, and how those choices translate into value for their business.

Gartner's 2026 research on B2B buying illustrates this shift. In a survey of 645 B2B buyers, 45% said they had used generative AI during a recent purchase, while 69% preferred to validate AI-generated insights with sales representatives. Buyers are increasingly self-directed, but they still need help validating information and making decisions.

That distinction is where Solutions Engineering matters.

An SE isn't a demo machine. The role isn't simply to show features, answer technical questions, or prove that a product works. It's to connect the product's vision with the customer's reality.

Imagine a customer deciding whether to build an internal solution or buy an existing platform. A standard demo might show how the product automates a workflow. A Solutions Engineer goes further. They uncover why that workflow matters, explore the customer's requirements, explain the reasoning behind the product's approach, and demonstrate how its capabilities address the broader problem.

They make the invisible visible: the product thinking, the design decisions, the experience built into the solution, and the problems the vendor has already worked to solve.

This is what helps a customer make an informed build-versus-buy decision. Not a longer list of features, but a clearer understanding of the value behind them.

The work also starts before the demo. I tell my team to disqualify early and qualify hard. If a product cannot meet a customer's fundamental requirements, we should establish that during discovery. If a critical technical blocker surfaces late in solution scoping or contracting when we could reasonably have identified it earlier, we've missed an opportunity to make a better decision.

Not every qualified opportunity will close. Competition, budget, and changing priorities will always play a role. The goal isn't to win every deal. It's to help the customer and the business understand the problem, validate the solution, and make the right decision.

And the value flows both ways. Every customer conversation gives the SE an opportunity to bring real-world insight back to Product, Marketing, RevOps, and Customer Experience. Those teams learn where the product's vision resonates, where customers struggle to see its value, and what needs to improve.

Solutions Engineering is the connection between what the business has built and what the customer needs to understand.

The Value Leadership Needs to Recognise

Despite this contribution, Solutions Engineering is still sometimes viewed primarily as a function that supports demos and technical validation. SE leaders often have to justify headcount without the broader value of the role being fully recognised.

The 2025 Sales Engineering survey from the North American Association of Sales Engineers, published in February 2026, offers a useful perspective. Among its respondents, 52% identified increasing win rates as their clearest measurable contribution, 38% pointed to strategic account influence, and 26% cited de-risking deals through security, compliance, and technical validation. The survey was voluntary and self-selected, with 42 respondents, so these figures are directional rather than industry-wide benchmarks. Still, they illustrate that the role creates value well beyond delivering demonstrations.

When we measure SEs only by the number of demos delivered or the number of account executives supported, we miss that value. We overlook the poor-fit opportunities disqualified early, the risks uncovered before they become expensive problems, the customer decisions strengthened through discovery, and the insights that improve the product itself.

An SE who identifies a fundamental mismatch during discovery might never deliver a demo. But that person may have saved the account executive, sales manager, and other teams hours of work on an opportunity that was never going to close.

An SE who helps a customer understand why an existing product is a better choice than building internally might influence a decision worth far more than the time spent in a single meeting.

These contributions should matter when leadership evaluates the function. Headcount shouldn't be based purely on demo capacity or a fixed ratio of SEs to account executives. It should reflect the role's impact on qualification, solution validation, customer confidence, and the productivity of the wider organisation.

AI makes this argument more urgent. As building software becomes easier, vendors will face more customers asking why they should buy rather than build. Having a product that works will not be enough. Businesses will need to communicate why their product exists, what makes its approach valuable, and what the customer gains by choosing it.

Solutions Engineering plays a critical role in making that case. Not by persuading every customer to buy, but by helping each customer understand what they're choosing and why it matters.

The people who build software create its capabilities. The people who shape the product give it direction. Solutions Engineers bring that vision into the customer's world, where its value can finally be understood, challenged, and acted upon.

Software is built. A product is shaped by a vision. Solutions Engineering helps the customer see that vision and decide whether it is worth buying.