AI In Your Product: Magic or Transparency

Yes, AI is pretty nifty. But when integrating AI into your product, you have two paths:

One—seamlessly integrate AI into the product, making it feel like magic for the user. The product is smarter, which makes the user feel smarter. Until it isn't. Sometimes, AI things go wonky (technical term, I'm sure), leaving your users frustrated and blaming your product.

Or two—call out that it's powered by AI. However, this could prevent users from trusting your product or make them opt out of using that feature or product altogether.

Which path do you choose? When and why?

The answer, of course, depends on the experience you're designing—and your users' tolerance for unpredictability.

If your AI feature is additive—something that enhances but doesn't make or break the core workflow—magic might be the way to go. Think auto-tagging content, generating a first draft, or suggesting an action. The risk is low, the payoff is high, and when it works, it feels delightful. When it doesn't, users can easily course-correct.

But if the AI is critical to success—driving decisions, surfacing key insights, or replacing a human task—it might be better to show your work. Users want to understand what's happening under the hood. They want transparency, clarity, and sometimes even a little control. Acknowledge the AI, set expectations, and design affordances that allow users to review, edit, or override as needed.

There's also a third path: contextual transparency. You don't need a flashing "AI did this" badge on every screen—but you can signal it thoughtfully. A well-placed tooltip, a short explainer on first use, or subtle visual cues that communicate what's automated versus manual. Transparency without fear. Trust without overwhelm.

Ultimately, it comes down to trust, clarity, and control. Not just what the AI does—but how you help the user understand what just happened, what they can do about it, and whether they feel empowered or undermined by the experience.

Because the real magic isn't that AI is in your product. It's when your user still feels in charge—even when they're not.

The Case for Outputs

Scrolling through twitter I stumbled across Barry’s post—Your Mission is to Produce Outcomes, Not Outputs—it got my interest immediately. As I was reading Barry’s post, I found myself nodding my head. A lot of good points. But I think it’s easy to miss what Barry is stressing, which is essentially to deliver value you can measure. So many people interpret this as ‘skip documentation and just ship something’. But that’s not the case at all. Sure, outputs aren’t typically a business model, but they’re tools that enable speed and quality.

In many cases, the maturity and size of the team determine the need for outputs. For a small, stable team, where the vision is clear and there are no blockers, many outputs could be skipped. But for large teams, often with various layers of stakeholders, outputs can help a team fire on all cylinders, reduce duplication, and quickly transfer context.

Yes, businesses survive on outcomes

Essentially Barry is saying the only real deliverable that matters is the outcome—the thing that moves the needle. Process maps don’t generate value, but a product that eliminates those process pain points might be worth more than gold. Outcome-based businesses value results. If your customers don’t succeed your effort is wasted—regardless of all the output you create along the way.

So many times, teams are showing dashboards of vanity metrics, or chart porn. These outputs make the team look busy, but it’s the same type of busy as hamsters on their wheels.

However, there can be a case made for outputs with outcomes. Outputs can be key to making sure outcomes are targeted, relevant, and impactful.

Outputs help makes success repeatable

Some products just work—AirBNB, Instagram, etc. There was a clear hole, the founders knew the space and how to solve it, and they nailed it. In these cases, the founders were scratching their own itch—they knew the problem space well. So why doesn’t everyone just do that? Well, it’s hard. And often times, teams are paid to scratch someone else’s itch. A lot of teams have found that a process can help them repeatedly hone a solution into a valuable product. A process, or checklist, is a way of ensuring you don’t forget key steps when you’re tired, excited, or just pressed for time.

These checklists often generate outputs that serve as inputs into next steps. For example, in the product design world, we generate personas to better understand the type of users we’re targeting—these are typically in the form of presentation slides or poster outputs. We then use those personas to map their journey in a given scenario and highlight their pain points (typically delivered as a poster). Then we co-create solutions around those pain points, validate, then integrate those solutions into our product. We follow this process whether it’s a new product or existing, digital or physical. It always works. If we jumped right into the journey map, we might gloss over one of our most important personas.

But checklists aren’t just for product development or innovation. Many industries use checklists to ensure a thorough job is complete—safety inspectors, pilots, and even busy shoppers. In fact, pilots depend on them for every flight. Yet we don’t say ‘a pilots job is to fly, not check lists’.

Checklists help us stay on track, and follow a process we’ve proven to work.

Outputs can reduce duplication

Often times different products within a business or organization will share similar users, scenarios, workflows, etc. In those cases, teams often dig up past project outputs to get a better understanding of what we know, what we don’t know, and what to validate. Now, typically we don’t take those old outputs as gospel, but it provides a baseline to validate and build on.

Without those past outputs, we start over fresh. This not only burns additional cycles, but it can start to negatively impact your stakeholders. If you interview a key executive every year asking similar questions each time, by the third time they might not accept your call.

Similar to history, if you don’t learn from your past outputs, you’re doomed to repeat the same discovery.

Outputs transfer knowledge

But the most powerful use of outputs is to preserve the context of the work. It could be helping the customer understand the impact of your findings or vision, or merely to educate so they can empathize better.

In large enterprise companies, it’s not usual for teams to morph over time—team members get promoted, move to other teams, or even other companies. Outputs help the team document knowledge along the project in meaningful ways, onboard new team members, and quickly answer ‘why are we doing this?’.

Rather than depending on tribal knowledge over time, new team members can review a few key outputs and get up to speed in no time.

Outputs create the outcome

Okay, not really. But often times, a proven process often generates and iterates outputs, and those outputs become inputs for future steps, and so-on. Those outputs and iterations will help ensure you’re making good decisions. It will help make sure your final solution is on point. It will help track your success, and know when you get there.

Move fast but don’t break things

Facebook’s motto used to be ‘Move Fast and Break Things’. Now, I have no idea how Facebook actually works, but hearing that motto and things like ‘Outcomes over Outputs’ always conjures images of bus-boys rushing to clean tables and get dirty dishes back to the kitchen only to have a bin full of broken dishware.

Barry is right—don’t fetishize outputs, because outcomes are the real value. But don’t throw outputs out the window; just find the right output. Realize they’re tools that can often help large teams get to value faster and more often.