The setup: SaaS is down, but the products are up
Investor sentiment on SaaS is risk-off. Public-market SaaS names, including Asana, are trading materially below their peaks. But if you look at real product performance — Figma, Atlassian, Datadog, Asana — the businesses are quietly having strong quarters. End-user utilisation hasn’t tapered off the way the market implies. Bose’s framing:
- Reality one — risk-off sentiment. Investors are pricing in a story where LLMs replace enterprise workflow apps.
- Reality two — the products still deliver value. 99.99% uptime, enterprise governance, security, trust. Real workflows still run on these products.
- Reality three — two AI-industry structures are forming. The AI infra layer (picks and shovels) that investors love, and the AI-value layer sitting on top of it. The value layer is where jobs-to-be-done haven’t changed much — the question is which incumbents can move fast enough to exploit the AI tailwind.
The core thesis: the work graph as the compounding asset
Asana’s data model is a work graph: mission → goal → portfolio → projects → tasks. Bose calls it “an enterprise context graph.” Every task carries who does what, by when, how, and why — the raw ingredients an AI agent needs to be useful in a business.
The bet is that whoever holds the richest shared context wins, not whoever has the best model. The model is a commodity; the context is proprietary.
“The future of AI at work belongs to whoever has the richest shared context, not whoever has the best model.”
— Arnab Bose, paraphrased from the episode intro
The mechanic: every approval is training data
This is the sharpest idea in the interview. Goldman Sachs and McKinsey both published research showing enterprise AI spend has produced near-zero measurable productivity gain. Bose’s explanation: people are chatting with genius LLMs one-on-one, copy-pasting outputs in and out of the systems where work actually happens. None of those decisions make it back into a shared context. Nothing compounds.
Asana’s counter-move is to make the loop closed and automatic:
- An AI agent proposes a spec, a plan, a PR — even a bad one.
- A human approves, edits, or rejects it.
- That correction is written back into the work graph, not lost in a chat window.
- Next iteration starts from that new state. The graph gets deeper. The agent gets sharper.
Bose’s phrase: “human beings are becoming like evals.” Yes/no/approve/change becomes feedback that trains the shared memory. Week over week, month over month, the loop compounds.
Even a shallow graph works, as long as the correction loop is captured automatically. The 2016 problem — nobody wants to update Jira/Asana/Salesforce — was fatal because humans had to read all that context. Agents don’t have that limit. Feeding them a shallow graph they can improve is more valuable than trying to hand-build a deep one.
Two modalities of work
Bose is deliberate about splitting Asana’s AI strategy into two flows, each with a different design ethic:
1. Headless / MCP — individual productivity
Expose the work graph via MCP and MCP UI into every LLM app the user already lives in. Asana has apps for Claude, ChatGPT, and Google’s Gemini. Ask Claude “what should I focus on today?” and it can read your Asana + Gmail + calendar and update project data for you. This is a read-and-write integration, not a chatbot.
The design goal is to eliminate the tax of putting information into Asana. Meet users where they are. Salesforce is doing the same thing — going headless, exposing data via well-structured APIs and MCP.
2. Multiplayer agents — collaborative work
This is the more novel flow. Inside Asana, AI agents live as teammates in the graph, not as anyone’s personal assistant.
- Powered by frontier models today, with a roadmap toward BYO agents.
- Assigned to projects and portfolios like a human. Role-based access control applies.
- Watch the graph. React to questions. React to status updates. Take proactive action.
- Their memory lives in the graph, not in a private chat. Multiple humans can work with the same agent, on the same context, at near real-time.
Org design: PLG, FDEs, and AI agents inside the product org
Bose has made structural moves that are unusual for a public SaaS CPO. Both the PLG business and the Forward Deployed Engineers now report into product, each under a General Manager who owns a revenue number and reports up to him.
PLG as an acquisition funnel — but not for SMBs under 10
PLG (pricing, packaging, experimentation, product-led acquisition) was moved fully into product. The reasoning: Fortune 500 accounts almost always start as a 5–10 person team signing up. PLG is the enterprise acquisition funnel.
But there’s a deliberate floor: teams smaller than ~10 can now hack around Asana with Claude Code + spreadsheets + Slack. Asana’s PLG is targeted at 50-person teams up to Fortune 500.
FDEs inside product, not sales
For newer AI-agent products, Asana staffs AI specialists as forward-deployed engineers, sitting inside the product org, reporting to the Asana AI GM. They don’t just deploy the first customers — every learning gets fed directly back into engineering, and they sit side-by-side with PMs helping close deals and driving product-market fit. Faster than a separate revenue-org FDE team that would talk to product monthly.
What Asana wires through its own graph
They eat their own dog food, and the loop matters:
- Meeting recordings (Chorus, Granola) flow into Asana as transcripts.
- A stand-up about a PRD has the PRD linked, the call notes linked, and a spec-writer agent that can revise the PRD from those inputs.
- A launch-planning agent breaks the PRD into tasks.
- A coding agent picks up the tasks via MCP and drafts PRs for engineer review.
- Voice-of-customer requests hit Asana from Slack or as tasks — an AI agent prioritises based on prior feedback, assigns to a PM, and can trigger the coding agent once the PM approves.
Bose extends this thinking beyond product: same shape applies to marketing operations, campaign launches, executive briefings, escalations. Once the graph is current, agents move any structured process forward faster.
What we take away for VeehiveLabs
This is the piece we’re writing as an operating principle, not a summary. Five things we’re internalising:
When we build for a client, the durable moat is not the LLM choice or the prompt. It’s the structured shared context we help them create — the graph that captures who does what, by when, and why. Every AI system we ship should be aggressively closing the loop back into that graph so it compounds.
“It gets to zero productivity when the corrections don’t compound.” Any system we ship where a user says yes / no / edit and that decision doesn’t automatically update a shared state — we’ve built a chatbot, not an AI system. Design for the write-back before designing the model call.
For every client we serve, we should ask: is this a headless flow (meet them where they already work — email, chat, browser) or a multiplayer flow (agents as teammates inside a shared workspace)? These require different integrations, different UX, different governance. Not choosing one on purpose is how projects get muddled.
Our own model of pairing AI specialists directly with clients during discovery and build — and feeding those learnings back into how we architect future engagements — is consistent with what Asana is doing at scale. Keep FDE-style talent close to the product and the client, not siloed.
We don’t need a client’s entire domain modeled before AI can help. Start with a shallow graph, close the correction loop, and let the graph deepen with usage. Waiting for “perfect data” is how AI projects die.
Open questions we’re holding
- How rich does a work graph need to be before agents can be reliably proactive without hallucinating context? Bose doesn’t answer this directly. Our client work suggests surprisingly shallow, provided the correction loop is tight.
- Multi-tenant vs single-tenant graphs: when an agent works across many humans, whose corrections carry more weight? RBAC handles who sees data, but not whose correction should train the shared model.
- The BYO-agent story is compelling but under-specified. Interop protocols aren’t settled yet. MCP is a start; it’s not enough.
Source: The Product Podcast — Arnab Bose, CPO Asana, in conversation with Carlos González de Villaumbrosia, Product School. Notes compiled by the VeehiveLabs team. If you spot a misinterpretation, tell us — the whole point of a knowledge base is that it can be corrected.