Ford rehired hundreds of the engineers it replaced with AI, and 95% of companies see no measurable return on it. The cause is the same: little was designed around the people who will judge the output. That's why our AI is a guided interface, not a chatbot.
I spent years running Amazon DSP campaigns at Amazon and at agencies. Now I'm building VICTOR.AD, an AI tool that helps teams plan Amazon DSP advertising campaigns. Along the way, five product decisions defined the tool more than any model upgrade or feature launch ever did.
These aren't advertising specific. If you're building an AI product that makes recommendations your users need to trust, most of this will feel familiar.
1. We chose forms over a chatbot
It seems like every AI product launches with the same interaction model: a text box that says "Ask me anything." It's fast to build, easy to demo, and immediately impressive.
We built a chatbot prototype. It worked. You could say "plan a campaign targeting health conscious dog owners on Netflix and Spotify" and get a full plan back. But then we asked ourselves a question we couldn't answer well: what exactly did the AI decide, and when did the user agree to it?
A campaign plan has dozens of connected decisions. Budget split across platforms. Audience segment selection. Pacing over a timeline. Creative format per channel. In a chatbot, all of these arrive at once in a single output. The user either accepts the whole thing or starts negotiating with the AI through follow up prompts. Most users accepted it without scrutinizing every number. That's the problem.
We switched to a step by step interface. Each AI recommendation gets its own screen. You see the reasoning. You adjust what doesn't fit. You move forward. Less elegant. Significantly more trustworthy.
There's a secondary argument that pushed us further. Chatbot interfaces have a known attack surface: prompt injection. A user (or an attacker) can attempt to manipulate the AI into behaving as if it has different permissions. Safeguards exist, but they come with tradeoffs in quality or latency. Structured interfaces don't expose that surface at all.
If your AI product involves decisions with financial consequences, it's worth asking: does the user actually understand what they approved?
2. We hid the wait time inside useful work
Some of our AI processes take 20 to 30 seconds. That's an eternity for a first time user who hasn't decided whether to trust you yet.
It sounds like most teams solve this with loading animations, progress bars, or status messages ("Analyzing your data..."). These help, but they still ask the user to wait passively. Passive waiting feels longer than it is.
Amazon Advertising launched an audience suggestion tool on their DSP platform. Same concept as ours. Even with their infrastructure, it takes about 20 seconds and runs at the very end of the workflow, right before launch. The user gets their result, but they've already sat through the wait.
We moved our slowest AI step (audience analysis) to run in the background while the user reviews other parts of the plan: timelines, budgets, creative formats. By the time they reach the audience suggestions, results are usually ready. No spinner. No perceived wait. They were doing productive work the entire time.
This is a sequencing problem, not a compute problem. If you have a slow AI step, look at your workflow and ask whether something useful can happen in parallel. The answer is almost always yes.
3. We let people finish before asking them to sign up
It seems like the default pattern in SaaS is: show a landing page, ask for signup, then let the user try the product. For a tool in a category people already understand, that works. For a new AI tool that nobody has a mental model for, you're asking for trust before you've demonstrated anything.
We let anonymous users complete the entire workflow. Describe a product. Set campaign goals. Review AI recommendations. Adjust the plan. By the time we ask them to create an account, they've already built something they want to keep. Signing up feels like saving your work, not starting a trial.
This improved signups by more than 50%.
It created real engineering constraints. Our final output is a downloadable campaign presentation, and Amazon restricts what data can be exported to unregistered users. We had to design the anonymous experience to deliver enough value within those limits. That took weeks to get right. Worth it.
The principle generalises: the closer a user is to their first meaningful result when you ask for commitment, the higher the conversion. Every step between "I'm curious" and "I can see this working" is friction.
4. We made limits visible instead of hiding them
Every AI product has usage limits. Compute costs money. Without constraints, one heavy user degrades the experience for everyone. Most products hide this until the user hits a wall, then show a generic error or a surprise paywall.
We show limits from the start: "You've used X of Y requests today. Resets in 4 hours." When someone reaches a limit, we explain what the alternatives are (register for more capacity, wait for the reset, try a different configuration) instead of displaying an error code.
This sounds minor. It isn't. Retroactively adding limits to a product that launched without them is one of the most painful things you can do. Users who were promised (implicitly or explicitly) unlimited access feel betrayed. Plan for limits from the first prototype. Show them clearly. Treat them as a feature of transparency, not a cost to apologise for.
5. We tracked every AI decision from day one
AI failures are quiet. A wrong audience suggestion doesn't throw an error. A budget split that's 15% off from what an experienced planner would recommend looks perfectly plausible in a formatted table. Without tracking, you don't know what your AI is getting wrong until a user tells you, and most users won't.
We log every AI decision: confidence scores, the full input and output, cost per call, and the reasoning chain. When something breaks (and it has), we trace it to the exact model call that produced the bad output. This has caught problems that no amount of manual QA would have surfaced.
The tradeoff: tracking everything means more compliance work. Encryption requirements, privacy regulations from platform partners, data retention rules from governments. You need tracking to build a good product. Tracking means more infrastructure to keep that data safe. Both need to be in the plan from the start, not bolted on after launch.
What would you build differently if you started over?
These five decisions cost us speed. A chatbot would have shipped faster. Hiding limits would have avoided an uncomfortable design conversation. Skipping tracking would have saved weeks of compliance work. We think the tradeoffs were right for a product where people trust AI recommendations with real advertising budgets. Your product might need a different balance.
If you're early in the process, the one thing I'd suggest is this: figure out whether your AI product is a replacement or an assistant, and make that decision explicit before you write the first line of code. The answer changes everything about how you design the interface, what you track, and how much control the user needs to feel.
That's the decision that shaped everything else for us.