Where should intelligence live?
Fredrik Björndahl
Senior Product Lead
When I run, I collect all my training data in Strava. When I actually want to understand that data, or get some coaching out of it, I don't open Strava. I bring the data to Claude instead.
That's a small, personal habit, but it points to a bigger question every product team is now facing. Where should intelligence live? Inside your product, where you build and control the whole experience? Or outside it, in the assistant your customer already has open, Gemini, Siri, Claude?
That's not just a fitness question. Products used to compete only with others in their category. Now they compete with whatever AI system a user turns to for the same task.
The bar quietly went up
Expectations spread fast between categories. Once someone gets used to a product remembering their context, or suggesting the next step for them, they start expecting that everywhere else too. Most products aren't delivering on it.
85% of the 400 apps surveyed in our Mobile App Trends Report have a negative net promoter score.
People keep using those apps anyway, often out of habit, or simply because they're the default choice already on the phone. Usage and satisfaction aren't the same thing. A product can fall behind what customers expect long before those customers actually walk away. That doesn't make it irrelevant. It raises the bar for what counts as good.
Strava vs. Google: two different bets
Strava calls its AI feature "Athlete Intelligence." It summarizes your activities, and if you've set a goal, it works that into the summary too, something like "a great interval session, that's great for your 10k race in June." You also get a weekly batch of workout suggestions. That's what it offers today.
Google's Fitbit app takes a different approach. Since May, it's shipped an AI feature Google calls "Fitbit Health Coach," built directly into an app that already existed. It reads sleep, recovery and workout data, and explains what that data actually means for you. Given access, it can also factor in more of your life, like whether you worked late or slept badly, to adjust your training schedule.
The question was never whether a product can generate a summary. It's whether the summary actually helps you act on your data, rather than just restating it back to you.
Different calls, different reach
Strava and Google made different calls here too. Strava enabled a Claude MCP connector for your training data, though not the social layer. Google, meanwhile, exposes Fitbit data through a developer-facing API, meant for building on rather than for asking an assistant directly. The practical difference comes down to reach. A connector only works for people who know it exists and set it up themselves, while a coach built directly into the app reaches everyone who opens it, with no extra steps required.
Here's the part worth sitting with. Even though Strava's AI feature is fairly light, I still open Strava daily, mostly for the social features. That's Strava's real moat, a social layer no outside assistant can replicate. Claude helps me understand my training. It doesn't replace what I get from opening Strava itself. Different jobs, different answers.
But if the goal is just getting people to use your intelligence features at all, building it inside probably increases those chances.
Two questions worth asking:
These questions can help you decide where intelligence creates the most value for users, and whether it belongs inside your product, outside it, or both.
Where does the useful context actually come together?
Around the user → outside — Training data, a work calendar, travel plans. Combining these needs an assistant that can see across the user's wider life.
Around the product → inside — How similar athletes progressed, training-plan logic, available routes. This context belongs to the product, and makes it smarter throughout the experience.
Where does the user actually get the value?
Mainly in the result → inside + outside — "How far did I run this week?" Make the answer effortless inside the product, but also easy to expose externally, for example through MCP.
Mainly in the interaction → inside — "Help me understand my progress." The value here sits in the interaction itself, so it's worth owning inside the product.
Three ways to go outside the product
OS Integrations
iOS App Intents, Android App Functions. Simple, single actions exposed at the operating-system level. A job like "start my interval session" doesn't need a conversation or an interface at all. Siri or Gemini can just do it.
Capabilities and data
Via an MCP server or connector, the assistant can combine your product's data with context from elsewhere. Answering something like "Why did last week feel harder?" means pulling in sleep and calendar data that no simple app intent would expose.
Apps inside the assistant
MCP apps, ChatGPT apps. A full interactive interface, brought right into the conversation, with MCP running underneath it. Choosing a training plan needs comparison and controls that a plain text answer can't really deliver.
When it's actually worth it
Open up only when there's a clearly better outcome for the customer and a measurable benefit for the business. If you can only name one, keep the capability inside for now, or run a smaller experiment first. Technical possibility alone was never a good enough reason.
AI assistants have raised the bar every product needs to clear. That doesn't mean handing your customer relationship over to whichever assistant they happen to be using. Your own product can still be the best place for someone to understand their own data, explore options, and build trust in what they're seeing.
Decide per job, not once for the whole product.
Build intelligence inside, where your product genuinely creates a better experience.
Open intelligence outside, when another route clearly improves the job and pays off for the business.
Let's map where it belongs
Where intelligence belongs is different for every product. It can sit inside the product, or outside it, in integrations with external assistants and agents. We run a short discovery sprint with your team to map where intelligence genuinely pays off for your users, and what a first version of it looks like.
-
Map where the value sits. We explore the use cases that matter to your users, and identify where intelligence can create more value than what exists today.
-
Prototype before you commit. We build and test promising solutions as part of the sprint. That gives you early validation from real users before you invest in a full build.
Subscribe
Join our newsletter and stay up-to-date