The question was simple: how do you know if AI agents will choose your tool?

With humans, you have SEO, copywriting, word of mouth. But an agent just looks at available tools in context and picks one based on the description, schema, and examples. YC had just published a video on the “agent economy” describing agents as autonomous economic actors, selecting products and services without human input and the question was whether you could engineer your way into being chosen.

Getting an agent to choose your tool is a two-stage problem. Almost everyone is only solving one stage of it. Let’s make this concrete with something we’ll carry through the whole piece.

You’re a PM building a report-generation tool. It takes structured receipt data and produces formatted expense summaries (fast, accurate, purpose-built for the job). You expose it via MCP alongside a dozen other tools in your agent context, including a general-purpose data-processing tool that can technically do the same thing if the agent prompts it correctly.

Your tool is the right one for this job. The agent keeps picking the other one. Let’s figure out why and why the fix might not be what you expect.

The problem that happens before your description is even read

Here’s the thing: if you have more than about 15 tools in your agent context, there’s a reasonable chance the agent isn’t reading your description with full attention. It might not be reading it meaningfully at all.

When a session starts, every connected MCP server dumps its full tool schemas into the context window at once. So in our example: the agent receives your report tool’s description alongside every other tool like the data processor, the file manager, the API caller, whatever else is connected. All of it, upfront, before any question is answered. Anthropic tracked real customer setups and found a five-server MCP configuration with 58 tools burns roughly 55,000 tokens just loading in.

Ever looked at the number of tools loaded in your VSCode for every call?

In other words: if your context has 30 tools, the agent isn’t carefully comparing your report tool’s description against the data processor’s. It’s pattern-matching under attention pressure and your position in the list may be doing more work than the words you wrote. Your description could be perfect and still lose to a mediocre tool that loaded in at position three..

But let’s say you adds a routing layer. Scoped dispatch, five tools per task. The report tool is in the room. Now what determines whether the agent picks it?

What actually moves the needle once your tool is in the room

The description is your entire pitch. The agent reads it once, decides, and moves on. Your tool is exactly what fits in a JSON object and the description field is the only thing with room for persuasion.

It won’t follow links to your docs. It won’t read your README. It won’t run a test query to see what comes back.

How do you fix this? Here’s what the practitioners found actually moves selection.

1. Write the negative case before the positive one. This was the single most consistent finding in the thread . The instinct is to describe what your tool does. The higher-leverage move is to describe what it doesn’t.

   

   
   Think about the report tool this way. The general-purpose data-processing tool can technically do the same job. The agent’s selection decision comes down to which description makes the boundary clearest. If yours says “generates expense reports” and the other says “processes structured data,” the agent is guessing. If yours adds “does NOT process arbitrary data formats or execute code,” the agent stops guessing.
   

2. Trigger words do more work than general descriptions. This was the insight I hadn’t seen articulated anywhere before this thread: maintaining explicit trigger word lists per skill i.e. specific phrases that should activate each tool. Without them, agents pattern-match on vague capability language and get it wrong roughly 30% of the time. With trigger phrases embedded explicitly in the description: under 5%. If a user says “compile my receipts into a summary,” does your description contain language that maps to “compile” and “summary”? Or does it say “generates expense reports” and leave the agent to figure out those are the same thing? Don’t leave that inference to the model. Build the map and put it in the description.
   

3. Inline examples beat external documentation, every time. Agents don’t follow links. This sounds obvious once you say it out loud, but it runs against every instinct teams have about good developer documentation practice. If you link to your docs in the description field, the agent will not go there. If you put one concrete example directly in the field like “Use this tool when a user asks: ‘Can you compile my receipts into an expense summary?’”. The agent has something to pattern-match against on every single call.

Your tool is in the room. You have the right description. You still lose. Why?

Even with a clean description, you can lose the call on the schema. The description gets the agent to your door. The parameter design determines whether it walks in cleanly or stumbles on the threshold.

Schema is the real interface. Clean parameter names with sensible defaults beat elaborate descriptions.

One example that illustrates this problem : query: string gets called correctly and consistently across model families. search_query_input_text: string doesn’t, even when it means exactly the same thing. The simpler name maps naturally to how models have learned to reason about inputs during training. The verbose name introduces an ambiguity the agent has to resolve and sometimes doesn’t infer correctly before it can even form the call.

Two things matter most beyond naming. First, explicit format guidance: if a field expects an ID formatted as “ORD-123456,” say so, with an example inline. Agents will hallucinate plausible-looking formats when you don’t constrain them, and a plausible-looking wrong format is worse than an obviously wrong one. Second, clear required-versus-optional semantics: an agent trying to minimize call friction will skip uncertain parameters and cause silent failures, or fill them with guesses that create errors until something breaks much further downstream.

How to build “brand” in the agent economy

Most framing of agent tool discovery assumes you’re optimizing for something like human brand preference like trust accumulated over time, word of mouth, reputation. That’s not how it works at all.

Every agent invocation is a cold start. The model reads your description and decides, fresh, with no memory of previous successful calls. No loyalty. No trust built up over a thousand prior interactions. The agent that picked your tool correctly 500 times last week has exactly zero preference for it today. The decision is made entirely on what the model reads in that context window, in that moment.

It means the best-described tool wins every single invocation regardless of who built it, how long it’s been around, or what brand the maker has. A well-crafted description from a solo developer beats a vague one from a well-funded company every time. The competitive moat isn’t brand. It’s craft.

Same description. Different models. Different results.

One more wrinkle that most teams discover the hard way: a description optimized for Claude may not behave the same way with GPT-family models, and vice versa. Claude is more conservative — it will ask for clarification before guessing when the description is ambiguous. Other models fire speculatively and recover from errors. These aren’t style differences. They’re fundamental differences in how calling confidence is computed from your description.

If your tool needs to work across model families, you should run evals against each target model separately. Treat selection accuracy as a conversion metric. Optimize for your worst performer first.

So what to actually do in practice?

Let’s bring it back to the report tool and the decisions that determine whether an agent picks it.

1. Solve the architecture problem first. If your context has more than 15 tools and no routing layer, start here. Scoped dispatch (3–5 tools per task), use lazy-loading, or use Anthropic’s Tool Search (85% reduction, but Claude-only). No description improvement compensates for attention-degraded context.

2. Write the negative case before the positive one. “Do not use this tool when...” is the single highest-leverage sentence in your description. Write it first. It will make every other word you write more precise, and it removes the boundary inference the agent was making badly.

3. Build a trigger word list and embed it. List the specific phrases a user might say that should invoke your tool. Embed them explicitly in the description. Without this, agents pattern-match on vague capability language and get it wrong roughly 30% of the time.

4. Put one concrete example directly in the description field. Not in a linked doc. Not in the README. In the field. Format: “Use this tool when a user asks: [specific request].” It’s 20 tokens and it does more selection work than a 500-word README the agent will never read.

5. Design your schema like a UI. Use query over search_query_input_text. Format examples inline for any structured field. Explicit required/optional semantics. Every ambiguity is a potential wrong call or a silent downstream failure.

6. Run evals across model families, not just one. Send 20–30 representative queries through each target model. Measure selection accuracy separately. Optimize for the worst performer first because your users won’t all be on the same model.

7. Rotate context before it degrades. In long sessions, optimal rotation point is 60–70% context usage. At 80%+, auto-compaction races with any cleanup and selection quality degrades faster than you can intervene.

Whose job is this, exactly?

The PM inside you would ask: who is supposed to own this? It’s not purely engineering. The description is a product decision about how you want agents to understand your capability. It’s not marketing as the audience is a model doing probabilistic pattern-matching, not a human responding to copy. It’s not DevRel as it requires understanding how specific model families reason about tool selection under uncertainty.

This is a new discipline without a team or a title. The tools to measure it are model-specific evals, description quality audits, semantic retrieval benchmarks. The window to get ahead of it is open right now, while most teams still treat tool documentation as the last thing they finish before shipping.

It’s not the last thing. It’s your homepage. Write it like one.

Lets dive straight into it.

1. Markdown as Memory: The Bet Against Vector Databases

Most agent frameworks store memory in vector databases. Embeddings, semantic search, the whole retrieval-augmented generation stack. OpenClaw stores everything as plain Markdown files and JSONL transcripts in a directory on your machine.

Your agent’s long-term memory lives in MEMORY.md. Its personality is in SOUL.md. Daily conversation logs are in YYYY-MM-DD.md files. You can open them in any text editor, version them with Git, grep through them, or delete them.

For search, OpenClaw uses a hybrid of 70% vector similarity and 30% keyword matching. But the source of truth is always the human-readable files.

The product decision this embeds: Memory should be inspectable, portable, and owned by the user. Not locked in a proprietary database that you can’t audit or migrate.

Why this matters for your product: If you’re building any agent feature that stores user context, ask yourself: can a user see what your agent “knows” about them? Can they edit it? Can they take it with them if they leave? OpenClaw’s answer is that memory is a user-facing feature, not a backend implementation detail. The file-based approach also makes debugging straightforward. When your agent acts weird, you can literally read what it remembers and see what went wrong.

The tradeoff is real, though. File-based memory works beautifully for a single user’s personal agent. It starts to strain when you need semantic recall across massive corpora, or when multiple agent instances need to share state. One community developer wrote about augmenting the default system with a more sophisticated cognitive architecture because the out-of-the-box memory wasn’t enough for complex workflows. That’s the tension: simplicity and auditability vs. sophistication at scale.

2. Deliberately ignoring MCP: Let the Agent Write Its Own Tools

This is the most provocative architectural choice OpenClaw makes, and the one that generated the most debate after Steinberger’s YC interview.

OpenClaw doesn’t use MCP (Model Context Protocol) natively. There’s no built-in MCP support. And this isn’t a gap they haven’t gotten around to filling. It’s a deliberate philosophical stance.

Armin Ronacher puts it directly: the omission of MCP “is not a lazy omission. The entire idea is that if you want the agent to do something that it doesn’t do yet, you don’t go and download an extension or a skill or something like this. You ask the agent to extend itself. Echoing the idea of code writing and running code.”

Instead of MCP servers, OpenClaw uses a SKILL.md system: Markdown files with YAML frontmatter and natural-language instructions that the agent reads and follows. Skills are modular, human-readable, and shareable through ClawHub (a community registry). More crucially, the agent can write its own skills. Ask it to do something new, and it’ll draft a SKILL.md, save it, and start using it immediately. No restart required.

The product decision this embeds: Extension through code generation rather than protocol integration. The agent doesn’t need pre-built connectors to new services. It needs the ability to write code and run it.

What this means for your product: This is a genuinely different mental model for agent extensibility, and it’s worth sitting with regardless of where you land on it.

• The MCP model says: build standardized connectors so agents can interact with tools through a common protocol. It’s the API economy applied to agents. Structured, predictable, controlled.

• The SKILL.md model says: give the agent the ability to read, write, and execute code, and let it figure out how to interact with anything. It’s more like hiring a capable developer and pointing them at a problem, rather than giving them a pre-wired integration.

Each approach makes a different bet about where we are in the maturity of agent systems. MCP bets on standardization, interoperability, and safety through structured boundaries. SKILL.md bets on the raw capability of LLMs to write correct code on the fly, and that this capability will keep improving.

3. Serial Execution by Default: Reliability Over Speed

The SKILL.md decision is about how the agent gains new capabilities. This next decision is about how it executes them. That’s an architectural choice that runs completely counter to the “make it faster” instinct most product teams have.

OpenClaw’s Lane Queue system enforces serial execution by default. Every message within a session is processed one at a time, in order. Parallelism is only allowed for tasks explicitly marked as low-risk and idempotent.

The pipeline is strict:

The product decision this embeds: Predictability and debuggability matter more than throughput for a personal agent.

Why this matters for your product: Most developers building agents encounter the same failure pattern. Messy concurrency creates ghost bugs. Two tool calls interfere with each other. State corrupts silently. The agent acts on stale context because a parallel operation updated something mid-task.

OpenClaw’s response is to make serial execution the boring, reliable default. This means your agent might be slower when handling multiple requests, but every failure is isolated, every log is readable, and you can replay the entire JSONL transcript to reproduce any bug.

4. The Interface Layer Split: One Brain, Many Mouths

OpenClaw separates the interface layer (where messages come from) from the runtime layer (where intelligence lives). This sounds like obvious architecture, but the product implications are significant.

Your agent has one persistent brain (memory, skills, personality) accessible through WhatsApp, Telegram, Discord, Slack, Signal, iMessage, and 20+ other channels simultaneously. Each channel gets a thin adapter that normalizes messages into a common format. Adding a new channel means writing one adapter, not touching any agent logic.

Multi-agent routing takes this further. You can run multiple agents on one Gateway, like a “Home” agent and a “Work” agent, each with their own workspace, personality, skills, and memory, routed by channel, account, or even specific group chat.

The product decision this embeds: The agent should live where the user already is, not force the user into a new app.

Why this matters for your product: This is the design choice that, more than any other, explains why OpenClaw went viral. Steinberger built a personal assistant that lives inside the messaging apps people already use every day. There’s no new app to download, no new habit to form, no new UI to learn. The user’s mental model is just: “I’m texting my assistant.”

As Steinberger told Lex Fridman, the magic clicked when he was using it in Marrakesh over shaky mobile internet. WhatsApp just worked, even on edge connections. He wasn’t thinking about the agent as software. He was just asking for help.

5. Semantic Snapshots: How the Agent “Sees” the Web

When OpenClaw’s agent needs to browse the web, it doesn’t take screenshots and send them to the model (the approach most agent frameworks use). Instead, it parses the accessibility tree of a page and creates a structured text representation. They call it a Semantic Snapshot.

Instead of a 5MB screenshot, the agent gets something like:

- button "Sign In" [ref=1]
- textbox "Email" [ref=2]
- textbox "Password" [ref=3]
- link "Forgot password?" [ref=4]

That’s roughly 50KB. Same actionable information. The agent references elements by ref numbers (”click ref=1” to hit the Sign In button).

The product decision this embeds: Token efficiency is a first-class product concern, not just an engineering optimization.

Why this matters for your product: Every time your agent processes a screenshot, you’re burning tokens. And that’s real money. A semantic snapshot is roughly 100x smaller than a screenshot. Across thousands of web interactions, that’s the difference between an agent that costs dollars per day and one that costs cents.

But the advantage isn’t just cost. Precision goes up too. An agent clicking pixel coordinates based on a screenshot is inherently fragile; slight layout changes break everything. An agent clicking ref=1 on a structured accessibility tree is interacting with the semantic structure of the page, which is far more stable.

If you’re building any product that involves agent web interaction, semantic snapshots (or something like them) should be on your roadmap. The screenshot approach works for demos. It doesn’t work for production agents that need to be reliable and cost-effective at scale.

The Bigger Picture: Architecture Is Strategy

Here’s the framework I keep coming back to when evaluating any agent architecture, whether it’s mine, yours, or OpenClaw’s:

No column is objectively right. But every agent product makes an implicit choice in each row. The problem is that most teams make these choices accidentally, by inheriting framework defaults, rather than deliberately. OpenClaw is instructive precisely because every choice was intentional and traceable to a product value.

The question for your product team isn’t “should we copy OpenClaw’s architecture.” It is: what are the product values your architecture embeds, and are they the right ones for your users?

Because architecture is product strategy expressed in code. OpenClaw just happens to make that connection unusually legible.

OpenClaw is moving to a foundation structure now that Steinberger has joined OpenAI. What happens when the most opinionated open-source agent architecture meets the resources of the biggest AI lab? That’s the story worth watching, and I’ll be covering it as it develops.

"Our agent could handle routine requests perfectly, but when faced with complex issues, users would try once, get frustrated, and immediately ask for a human."

This pattern is observed across every product team that focuses on making their agents "smarter" when the real challenge is making architectural decisions that shape how users experience and begin to trust the agent.

We'll use a concrete customer support agent example throughout, so you can see exactly how each architectural choice plays out in practice. We’ll also see why the counterintuitive approach to trust (hint: it's not about being right more often) actually works better for user adoption.

Let's say you're building a customer support agent

You're the PM building an agent that helps users with account issues - password resets, billing questions, plan changes. Seems straightforward, right?

But when a user says "I can't access my account and my subscription seems wrong" what should happen?

The Four Layers Where Your Product Decisions Live

Think of agent architecture like a stack where each layer represents a product decision you have to make.

Layer 1: Context & Memory (What does your agent remember?)

The Decision: How much should your agent remember, and for how long?

This isn't just technical storage - it's about creating the illusion of understanding. Your agent's memory determines whether it feels like talking to a robot or a knowledgeable colleague.

For our support agent: Do you store just the current conversation, or the customer's entire support history? Their product usage patterns? Previous complaints?

Types of memory to consider:

• Session memory: Current conversation ("You mentioned billing issues earlier...")

• Customer memory: Past interactions across sessions ("Last month you had a similar issue with...")

• Behavioral memory: Usage patterns ("I notice you typically use our mobile app...")

• Contextual memory: Current account state, active subscriptions, recent activity

The more your agent remembers, the more it can anticipate needs rather than just react to questions. Each layer of memory makes responses more intelligent but increases complexity and cost.

Layer 2: Data & Integration (How deep do you go?)

The Decision: Which systems should your agent connect to, and what level of access should it have?

The deeper your agent connects to user workflows and existing systems, the harder it becomes for users to switch. This layer determines whether you're a tool or a platform.

For our support agent: Should it integrate with just your Stripe’s billing system, or also your Salesforce CRM, ZenDesk ticketing system , user database, and audit logs? Each integration makes the agent more useful but also creates more potential failure points - think API rate limits, authentication challenges, and system downtime.

Layer 3: Skills & Capabilities (What makes you different?)

The Decision: Which specific capabilities should your agent have, and how deep should they go?

Your skills layer is where you win or lose against competitors. It's not about having the most features - it's about having the right capabilities that create user dependency.

For our support agent: Should it only read account information, or should it also modify billing, reset passwords, and change plan settings? Each additional skill increases user value but also increases complexity and risk.

Implementation note: Tools like MCP (Model Context Protocol) are making it much easier to build and share skills across different agents, rather than rebuilding capabilities from scratch.

Layer 4: Evaluation & Trust (How do users know what to expect?)

The Decision: How do you measure success and communicate agent limitations to users?

This layer determines whether users develop confidence in your agent or abandon it after the first mistake. It's not just about being accurate - it's about being trustworthy.

For our support agent: Do you show confidence scores ("I'm 85% confident this will fix your issue")? Do you explain your reasoning ("I checked three systems and found...")? Do you always confirm before taking actions ("Should I reset your password now?")? Each choice affects how users perceive reliability.

Trust strategies to consider:

• Confidence indicators: "I'm confident about your account status, but let me double-check the billing details"

• Reasoning transparency: "I found two failed login attempts and an expired payment method"

• Graceful boundaries: "This looks like a complex billing issue - let me connect you with our billing specialist who has access to more tools"

• Confirmation patterns: When to ask permission vs. when to act and explain

The counterintuitive insight: users trust agents more when they admit uncertainty than when they confidently make mistakes.

So how do you actually architect an agent?

Okay, so you understand the layers. Now comes the practical question that every PM asks: "How do I actually implement this? How does the agent talk to the skills? How do skills access data? How does evaluation happen while users are waiting?"

Your orchestration choice determines everything about your development experience, your debugging process, and your ability to iterate quickly.

Lets walk through the main approaches, and I'll be honest about when each one works and when it becomes a nightmare.

1. Single-Agent Architecture (Start Here)

Everything happens in one agent's context.

For our support agent: When the user says "I can't access my account," one agent handles it all - checking account status, identifying billing issues, explaining what happened, offering solutions.

Why this works: Simple to build, easy to debug, predictable costs. You know exactly what your agent can and can't do.

Why it doesn't: Can get expensive with complex requests since you're loading full context every time. Hard to optimize specific parts.

Most teams start here, and honestly, many never need to move beyond it. If you're debating between this and something more complex, start here.

2. Skill-Based Architecture (When You Need Efficiency)

You have a router that figures out what the user needs, then hands off to specialized skills.

For our support agent: Router realizes this is an account access issue and routes to the `LoginSkill`. If the LoginSkill discovers it's actually a billing problem, it hands off to `BillingSkill`.

Real example flow:

1. User: "I can't log in"

2. Router → LoginSkill

3. LoginSkill checks: Account exists ✓, Password correct ✗, Billing status... wait, subscription expired

4. LoginSkill → BillingSkill: "Handle expired subscription for user123"

5. BillingSkill handles renewal process

Why this works: More efficient - you can use cheaper models for simple skills, expensive models for complex reasoning. Each skill can be optimized independently.

Why it doesn't: Coordination between skills gets tricky fast. Who decides when to hand off? How do skills share context?

Here's where MCP really helps - it standardizes how skills expose their capabilities, so your router knows what each skill can do without manually maintaining that mapping.

3. Workflow-Based Architecture (Enterprise Favorite)

You predefine step-by-step processes for common scenarios. Think LangGraph, CrewAI, AutoGen, N8N, etc.

For our support agent: "Account access problem" triggers a workflow:

1. Check account status

2. If locked, check failed login attempts

3. If too many failures, check billing status

4. If billing issue, route to payment recovery

5. If not billing, route to password reset

Why this works: Everything is predictable and auditable. Perfect for compliance-heavy industries. Easy to optimize each step.

Why it doesn't: When users have weird edge cases that don't fit your predefined workflows, you're stuck. Feels rigid to users.

4. Collaborative Architecture (The Future?)

Multiple specialized agents work together using A2A (agent-to-agent) protocols.

The vision: Your agent discovers that another company's agent can help with issues, automatically establishes a secure connection, and collaborates to solve the customer's problem. Think a booking.com agent interacting with an American Airlines agent!

For our support agent: `AuthenticationAgent` handles login issues, `BillingAgent` handles payment problems, `CommunicationAgent` manages user interaction. They coordinate through standardized protocols to solve complex problems.

Reality check: This sounds amazing but introduces complexity around security, billing, trust, and reliability that most companies aren't ready for. We're still figuring out the standards.

This can produce amazing results for sophisticated scenarios, but debugging multi-agent conversations is genuinely hard. When something goes wrong, figuring out which agent made the mistake and why is like detective work.

But here's what's interesting - even with the perfect architecture, your agent can still fail if users don't trust it. That brings us to the most counterintuitive lesson about building agents.

The trust thing that everyone gets wrong

Here's something counterintuitive: Users don't trust agents that are right all the time. They trust agents that are honest about when they might be wrong.

Think about it from the user's perspective. Your support agent confidently says "I've reset your password and updated your billing address." User thinks "great!" Then they try to log in and... it doesn't work. Now they don't just have a technical problem - they have a trust problem.

Compare that to an agent that says "I think I found the issue with your account. I'm 80% confident this will fix it. I'm going to reset your password and update your billing address. If this doesn't work, I'll immediately escalate to a human who can dive deeper."

Same technical capability. Completely different user experience.

Building trusted agents requires focus on three things:

1. Confidence calibration: When your agent says it's 60% confident, it should be right about 60% of the time. Not 90%, not 30%. Actual 60%.

2. Reasoning transparency: Users want to see the agent's work. "I checked your account status (active), billing history (payment failed yesterday), and login attempts (locked after 3 failed attempts). The issue seems to be..."

3. Graceful escalation: When your agent hits its limits, how does it hand off? A smooth transition to a human with full context is much better than "I can't help with that."

A lot of times we obsess over making agents more accurate, when what users actually want was more transparency about the agent's limitations.

What's Coming Next

In Part 2, I'll dive deeper into the autonomy decisions that keep most PMs up at night. How much independence should you give your agent? When should it ask for permission vs forgiveness? How do you balance automation with user control?

We'll also walk through the governance concerns that actually matter in practice - not just theoretical security issues, but the real implementation challenges that can make or break your launch timeline.

For the last two decades, the tech world’s real currency was attention. Whoever controlled the user’s attention owned distribution: Google with search, Apple with app stores, Facebook with the feed. But there’s a new game now, and the rules are being rewritten at breakneck speed.

It’s no longer about what a user sees. It’s about how easily an AI agent can access and use your product to get things done without friction, and at machine speed.

1. The Rise of AI Clients & Callable Products

A new interface layer is emerging: the AI client. Products like ChatGPT, Claude, and Cursor aren’t just answering questions. They’re acting as your bespoke operator, taking action across dozens of apps and APIs, stitching together workflows, and making decisions you once made by hand.

In this world, callable products (products that can be directly invoked by models) become the new gatekeepers of distribution. If your service, tool, or workflow isn’t exposed in a way these agents can call upon, you become invisible, no matter how polished your home page or onboarding flow.

2. ChatGPT Agent Mode Signals the Demand Shift — But It’s Not (Yet) Open

The unveiling of ChatGPT’s Agent Mode this week isn’t just an incremental feature. It’s tectonic and it shows us where demand is heading. Agent Mode turns ChatGPT from a conversational assistant into an autonomous, workflow-driving operator. It sequences tasks, interacts with tools, holds context, and executes end-to-end jobs without direct human steering.

Let’s break that down:

• Task Chaining: The agent hears “Plan our Q4 offsite” and handles calendaring, location scouting, booking, and payments; possibly across multiple tools.

• End-to-End Execution: These aren’t one-shot API calls. They’re multi-step decisions with context, memory, and retries.

• User Delegation Norms: As users get comfortable delegating full workflows to agents, the expectations of products shift too: composability, predictability, and programmatic clarity become the new UX.

👉 But here’s the key: ChatGPT’s Agent Mode currently relies on custom logic and integrations meaning it’s hand-built, not open-discovery. This creates a massive opportunity for standardized invocation.

“Users are ready to let agents act on their behalf — so now, agents need a standard way to find, understand, and safely invoke products.”

This shifts the product landscape: How do we design products that agents choose intuitively?

3. The Model Context Protocol: Key to the New Software Stack

Model Context Protocol (MCP) is the emerging lingua franca of agent integration and are being coined as the “USB-C for models and actions” letting you expose what your product can do, and how, in a format models understand. MCPs streamline integration by providing capabilities that unlock:

• Agents discovering tools, permissions, and actions with zero guesswork.

• No brittle, custom integrations; no ad-hoc hacking.

• Whether you’re a SaaS giant or a three-person startup, MCP levels the playing field: if your actions are described, agents can find and use them.

4. Discoverability in the Age of MCP: The New Product Battleground

If you build the best travel engine, but the agent calls your competitor’s API because of a partnership, schema fit, or faster response time, you never get to the table even if users want you. With potentially hundreds of MCP-compliant endpoints proliferating, how does your product stand out to agents hunting for the perfect tool to fulfill a user’s intent?

To ensure discoverability in a future where hundreds of MCPs exist you must ensure your product offers:

• Clear, semantic descriptions of actions, inputs, and outputs (not just technical fields, but business-relevant intent and usage scenarios).

• Rich metadata for permissions, usage restrictions, and context, making it easy for agents to interpret what’s safe, relevant, and applicable.

• Fast, reliable endpoints that support low-latency, conversational interactions as agents will default to tools that respond quickly and handle volume gracefully.

• Centralized and unified architecture, so that a single MCP surfaces broad, cohesive capabilities rather than fragmented services.

  If you’ve enjoyed reading so far, please take a moment to subscribe

5. Metrics, Metrics and Metrics

As Product Managers, we need a new lens on metrics. While traditional dashboards like DAU, retention, and conversion are still important, they don’t reveal how visible or valuable your product truly is to agents. Let’s break it down.

1. Invocation Rate

What it tells you: How often your product is being invoked by agents (Copilot, Cursor, Perplexity) relative to peers or similar tools.

• Metric: # of Agent Calls per Day / Session

• Why it matters: Invocation is the new homepage visit. If agents aren’t calling your product, you’re losing discoverability.

2. Invocation Share

What it tells you: Out of all eligible tools or APIs in a domain (e.g., “summarize PDF”), what percentage of invocations does your product get?

• Metric: Your Tool Invocations / Total Invocations in Category

• Why it matters: Helps benchmark competitive discoverability. Losing share? Your MCP metadata or capabilities may be under-optimized.

3. First-call Success Rate

What it tells you: When an agent calls your product, does it work well enough on the first try to meet the user’s intent?

• Metric: Successful Outcomes / Total Agent Invocations

• Why it matters: Agents optimize for reliability. If you return errors, ambiguous results, or slow responses, you’ll get deprioritized fast.

4. Agent Feedback Signals

What it tells you: Are agents giving implicit feedback like retrying with another tool, rephrasing, or manually overriding your invocation?

• Examples:

  • Retry Rate

  • Re-invocation of different tool for same task

  • User manual selection override

• Why it matters: These signals often happen silently. They're your new churn indicators.

5. Metadata Completeness Score

What it tells you: How well-described and interoperable your tool is within MCP clients.

• Metric: Percentage of completed fields in MCP schema (capabilities, examples, usage hints, categories)

• Why it matters: Well-documented products with clear affordances are more likely to be discovered and invoked.

6. Latency-to-Invocation Dropoff

What it tells you: How sensitive your invocation rate is to performance and latency.

• Metric: Invocation Dropoff (%) vs. Response Time (ms)

• Why it matters: Agents prefer fast tools. You may be losing invocations purely on latency, not capability.

TL;DR: Think Like an API, Compete Like an App Store

6. Challenges & Open Questions

A new stack this powerful comes with risks, riddles and a few what ifs:

• Will giants like OpenAI, Apple, Microsoft or Google fork MCP for their own platforms? Or will open standards win?

• How do we handle safety, abuse, throttling, billing, and identity, now that thousands of actions can be triggered per second by agents, not humans?

• Who decides what gets promoted and why? Do we end up with “sponsored invocation” and a pay-to-play ecosystem at the agent layer?

• What does governance look like when agents can transact and orchestrate on our behalf at scale?
  

In the coming decade, your model-native products don’t need to be pretty. They need to be callable, composable, and the invisible backbone for agentic workflows.

If you’re building anything model-forward or callable by default, I want to jam. Let’s trade notes, team up something weird, or help each other win this shift. Hit me up on LinkedIn!

According to Sacra, Cursor skyrocketed from $1M in ARR in 2023 to $100M by the end of 2024—a staggering 9,900% year-over-year growth. It reached this milestone in just 12 months, surpassing other high-growth companies like:

• Wiz (18 months to $100M ARR)

• Deel (20 months to $100M ARR)

• Ramp (24 months to $100M ARR)

The hype around Cursor AI has been real. To give an example, Ricky Robinett, VP of developer relations at Cloudflare, posted a video of his eight-year-old daughter building a chatbot on the Cloudflare Developer Platform in just 45 minutes using Cursor AI, documenting the whole process, even the spelling mistakes while giving prompts! In this edition of Product Curious, we look into Cursor’s distribution hacks, Product Led Growth tactics, and an insane focus on Developer Community growth.

The Secret Sauce: 3 Product Principles That Made Cursor Unstoppable

When people think ‘AI plus coding,’ their mind usually goes to AI-powered autocomplete. Cursor AI thinks this has been done particularly well by GitHub Copilot and others, so they focused on problems that come after autocomplete, like finding and fixing bugs and codebase Q&A.

1. Performant, Aware and Flexible: AI-Native First, Editor Second

The team rejected the prevailing "AI as plugin" paradigm, instead rearchitecting the entire coding environment around AI capabilities from the ground up. They also knew that developers would abandon a tool that slowed them down, so Cursor was always designed for speed. This manifested in three foundational choices:

• Forked VS Code Architecture: By modifying VS Code's core rather than building plugins, they gained low-level access to implement features like real-time model inference (achieving <150ms latency vs. GitHub Copilot's 300-500ms).

• Contextual Awareness Engine: Unlike tools limited to single-file analysis, Cursor indexes entire codebases to power features like cross-file refactoring and architecture suggestions.

• Multi-Model Orchestration: Early integration of OpenAI, Anthropic, and proprietary models allowed performance optimization per task (e.g., Claude for creative solutions, GPT-4 Turbo for boilerplate)

2. Massive Developer Empathy: Reducing Cognitive Load

Cursor’s UX decisions stemmed from obsessive study of developer workflows:

• Frictionless Adoption: Maintaining VS Code keybindings and UI conventions reduced switching costs, helping capture 360,000+ developers in just about 18 months

• Cognitive Load Reduction: Features like "Codebase Chat" (natural language Q&A about project structure) and auto-generated documentation directly address pain points identified in 200+ user interviews,

3. Code Privacy. That’s Cursor!

• Local Processing: All code analysis runs on-device unless explicitly opted into cloud processing.

• Selective Context Sharing: Users control which code snippets are sent to AI models, with automatic scrubbing of sensitive patterns (API keys, credentials)

Subscribe now

From Zero to Viral Hero: The Growth Explosion Recipe

Cursor’s first 1000 users came through targeted outreach to MIT alumni and Y Combinator’s startup network in late 2022. The team implemented three growth hacks:

1. Freemium Led Growth:

   Cursor’s pricing model created a self-reinforcing adoption loop. The free tier’s 2,000 completions aligned with average hobbyist usage patterns, while paid tiers targeted professional needs. This structure achieved:

   • 14% free-to-paid conversion rate

   • 40% team adoption within 30 days of individual upgrade

2. Product Led Growth:

   1. VS-Code Familiarity: By maintaining VS Code keybindings and UI conventions, they reduced the learning curve for developers already comfortable with VSCode.

   2. Smartly Hiding Latency: Prefetching suggestions during natural pauses (file saves, keystroke gaps) created perceived instantaneity

   3. Vertical Integrations: Partnerships with Vercel/Replit enabled one-click deployments from editor reducing context switching dramatically.

   4. Community Led Growth: Early adoption by engineers at influential companies like OpenAI, Midjourney, and Perplexity created word-of-mouth buzz within the developer community. However, a lot of success is attributed to three key masterstrokes:

      • Open Source Contributions: Founders contributed to React/TensorFlow with Cursor-optimized code, attracting maintainers.

      • "Edited with Cursor" Footers: Auto-added to pull requests, driving 32% of organic signups via GitHub visibility.

      • Coding Bootcamp Partnerships: Free licenses for Lambda School/Fullstack Academy created bottom-up enterprise adoption (22% conversion to paid within 6 months)

        

Why Cursor Has a Strong Future Against Incumbents

Despite being a newer player, Cursor has built impressive advantages that position it well against tech giants like Microsoft and GitHub. Here's what makes Cursor special:

Lightning-Fast Performance

1. Instant Response Times: Thanks to clever engineering, Cursor responds twice as fast as GitHub Copilot (sub 150ms latency) making coding feel smooth and natural

2. Smarter Code Understanding: Unlike other tools that only look at one file, Cursor understands your entire codebase, making it better at suggesting improvements and fixes

3. Best-in-Class AI: By combining multiple AI models (GPT-4, Claude 3.5, and others), Cursor picks the perfect tool for each task - whether you're writing new code or fixing bugs

Privacy You Can Trust

1. Your Code Stays Private: Cursor processes your code locally on your computer, not in the cloud (unless you specifically opt for it)

2. Enterprise-Ready: Cursor earned important security certifications (SOC2 Compliance) in record time, making it safe for business use even in highly regulated industries.

3. You're in Control: You decide what code snippets Cursor can see, and sensitive information is automatically scrubbed.

Growing Ecosystem

Cursor works seamlessly with popular developer tools building an ecosystem through strategic partnerships:

Built By Developers, For Developers

Cursor puts the developer community first, operationalizing developer communities as a defensible asset and building strong brand loyalty.

Additionally, Cursor achieved $276 ARPU through individual developers, avoiding enterprise sales complexity.

Subscribe now

The Future of AI Coding: Why You Should Be Excited About It?

Cursor published its initial roadmap in 2023 titled "Our Problems" and a follow-up in 2024 titled "More Problems," offering unique insights into how a category-defining AI startup prioritizes challenges. For early-stage founders and product managers, this roadmap reveals vital lessons in building defensible AI products, executing community-driven development, and maintaining technical momentum. Here are the three core problems that stand out:

1. Contextual Intelligence at Scale: Teaching AI to Understand Entire Codebases

Cursor aims to transform how AI understands codebases by integrating diverse data sources:

• 500k Token Context Window: Aggregating open files, git history, execution traces, and external docs into a unified context.

• Custom Reranker Model: Filters context to 8k relevant tokens per query while maintaining <150ms latency.

• 1.4B+ Vectors Indexed: Scaling codebase understanding to enterprise-grade repositories.

Why It Matters: Traditional AI coding tools (GitHub Copilot) operate on single-file contexts, limiting their utility in complex projects. Cursor's approach enables cross-file refactoring and architecture-level suggestions—critical for enterprise adoption.

2. Edit-Centric AI Workflows: Fix More, Type Less

Cursor is reimagining AI's role in code modification:

• "Copilot for Edits": Focuses on low-entropy keystroke reduction for existing code (renames, type changes).

• Real-Time Diffs: Unobtrusive visualizations of AI-proposed changes during active coding sessions.

• Multi-File Refactoring: Agents that modify entire directories while preserving code structure.

Why It Matters: Developers spend 70% of time modifying existing code. Tools optimizing this phase unlock 10x productivity gains vs. new-code-focused solutions.

3. Constrained-Agent Architectures: Smarter Agents, Fewer Mistakes

Cursor is pioneering a new paradigm for AI-assisted development:

• Few-Step Agents: Execute tasks like dependency upgrades within defined boundaries, consulting users for feedback.

• Local-First Execution: Operates on 100k-token codebases without cloud dependencies.

• Passive Bug Detection: Background scanning + active debugging modes.

• Prefetching: Anticipates developer needs during natural pauses (keystroke gaps, file saves)

Why It Matters: Autonomous coding agents often produce unstable results. Cursor's constrained approach balances automation with human oversight—a model for reliable AI products.

In conclusion, Cursor’s journey from MIT dorm room to $100M ARR demonstrates the transformative potential of AI-first tooling. By combining technical audacity (forking VS Code) with community-driven growth, the team has created a new paradigm for developer productivity. As AI capabilities advance, Cursor’s focus on real-time collaboration, local model execution, and richer vertical integrations positions it to define the next era of software development. Emerging startups should heed their playbook: integrate deeply, iterate relentlessly, and empower users as co-creators!

Mohit Jitani, Product Director at Spotify was tasked with the challenge to “looking into what learning could look like for Spotify?”. This is a master-class in identifying a sizeable market, rapid iteration, and a strong go-to-market strategy. “Courses on Spotify” is being launched specifically in the U.K with partners like BBC Maestro, PLAYvirtuoso, Skillshare, Thinkific. Why is Spotify getting into the education space, why only the UK and why could this be right strategic move? Let’s find out!

Come for the podcast, stay for the course - The fly-wheel effect!

“One of the most interesting things and trends that we started noticing was more and more people were starting to come to Spotify with some intent of learning,” Jitani says. “And we thought, how can we take this core insight and build something on top of it?” In a press release, Jitani continues to say that around half of its Premium subscribers have engaged with education or self-help themed podcasts.

The increase in demand for online learning isn’t fading anytime soon. Infact, Coursera released its 2023 Impact Report, which shows more than 20 million new learners registered for courses in the year - equivalent to total growth in the three years pre-pandemic. The question still remains unanswered, why take a multi-business model and multi-vertical approach within one user experience instead of doubling down on existing trends like short-form videos/ reels for the music, podcast or even the new audio-books vertical?

Well, video isn’t totally new to Spotify. In non-US markets, they’ve been penetrating the music video and podcast video space for the last few years. My best guess is that Spotify is creating a fly-wheel effect. By hosting far more than just music, the company can increase engagement, raise prices and maximize value in a bet to reach its long-time goal of becoming profitable.

Is Spotify’s Q2 earnings call, CEO Daniel Ek and interim CFO Ben Kung repeatedly referred to “the Spotify Machine” when explaining the company’s expansion beyond music. As Ek explained, the term means the company “isn’t just a sort of one-trick pony anymore, but it’s actually multiple verticals working together” to create more choice for consumers and drive more engagement. Almost like “you may come for the music and stay for the audiobooks,” or “some customers may come for the podcast and stay for the education content.”

This strategy for Spotify to branch out from music will help improve its margins and become the profitable company it has long aspired to be. Music margins are roughly 30% of revenue — the remaining 70% goes to rights holders. Ultimately, the goal here is to increase app engagement. When engagement increases, churn decreases. This by design is inherently limited if the company sticks to its audio-first model. This strategy not only benefits the company but also benefits the user by giving them greater freedom of choice and providing more value.

Why the U.K.?

Babar Zafar, VP of Product Development at Spotify, said in a statement “Testing video courses in the U.K. allows us to explore an exciting opportunity to better serve the needs of our users who have an active interest in learning.” According to the World Economic Forum, The highest rate of new learner growth online came from emerging economies. Then why choose the U.K. as the primary market to experiment the success of this product with?

Selecting the right market would mean considering the three forces:

1. Demonstrated Market Appetite for e-learning.

2. Infrastructure supporting e-learning.

3. Spotify’s existing captured market foot-hold.

Let’s breakdown the forces one at a time starting with the market appetite.

Market Appetite:

Unsurprising for the online learning market which is estimated to have been worth more than $315 billion in 2023. Let’s look at few stats:

1. 75% of the internet search for online education comes from only 14 countries.

2. 10 of the 14 countries do not have English as the most spoken language.

3. 8 of the 14 are developing countries.

   

Infrastructure Support and Readiness:

Macro-economic factors contribute a lot to the success of a particular industry. E-Learning index is a great metric to interpret and understand learning and infrastructure support in a consumable manner. It is scored on the following nine parameters:

The top five markets by weighted scores are Denmark, United States, Ungary, U.K, and France. More detailed report here: https://preply.com/en/d/e-learning-index. The U.K. holds a strong #4 on the list.

Spotify’s existing foot-hold

Spotify’s market capture needs no introduction, with over 600 million MAUs Spotify leads the industry in the music segment. Europe, with its 121 million annual users, is the largest market for Spotify, the US's 65 million annual users make it the individual country that uses the app the most. The U.K. still ranks a #3 in this list as well.

A smart combination of existing foothold, room to experiment, infrastructure readiness and market appetites makes U.K. the most promising candidate in this segment. But so does it make the U.S. a promising candidate, doesn’t it? It seems that there are two more factors contributing to this decision: 1. Existing entry of Spotify video streaming in the U.K. and 2. Spotifiy’s origins in Europe!

How will Spotify differentiate itself?

The streaming service is offering courses within four categories: make music, get creative, learn business, and healthy living. To begin with, Spotify is offering courses via a freemium model, similar to the one it used when it first launched audiobooks. Free and premium Spotify subscribers alike are able to access at least two video lessons per course for free, but will have to pay a fee to access the full course.

A large chunk of Spotify's offered courses are fittingly music-related, with tutorials for music recording and production, songwriting, DJing, radio broadcasting, and specific genre courses including rap, grime, garage, drum and bass, house, and techno. But there are also courses geared toward a larger range of topics including startups and business, cooking, money, dancing, fitness, mindfulness, video production, and art techniques from watercolour painting to photography and graphic design.

This is vastly different from the up-skilling courses we see on Coursera, Udemy and EdX. The identified gap seems to be very focused on music, video, arts, personal and mental health. It is a win-win situation for the partners to leverage the strong distribution network of Spotify to broaden their reach. Let’s look at a few examples below.

Partnerships - The creator funnel.

The first partners for Courses are Skillshare (which will focus on creatives), PLAYvirtuoso (music industry courses), BBC Maestro (Master Class-esque) and Thinkific (for those inspired to build their skills into online learning classes of their own). It is an interesting mix of high quality creators (think celebreties and progressionals) and independent creators aggregated across different platforms.

• BBC Maestro creates content to educate and inspire people to explore their creativity. Through prerecorded lessons and detailed course notes, anyone can learn a wide range of disciplines and follow in the footsteps of experts respected all over the world. www.bbcmaestro.com

• PLAYvirtuoso is transforming modern music learning through artist-led courses, mentoring, and structured curriculums. PLAYvirtuoso develops artists to become inspirational educators and empower young creatives with real skills and outcomes. www.playvirtuoso.com

• Skillshare is an online learning community where millions of creatives go to develop and deepen their skills. Watch thousands of creative classes in topics including design, freelance, 3D animation, entrepreneurship, photography, productivity, and more. Join today at https://join.skillshare.com/learn

• Thinkific Labs Inc. is a leading platform for creating, marketing, and selling courses, digital products, communities, and learning experiences. www.thinkific.com

This partnership model works well for the partners as well allowing for more education content creators to use their (the partner’s) platforms to curate content and leverage the hosting and distribution of Spotify. The partnership story doesn’t stop here but it starts here. Spotify will soon define segments and a strong partner pricing model. “We’ll learn a lot about what people are actually interested in [and] we will start getting a lot of segments around that,” Jitani said. “And then we’ll go and find… the best content.”

So will your next course be on Spotify?

If you think of it companies like BBC, Skillshare, Thinkific and PlayVirtuoso would have had nothing to do with Spotify had it not been for this experiment. Spotify doubled down on its distribution network, wide outreach, agility to experiment and create the fly-wheel effect to support more revenue streams.

Spotify is the only company after Youtube, TikTok and Meta to have a very strong content distribution reach. While Youtube, TikTok and Meta focused on short form content, Spotify is taking its bet on long form content through podcasts, audiobooks and now education. It’s a strategic bet and will ensure that it dominates the space with strong creation powered by an even stronger distribution.

It’s a great case study in realism and business, where we are not talking colonizing mars, AGI, reducing global carbon footprint but purely product driven business. It remains to be seen whether this experiment will strike a chord with listeners or fall flat. Still, Spotify's willingness to try something new demonstrates its commitment to keeping users engaged on the platform, even if it means stepping outside its comfort zone.

References

1. https://courses.spotify.com

2. https://www.weforum.org/agenda/2022/01/online-learning-courses-reskill-skills-gap/

3. https://blog.coursera.org/coursera-2023-learner-outcomes-report/

4. https://worldpopulationreview.com/country-rankings/spotify-users-by-country

5. https://preply.com/en/d/e-learning-index

6. https://www.semrush.com/website/spotify.com/overview/

7. https://www.linkedin.com/pulse/75-online-education-demand-comes-from-countries-abhishek-chhibber/

Raphael Schaad, who heads Notion Calendar, describes the solution as “a new way to manage your most precious resource, - Time.”

Why build another calendar app in an already saturated market? What are the gaps in existing solutions? Why is Notion uniquely positioned for this? Why now? Let’s find out..

Notion states that the overall vision here is to bring a “time layer” to every aspect of life.They aspire to be the layer that helps you understand, visualize and comprehend your relationship with time. What is this “time layer” and what is so unique about this? Before we dive into the specifics and strategy, let’s understand Notion a little bit in depth and some history. 

What should you know about Notion that you don’t already know?

Notion’s has been in the business of redefining productivity with their versatile all-in-one workspace integrating note-taking, project management, and collaboration features with an extremely well defined set of community developed integrations.

However, their success is rooted on two primary fronts:
1. Strong Community and Network Effects.
2. Minimalist yet powerful Design.

Notion actively cultivates community champions through programs like Notion Pros and Ambassadors. These power users create tutorials, templates and integrations that assist fellow users. Additionally, Notion maintains an active presence across over 150 online communities on platforms like Reddit and Facebook. These allow users to exchange tips, share experiences, and foster connections.  A thriving community promotes loyalty, and now with over 20 million users, Notion is valued at $10 billion!

A dive into History: The acquisition of Cron

Cron is the backbone behind “Notion’s Calendar App”. Notion acquired Cron in June 2022. Cron, which was part of Y Combinator's winter batch of 2020 had raised a $3.5 million seed round in March 2020 with notable investors like Y Combinator CEO Garry Tan, Elad Gil, Figma founder Dylan Field, former LinkedIn CEO Jeff Weiner and Sunrise co-founder Jeremy Le Van.

Cron addressed some of the most basic time interaction needs of the market -  Time zone conversions. Multiple accounts. A cleaner, faster interface, and ofcourse, dark mode! Cron was making waves and applauds in the industry.

Cron for iOS was named Mobile App of the Year 2022! Cron was recognized for Best Design in a Calendar App in 2022 and was awarded Productivity App of the Year in 2021.

This caught Ivan’s (Notion’s co-founder) eye.

Where is the Gap? What Metrics are they behind? 

I believe that Notion is optimising for “Time Spent in Managing Time”. For example, checking the time of an upcoming meeting may feel harmless, but this context-switching can be detrimental to productivity (it takes up to 23 minutes to regain focus).

Notion’s approach to user-centred design enables it to imagine a world where time is seamlessly integrated into our lives. Productivity solutions today are very disjoint in nature in their interaction with time and exist in disconnected environments. If you paint the landscape of all the places we interact with time today on the back of a napkin, here’s what it looks like: 

Clearly, there is a huge cognitive overload in managing time across our lives and it seems that Notion sensed a unique opportunity to build a layer that wraps across multiple dimensions of managing time. 

Why now and Why Notion? 

It seems that Notion is not trying to compete head-to-head with other Calendar apps. Their core focus is not to provide a better time-management capability but instead interleave time as the connective tissue across calendar, tasks, documents, work/personal profiles and timezones. 

You might not be very impressed with the feature set of the Calendar App launched today but the beauty lies in bringing the product to the community (and not necessarily the market). Notion’s strong distribution effects. By providing a robust set of integration points, Notion will leverage the power of the community to build workflows and models that help solve time-based use cases at scale. It's smart how Notion did not wait to build the perfect product before launching, but instead is building with the community that’s invested in it’s success.

Getting to Launch

While Notion does have a good number of loyal users and a strong foothold in the community, the Notion Calendar is launched as a standalone product. Notion still needs to have differentiating features from the other calendar apps and that’s where it doubles down on its strength in simplistic design. 

Notion has kept it’s focus on seven core scenarios:

1. Minimise Distractions.

2. Built-in scheduling and availability sharing capabilities.

3. Thoughtful coordination across multiple time-zones..

4. Out of box support for 12+ Languages.

5. End-to-end integration with Notion workplace - across Documents, Project Timelines, Quarterly Planning, Personal commitments etc. 

6. Two way sync across multiple calendars + Zoom/ Meet Integrations.

7. Out of the box iOS application.

Explore more here: https://www.notion.so/product/calendar

The Vicious Circle of Uncovering Product Value

One of the best known ways to get user commitment and loyalty is to get their skin in the game by having them invest the time and effort to uncover product value. IKEA and Costco are both notoriously famous for doing that. Notion does that too and super well at scale. Infact, it does not employ a huge workforce of Solution Architects/ Professional Services to help achieve this at enterprises, it very much relies on community driven marketing and product led growth! 

Now because Notion has done this before, it knows how to do it again. They likely will have users go through the value curve until enough use cases have been built or discovered that the product starts to differentiate itself. Today, they’re kicking off with a very familiar calendar look-a-like which doesn’t seem very different from a traditional calendar app (think GCal + Calendly+ Cron combined) but the future does seem ambitious! 

If it’s free, how will it generate Revenue? 

This is Notion's classic entry into the untapped “Time Management” market. It is operating on the classic model of lowering costs and barriers to get users addicted. The fact that it is launched as a standalone app signals that users need not be actively using the Notion platform but also hints at the potential that is waiting to be unlocked if they were to be on it. Then follows the Domino effect. 

Let’s say, I try Notion Calendar to manage my personal life and let’s say sharing my availability for mentorship sessions -> I then uncover more templates or use cases powered by the community and understand powerful Notion integrations -> I get hooked on to Notion and leverage further nuanced scenarios for School, Fitness, Diet, Date Nights etc. -> I share my templates with my friends, workout group, partner and even children!

I won't stop there. Next time I see a similar problem at my work-place -> I know exactly the kind of Notion solutions that are built to solve this and a push for a sale purchase order is made. The Domino Effect continues. 

Will this be a breakthrough product? 

Addressing the Elephant in the room. Will this be a breakthrough innovation? 

Maybe. In the future. If the vision is followed through. For now, it seems as though: 

1. Indistinguishable from existing Calendar apps on the market.

2. Next to none out of the box integrations/ workflows/ templates offered.

3. Lack of features, such as support for Outlook/Apple Email and Android/iPad.

Notion has a very strong “distribution network” and has the “flywheels" in effect to empower the community to build more. It is in a unique position to create these effects without necessarily being open-source.

Sometimes getting things out in the market and letting systemic effects do its magic is a stronger move, than to perfect a product offering and then release it.

I’m sure nothing in 2024 will go without the use of the word “AI”. I am curious to see where this lands and how the offerings evolve. Until then, subscribe for more such product deep-dives.