AI-first product building: what changes, what doesn’t, and what we could build next

AI-first product building sounds like an obvious direction until you ask what the “first” means.

Are we using AI to build a product faster? Adding AI features to something that already exists? Or designing a different kind of product because AI makes a previously awkward or expensive job possible?

Those are different decisions. Mixing them up is how we end up with another chatbot attached to a dashboard, without making the customer’s day any easier.

The opportunity that interests me is more practical: finding work people struggle to get done, then asking how much of that work software could now help complete.

What is an AI-first product?

There isn’t one universally agreed definition. For this article, I mean a product designed around AI as a core part of how it delivers value.

A useful test is to imagine removing the AI. Would the product still deliver roughly the same experience, or would its main promise stop working?

A booking system with an AI-written confirmation email is mostly a conventional booking system. A service that interprets a customer’s messy enquiry, asks for missing details and prepares a suitable booking for approval depends much more heavily on AI.

And using an AI coding tool to build a booking website does not automatically make the website AI-first. That describes how it was built, not what the customer is buying.

An AI-first product also doesn’t have to be autonomous. Helping someone produce a trustworthy draft can be valuable without giving the system permission to send it, spend money or make commitments.

AI-first, product-first and customer-first ask different questions

I wouldn’t treat these as three rival religions. They describe different starting points, and good teams can combine them.

Customer-first starts with the person and the problem. What are they trying to achieve? What gets in their way? What would a better outcome look like? It doesn’t require taking every feature request literally. Understanding why someone wants a feature is often more useful than building exactly what they asked for.

Product-first starts with a vision of the experience. What product should exist, and what should it feel like to use? I’m using the term in that sense here, rather than product-led growth, which is about acquisition and adoption. A strong product vision can connect needs customers have never expressed as a specification. Its risk is becoming attached to an elegant solution people don’t need.

AI-first starts with a change in capability. What could we now interpret, generate or coordinate that previously required too much manual effort? Its risk is becoming fascinated with the technology and then searching for a problem to justify it.

Consider a small trade business struggling to respond to enquiries.

The customer-first question is why enquiries are being missed and what that costs the owner. The product-first question is what a good enquiry-to-booking experience should be. The AI-first question is whether messages, photos and voice notes can become a structured job brief without the owner retyping everything.

I’d want all three perspectives before deciding what to build. Customer-first should remain the test of whether the result is worth paying for.

What changes when AI is part of the core product?

Traditional software often asks people to translate their work into fields, forms and commands. AI creates more options for handling the untidy material that work begins with: conversations, documents, screenshots and incomplete requests.

That can change the workflow. A customer describes a problem; the product assembles a draft; a person reviews the gaps and approves the next step.

It changes the quality problem too. A functioning button is easier to test than whether a generated answer misunderstood a customer’s intention. Testing has to include realistic tasks, ambiguous inputs and cases where the system should refuse to act or ask for help.

The interface needs to make that uncertainty visible. Users should be able to see what happened, inspect relevant evidence, correct mistakes and understand which actions still need approval. A chat window alone rarely provides all of that.

The products already showing the direction

These are existing examples of the current wave, rather than predictions or a list of this week’s launches. Their product pages describe capabilities; they don’t prove that every deployment delivers the same results.

Software that helps create software

Cursor describes coding agents that can build, test and demonstrate changes for review. Lovable lets people describe web applications in natural language and generates editable code, including frontend and backend components.

Both move some of the work from writing every instruction yourself towards describing an intended result and reviewing an implementation. Neither removes the need to understand security, maintenance or whether you built the right thing.

There are two opportunities here: products that help people build software, and smaller, more specialised products that become feasible when development effort falls. The second still needs evidence that somebody wants the result.

Customer-service agents connected to real workflows

Fin is built around handling customer conversations using business knowledge, context and configured processes.

The product direction is broader than answering a question from a help page. It is handling a bounded service task and passing the conversation to a person when necessary. For builders, the difficult parts include access permissions, policy exceptions and reliable handovers, not just generating a friendly response.

Specialist products that turn conversations into useful records

Abridge turns clinical conversations into note drafts within electronic health record workflows. Its product includes linked evidence to help clinicians verify those drafts.

That is a useful example of domain-specific product design. The output has a particular purpose, the review happens inside an existing workflow, and the user needs to check where information came from. It should not be confused with autonomous medical judgement.

Across these examples, the interesting shift is towards software doing more of a defined job, with review and control designed around that job.

Where I think the opportunity is

For smaller builders, I’d look closely at the gaps between tools.

An enquiry arrives in email. Someone copies it into a CRM. A colleague asks for more information. A quote gets drafted elsewhere. Then somebody has to remember to follow up.

Each individual application might work perfectly well. The business still depends on a person keeping the whole process moving.

AI can help interpret the messy inputs. Ordinary software should still handle exact calculations, permissions and clear rules. The value comes from connecting those parts into a workflow that reliably reaches a useful outcome.

That also changes how I’d judge the economics. A cheap model call is not a cheap service if someone spends half an hour correcting it. Model usage, integrations, human review, support and the cost of mistakes all count.

The defensible advantage might be deep knowledge of a trade, access to customers, reliable integrations or a set of realistic tests built from permitted customer cases. Access to a widely available model, by itself, is a weak reason to expect customers to stay.

Five products I’d explore

These are ideas to validate, not claims of untouched markets. Versions of several already exist. The opportunity would depend on choosing a specific customer and doing their workflow well.

1. An enquiry-to-quote assistant for one trade. Turn messages, photos and voice notes into a job brief, identify missing information and prepare a quote from an approved price list. The owner approves pricing and promises. Start with one trade and measure response time, corrections and accepted quotes.

2. A client-onboarding coordinator for a small agency. Check the signed scope against the documents and access details received, then prepare the missing-information requests. Start with a checklist and draft reminders. Avoid giving an agent broad account access before the business has proved it can handle the simpler work reliably.

3. A tender-evidence assistant for specialist SMEs. Map tender requirements to approved company evidence, flag missing documents and draft referenced answers. It must never invent a certification or past project. The first useful product could be a gap report rather than a system that writes an entire submission.

4. A field-service reporting tool. Turn a technician’s dictated notes and authorised photos into a structured report and proposed follow-up work. Keep observations separate from AI suggestions, and require review before reports or safety-related recommendations leave the business.

5. A workflow watchdog. Notice when a process has stalled because a document, approval or response is missing. Tell the right person what is blocked and what they need to do. Start with alerts; earn permission for narrowly defined follow-ups later. Some checks won’t need AI at all. Use it where interpreting an unstructured reply adds value.

I’m particularly interested in that last category. There is a practical difference between a product that generates more work and one that helps people finish the work already on their plate.

What could come next?

My expectation is that more products will combine a conventional interface with background assistance. People will still need lists, calendars and records, but may spend less time moving information between them.

We could see more software configured around a narrow role: a coordinator for a particular type of clinic, an estimator for one trade, or an evidence assistant for one regulated process. That is a direction to explore, not a guarantee that broad software suites disappear.

I also expect the controls around AI to become products in their own right: permission management, evaluation, approval queues, action histories and recovery when a task fails halfway through.

If I were starting now, I’d pick one recurring job, watch how customers do it and collect examples with their permission. Then I’d build the smallest version that prepares useful work for review, compare it with the existing process and test whether anyone will pay for it.

AI expands what we can attempt. We still have to prove that what we build makes somebody’s working day better.