Notes from Software Product Management at ISB, and the one idea that tied them together.
Near the end of our Software Product Management course, our professor asked the class to vote: is product management a shrinking profession? Eight or nine hands said yes. Ten to fifteen said it has a long shelf life.
Then he told us why he sits in the second camp, and it has stuck with me for weeks. When building gets cheap, everything around building gets expensive: deciding what to build, specifying it, checking it, convincing people, and getting it in front of customers.
That sentence is the spine of this post. Most product management takes right now come with a prediction: PM is dead, building is easy, deciding is hard, plus ten more. I want to sort them through one idea and one person who has watched several product cycles up close, Prof. Chandrashekhar Vattikuti, who co-taught the course and whom everyone calls Chandra.
It is a long one. Most of it comes from our class recordings and my office hours with him, plus his public interviews and this year's Lenny and Friends Summit talks.
Who was teaching us
Chandrashekhar Vattikuti co-taught the course this term across the Mohali and Hyderabad campuses. He is an ISB alum who spent most of his career in internet products: Yahoo, Microsoft, the property portal CommonFloor, and then InMobi, where he became Chief Product Officer and later ran its Telco Cloud business. Today he is building Gruha.ai, an AI-first take on how Indians buy homes, and he used it in class as a live case.
He also turns up in places that turned out to be useful homework. In October 2024 he was a guest on The Ken's Two by Two podcast, in an episode titled "Do we even need product managers?", opposite Paytm's product chief. Last year The Ken had him back to look at the free AI subscription bundles from OpenAI, Google and Perplexity with Indian telcos, and they re-ran that episode in August because Perplexity's free year with Airtel had started to expire. His job in that conversation was to sanity check whether those user numbers would stay once the free period ended.
That last point connects to something he said in class. He credited cheap, subsidised data for rescuing a generation of Indian consumer apps whose retention curves would otherwise never have paid back. Hold on to that, because it shows up again when he talks about what AI products will cost to run.
The funnel is moving inside the conversation
Funnels, activation and cohorts were the metrics block of the course, and Chandra's version came with warnings the usual textbook leaves out.
The first is that a funnel tells you where to start digging and never what you will find. At Visit I broke the pre-policy medical exam funnel into four drop-off points and built a fix for each, so this one landed. His rule for the digging: check that the instrumentation did not break, then segment, then find the smallest group with the worst retention and call them.
The second is about activation. Onboarding is the account, the login and the bank details. Activation is the first moment of real value, like the first cab showing up without a phone call. When marketing is paid per activation the definition gets gamed, so product has to define it from retention. His illustration was a payments app handing out ₹100 on sign up, where "sent more than ₹100 within 72 hours" became the activation event because that cohort retained at 42%, far better than people who only came for the cash.
Now the AI part, which came in the last session. Most software, he said, is an edifice: filters on the left, categories on top, and the user bends to the builder's mental model. For a lot of people that is already gone. It is a box and you type what you want. If a product is built agent-first, that box is the UI and there is no edifice. He explained why the big marketplaces are slow to get there. Someone sitting on 360 billion in GMV (his number, from memory) will not casually test a bot that might stretch search to purchase from three days to five. The upstarts have no funnel to protect.
If the edifice goes, the funnel does not disappear. My read is that it moves inside the conversation. Search, filter, view and add to cart collapse into one request, and the signals shift to task success, whether the user kept rephrasing, whether they asked for a human, and whether they gave up and retried. Those were the signals he listed for AI products, along with thumbs up or down and how far a prompt gets edited. Activation for a chat product then becomes the first answer that actually solved the problem.
The interface itself is also changing shape. He thinks the compute will always sit behind a piece of glass or plastic, whether that is a phone, a pair of spectacles or a pendant. He thinks the real prize is the next 800 million Indian users, who today are asked to learn English to use a product and who will arrive through voice in their own language. His own startup is voice-first, with a small set of grounded question families so the user always knows where the conversation is going, and the ability to start a call, hang up and come back. This further resonated in the recent Lenny and Friends Summit, wherein folks leaned on voice as the next big thing in 2027, and in big tech's product roadmaps.
Cohorts got the sharpest line. Users who tried you once, he said, take you to bankruptcy. His examples were AI toys: sunglasses on your cat's photo, virtual try-ons, the party trick that is over after one use. The same test applies to the free AI subscriptions bundled with Indian telcos that I mentioned earlier. The number that matters is the cohort curve after the free period ends. One caution from him: cohorts only work above some scale. A 2 to 3 percent move on ten million users is 100,000 people. On 5,000 users it is noise.
Prioritisation loses its denominator and keeps its politics
RICE is in every PM course, so I will skip the formula. What Chandra added was where it breaks.
Effort is estimated by whoever wants the feature, so two weeks quietly becomes eight. Reach gets nudged from 18,000 to 26,000 because nobody has the patience to disprove it. A flat 75% does not sound credible, so people write 75.85%. And confidence, in his words, is where politics hides. Any organisation where access to resources depends on something will be political, he said, which makes all of them political.
I heard the same warning from the other side at the Lenny and Friends Summit. Marty Cagan listed being naive about politics among his ten regrets. He says good product work does not win by default, and incentives and influence decide a lot of what happens.
AI changes one part of this, the denominator. Effort used to ration engineering time. Claire Vo's argument is that roadmaps were built for scarce engineering, and once far more ideas are buildable, buildability stops being a useful filter. Take effort out and what is left is reach, impact and confidence, which is judgment and politics in a table.
Chandra also added the human side to this conversation. When anyone can prototype, everyone in the room believes they can choose better than the PM: the head of engineering, the head of ops, the neighbouring PM. And the most dangerous person in that room, he warned, understands cognitive biases and uses them on you. Spot a recency bias, drop a few nuggets days before the meeting, reinforce them in the room, and you are aligned before anyone argues. His advice was to be wary of those people and to build your own defences by being self-aware or maybe use these to your advantage, depends on the situation you're in I guess :D
The skill that comes out of this is saying no to something that is cheap to build and defending the no in a room full of prototypes. Lenny put the day's lesson in one line: it has never been easier to build something nobody wants.
Specs are written for agents now
Specs used to be written for human consumption. The good PMs wrote them carefully, kicked off the meeting and walked everyone through. At Amazon, Chandra pointed out, people read together in silence for the first fifteen minutes. The point of a spec was to get a room of people to understand the same thing.
That is changing, and he put it bluntly. Everyone is throwing AI slop grenades at each other. Hand ChatGPT a template, get a seven-page document, forward it. The engineer pastes it into his own ChatGPT, the designer pastes it into a Figma generator, and the old question of whether you are persuading a person or feeding that person's agent is up in the air. The cost of this, as Chandra described it, is that the person who generates the material skips the thinking, and the reviewer pays for it.
So write a good spec and hope a person reads it, while accepting that more and more specs are written so an agent can do its job. An agent punishes vagueness faster than a colleague does, which makes being articulate a PM skill with a price tag.
Two of his examples show what articulate looks like. "Checkout should be fast and reliable" is a real line he has seen, and people have survived on lines like it. The version that works says the 95th percentile transaction should finish in under four seconds on a 4G connection, because then you know what good and bad look like. The other was "fix the checkout", also real. A PM wrote it and left for a wedding. By the end of the week design had spent two full days in workshops redesigning the flow and borrowing from Stripe, because nobody had said which class of problem needed solving.
Before any of that, he wants us to write a pre-mortem of what we're building. Before you launch anything, write down the ways it might fail, then go and reduce those chances. It belongs in a good spec next to the problem, the persona, the goals and the non-goals, and an agent can use it as a checklist as readily as a person can.
Then came the sentence. Whether you like it or not, he said, and he is not comfortable with it himself, a lot of our competency will boil down to the ability to articulate instructions, guardrails and evaluation criteria for AI agents to do their job. He called that the new definition of work and told the room to get comfortable being well-paid AI agent orchestrators.
The eval is the spec
The last session took that idea into AI products. His framing was that you are not shipping a behaviour, you are shipping a distribution of behaviours. Same prompt, three runs, three different answers. A normal product has a checklist and a list of severity-one bugs. An AI product has a spread, and someone has to draw a line and say that everything to the right of it is good enough to ship.
Hence the sentence he asked us to take away:
If you cannot write the eval, you have not specified the requirement.
What I liked is how unglamorous an eval is. You pull a few hundred, or if you are patient a couple of thousand, real user messages. You read each response and mark it yes or no on whether it solved the problem, because he said most teams have moved from 1 to 5 scales to simple yes or no. You set a launch threshold and run it again after every change. People at the big AI labs, he said, sit on anonymised traces doing exactly this, and many of them are junior.
His credit card example makes it concrete. One user asks for last month's bill and the bot answers, so that is a yes. Another asks whether the purchase she made thirty minutes ago has been charged. The bot is not grounded in recent transactions, so it makes something up, and that is a no. Do that across enough messages and you have a distribution. To do it at scale you let an LLM act as judge, which he compared to a nightly regression, and you keep humans in the loop for every major and minor release.
Two more stories from that session. In the first, one model gets 94 of 100 answers right but commits one stark false positive, calling a tumour that is not there. Another gets 92 right and never makes that mistake. You ship the second one every time, and the eval is how you write that choice down. In the second, you swap in a newer model that wins on every benchmark, and escalations to a human go from 18% to 42%. He gave that one as a hypothetical, but said it is entirely possible, because model changes shift the tone and tone decides whether a user feels helped.
He also reminded us about cost. For years the marginal cost of one more user was zero. Add a copilot and every user burns tokens. All of us, he said, are living on subsidised tokens, and at some point you realise two hundred ops people might have been cheaper. So you cache, route simple questions to smaller or open-source models, and land on his line for that section: the model is a component, and the product is everything around it.
Research is being automated from both ends
One of Chandra's demos was a persona document. He and his co-founder asked an LLM for about forty fictional home buyers with detailed journeys, including an NRI buying over a video call and a family expecting a child, and held their product up against them. He was clear that this is no substitute for the thirty or forty real customers they had actually spoken to. The synthetic set gave them breadth and speed. He also described voice bots, grounded well, that can run hundreds of customer surveys and turn the audio into insights, without the biases a human interviewer brings.
There is now an industry built on that idea. Simile, a Stanford spinout that builds AI digital twins of real people to predict how customers will behave, came out of stealth in February with a $100 million round and closed a $200 million Series B at a $2 billion valuation in July. Aaru, which simulates whole synthetic populations, has been reported at a $1 billion valuation. Others, like Listen Labs and Outset, use voice AI to interview real people at scale. TechCrunch reported in September that Listen Labs had signed a term sheet at a $1.5 billion valuation and then walked away to talk to Salesforce. The category is splitting into tools that simulate people and tools that interview them faster.
The other end of the pipe worries me more. Sean Westwood, a political scientist at Dartmouth, published a paper in PNAS describing an autonomous synthetic respondent that got past the standard bot checks in online surveys 99.8 percent of the time across more than 43,000 tests. He estimated that between 10 and 52 fake respondents could have flipped which candidate led in the major polls he examined. "We can no longer trust that survey responses are coming from real people," he said.
Put the two together and the research stack looks strange. Synthetic users can answer your questions, bots can answer your surveys, and an LLM can summarise both for your leadership. At that point nobody has spoken to a customer. Claire Vo's list of what becomes scarce starts with customer truth. Chandra's rule for funnels says the same thing: the numbers point, and then you go and talk to the smallest group where retention is worst.
My rule from this fits on a wall. Use synthetic users for breadth, to pressure-test your questions and screen a lot of ideas cheaply. Use real conversations for truth. And count how many real customers you spoke to this week, because that is the number a bot cannot inflate.
Building got cheap, so everything around it got expensive
In the last session he listed what got cheaper: documents, mockups, clickable prototypes, first drafts, summaries, meeting notes. He described people summarising a Granola summary against a Teams summary and running a meta-summary on top, with an agent turning all of it into a weekly update for the CPO. At Bing, he said, a 300-slide customer research deck once took an 80-person team a year, and something similar can now be produced for around a hundred dollars of tokens. You cannot tell which one is real.
A thorough document or a working prototype is therefore minimum hygiene, in his words not even a differentiator. When everyone is a kid in a candy store, the scarce skill is choosing which of the hundred things to build, and then landing that choice in a company where the VP of engineering, the head of ops and the neighbouring PM all think they could choose better. His rule for individual work was three hours thinking for every hour building. Convincing people and getting legal to bless your terms take as long as they ever did.
Three things became more valuable. Taste, which is picking the better of three mockups that were all easy to generate. Review, which is the last 20 to 30 percent between an AI draft and something usable. He told us about a batchmate who spent five times the effort making an AI-built interface stop looking AI-built. That, he said, is the extra mile. And ownership, because you cannot hold a model accountable. You still need what he called a throat to squeeze, and more often than not the person who sticks their neck out is the PM.
The Summit gave me a practice for the taste part. Linear runs an optional weekly feature roast where anyone can critique a new feature, nitpicks included, without it getting personal. A lead turns the raw feedback into issues, and the logic is that if people inside the company are confused, customers probably will be too. Karri Saarinen's argument was that automating execution can strip out the learning that used to come from struggling with the work, so teams need rituals that keep judgment shared. Linear's Quality Wednesday, where everyone fixes and shares one small defect a week, does the same job. Katie Dill of Stripe made a related point: built, done and good are three different states, and someone should be the named editor who decides which one a release is in.
Chandra was candid about the cost for people early in their careers. The entry rung is the risk, not the ladder. His own first year and a half at Yahoo was mundane work, pulling his own numbers, reading support tickets, grooming a backlog, work where you could make cheap mistakes. Now it is an MCP connection away. The judgment bar he once held for a senior PM he now holds for a PM. The way is harder, he said, and the door is still open.
He asked us to build our own conviction, since he has no skin in our decision. He also pointed to a data point from the day before, that only about 2.5% of households pay for AI, as a reminder that diffusion takes a long time. For his part he is slightly bullish. If writing code stops being the bottleneck, he argued, a PM who can straddle English, code and design sits in a very useful spot.
Build fast, shut faster
If building is cheap, so is being wrong, and the founders I have been reading and watching treat a product as an experiment with an expiry date.
Claire Vo made the case at the Summit. Her idea is durable convictions with disposable implementations: stay with an important problem, change the solution freely, and watch for the bad kind of stubbornness, which is moving the success criteria to justify more building. She asks teams to label every release a probe, an experiment or a promise, so customers know which one they are getting. Dan Shipper described a one or two person lab at Every that expects to discard roughly nine in ten of its experiments, with a path from lab to internal use to early customers to the product team. The Anthropic panel added a neat trick: when a project fails because the model is not ready yet, park it as an eval and rerun it when the next model arrives, since the failure may say more about the model than about the customer problem.
Chandra lives this way himself. He was candid that he is building with the next year or two in mind, and that he knows the solution may not be viable until then. If it does not work, he said, he may close it and move on to the next opportunity.
The constraint, then, is not the cost of building. It is the discipline of deciding in advance what would make you stop, and then actually stopping.
Gruha.ai up close
What makes Chandra's views credible is that he is running the experiment himself. In an earlier class he opened his Google Drive and walked us through Gruha.ai, the startup he is building.
The hypothesis goes like this. In the US a buyer's agent and a seller's agent each take a commission and sit behind a wall, so the buyer's agent only works for the buyer. Indian real estate has no such split. His bet is AI agents on the buy side and human agents on the sell side. Price negotiation and what someone plans to build next door cannot be turned into a model prompt. Plot size, orientation and how much traffic a road gets can, and he thinks a well-trained buy-side agent can get to roughly the quality of the best one you could find in the country.
The part I appreciated most was how honest he was about maturity. He set the company up to be agent-first, where the humans curate context and the agents run marketing, reports and the rest. On a scale of zero to ten, he put them at 1.5 or 2. Without AI, he guessed, they would have been a 70 or 80 person shop. In a post-AI version it might be 15 humans and 25 or 30 specialised agents. His own days, he said, are now spent cleaning folders and writing crisp markdown files so the model knows what to remember and what to forget, and he calls that a new definition of work.
Where it has worked is product discovery. From hypothesis to a design took three weeks, and he said it would have taken six months before. He also noted that code writing, which used to be about 60 percent of the time on a project, has shrunk to 20 or 25 percent. He added the caveat that you could be building in a vacuum, which is why the forty fictional personas sit next to thirty or forty real conversations.
Two warnings from him that I have in my own notes now. Hallucination is the smaller problem, he said, and sycophancy is the bigger one. You say something strongly and the model tells you it is a great point, so you have to know whether it is acting as your mirror or pushing you out of your comfort zone. The second is about the name. They went with .ai partly because they could not get the .com and it felt odd to be a post-AI startup without it, and he used that story to warn us about adding AI to a product because it helps a career or a valuation. Ask what the user is trying to solve first, he said, and if AI fits, go ahead.
In office hours the same instinct showed up in a smaller way. As I understood it, he is wary of forcing buyers into a new behaviour. If someone is comfortable with the familiar way of looking at a plot, make that better, for example by generating renders from open map data so they can picture a house, and leave the new paradigm for later.
My read, as someone who has not built in this space, is that the model may be the easiest part of Gruha. The hard parts sit around it: who pays, who carries the liability, and who a buyer trusts with a token advance. That is his own line, the model is a component and the product is everything around it, applied to his own company.
One more line from the same class stays with me. Most of a PM's day, he said, is rituals: the Monday meeting, the Wednesday metrics review, the stakeholder updates. The valuable work sits on top of that. You do not rise to the height of your ambitions, he said, you rise to the height of your rituals.
Where this leaves me
So, is product management shrinking? The version of the job that is mostly artifacts is, and quickly. Specs, decks, summaries, prototypes and survey reports are cheap now. The version that is mostly judgment is growing. Someone has to choose the problem, say precisely what good looks like, check it against real customers, and stand behind the result.
That is my working definition of a PM now: the person who owns the decision about what is worth building, and the proof that it worked. The eval is the proof. The pre-mortem is the doubt you write down first. The customer calls are the part a bot cannot fake. And shutting a product down when the evidence says so is part of the job.
I am holding myself to a short list:
- Write the pre-mortem before the spec and the eval before the feature.
- Talk to real customers every week.
- Keep a notebook of when AI output was wrong and why.
- Decide in advance what would make you stop.
- Build a portfolio where every line survives three follow-up questions.
The Summit speakers disagreed on almost everything else: whether PMs should code, whether roadmaps survive, whether the role grows into general management. I find that reassuring. If the vote were today, I would raise my hand with the second group, on one condition: that the job is the judgment half.