Reading Time: 12 minutes

Table of Content

Before You Build With AI, Architect the Outcome

Before You Build With AI
A practical perspective on keeping the grand vision in sight while solving a real business problem now.
In my last article, AI Adoption Isn’t AI Enablement, I suggested starting with a simple question:
What are we trying to make better?
I still believe that is where an AI conversation should begin. But it naturally leads to another question: Once I know what I want to make better, what do I actually do next?
Throughout my career, I have approached technology by keeping the larger vision in sight while solving the problems immediately in front of the business. I want to understand where we ultimately want to go, but I don’t believe we need to build the entire vision before we can start creating value.
AI hasn’t changed that thinking. What it has changed is how quickly we can move.
Today, we can go from an idea to something tangible at a pace that would have been difficult to imagine even a few years ago. That creates enormous opportunity, but it can also push us toward two extremes. We can jump straight into AI and start building simply because we can. Or we can spend months developing an elaborate AI strategy, architecture and governance structure before solving a single real business problem.
Keep the grand vision in sight. Solve a real problem now. Make sure what you build today can support where you want to go tomorrow. Then learn from actually using it.
That is what I mean by architecting the outcome.

Start With Where You Want to Go

When I use the word architecture, I don’t mean that every AI initiative needs to begin with a complicated technical design. I mean understanding the destination.
Suppose customer onboarding currently takes five days. Information arrives through different channels, employees manually review documents, information gets entered into multiple systems, and people spend time chasing whatever is missing. It would be easy to start by saying, “Let’s build an AI agent for onboarding.” I would start somewhere else: What does better look like?
Maybe the goal is to reduce onboarding from five days to one without sacrificing quality or the judgment people bring to the process. Now we have something meaningful to work toward.
We can understand how onboarding works today. Where does information come from? What causes the delays? Which steps follow clear rules? Which ones require someone to interpret information or make a judgment? Where are employees spending time on repetitive work that adds little value?
AI may be part of the answer. Automation may handle another part. Connecting two existing systems may eliminate an entire step. And there may be places where an experienced person should continue making the decision.
The business outcome should shape the solution, not the other way around.

Think Big, but Start With Something Real

Once you start looking at a business problem this way, you begin seeing everything else that could be improved. One process touches another. That process depends on another system. The data could be better. Another department has a similar problem. An integration needs improvement. Soon, what started as one use case can turn into a much larger transformation initiative.
Having that broader view is valuable. In fact, I believe it is necessary. But seeing the larger opportunity doesn’t mean we need to solve all of it now.
I prefer to understand the grand vision and then ask: What meaningful part of this can we solve now?
Not a demonstration created simply so we can say we are experimenting with AI. Pick a real business problem—something small enough to manage, but important enough that solving it creates meaningful value.
Then get it into use, learn from it and allow those lessons to influence what comes next. This isn’t a new way of thinking for me. What AI changes is the speed at which that cycle can now happen.

You Don't Have to Build It Yourself

There is an important distinction here. When I say businesses should start working on a real use case, I don’t mean the business leader needs to become an AI developer.
Your greatest contribution may be something much more valuable: you understand the business.
If you lead operations, you understand how the work actually gets done. If you lead finance, you understand the decisions your team makes and the information behind them. If you lead sales, you understand your customers, your process and where opportunities are won or lost. You know where people struggle. You know the exceptions. You know what customers expect. And you probably have a pretty good idea of what a better outcome would look like.
Historically, turning that knowledge into something a technology team could build could itself be challenging. A business leader explains the need. Someone translates it into requirements. Those requirements may pass through an analyst, architect or project manager before they reach the people actually building the solution. Every handoff creates another opportunity for context to be lost.
AI can help shorten that distance. A business leader can now describe the problem to AI in plain language. Explain how the process works today. Explain what isn’t working. Describe the people involved, the information they use, the decisions they make and the exceptions you already know about.
Then let AI question you. What haven’t we considered? What information is missing? What exceptions should we think about? What would a developer need to know? What questions would someone designing this system normally ask?
You don’t have to know all of the technical terminology. AI can help take that conversation and organize it into structured business requirements. It can identify workflows, business rules, user roles, information requirements, exceptions and even criteria that could eventually be used to determine whether the solution is working correctly.
That doesn’t mean blindly accepting an AI-generated requirements document and handing it to a developer. It means you can walk into that conversation far better prepared.
An AI specialist, developer or technology partner can then work with you to challenge those requirements, understand the larger vision and determine what the solution should actually look like. The business expert continues steering what needs to be accomplished and why. The technology expert determines how it should be built. And increasingly, AI can help translate between the two.

I Saw This From the Technology Side

My own situation gave me an opportunity to explore this from another angle.
In a recent review, I was looking at estimates for a software development effort. I’ve spent a significant part of my career around software development, from small deliverables and development teams to large, enterprise-grade applications. The estimates themselves didn’t surprise me. They were reasonable within the traditional development model.
But I’ve never been completely satisfied with the pace of that model.
Traditionally, a business need moves through several stages. Requirements are gathered and translated. A solution is designed. Developers build it. QA tests it. Gaps are identified. Changes go back to development. The solution gets tested again and eventually makes its way back to the business. Every one of those disciplines is important. The challenge is the friction that can accumulate between them.
Context can be lost as requirements move between people. A developer can make a perfectly reasonable decision without knowing something the business assumed was obvious. QA can identify something late that would have been easier to address earlier. Changes create additional work and testing. Technical debt can accumulate while progress slows. Meanwhile, the business doesn’t stop changing simply because development is underway.
I’ve seen that challenge throughout my career. Looking at those recent estimates made me ask a different question. I wasn’t questioning the developers or whether their estimates were reasonable. I was questioning the model.
Could AI change the way we move from a business need to a working solution?
So I decided to test it.

Start Small Enough to Learn

Rather than trying to redesign our entire development process around AI, I selected a contained piece of the work and went hands-on.
I already understood the business requirement, the application and the underlying architecture. I knew where the larger solution needed to go. I wasn’t asking AI to determine the destination for me. I wanted to see how differently we could get there.
AI could generate code remarkably quickly. It could understand our existing development patterns and work within them. But simply proving that AI could write code wasn’t particularly interesting. What interested me was whether some of the distance between the business requirement and a working solution could begin to collapse.
As I worked through the use case, I brought more of the traditional development process directly into the AI workflow. I made the business requirements explicit. I provided our development and architectural patterns. I incorporated validation and QA expectations. I gave it direction around the user experience. I could see what was being produced, challenge it, provide additional context and immediately work through another iteration.
I also discovered that there was no reason to expect one AI model to do everything particularly well. At times, another model or tool could help explore an interface or think through an approach differently, and that output could become better context for the next stage.
In this particular experiment, a piece of work estimated in weeks was completed in hours.
That’s a dramatic result, but I want to be careful about what I take from it. I’m not suggesting that every development project can suddenly be reduced from weeks to hours. My knowledge of the business, the application and the architecture mattered enormously. I could recognize when something wasn’t right, provide context AI didn’t have and understand the consequences of the decisions being made.
What interested me most was something broader: the distance between business thinking, design, development and validation had become much smaller.
And while working through that contained use case, I learned things about how I wanted AI incorporated into the process that I would not have completely understood by trying to design the perfect AI-enabled development model beforehand. That reinforced the larger lesson for me: start with the vision, understand the outcome, put enough structure around the first step that you’re moving in the right direction, and then start learning from something real.

Let the First Use Case Teach You

The same principle applies well beyond software development. Imagine applying it to customer onboarding, preparing proposals, reviewing documents, analyzing financial information, responding to support requests or any number of business processes.
Once AI is working against an actual problem, you begin discovering things that are difficult to see on a diagram. The information you thought was sufficient may not be sufficient. Employees may be handling exceptions nobody documented because they’ve simply learned what to do. AI may be exceptional at one part of the process but need more guidance in another. Something you assumed required AI may actually be handled more reliably through simple automation. Or you may discover an opportunity that wasn’t obvious when you began.
Those discoveries aren’t necessarily failures in the original plan. They are knowledge. And that knowledge should influence what you build next.
You need enough planning to avoid chaos, but enough action to discover what you don’t yet know.

Match the Controls to the Risk

Starting small doesn’t mean being careless. There is a big difference between asking AI to summarize information for an employee and allowing an AI agent to approve a financial transaction, communicate independently with a customer or change information inside a critical business system.
The more serious the consequence of getting something wrong, the more controls we need around it. Early on, AI might recommend while a person makes the final decision. Access to certain information might be restricted. Outputs might be reviewed until everyone becomes comfortable with their reliability.
As confidence grows and the organization learns where AI performs well and where it needs help, those boundaries can evolve. You don’t need to answer every future governance question before beginning. You do need enough structure and common sense to make sure the way you’re learning matches the risk you’re taking.

Build Today's Solution With Tomorrow in Mind

This is where the grand vision comes back into the picture. Starting small should never mean thinking small.
If I know a solution may eventually connect several parts of the business, I want to understand that before building the first piece. If more systems will eventually participate, I want to consider that. If something that begins with ten users could eventually serve hundreds, I don’t want today’s decisions to unnecessarily prevent that.
But understanding those possibilities doesn’t mean we have to build all of them today.
Know where you’re going. Build what you need now. Don’t unnecessarily close the doors you’ll need later.
For small and midsize businesses, I think this is particularly important. Most SMBs don’t have unlimited technology budgets, dedicated AI teams or the luxury of spending a year developing an enterprise AI transformation before seeing value from it. And increasingly, I don’t think they need to.
AI gives smaller organizations an opportunity to solve meaningful problems incrementally while still working toward a much larger vision.

So What Do You Do Monday Morning?

If you’re a business leader who believes AI could create value in your organization but doesn’t know where to begin, don’t start by trying to transform the entire company.
Pick one thing you genuinely want to make better. Define what better means. Understand how it works today. Talk to the people who actually do the work. Find where time is being lost, where information gets stuck, where repetitive work exists and where human judgment matters.
Then think about where you ultimately want that process to go. Use AI to help you articulate what you know. Let it question you. Let it help uncover gaps in your thinking and organize the business requirements.
Then bring in someone who understands how to build with AI. You don’t need to tell that person how to architect the technology. Give them something more valuable: a clear understanding of the business problem, the desired outcome, the people involved, the rules, the exceptions and the larger direction.
Together, determine what the first meaningful piece should be. Put enough thought and appropriate controls around it that you’re not creating a dead end or taking unnecessary risk. Then build it. Put it into use. Learn from it.
Take what you learn back into the larger vision and decide what comes next. Then repeat.
I believe this is one of the most practical ways businesses—especially SMBs—can move from talking about AI to actually becoming enabled by it.
You don’t need to know every step before taking the first one. But you should know where you’re trying to go.
Keep the grand vision in sight. Solve a real problem now. Learn from it. Then use what you learned to build the next piece better.
That, to me, is how you architect the outcome.
Scroll to Top