Your Product Must Earn the Context Switch

A camera roll can now become the start of a shopping journey. An operating system can handle tasks that previously required a separate AI productivity app. A streaming service can add short-form news, while an email product can expand into meeting notes through acquisition.

These developments look unrelated, but they point to the same product dynamic: the place where a customer already spends time is absorbing more of the jobs around it.

This changes how I think about competition. The main competitor is often no longer another product in the same category. It is the customer’s current context.

A dedicated shopping app may provide better recommendations, but the camera roll already contains the customer’s intent. A standalone assistant may have more features, but the operating system is already open and has access to the device. A specialist meeting tool may produce better notes, but the email or calendar product already knows where the meeting came from and what happens next.

The standalone product therefore has an extra cost to overcome. It asks the customer to stop what they are doing, open something else, transfer information and later bring the result back. Product teams tend to underestimate this cost because it rarely appears as a line in a funnel. We see a user who did not activate or return. We do not see that the existing environment was simply good enough.

My conclusion is not that every product should become a platform, or that specialist tools will disappear. Specialist products can still win through greater depth, reliability, collaboration, service or domain knowledge. But they have to earn the context switch.

That requires a different standard than feature comparison. If an operating system offers a basic version of your capability, matching its feature is not enough. It already wins on convenience. Your product needs to produce a meaningfully better outcome.

I would make this explicit in product strategy. For each important customer job, I want to know where that job naturally starts, what the customer has to move into our product, and what they gain by doing so. I also want to know whether customers deliberately return to us when a convenient alternative is available.

This changes prioritisation. A team might otherwise spend a quarter reducing clicks in an onboarding flow while ignoring the larger problem that customers do not want another destination. In that situation, better onboarding improves the journey into a product people still have little reason to visit.

The answer could be deeper specialization. It could also be bringing the capability into the customer’s existing environment, provided the economics and experience still work. Sometimes the right move is an integration, extension or embedded workflow. Sometimes it is narrowing the audience so the product solves a harder problem than a general platform reasonably can.

The measurement also needs to follow the argument. Activation and monthly usage are not enough. I would look at direct repeat use, the amount of information customers bring into the product, whether they complete the full job there, and whether they return despite having a simpler alternative. For paid products, renewal and expansion tell us far more than curiosity-driven adoption.

This is also why small process experiments and clearer product responsibilities matter. Teams need room to test where the job should live, not just how a predetermined feature should work. A product manager responsible only for shipping the next capability cannot answer whether the product remains the right destination for that capability.

As large products keep expanding into nearby jobs, more teams will be tempted to copy what just appeared elsewhere. I would resist that reflex. The strategic question is not whether we can build the same thing. It is whether our version gives customers a sufficient reason to leave where they already are.