TL;DR
AI has made it possible for business owners to build tools, workflows, and internal systems that once required developers. But access to building does not guarantee that we will build the right thing.
The owner still has to identify the problem, define the outcome, provide the context, and decide where human judgment belongs. That sounds a lot like product management. Whether you realize it or not, you may already be doing it.
A few months ago, I started building an AI agent for my newsletter. It could read the research I had collected, review articles I had published, identify recurring themes, organize sources, and prepare material for a new edition.
Then it stopped.
The technology had not failed. The agent was waiting for me to choose what I wanted to write about. The research was available, the tools were working, and the agent was ready. But the decision was still mine.
That experience changed how I think about building with AI. The limitation was no longer whether I could build the system. It was whether I could tell the system what mattered.
The old barrier was building
For most of the history of software, an idea had to survive a long journey before anyone could use it. Someone identified a need. A product manager translated that need into requirements. Designers created the experience, engineers built it, and the team tested and revised it before releasing it.
The process required specialists, money, and time. That made building inaccessible to most small-business owners. You might have known exactly what you needed, but knowing was not enough. You still needed someone who could translate the idea into software.
That barrier is falling.
Josh Elman, a former product leader at Twitter, LinkedIn, and Robinhood, recently described how AI is changing the traditional product-development loop. The old process was largely: specify, scope, build. The emerging process looks more like: build, play, design, ship.
Instead of describing an entire system before anything exists, people can create a rough version, try it, learn from it, and improve it. You can read more about that shift in Josh Elman’s a16z article.
This matters beyond technology companies. It changes what is possible for someone running a consulting practice, restaurant, agency, real estate company, or professional service business.
You no longer need to begin with a software project. You can begin with a problem from Tuesday afternoon.
Product management without the title
A good product manager does not simply tell engineers what to build. The job begins by answering a series of questions:
What problem are we trying to solve?
Who experiences it?
What happens today?
What should happen instead?
Which decisions can the system make?
Which decisions require a person?
How will we know whether the new process works?
Business owners answer versions of these questions every day. When a client inquiry arrives, you decide what information your team needs before responding. When a proposal takes four hours to prepare, you decide what can be standardized and what must remain specific to the client.
When inventory keeps running short, you determine which information would help you order more accurately. When follow-ups disappear, you decide when a relationship needs attention and what should happen next.
You may not call this product management. You call it running the business. But the underlying skill is the same: understanding a problem well enough to design a better way through it.
AI gives proximity a new value
A developer may know how to build the system. A consultant may recognize useful patterns. AI may be able to produce the first version. But the owner knows what happens when the restaurant is busy, the client changes the scope, an invoice arrives late, or an exception does not fit the documented process.
That proximity tells you where a process looks clean on paper but breaks in practice. It helps you recognize which client question signals a real opportunity, which recommendation is technically correct but commercially foolish, and when an exception is noise versus evidence that the process itself was designed incorrectly.
As AI becomes more capable, that knowledge does not become less important. It becomes the ingredient that makes the technology useful.
A Harvard Business School study involving 640 entrepreneurs in Kenya found that access to an AI business adviser produced different results depending on the person using it. Higher-performing businesses improved, while lower-performing businesses experienced declines in revenue and profit.
The researchers suggested that AI could produce advice that sounded reasonable without understanding whether it addressed the owner’s underlying problem. The owners still needed the judgment to evaluate and apply it.
The lesson is not that AI only works for successful people. The lesson is that access to an answer is different from knowing whether it is the right answer.
Your advantage is not technical
When I tell business owners they can build with AI, many imagine they need to become programmers. They do not. They need to become better at describing the work.
Take a proposal process. The owner does not need to understand the code behind the system. But the owner does need to explain:
Where the information comes from
What must be included
What changes from client to client
What language should never be used
Who approves the price
When the proposal is ready
What the system must never send automatically
Those are business decisions. Once they are clear, AI can organize the inputs, retrieve relevant material, prepare the first draft, identify what is missing, and present the proposal for review.
The owner keeps the decisions about fit, price, the promise, and whether the proposal goes out.
The machine prepares. The owner decides.
That is not handing the business to AI. It is designing the business so your judgment is used where it creates the most value.
Four decisions the owner must keep
1. Decide what outcome matters
“Use AI for proposals” is not an outcome. “Reduce proposal preparation from four hours to 45 minutes without weakening the client-specific recommendation” is an outcome.
The first statement names a tool. The second describes what should change in the business and what must be protected while it changes. The clearer the outcome, the easier it becomes to design the machine.
2. Find the real constraint
The loudest complaint is not always the real problem. A founder may complain about email, but the deeper issue may be that nobody knows which messages require a decision.
A restaurant owner may complain about inventory, but the deeper problem may be that purchasing decisions are based on memory instead of current sales and cost information.
If you solve the complaint without finding the constraint, you may automate the wrong process. That only helps the wrong work move faster.
3. Separate preparation from judgment
AI can collect, organize, compare, calculate, summarize, and draft. The owner should identify the decisions that affect trust, money, positioning, or accountability.
Those decisions need a person. The boundary between preparation and judgment should be designed before the workflow is automated.
4. Define what better means
A machine needs a scoreboard. Did it give time back? Did it protect margin? Did it improve the customer experience? Did it increase capacity without another hire?
If the business cannot describe what should improve, it cannot know whether the machine is working.
Start with one machine
You do not need to automate the company. Look for one repeated piece of work that happens often, consumes meaningful time or money, and follows a recognizable pattern.
Then ask:
What could the machine prepare before I arrive, and which decision should remain mine?
That question might lead to a market-intelligence system that prepares the week’s relevant developments, a content system that turns your knowledge into publishable ideas, or a proposal system that retrieves the right information and prepares a draft.
It might lead to a follow-up system that shows which relationships need attention, a repurposing workflow that adapts one article into several formats, or a purchasing report that gives an owner better information before placing an order.
None of these requires a giant collection of autonomous agents. A useful machine can be surprisingly simple. It combines a repeatable process, the context of the business, a few tools, human judgment, and a way to measure the result.
The owner as builder
I believe business owners should participate in building their first AI machine. Not because they need another responsibility or should spend their evenings becoming software developers. They should participate because building reveals the business.
You discover which decisions were never documented and where important information lives only in someone’s memory. You see how often a process depends on an exception. You learn which parts can move without you and which parts still deserve your attention.
Most importantly, you stop seeing AI as something being done to your business. You begin to see it as a material you can shape.
This is why I created Build My Machine. Across two working sessions, I train you to work with Claude Cowork and give you the plug-ins needed to begin applying it to specific areas of your business.
The real outcome is not installing a plug-in. It is understanding how a business machine is put together.
The larger system I use with clients is called ThriveOS. It helps us connect the technology to the way the business actually operates. You provide the context, see how the instructions shape the result, and identify where your judgment belongs.
You leave understanding what you built and how to use it. The goal is not to make you dependent on me. It is to help you become capable of building with AI.
If you only remember one thing
You do not need to become a product manager or software developer. You need to recognize that your experience is now part of the building technology.
AI can help create the system, but you know the customers, the exceptions, what the business can promise, and what good looks like. That knowledge is what turns an AI workflow into a business machine.
Once you learn to build one, you begin seeing possibilities throughout the company.
Build assets. Create freedom. Thrive on your terms.
Juan
AI can handle the building, but it cannot decide what truly matters to the business.
The real product skill is knowing which problems matter and why.