Five Questions That Create Better Technology Value
Why this matters:
By the time an enterprise technology project reaches implementation, some of the most important success conditions may already have been missed.
When that happens, blame for project failure usually falls on the product, the vendor, or the customer. But the deeper issue is often simpler: the right questions were asked too late.
This article unpacks five questions vendors and customers should frame earlier if they want technology investments to deliver successful business outcomes.
Mary Elizabeth Porray’s recent article, Stop Building Technology No One Asked For, makes a point that should resonate across the enterprise technology sector: technology should not be built before the underlying customer problem is properly understood.
That argument is difficult to dispute, as organisations continue to invest heavily in new platforms, digital initiatives, automation programmes, and now AI-enabled capabilities, often before the business problem, value case, and success conditions are sufficiently clear.
But there’s another side to this issue.
If organisations need to ask better questions before building or buying technology, then enterprise technology vendors need to become better at helping customers answer those questions.
In increasingly complex enterprise markets, the vendor that can help a customer make a better decision may become more valuable than a vendor that simply presents the strongest functionality.
Technology failure rarely starts with the technology
When enterprise technology projects fail, the explanation that follows is often too narrow.
| Common explanation | Deeper question |
|---|---|
| The platform was too complex. | Was the operating environment properly understood? |
| The implementation was poorly managed. | Were success conditions visible before delivery began? |
| The customer was not ready. | Was readiness assessed before contract signature? |
| Users resisted change. | Was adoption treated as a value condition, not a training issue? |
| The business case was weak. | Was value validated, or merely estimated? |
| The data was not clean. | Was data readiness tested early enough? |
| The executive sponsor disappeared. | Was executive ownership real, or only assumed? |
| The project team underestimated the operational impact. | Was the business system around the technology properly diagnosed? |
Each of these may be true, but they are usually symptoms of a deeper problem: the organisation did not validate the business problem, value case, stakeholder alignment, and success conditions before the project moved forward.
In other words, technology often begins to fail before the technology is deployed.
It can begin in the first conversations between vendor and customer, when capability is positioned before the problem is properly understood. It can begin when a business case is created around expected benefits rather than validated operating realities. It can begin when stakeholders agree to the purchase, but not to the organisational change required to make the investment successful.
This is especially relevant in enterprise systems environments such as workplace technology, facilities management, asset management, ERP-adjacent platforms, operational systems, and AI-enabled business platforms. These solutions rarely affect only one team or one process. They cut across functions, operating models, data flows, governance structures, and executive priorities.
A technically sound solution can still fail if the surrounding business system is not ready to absorb it.
Complexity changes the vendor’s responsibility
Mary Porray points to shifting market conditions, economic uncertainty, evolving customer needs, and rapid technological change as reasons why technology can fall short of expectations.
Those forces matter. But in enterprise technology, they combine with another force: complexity.
| Area of complexity | What changes for the vendor |
|---|---|
| Buying centre complexity | More stakeholders need to understand and agree on value. |
| Operating environment complexity | The solution touches more processes, teams, and constraints. |
| Stakeholder complexity | Different groups may define success differently. |
| Value-case complexity | Benefits may be financial, operational, strategic, reputational, or risk-related. |
| Implementation complexity | Delivery depends on data, process, governance, and adoption conditions. |
| Risk complexity | Customers are more cautious about disruption, cost, and accountability. |
That changes the role of the vendor.
The vendor’s job is no longer simply to prove that the technology works. It is to help prove that the customer is solving the right problem, for the right reasons, with the right conditions in place for success.
That requires a different kind of commercial capability. It requires vendors to move beyond product positioning and into structured problem validation, stakeholder alignment, value definition, and success governance.
VUCA and the moving targets
This is sometimes described as a VUCA environment: volatile, uncertain, complex, and ambiguous.
Customers are being asked to make high-cost technology decisions in conditions where the problem, priorities, stakeholders, constraints, and expected value may still be moving.
The five questions that vendors need to help customers answer
Porray’s article suggests that organisations should ask a set of fundamental questions before developing a technology solution.
These questions are just as important in the vendor-customer relationship.
| Customer question | Vendor-side responsibility |
|---|---|
| What value are we trying to create? | Help clarify business value, not just product benefit. |
| What problem needs to be solved? | Validate the underlying business issue before positioning capability. |
| How will this support our overall goals? | Connect the solution to strategic, operational, and financial priorities. |
| What do we need to get right for this to work? | Surface readiness issues across data, process, governance, and change. |
| How will we measure success? | Define value measures before the proposal becomes the project. |
In fact, they may be more important there, because the commercial process often determines which assumptions become embedded in the proposal, the business case, the delivery plan, and the customer’s internal expectations.
1. What value are we trying to create?
Too many technology conversations start with capability.
Value only exists when a capability improves something that matters to the customer. That could mean reducing cost, improving compliance, increasing asset uptime, improving space utilisation, reducing risk, accelerating decisions, improving employee experience, or enabling a strategic operating model shift.
Capability matters. But capability is not value.
The vendor’s responsibility is to help the customer move from functional interest to value clarity.
That means asking:
What business outcome does this support?
Who cares about that outcome?
What is the cost of the current problem?
What changes if the problem is solved?
What happens if nothing changes?
Without this work, value remains abstract. The customer may understand what the technology does, but not why it matters enough to act.
2. What problem needs to be solved?
Enterprise technology projects often begin with a stated problem that is not yet the real problem..
| The customer may say... | But the underlying issue may be... |
|---|---|
| “We need better reporting.” | Poor data governance, fragmented processes, weak executive visibility, or slow operational decision-making. |
| “We need workflow automation.” | Unclear accountability, inconsistent process design, or weak cross-functional coordination. |
| “We need an AI-enabled capability.” | Unstandardised data, decisions, and workflows that AI would depend on. |
| “We need a new platform.” | A fragmented operating model, poor process ownership, or lack of integration across teams and systems. |
| “We need better user adoption.” | Weak change readiness, unclear value to users, or insufficient operational ownership. |
If vendors accept the first stated problem too quickly, they risk selling into a symptom.
The better role is to help the customer diagnose the issue more carefully. What is happening? Where is it happening? Who experiences it? What evidence supports it? What is ambiguous? Which adjacent processes or systems are affected?
This does not require the vendor to become a management consultant in the traditional sense. But it does require enterprise vendors to develop stronger diagnostic discipline.
If the problem is poorly understood, the solution will be poorly aimed.
3. How will this support the customer’s overall goals?
Technology initiatives often struggle when they are justified at one level of the organisation but not connected to broader strategic priorities.
All of these may be valid. But unless they are connected, the initiative can lose coherence.
The vendor’s role is to help link the solution to the customer’s wider goals. That means moving beyond departmental benefit statements and helping the customer articulate how the investment supports strategic, operational, and financial priorities.
This is particularly important in complex enterprise systems, where the buying decision may involve multiple executives, technical evaluators, operational leaders, finance stakeholders, and end-user groups.
If each stakeholder sees a different version of the value case, the project may still proceed, but alignment will be fragile.
The vendor should help create a shared view of success before the customer commits.
4. What needs to be right for this to work?
This may be the most underdeveloped question in enterprise technology selling.
Vendors are naturally inclined to focus on what their solution can do. Customers are naturally inclined to focus on what they want the solution to achieve. But successful outcomes depend on the conditions around the technology.
Successful outcomes depend on the conditions around the technology. Those conditions usually fall into four areas: data and systems readiness, process and governance readiness, people and change readiness, and ownership and measurement readiness.
When these conditions are ignored during the commercial process, they reappear later as delivery risk.
This is why vendors need to become more transparent and more rigorous before the deal is signed. Not every customer is ready for every solution. Not every desired outcome is achievable under current conditions. Not every implementation risk can be solved by the project team after the fact.
That does not mean slowing everything down. It means making the success conditions visible early enough to act on them.
A vendor that can help a customer understand readiness is more valuable than a vendor that simply avoids difficult questions until implementation.
5. How will we measure success?
Most enterprise vendors understand the importance of value, readiness, governance, adoption, and measurement in principle. The issue is timing.
These questions are often treated as post-sale matters. They become implementation topics, customer success topics, or renewal topics.
That is too late.
By the time a project reaches delivery, many of the assumptions that determine success have already been made. The problem has been framed. The solution has been selected. The business case has been approved. The project scope has been agreed. Expectations have been set.
Success measures are often created after these decisions, rather than before them. They may be added during implementation, during customer success handover, or only when renewal or expansion becomes a priority.
By then, the original commercial assumptions may already have faded. Delivery teams may not know which outcomes mattered most. Customer success teams may inherit a vague expectation of value without a clear baseline. Executives may judge success against criteria that were never made explicit.
The result is predictable: the project may go live, but value remains contested.
This is why measurement needs to begin earlier. Before the proposal becomes the project, the vendor and customer should have a shared view of:
What outcomes are expected?
Which metrics will indicate progress?
What baseline exists today?
Who owns the result?
What evidence will demonstrate improvement?
When will value be reviewed?
This is not just a reporting exercise. It is a governance discipline.
Early conversations do not simply qualify opportunities. They shape the customer’s understanding of the problem, the perceived value of solving it, the stakeholders who need to be involved, and the conditions required for success.
If those assumptions are weak, untested, or politically convenient, delivery inherits the risk.
The right time to ask these questions is before the proposal, not after contract signature.
This creates continuity between selling, delivery, adoption, and customer success.
If success cannot be measured, it cannot be managed. If it cannot be managed, it is unlikely to be realised consistently.
Value Breaks at the Handoffs
One reason these questions fall through the cracks is that ownership is fragmented or disconnected.
Each function sees their own part of the picture. But the customer experiences one continuous journey.
That creates a problem. If no one owns the value thread from first conversation through adoption, value becomes vulnerable at every handoff.
Everyone contributes to value. But the value thread needs explicit ownership.
The answer is not to make one function responsible for everything. The answer is to create a shared commercial discipline around value validation and lifecycle continuity.
| Function | Contribution to the value thread |
|---|---|
| Sales / Business Development | Identify whether the opportunity is real and worth pursuing. |
| Solution Engineering / SE | Validate problem, evidence, stakeholders, and business impact. |
| Value Engineering | Convert validated issues into a credible investment case. |
| Commercial Leadership | Ensure scope, proposal, and governance reflect real success conditions. |
| Delivery | Implement against the agreed value assumptions. |
| Customer Success | Carry value into adoption, review, renewal, and expansion. |
| Executive Sponsorship | Maintain organisational commitment to the outcomes being pursued. |
The point is not organisational perfection. The point is continuity.
Enterprise vendors need a value thread that runs from first conversation to customer success.
Better Questions Create Better Outcomes
For many years, enterprise technology vendors could differentiate through product capability, implementation experience, market reputation, or price.
Those still matter. But in increasingly complex markets, they may not be enough.
Customers are becoming more cautious. Buying groups are larger. Budgets are more scrutinised. AI has raised both ambition and risk. Executives are under pressure to prove that technology investments create measurable business value.
In that environment, the most valuable vendors will not simply be those with the strongest functionality. They will be the vendors that help customers make better decisions.
That means helping customers:
- validate the problem before they commit to the solution.
- helping them define value before they approve the business case.
- helping them understand readiness before they launch the project.
- helping them measure success before success becomes subjective.
- helping them govern value after the deal is signed.
The future of enterprise technology selling is not more persuasive product presentation. It is better problem validation, better value articulation, and better continuity from decision to outcome.
Technology creates value only when it solves a problem that matters, under conditions that allow success, with measures that prove progress.
Customers need to ask those questions.
And vendors must help to answer them.