Design Pattern · September 2026

Microsoft and Google as business operating substrates

Treat the owned platform as a substrate of capabilities rather than a bundle of products, then map those capabilities against the jobs that category software is bought to perform.

Under the pillar Zero Neo

Capabilities, not products

Product lists are unhelpful here. What matters is the capability inventory: identity, email, calendar, appointments, booking, forms, documents, spreadsheets, structured data, shared storage, collaboration, chat, video, workflow, approvals, notifications, search, knowledge, intranet, lightweight applications, dashboards, automation, AI, security, permissions, and audit trails.

Most organizations already pay for all of that. Very few have an inventory of it, which is one reason the same capability gets purchased a second time under a category name.

Three worked examples

In each case the question is not whether the platform can imitate the product. It is whether the outcome the product is bought for can be produced from capabilities already owned.

Instead of a CRM

Contacts, mail, calendar, a structured list or table of accounts and opportunities, forms for inbound interest, workflow for stage changes, documents for proposals, and AI for summarizing and drafting. Ask what the CRM does beyond that, and whether the business uses it.

Instead of booking software

Calendar with published availability, an appointment page, a form for the intake questions, notifications and reminders, video for the meeting, a payment link where money is involved, and workflow for reschedules and no-shows.

Instead of a customer portal

External identity, a shared document space scoped per customer, forms for submissions, workflow for approvals, messaging for the conversation, and a lightweight generated interface over the top.

Instead of a relationship-management product

Name the jobs it performs, decompose them, and check each against the inventory before assuming the category is required.

Category is not the same as job

A software category is a marketing container for a set of jobs that were commonly bought together. It is a fact about the industry, not about the work.

The research discipline here is to keep the two apart. Write down the jobs first, in the language of the business, and only then look at what a product in the category provides. The difference between the two lists is the honest measure of what buying would actually add.