AI projects often begin with an implementation decision: use a large language model, build a retrieval augmented generation pipeline, or deploy an agent that can take action.
That is usually too late in the conversation.
The first responsibility of a forward-deployed engineer, solution architect, or technical leader is to understand the outcome, the people involved, the workflow they follow, and the friction preventing progress, ahead of choosing the technology. Only then can the team determine whether AI belongs in the solution at all.
The objective is to make technical complexity earn its place, not to avoid advanced technology for its own sake.
The production paradox
Building a convincing AI demonstration is becoming easier. Turning that demonstration into durable business value remains difficult.
Teams can now assemble models, retrieval systems, tools, and user interfaces in days. That speed is useful, but it creates a subtle risk: technical feasibility can be mistaken for problem validation. A system may produce fluent answers, achieve a strong offline score, and still fail to improve the workflow it was meant to support.
| Delivery signal | What it can hide |
|---|---|
| The prototype works | The underlying problem may not matter enough to users |
| The model is accurate | The output may not help anyone decide or act |
| The workflow is automated | The team may have automated the wrong step |
| Users tested the product | The test may not reflect real operating conditions |
| The pilot generated interest | Interest may not become adoption or measurable return |
The central challenge is whether the intervention removes meaningful friction and improves an outcome someone owns, rather than whether the team can build the requested system.
This leads to the first rule of problem-first architecture: define the change in the business or operating environment before defining the software.
Begin with the outcome, not the request
Stakeholders usually describe solutions because solutions are easier to request than problems are to diagnose:
- “We need an AI assistant.”
- “Add semantic search.”
- “Build an agent to automate onboarding.”
- “Use recommendations to increase conversion.”
Each request may be reasonable, but none is yet a problem definition.
Before discussing architecture, establish six things:
- What outcome should improve?
- How is that outcome measured today?
- Where does the current workflow break down?
- Who experiences the friction?
- What constraints shape an acceptable solution?
- What evidence would justify continued investment?
“Improve onboarding” is too broad. “Reduce the percentage of customers who abandon onboarding when their source data fails validation” creates a boundary, a population, and a measurable outcome.
Once the outcome is precise, the architecture conversation becomes more useful. The team can compare interventions instead of assuming that the requested technology is the only path.
Identify the people the system must serve
Enterprise systems rarely have a single customer. A useful design must account for at least three groups:
| Stakeholder | What they need | Common failure when ignored |
|---|---|---|
| Economic owner | Revenue, cost, risk, or another measurable result | The project succeeds technically but loses funding |
| Operator | A faster, clearer, or safer way to complete work | Users bypass the system and return to familiar workarounds |
| Platform owner | Security, reliability, maintainability, and predictable cost | The pilot cannot survive production review or scale safely |
The economic owner justifies the investment. The operator determines whether the workflow is adopted. The platform owner determines whether the system can operate responsibly over time.
Serving one group while ignoring the others produces a fragile result. A useful prototype that cannot pass security review will not ship. A compliant system that adds friction will not be used. A popular tool that does not move a business measure will eventually lose support.
Problem discovery should therefore include all three perspectives before the architecture is fixed.
The root-cause trap
Literal requirements can be correct and still describe the wrong intervention.
Imagine asking someone to cut potatoes in half before putting them in a pot. They follow the instruction exactly, cutting each potato into two large pieces. Dinner still takes too long because the actual objective was to reduce cooking time by creating smaller, evenly sized pieces.
The instruction was satisfied. The intent was not.
Enterprise teams repeat this pattern when they translate a stakeholder request directly into a backlog. Consider an ecommerce product manager who asks for an AI recommendation engine to increase upsell conversion. The engineering team builds embeddings, provisions a vector database, and deploys a sophisticated ranking pipeline. The system then recommends products customers have already purchased.
The technical implementation may be sound, but the intervention does not address the real constraint. Further investigation might reveal that most lost conversions involve first-time visitors with no purchase history, unclear compatibility information, or unexpected shipping costs.
The important question is not “How should we build the recommendation engine?” It is “What prevents the customer from completing the next valuable action?”
A concrete example: marketplace liquidity
Consider a B2B marketplace that connects independent designers with enterprise software companies. Leadership observes a low contract-completion rate and asks the engineering team to build semantic matching between project briefs and designer portfolios.
The solution-first approach
The team builds a retrieval pipeline, embeds the marketplace content, and produces convincing matches in a demonstration environment. Offline evaluation shows that the system can identify designers whose experience resembles the project brief.
But completed transactions do not improve.
The system optimized matching quality without establishing whether matching was the constraint.
The problem-first approach
A problem-first team maps the workflow before selecting the intervention:
- A client drafts a project brief.
- Designers review it but cannot determine the budget boundaries, revision limits, deliverable format, or intellectual-property terms.
- They send clarification questions.
- The client responds later, if at all.
- Qualified designers disengage before matching becomes useful.
The primary bottleneck is incomplete input and communication latency, not discovery.
The team can now define victory: increase the percentage of complete briefs that receive qualified responses within an agreed time window. It can measure brief completeness, clarification volume, response time, and completed engagements.
The problem-informed architecture
The first intervention may be a structured brief validator rather than a semantic matching system. As the client drafts the brief, the product identifies missing operational terms and asks for them before publication.
That solution could begin with required fields, deterministic rules, and structured extraction. AI may help interpret free text where rules are insufficient, but it is a component of the intervention, not the entire premise.
| Solution-first question | Problem-first question |
|---|---|
| How accurately can we match portfolios? | Where and why do viable engagements stall? |
| Which vector database should we use? | What is the minimum information required to proceed? |
| Can an agent automate the workflow? | Which decision or handoff creates the delay? |
| Did the prototype perform well? | Did the intervention improve completed transactions? |
Semantic matching may still become valuable after brief quality improves. Problem-first architecture does not reject the original idea; it places it in the correct sequence.
Redefine the proof of concept
A traditional proof of concept asks whether the technology can work. For enterprise AI, that is necessary but insufficient.
A useful proof of concept should test three uncertainties:
- Technical feasibility: Can the system produce an acceptable result within the required cost, latency, privacy, and reliability boundaries?
- Workflow adoption: Will operators use the intervention under realistic conditions, including exceptions and time pressure?
- Outcome movement: Does the intervention improve the measure that justified the work?
| Dimension | Technical demonstration | Problem-first proof of concept |
|---|---|---|
| Primary objective | Show that the system functions | Reduce the most important uncertainty |
| Success evidence | Accuracy, latency, or throughput | Adoption, workflow improvement, and business effect |
| Test environment | Isolated or curated inputs | Representative users, data, constraints, and exceptions |
| Core question | Can we build it? | Should we invest in operating it? |
Consider a logistics team that builds a model to predict shipping delays. The model performs well in offline evaluation, but dispatchers ignore it in production. Interviews reveal that a probability score does not help them resolve the situation. They need the likely cause, the affected shipment, the available alternatives, and the authority required to act.
The prediction was technically useful but operationally incomplete. The proof of concept should have tested the decision workflow, beyond the forecast alone.
A practical diagnostic playbook
Before selecting a model, framework, or infrastructure pattern, run the opportunity through five steps.
1. Define victory in operating terms
Name the measure, its current baseline, the desired direction, the affected population, and the evaluation window. If the team cannot describe what should change, it is not ready to choose an architecture.
2. Follow the request to its economic driver
Use the Five Whys or a similar root-cause method to move from a requested feature to the underlying constraint.
For example:
- Request: “We need a conversational onboarding assistant.”
- Why? Customers abandon onboarding.
- Why? They cannot complete the data-import step.
- Why? Their files require manual reformatting.
- Root constraint: inconsistent source data and weak validation.
The appropriate first intervention may be an ingestion and validation workflow, not a chat interface.
3. Audit the shadow system
Observe how people complete the work today. Look for spreadsheets, email threads, copied templates, private notes, unofficial messaging channels, and local scripts.
These workarounds reveal both unmet needs and adoption requirements. They also establish the real baseline. If the proposed system is slower or less flexible than the shadow process, users will return to what already works.
4. Find the minimum viable intervention
Ask what smallest change could produce evidence. It may be a policy clarification, a required field, a database query, a workflow notification, or a human-operated service.
Start with the least complex intervention capable of testing the hypothesis. Complexity can be added when evidence shows where it is needed.
5. Run the workflow manually
Before automating a new process, operate it manually for a limited period. A concierge trial can expose missing inputs, ambiguous decisions, exception paths, and trust barriers faster than an automated build.
If a knowledgeable person cannot produce consistent value while performing the workflow manually, adding a model is unlikely to repair the underlying design.
Make AI earn its place
AI belongs in the design when the problem requires capabilities that simpler methods cannot provide economically: interpreting unstructured information, recognizing patterns across large datasets, generating useful drafts, adapting to varied language, or coordinating bounded actions under explicit controls.
It does not belong merely because the organization has access to a model or because an AI demonstration will attract attention.
The most effective technical leaders are not measured by the complexity of the stack they deploy. They are measured by whether people adopt the result, whether the intended outcome improves, and whether the system can be operated safely and economically.
Understand the outcome. Map the workflow. Find the constraint. Test the smallest intervention. Then select the technology.
The code is the final expression of that understanding.