PN: 2483-AX9
DO NOT REMOVE DURING OPERATION
SN: 002194-C
MAT: AL6061-T6
信頼
Book a call

AI product development: make the AI earn its place

AI product development is splitting into two jobs, and they are pulling apart. The model you build on keeps getting cheaper, faster and easier to swap. The product you wrap around it, the part that decides whether anyone keeps using the thing, is where the real work now sits.

Jacob Andreou, who runs Copilot at Microsoft, made that case in a Rundown interview this week. His framing is worth borrowing if you are building anything with AI in it.

What Microsoft relearned about adding AI everywhere

Microsoft pulled Copilot out of several Windows apps after it found they drove traffic but little value, Andreou said. He described places where you could be using your machine and then, suddenly, Copilot, for no reason anyone asked for. Cutting those entry points did not lower usage. It raised usage per user, because the people left were the ones getting something out of it.

His rule for that is simple: products have to earn their right to exist. Here is the line from Andreou I would pin above a product roadmap:

Each generation of intelligence needs a product form factor for you to actually get value out of it.

For a founder, that reframes a tempting mistake. Dropping an AI chat box onto every screen feels like progress and ships fast. It is not product development. The work is finding the few places where AI removes something a person currently has to do, and building those well enough that people come back.

Why the model is no longer the hard part

Andreou also said no single lab wins at everything anymore. Earlier in the year you could take one provider's full line-up and get the best result across the board. That stopped being true. One class of models turned out strong at spreadsheet work, another better at drafting a slide deck. Copilot's answer is an Auto mode that picks the model for each task, while still letting you choose one yourself.

Read that as a founder and a real worry goes away. You do not have to bet your product on one lab staying ahead forever. The model is a part you can change. What you cannot swap out cheaply is the product judgment around it: what it should do, what it should refuse, and how it recovers when it gets something wrong.

What this means for AI product development

If the model is close to a commodity, then your product is the differentiator, and most of it is not AI at all. It is the onboarding, the data model underneath, the moment the AI hands back to a person, and the fallback for when the clever path fails.

That last one is easy to skip and expensive to miss. An AI feature that works in the demo and breaks on the messy real input is worse than no feature. The part that makes it trustworthy is almost always ordinary product engineering: validation, a sensible default, and a way out when the model is wrong.

What we have seen building AI products

We have shipped a few of these, and the pattern holds every time. The model is a small slice, and the product around it is the job.

On Lora, an AI travel app, we took over a half-built React Native codebase in March 2026 and built it feature by feature from the founders' designs. People paste a TikTok or Instagram reel and Lora pulls the places out of it onto a map. You can plan by text or by a real-time voice call with an animated avatar that falls back to text when it needs to. The model generates and understands; everything that makes it usable, the Mapbox map underneath, the one data model every feature sits on, the fallback, is product work we built around it. One of the founders, Ben Whatson, put it this way:

We are so anal about UI, and you nailed it. ... Genuinely, looking at the UI, it's so good.

On Thredly, an AI social listening platform, we went from idea to production in three months. The AI pipeline uses OpenAI and Grok models to generate platform-specific searches, score how relevant a post is, and sort posts into eight intent categories like high-intent sales and complaints. Two different model providers inside one product, which is Andreou's multi-model point in practice. Around that sits the part that makes it a product: a background system that scans eight platforms and sends a digest of the signals that matter.

Every engineer who works on a build like this is senior, and you see the work every week.

Where to start

If you are adding AI to a product, or building a new one around it, this is the order I would go in:

  1. Name the one job AI should do first. Pick the task where it clearly removes work a person does today, and leave the rest of the surface alone for now.
  2. Treat the model as swappable. Keep the prompt and the model behind one seam so you can change providers without rewriting the product.
  3. Build the fallback before the demo. Decide what happens on the messy input, the timeout and the wrong answer, because that is most of what real users will hit.
  4. Decide what the AI can do on its own. Anything irreversible, like sending, publishing or spending, should wait for a person.
  5. Put the product work first. Onboarding, the data model and the handoff to a human will do more for retention than a smarter model will.

The labs will keep shipping better models, and that is the easy part to adopt. The product you build around them is the part that is yours. If you want a hand building that part, see what we do and book a call below.

Book
a call

連絡先
If this is the kind of problem you are working through, we can talk it over.