Forward: Where Your Product Becomes AI

This is the fourth article in the Success by a Thousand Paper Cuts series. The previous articles covered where most organisations should start -- inward and outward. This one covers where a smaller number will end up. Forward is the most exciting domain, but the narrowest. Not every organisation can do this. Not every organisation should.

Forward is where AI stops being something you use and becomes something you sell.

What forward means

This isn't putting a chatbot on your website. That's outward. It's not using AI to improve your customer service, onboarding, or support. Those are valuable, but they're about improving how you serve customers within your existing product.

Forward is about changing what you deliver. AI becomes the core of the product, the thing your customers pay for.

The distinction from outward matters. Outward takes your existing product and makes the experience better with AI. Forward takes AI and builds the product around it. Different proposition, different risks and rewards.

A couple of examples make the distinction concrete.

Think about Canva. I mentioned it in Success by a Thousand Paper Cuts, and it's worth expanding here. Canva started as a design tool. Templates, drag-and-drop, accessible graphic design. Then AI arrived: generating layouts, suggesting copy, removing backgrounds, resizing for every format, translating content. Take the AI out and Canva still works, but it's a worse product. The AI didn't enhance the experience around the product. It became part of the product.

Or consider Perplexity. Traditional search gives you a list of links and leaves you to figure out the answer. Perplexity reads the sources, synthesises an answer, and cites its work. The product is the AI-generated synthesis. Without the AI, there's no product -- just another search engine.

In both cases, the AI isn't a feature. It's the capability that makes the product what it is.

Build vs integrate vs wrap

Forward doesn't mean training your own models. I'd break it into three approaches, and the least discussed is the most accessible.

The first is build. Train or fine-tune models on your own data for your domain. Expensive, complex, and only makes sense when you have unique data and the resources to maintain the pipeline. Most organisations won't need to do this.

The second is integrate. Use existing models via APIs as core components of your product. Most AI-powered SaaS products work this way. They take a capable language model and apply it to a specific, constrained domain with specific data. You're not building AI; you're building with AI. The model is infrastructure, like a database or a payment gateway, except it understands natural language.

The third is wrap. This is the one I think is underappreciated. Think about any process where there's a step that requires human judgement at a scale humans can't handle. Extracting structured data from messy documents. Classifying customer enquiries that don't fit neat categories. Reading images to identify products, defects, or conditions. These are tasks a human can do, but not at scale.

The wrap approach takes that unscalable human-judgement step and puts AI around it. Everything else (the data pipeline, the user interface, the integrations) is conventional software. The AI handles the part that was previously manual and unscalable.

The human doesn't disappear from this equation. The AI handles the 95% it's confident about. The remaining 5% of edge cases, ambiguous inputs and the things it's not sure about still escalate to a person. But that person is now processing exceptions, not volume. They're doing the interesting work, not the repetitive work. That's a different job, and a much better one.

This is how a lot of forward-domain products will get built. You don't need a research team. You need a clear understanding of where the hard, unscalable, human-judgement step is in your process, and then you wrap AI around that step.

When to go forward (and when not to)

Go forward when AI creates value that's hard to replicate without it. If someone could replicate your product with a spreadsheet and some elbow grease, you're not in the forward domain. You've added AI to something that didn't need it. And don't use AI to solve what's really an IT problem. If the real issue is bad data, broken integrations, or missing infrastructure, AI won't fix it. It'll just make it harder to see.

Don't go forward because a board slide says you should. Some organisations chase "AI-powered product" as a strategic objective without answering the most basic question: would customers pay for this? Not "would they think it's cool?" Not "would it get press coverage?" Would they exchange money for it?

If your AI-powered product solves a problem people will pay to solve, and the AI is what makes it possible or much better, you're in the right territory. If you're bolting AI onto something to sound more innovative, you're spending money to create risk without creating value.

The governance burden

This is where it gets heavy. Inward: AI is a tool your people use. Something goes wrong, a human catches it before it reaches anyone outside. Outward: AI touches customers, but it's wrapped around your existing product.

Forward: AI is the product. When it gets something wrong, your customer experiences it directly. Your reputation is on the line in a way the other domains don't touch.

The data implications shift too. In other domains, data flows through AI as part of processes or interactions. In forward, data flows through AI as the product itself. Different risk profile. You're storing customer data, processing it through models whose behaviour you don't fully control, and delivering the output as your product.

This is where standards like ISO 42001 start earning their overhead. In The AI Promise I wrote about the tension between formal AI management systems and the pace of change. That tension doesn't disappear here, but the cost-benefit equation shifts. When AI is your product, the consequences of getting it wrong are severe enough that structured governance becomes table stakes.

Impact assessments, bias testing, monitoring outputs in production, understanding what happens when the model behaves unexpectedly. None of that is theoretical when your customers experience the AI directly.

The differentiation opportunity

The flip side of governance is the strategic opportunity. A forward-domain product, done well, creates a moat that's difficult to cross.

When AI is your product, you generate data from how customers use it. That data improves the AI. Better AI makes the product better. Better product attracts more customers. More customers generate more data. It's a flywheel, and once spinning, it's hard for a competitor to catch up, even with the same underlying models.

This is what businesses should be excited about, rather than the cost-cutting narratives that dominate most AI strategies. Cost cutting is a one-time gain. A forward-domain flywheel is a compounding advantage.

Perplexity is a good example. Every query it answers, every source it reads, every citation a user clicks or ignores, all of that improves the product. A competitor starting from scratch with the same underlying models would need to build the same volume of usage data and refinement. The models are commodity. The data flywheel isn't.

Getting there from here

If you're thinking "we should build a forward-domain product," pump the brakes. Not because the opportunity isn't real, but because forward is the last domain you should tackle, not the first.

Build fluency inward first. Get your people comfortable with AI as a tool. Move outward. Learn what governance looks like in practice, not in a policy document. Understand where AI is reliable and where it falls apart. Build the muscle to monitor, evaluate, and improve AI-driven processes.

Then, when you have a product idea where AI is the enabling capability, where the thing you want to build isn't possible without it, you'll have the maturity to do it well.

Forward is the boldest domain in this series. Biggest opportunities, biggest risks. Treating it as a destination you earn your way to, rather than a starting point, is the difference between building something lasting and building something that blows up in your face.

The final article in this series brings it all together: how the three domains connect, how they feed each other, and what happens when the cuts start compounding.