Designing for measurable business outcomes

Business requests often arrive as features: "Build a claims app" or "Add an AI agent to customer service". A feature tells you what to build. It does not tell you why. 

Before you design, ask the business: 

• What problem are we solving? 
• How does this problem show up today, and what does it cost? 
• What will be different when we succeed? 
• Who will notice the difference first: customers, staff, or management? 

Example: An insurer asks for a new claims application. After a few questions, you learn the real problem: simple claims take 10 days to settle, which is leading to customer complaints. The outcome is no longer "a new claims application".  It is "Reducing the settlement of simple claims from 10 days down to two days".

That one sentence gives your design a clear direction. 

Turn the outcome into a few clear measures 

Success metrics and key performance indicators (KPIs) are the measures that help determine whether the solution delivers the intended business outcome. Each measure defines what you track, the current baseline, the target, and the timeframe for achieving it.

A good measure has four parts: 

Agree on these measures with the business before design starts. Write them down and agree who owns each one. 

Keep the list short: three to five measures are enough. If you track 20 measures, nobody watches any of them. 

Example measures for the claims project: 

• Average time to settle a simple claim: from 10 days to two days 
• Claims settled without manual work: from 0% to 40% 
• Time an adjuster spends on each claim: from 45 minutes to 20 minutes 
• Customer complaints about claim delays: down by half 

When you know the measures, use them to guide your design. For each major decision, ask: Which measure does this move? The following table maps each design decision to the measure that it affects.

If a feature does not affect any measure, question its value. You might still need the feature to meet a compliance or operational requirement, but make that decision intentionally. 

Not every technical decision maps directly to a measure. Choices such as data model or security design support the outcome indirectly. Focus on the major decisions and ensure that each one contributes to the intended business outcome. 

Explain your decisions in the language of the business 

The business approves what it understands. Explain your design in terms of the outcome, not the technology. 

• Instead of: "We will use an AI agent with bounded large language model (LLM) instructions for document extraction." 
• Say: "An AI agent reads claim documents and enters the relevant information, which can reduce adjuster time from 45 to 20 minutes per claim.” 

When you link each decision to a number the business cares about, approval becomes easier and trust grows. 

Plan the data you need to measure 

After go-live, business stakeholders ask, “Did the solution produce the intended outcome?” The team cannot answer the question if the application does not capture the required data. 

Design the data you need from the start by: 

• Recording when each case starts and ends. 
• Recording whether a person, a rule, or an AI agent handled the case. 
• Recording the reason for each delay, return, or escalation. 
•  Capturing today's numbers before go-live to establish a baseline for measuring improvement. 

Measure after go-live, and improve 

Go-live is not the end of the project. Review the measures with the business at regular intervals, for example after 30, 60, and 90 days. Use the review results to determine the next steps: 

• If a measure improves, show the business the result. 
• If the measure does not move, find out why. Check whether users skip a step, the AI makes errors, or the rules are too strict. 
•  Incorporate feedback into the next release. 

This cycle turns a one-time project into a solution that keeps delivering business value. 

Common traps to avoid 

Even experienced teams that agree on outcomes at the start can lose sight of them during delivery. Deadlines, changing requirements, and the excitement of new AI capabilities can pull attention away from what the business needs. Watch for these common traps: 

AI helps you build faster, but speed alone does not prove value. The business judges your work by what changes: faster service, lower costs, and happier customers. When you design with clear measures and prove the results, "business value" stops being a slogan and becomes a result the business can see.  That is what sets an LSA apart in the AI era. Instead of just building solutions faster, you prove they make a difference. 

Check your knowledge with the following interaction: