Anand Bhaskaran

Your story: how did you end up in product?

I came in through research. At EPFL, I evolved robot bodies and brains with genetic algorithms, and the rule there is simple: explore deeply, build until it is complete, publish, spin off. We did exactly that with Dronistics, a drone-delivery spin-off where I was the founding engineer. Five years later we had a patent, a resilient software stack and 500 real deliveries. We also had almost no paying customers. That was the trigger. I had built an exceptional thing, and nobody was pulling it. I took a side role as Technical Product Manager at Obermatt, did an MBA at night, and at Beekeeper ended up owning products, not just code: a templating engine that now produces 15% of everything created on the platform, and an employee referral product that became the top acquisition channel. Today I build production AI agents for sales teams at Lumapps. I still write the code. I just refuse to start without a number and a customer on the other end.

How do you define product success?

Adoption that holds without me pushing, tied to a number the business already tracks. Early in my career I thought success was the thing working. Now I think an exceptional feature without adoption is a mediocre product. The signal I trust most is unprompted repeat use: people coming back on a Friday afternoon when nobody is watching, and then a business metric moving behind it. For the outbound agents at Lumapps that was reps opening the brief on their own accounts, then meetings booked doubling and sales-approved meetings per month rising 71%. Launch day, demo applause and NPS surveys tell me very little. A usage curve that climbs after the announcement fades tells me almost everything.

What's your decision-making philosophy?

Building a great product is 80% understanding and 20% execution, so most of my decision work happens before anyone writes code. Three habits. First, I write the assumption down early: "I am going to do X unless someone says otherwise by Friday." Silent misalignment is cheap in async teams, and a written sentence forces disagreement to surface. Second, I ask the person who does the work, not the person who approves it. Managers approve, individual contributors adopt. A rep on their 30th account of the day knows things no spec captures. Third, I decide at 60% information and ship something small enough to be wrong cheaply. Past 60%, more analysis costs more than a bad week in production. If I cannot name the number a decision should move, I am not ready to decide.

What's your biggest PM lesson or mistake?

Dronistics. I came from research, where the loop is explore, build until complete, publish, spin off. We ran that loop for five years and it worked: a patented drone delivery system, software resilient enough for enterprise partners, 500 real deliveries. My co-founder and I were obsessed with product design, so eventually we got a paying customer. Then regulation kicked in. The regulator wanted the probability of a car accident caused by a driver distracted by a drone overhead. Lawyers sent invoices we could not afford. Investor interest faded because the next paying customer took months. It ended as a great research project. The lesson: we were deeply curious about the solution and barely curious about adoption. Who engages, which use case pays, what blocks the second customer. Those questions could have turned the story around, and we never asked them with the same intensity. Every product since, I spend the first weeks on adoption and use cases before I touch the architecture. Exceptional feature, no adoption, mediocre product.

How do you manage stakeholders?

A line I keep coming back to: if people are not informed, they start to imagine. So I over-communicate in writing. Every meeting gets a goal up front, active notes, and takeaways plus next steps posted in the chat before people leave the call. That habit alone made me the go-to person on a topic at Beekeeper within weeks. When people disagree, I assume their picture of past events differs from mine, and I fix that with communication before arguing the decision. Hard on the problem, soft on the people. In a room with senior stakeholders, I go with the flow and pull the thread toward where I want to land, instead of fighting the current.

How do you prioritize?

Deprioritising, saying no and cutting down are the most under-used strategies in product, so my framework is mostly about what not to do. I use Elon Musk's five-step order: question the requirement, delete the part, simplify, speed up, then automate. The order matters. Most teams skip to automating something that should have been deleted. Two filters on top. Does this tie to the broader vision we wrote down? If I cannot draw the line, it waits. And what number does it move, who owns that number? No owner, no build. Then I do one thing at a time. The periods where I shipped the most were the ones with a single focus area. When I was spread across six projects this year, all six slowed down. The main thing is to keep the main thing the main thing.

How do you do customer discovery and validation?

I sit next to the person who does the work while they do it on real data. Not a demo, not a survey, not a workshop. For the outbound research agent, one session watching a rep on their own pipeline changed the whole output format: a brief under 80 words, inside Outreach, where they already were. No manager could have told me that. I trust what I learned when behaviour changes, not when people say nice things. Reps stopped asking "is this accurate?" and started asking "which of these do I use?" That shift is the validation. Then I ship with instrumentation so I know within a week whether the number moved. I learned this the expensive way at Dronistics, where we validated the technology for years and the customer for months.

What's your favorite product you've shipped?

The outbound research agent at Lumapps, and the AI brain growing underneath it. Reps spent 30 minutes per account tab-switching across LinkedIn, Salesforce, news and Outreach before writing a word. The agent now hands them a brief in under 80 words, every claim with an inline source link, inside the tool they already use. What made it work was not the model. It was the trust loop: links the rep can check in one click, approval before anything sends, evals and reporting every week. Meetings booked doubled, sales-approved meetings per month went up 71%, and the chance of an opportunity reaching the next stage rose 113%. The brain is the second half: a temporal knowledge graph that pulls CRM, product usage and call transcripts into one memory every agent reads and writes. The agent was the easy part. The context is the moat.

What product inspires you?

Four, each for one thing it gets right.
Obsidian: plain Markdown files on my disk, no lock-in, a plugin ecosystem that lets the product become whatever I need. My second brain lives there and it has compounded for years.

Miro: the only tool that gets a cross-functional room thinking together instead of presenting at each other.

Revolut: I live between two countries and two financial systems, and it removed friction nobody else bothered to remove.

Quantic: an MBA on a phone, built around active learning, and it taught me more than I expected.
The common thread is that each one found a single thing people actually struggle with and refused to be a feature list.

How is AI changing product management?

The 20% got cheap and the 80% got more valuable. Execution used to be the bottleneck, so product managers wrote specs and waited. Now I can prototype in an afternoon with Claude Code, so the expensive part is knowing what to build, who will adopt it, and which number it should move. Understanding was always most of the job. AI just made that obvious. In my day-to-day, the PM and engineer roles have merged. I read the code, I sit with the user, I own the outcome. What has not changed: adoption is still earned one user at a time, trust is still built with a loop and not a prompt, and saying no is still the highest-leverage move. AI also raised the bar on discipline. When shipping is cheap, the temptation is to ship everything. That is how you end up with a hundred mediocre features.

Which AI product do you use and respect?

Anthropic, mainly through Claude Code. I run my notes, my daily automations, and parts of my work stack on it. What earns respect is that it treats the model as one part of a system, not the product. It is a harness: tools, files, a loop, with the model inside. That is the same conclusion I reached building agents for sales teams. The model is the easy part. They also publish what they are doing, open standards like MCP, and the product gets better in ways that compound for the person using it rather than in ways that look good in a demo.

What's one thing about AI everyone gets wrong?

A better model will fix it. Most AI projects that stall are not short on intelligence. They are short on context and trust. The model does not know your customer history, what was promised on the last call, or which fact changed yesterday. And the user does not trust it because there is no way to check its work. When I built outbound agents, the design decisions that mattered were inline source links, approval before sending, and weekly evals. Zero of them touched the model. Think of the model as the CPU. What most companies are missing is the disk: a persistent, queryable memory of their own business. The model layer commoditises. The brain layer compounds.

What's your unpopular product opinion?

The PM and engineer split is a bug. A product manager should be able to read the code and approve a PR. An engineer should own the outcome, not an SLA. When one person, or one tightly fused team, holds both the customer understanding and the ability to build, the product gets a point of view. When the roles are split, you get a spec on one side, a ticket on the other, and nobody who feels the whole thing. AI makes this worse for the split model and better for the fused one, because execution is no longer scarce. Most product people push back on this because it sounds like "learn to code". It is closer to "learn to own".

Which author, thinker, or influence shapes you?

Two ideas rather than one person. Focused Curiosity, from Greg McKeown's Essentialism and Gary Keller's The ONE Thing, filtered through a coaching program at Beekeeper. Curiosity without a chosen arena scatters. Focus without curiosity stagnates. The phases where I had real impact were the ones where I narrowed the arena first and was relentlessly curious inside it. And Quiet Compounding, from Morgan Housel. Do not compare, pick a long horizon, let small things stack. It explains how I invest, how I keep a second brain, and how I think about products: the ones that win get a little better with every use and every piece of data, for years.

What makes a great product?

It compounds. Three tests. People come back without being reminded. It lives inside the flow of work instead of asking for a new tab. And it gets better with use, because every interaction leaves data or context behind. A product that passes the first test is good. One that passes all three keeps growing after the launch team moves on. There is a fourth, negative test: an exceptional feature with no adoption is a mediocre product. Craft past the adoption threshold is vanity.

What does your product solve?

The GTM AI Brain at Lumapps. It is for the sales, account management and customer success people at a B2B software company. Everyone needs the full picture of a customer. Everyone holds a recent, partial slice in their own head. The rest is scattered across the CRM, marketing tools, product analytics and call transcripts, and nobody can see all of it at once. The brain is one time-aware memory that pulls those sources together, knows when a fact changed, and lets every AI agent read from it and write back to it. It started as the layer under our outbound agents, so a researcher agent and a sequence agent work from the same fresh view of the account. I write about the build at anand-creations.com/projects/gtm-ai-brain.

What's the biggest misconception about it?

That it is a chatbot over documents, or "just RAG". Chunking documents into a vector store loses the thing that matters: how facts relate and when they changed. A deal moved stage last week. A champion left the company. A promise was made on a call. A temporal knowledge graph keeps that structure, so an agent can answer "what changed at this account since the last touch". The second misconception is that the hard part is the model. The hard parts are the ontology, the ingest contracts and the freshness policy. That is where most brains die.

What's the market opportunity?

MIT's 2025 study found about 95% of generative AI pilots produced no measurable P&L return, mostly because they never got wired into real workflows. The models are good enough. Context is the bottleneck. Every company already has years of customer conversations, won and lost deals, tickets and decisions. Almost none can reason over it. Over the next couple of years I expect every serious company to build or buy a brain layer: a single, evolving, queryable model of its own business that every agent plugs into. Why now: agent frameworks matured, graph plus temporal memory tools went open source, and the budget that went to pilots is looking for something that compounds.

Why would you recommend it to a peer?

Honest answer: it is an internal system at Lumapps, so there is nothing to buy. What I recommend is the pattern. If you lead GTM, RevOps or product at a company with a fragmented stack and a procurement queue full of AI vendors, ask one question before the next purchase: whose brain is this feeding, and do we own it? Start with one agent that moves one number, give it a shared memory it writes back to, and let the next agent inherit that memory. I wrote up the tool choices on my blog, and I am happy to swap notes with anyone building the same thing. I mapped the 14 memory and retrieval tools I evaluated, and what I would pick for each situation, on my blog: anand-creations.com/blog/your-ai-needs-a-brain. If you are building the same thing, I am happy to swap notes.

What would you tell a PM just starting out?

Spend 80% of your time understanding and 20% executing, and defend that ratio when the calendar fights you. Pick the number before the feature. Sit next to the person who does the work while they do it. Learn to read code, so you can see what you are approving. Say no more than feels polite. And pick one arena and be relentlessly curious inside it. Curiosity everywhere is the same as focus nowhere. Small things done well stack up over years, and nobody notices until suddenly they do.

You are an engineer. Why answer a product questionnaire?

Because I think the split is the problem. The products I am proudest of happened when I held the customer understanding and the keyboard at the same time. Templating engine, referral product, outbound agents, GTM Brain: in each case, I was the product owner and the person shipping it. I do not think every engineer should become a PM. I think every product team should have people who can do both, and most do not.

What does Focused Curiosity look like on a normal Tuesday?

One focus area on the calendar, and a lot of questions inside it. This year that meant going back to our own SDRs, AEs and CSMs, from ICs to leadership, and asking what they actually need to see about a customer. Every conversation landed on the same three facts, and that became the design of the AI brain. The curiosity is open. The arena is narrow. The moment I had six projects, all six slowed down.

What does compounding mean for a product?

A product compounds when each use makes the next use better. Obsidian does it with links. A CRM does it. An AI brain does it when every agent writes back what it learned. If I had to bet on one property that separates products that last from products that launch, it is that one.