Bring Me the Problem, Not the Prototype
One of the most common anti-patterns in software delivery is not a technical failure. It is a communication failure.
A stakeholder identifies a challenge, finds a tool, builds a spreadsheet, purchases a SaaS product, creates a low-code workflow, or commissions a proof of concept. They then present it to the software delivery team with a request:
"Can you productionise this?"
Or worse:
"Can you support this going forward?"
While the intention is usually positive, the outcome is often expensive, frustrating, and slow.
The most effective software teams are not order-takers. They are problem-solvers. The best outcomes emerge when stakeholders bring a problem to the team rather than arriving with a pre-selected solution and asking the team to operationalise it.
The Difference Between a Problem and a Solution
A problem describes an outcome that needs to be achieved:
- Customer onboarding takes too long.
- Engineers cannot find the information they need.
- Regulatory compliance activities are highly manual.
- Staff enter the same data multiple times.
A solution describes one potential way of addressing that problem:
- Build a Power App.
- Purchase a workflow tool.
- Create a custom portal.
- Develop a new integration.
The challenge is that when a solution is proposed first, the organisation immediately narrows its thinking. The discussion shifts from understanding the problem to defending the chosen approach.
The software delivery team is then deprived of its ability to explore alternatives and apply its expertise. Instead of solving the problem, it is asked to implement an assumption.
This runs counter to many of the principles behind agile delivery, which emphasise collaboration, learning, and adapting as understanding evolves. The Agile Manifesto specifically values customer collaboration and responding to change over rigid adherence to a predefined plan. Manifesto for Agile Software Development [Manifesto...evelopment], [framework....dagile.com]
Why Software Teams Need the Problem
Software engineers, architects, product managers, security specialists, and user experience professionals each bring different perspectives.
When presented with a problem, they can explore:
- Root causes
- User needs
- Technical feasibility
- Existing capabilities
- Operational implications
- Security concerns
- Long-term support requirements
- Cost of ownership
Very often, the solution that emerges from this discovery process is entirely different from what was originally imagined.
And sometimes, the most valuable finding is that the solution is not technical at all.
Sometimes the Best Solution Is No Software
Many organisations assume that every business problem requires a technology solution.
In reality, some of the highest-value improvements come from changes to processes, governance, training, or organisational structure.
Consider a team that repeatedly enters the same information into multiple systems.
A stakeholder might conclude:
"We need a new integration platform."
After further investigation, the delivery team may discover that the duplication exists because different departments maintain their own spreadsheets and have no agreed source of truth.
The solution may be:
- Better data governance
- Clear ownership of information
- Process simplification
- Additional training
No new application is required.
No integration is required.
No code is required.
The problem still gets solved.
This is an important mindset shift. The purpose of software delivery is not to create software. The purpose of software delivery is to solve business problems.
Success should be measured by outcomes, not by the amount of technology produced.
The Hidden Cost of "Productionising"
Creating a prototype is relatively easy.
Running a production service is not.
A prototype can be created in days or weeks. A production service may need to operate reliably for years.
When stakeholders ask a software delivery team to productionise an existing solution, they often underestimate the work required.
Production systems require:
- Authentication and authorisation
- Security reviews
- Monitoring and alerting
- Backup and recovery procedures
- Disaster recovery planning
- Performance and scalability testing
- Documentation
- Support processes
- Compliance controls
- Ongoing maintenance
What appears to be a finished solution is frequently little more than a proof of concept.
The delivery team then discovers that much of the original work must be redesigned or rebuilt before it can meet enterprise standards.
Code Is a Liability, Not an Asset
One of the most useful ways to think about software is to recognise that code itself is rarely an asset.
The business capability enabled by software may be valuable.
The code that delivers that capability is often a liability.
This idea can feel uncomfortable because organisations frequently celebrate the creation of new systems. Yet every line of code introduces a long-term obligation.
Someone must:
- Maintain it
- Secure it
- Monitor it
- Document it
- Upgrade it
- Support it
- Eventually replace it
Unlike a physical asset, software does not appreciate in value simply because it exists. In many cases, the opposite is true.
As technology evolves, code becomes harder to maintain unless continuous investment is made.
This is why experienced delivery teams ask a different question from stakeholders.
Rather than asking:
"Can we build this?"
They ask:
"Should we own this for the next ten years?"
Every new application, workflow, integration, database, or service creates operational overhead. If the same business outcome can be achieved through configuration, process improvement, or better use of existing platforms, then that option may represent the lower-risk and higher-value choice.
A useful rule of thumb is:
Every line of code should have to justify its existence.
Writing software should be a last resort after simpler alternatives have been explored.
An Example: The Employee Onboarding Application
Imagine a Human Resources department struggling with employee onboarding.
New starters need accounts creating, equipment ordering, mandatory training assigning, and access to various systems. The process feels slow and inconsistent, and managers frequently complain about delays.
Wanting to move quickly, the HR team commissions a supplier to build a custom onboarding application.
Six months later, they approach the software delivery team and say:
"The application is working well. Can you productionise it and support it?"
The delivery team's review uncovers several concerns:
- No integration with the corporate identity platform
- No audit trail for compliance purposes
- Sensitive employee information stored outside approved systems
- Duplicate functionality already available within existing HR and IT service management platforms
- No automated testing or deployment process
- No support or maintenance model
What initially appeared to be a finished solution now requires significant investment before it can be safely operated and supported.
What Could Have Happened Instead?
Now imagine HR approached the delivery team with the problem rather than the solution.
The conversation starts with:
"New employees take too long to become productive, and managers report inconsistent onboarding experiences."
After discovery, the team uncovers several root causes:
- Hiring managers frequently submit requests late.
- Equipment ordering follows different processes across departments.
- Existing workflow capabilities in the HR platform are underutilised.
- Ownership of onboarding tasks is unclear.
- Training requirements are not consistently documented.
The eventual solution includes:
- Standardising the onboarding process
- Clarifying responsibilities
- Automating notifications using existing platforms
- Improving reporting for hiring managers
- Providing targeted training for HR staff
A small amount of configuration is required.
No new application needs to be built.
No additional database needs to be maintained.
No long-term software support burden is created.
Most importantly, the business problem is solved.
This example highlights an important lesson: the custom onboarding application was never the goal. Faster and more consistent onboarding was the goal. By focusing on the problem rather than a preconceived solution, the organisation achieved the desired outcome with less cost, less risk, and far less technical complexity.
The Importance of Root Cause Thinking
Humans naturally jump to solutions.
When faced with a challenge, our instinct is to ask:
"How do we fix it?"
instead of:
"Why does it happen?"
This tendency is one reason why root-cause analysis techniques remain so valuable.
Toyota's famous Five Whys approach encourages teams to repeatedly ask "why" until the underlying cause is revealed rather than treating symptoms. The technique became a cornerstone of the Toyota Production System and remains widely used in continuous improvement practices. How Toyota Utilizes the 5 Whys Method for Problem Solving and 5 Whys [orcalean.com], [mindtools.com], [get-alfred.ai]
The same principle applies in software delivery.
A proposed solution is often an answer to a symptom.
The real opportunity lies in understanding the underlying business problem.
Moving From Supplier to Partner
When stakeholders bring finished solutions to delivery teams, they unintentionally position those teams as implementation factories.
When stakeholders bring problems instead, they create the conditions for genuine partnership.
The conversation changes from:
"Can you build this?"
to:
"What is the best way to solve this?"
That subtle change unlocks broader thinking, encourages innovation, reduces unnecessary complexity, and frequently uncovers solutions that no one initially considered.
It also changes how success is measured. Rather than rewarding teams for producing software, organisations begin rewarding them for solving problems. Sometimes the answer is a new system. Sometimes it is a process change. Sometimes it is simply removing unnecessary work.
Conclusion
Organisations often assume that software teams create the most value when they build software.
In reality, their greatest value often comes much earlier by helping to understand, challenge, and frame the problem itself.
When stakeholders arrive with a predetermined solution, they restrict options, increase the risk of technical debt, and may commit the organisation to years of unnecessary support and maintenance.
When they bring the problem instead, they allow the team to explore the full range of possibilities, including solutions that require little or no new technology.
This matters because software is not free once it has been built. Every application, workflow, and integration introduces a long-term maintenance burden. Code must be secured, monitored, maintained, upgraded, and eventually replaced. In that sense, code is often better viewed as a liability that enables business value rather than an asset in its own right.
The best software delivery teams understand a simple truth:
Their job is not to maximise the amount of software created. Their job is to maximise the amount of value delivered.
Sometimes that means building a system.
Sometimes it means improving a process.
Sometimes it means configuring an existing platform.
And sometimes the best software solution is realising that no new software is required at all.
References
Manifesto for Agile Software Development. Agile Manifesto. Values customer collaboration and responding to change. [Manifesto...evelopment], [framework....dagile.com]
What are the 4 Agile Values?. Productboard. Discussion of collaboration, feedback, and adaptability within modern software development. [productboard.com]
How Toyota Utilizes the 5 Whys Method for Problem Solving. Root-cause analysis and continuous improvement within the Toyota Production System. [orcalean.com]
5 Whys. Mind Tools. Explanation of countermeasures versus symptom-based fixes. [mindtools.com]
The Five Whys: Root Cause Analysis from Toyota. Historical background and application of the Five Whys technique. [get-alfred.ai]
