How do you know when you've discovered the real problem?

You've discovered the real problem when users describe the friction point in their own words, and solving it would directly reduce their effort or cost. If users can't articulate why they need the solution, you haven't found the real problem yet. Validate by showing a prototype—if users engage with it unprompted, the problem is real.

Should you always build a prototype before training a model?

Yes, unless the problem is already deeply validated in production. A prototype—even a rule-based system—costs a fraction of model training and answers the question of whether the problem is worth solving at all. If a simple heuristic solves it, you've saved months of work. If it doesn't, you've learned what the model needs to do differently.

What's the difference between design thinking and agile development for AI?

Agile focuses on iteration speed and delivery cadence. Design thinking focuses on problem validation before iteration. They work together: design thinking ensures you're building the right thing, and agile ensures you build it efficiently. Without design thinking, agile teams iterate fast on the wrong problem.

How do you align a technical team on user-facing metrics instead of model metrics?

Start by defining what the user problem actually is, then work backward to metrics. Ask: 'If this metric improved by 20%, would the user's experience improve?' If the answer is no, it's not a user-facing metric. Document the chain from user outcome (e.g., faster decisions) to the metrics that measure it (e.g., time-to-decision, adoption rate).

Can design thinking slow down AI development?

It can slow down the first two weeks, but it accelerates the overall timeline. Spending time validating the problem prevents months of building the wrong solution. Teams that skip discovery often ship, find low adoption, and iterate back to problem discovery anyway—at much higher cost.

AI Growth Through Design Thinking: A Systems Approach

The Cost of Solving the Wrong Problem

Most AI teams skip the hardest part: confirming they're solving a real problem. They inherit a business hypothesis, build a model, and launch. When adoption stalls, they blame the model accuracy. The model was never the bottleneck.

Tackling this yourself? Reach out to Saygin to talk it through.

The bottleneck is misalignment. You optimized for a metric that doesn't matter to users. You automated a task nobody wanted automated. You reduced latency on a decision nobody needs to make faster. Design thinking begins by rejecting the assumption that the problem is already known.

In technical organizations, this feels like wasted time. But the math is simple: spending two weeks validating the problem saves eight weeks of building the wrong solution. The discovery phase is not a soft skill—it's a force multiplier on engineering productivity.

Discovery: Defining the Real Constraint

Design thinking's first discipline is problem discovery. Not brainstorming solutions. Not debating which algorithm to use. Defining what the user actually needs.

Start with observation. Talk to the people who will use the system. Watch them work. Document the friction point—the specific moment where the current process breaks down. Is it speed? Accuracy? Trust? Cost? Availability? Each constraint demands a different AI approach.

Then reframe the problem as a constraint, not a feature request. Instead of "we need AI to write email subject lines," the real problem might be: "our email team spends 40 minutes per day on subject-line variants, and we can't scale that manually." Now you have a measurable constraint. You can test whether an AI solution actually solves it.

This step eliminates dead-end projects before engineering starts. A validated problem statement is worth more than a perfect model on an invalid problem.

Prototyping Before Training: Test the Assumption

Once you've defined the problem, the instinct is to train a model. Don't. Build a prototype first.

A prototype can be a spreadsheet, a rule-based system, a simple template, or a low-fidelity mockup. The goal is not accuracy—it's validation. Can users interact with this solution? Does it reduce the friction you identified? Would they actually use it?

Rule-based systems and heuristics are underrated in AI organizations. They're fast to build, easy to debug, and they answer the question: "Is this problem worth solving with a model at all?" Many problems that seem to require machine learning can be solved with domain logic and conditional rules. When they can, you save months of training, validation, and maintenance.

If the prototype validates the problem, then you have permission to train. You know the problem is real. You know the interaction model works. Now the model is an optimization, not an experiment.

Alignment: Metrics That Matter

AI teams often optimize metrics disconnected from user value. Model accuracy is the clearest example. A 95% accurate classifier that nobody uses grows nothing.

Design thinking forces alignment on what matters. Before building, agree: What will success look like to the user? How will you measure whether the AI actually solved their problem? Align on user-facing metrics before you optimize for model metrics.

User-facing metrics might include adoption rate, time saved per task, error rate on critical decisions, or user confidence in the output. Model metrics (precision, recall, F1 score) are tools to reach those targets, not targets themselves.

This alignment prevents the common failure mode: shipping a model that improves in the lab but fails in production because it doesn't match how users actually work. Cross-functional teams—product, engineering, design, and domain experts—agree on what success is. Then engineering builds toward it.

Iteration Speed: Why Design Thinking Scales AI Growth

The final advantage of design thinking is iteration speed. When you've validated the problem and aligned on metrics, each iteration cycle is tight and purposeful.

Early iterations test interaction design and problem fit. Middle iterations test whether the AI solution outperforms the rule-based baseline. Late iterations optimize performance and scale. Each phase has clear exit criteria. You don't waste cycles debating whether the problem is real—you already validated it.

This discipline is what separates AI products that grow from those that plateau. Growth requires rapid feedback loops. Design thinking creates feedback loops that inform both product and technical decisions, not just technical metrics. Teams that align on the problem first iterate faster and ship solutions users actually adopt.

The systems that scale are the ones where the AI team understood the constraint, designed for it, validated it, and then optimized. Not the ones that built the fanciest model and hoped adoption would follow.