Blog

Thinking out loud.

Weekly essays on building products that matter. Strategy, process, frameworks, and hard-won lessons.

NewMay 22, 2026

AI didn’t blur product roles. It exposed what was already broken.

I have been reading the same article for six months. Different titles, different authors. But the argument is identical. AI is dissolving the boundaries between PMs, designers, engineers, and strategists. The future belongs to hybrid people: T-shaped, fluent across domains, comfortable in every part of the stack. The advice is not wrong, exactly. It is just answering a question that nobody asked correctly. The hybrid framing assumes there was a clean specialist model before all this. There wasn’t. The roles that are supposedly collapsing now were never quite as clear as we acted like they were. PMs were supposed to own strategy, but in every team I have ever worked on, the actual strategic calls got made by whoever had the loudest opinion that month, sometimes in the meeting, sometimes on Slack at 11pm. Designers were supposed to own user understanding. But in practice, none of us really owned it. We had partial views and compared notes when we remembered to. Mostly we hoped the others were doing more research than we were. Here is a test. Pick any product team you have ever been on. Ask: who would have lost their job if the wrong thing got built? Not who ran the meeting. Not who wrote the PRD. Who was actually on the hook. For most teams, the honest answer is nobody. Or everyone, which is the same thing. At a SaaS company I worked for a few years ago, we built a feature that nobody had asked for and everybody had agreed to. The kickoff was good. Reviews stayed clean and engineering hit the date. Three months after launch, the metrics had not moved. The post-mortem was the first quiet meeting we had had in a while. The PM said he had assumed the designer was leading user research. The designer said she had assumed the PM was. I had assumed both of them had been talking to customers all quarter. None of us had been. We had spent four months building something based on an internal hypothesis that had never been tested with anyone outside the building. Nobody got fired. We took the lesson, said the right things, and moved on. But the meeting stayed with me longer than the launch did. What we had run into was not a process failure. The process had worked. The thing that had failed was further upstream. None of us, including me, had owned the question of whether the feature was worth building in the first place. This was years before the current AI conversation. The misalignment was already there. But we had enough specialists in the room that you could not see it unless you looked hard. What changed in 2026 is not that the specialists merged. It is that the work each specialist used to do became cheap. A PM with the right tools can build a working prototype over a weekend. A designer with the right tools can write a strategy doc that holds up in front of a leadership team. An engineering lead can run user interviews and have the conversation summarised before lunch. The execution work that used to fill a sprint now fills a Wednesday afternoon. But all three of those people are still sitting in a room having to decide whether the thing they are about to make cheaply is the thing worth making. That part has not gotten any easier. It might have gotten harder. The tools made the execution portable. But they did not make the judgment portable. And judgment is the part that was never really owned by any of the roles to begin with. This is why “hybrid skills” feels wrong as the answer. Hybrid skills are about distributing more execution work across fewer people. But the execution work is already cheap. The hard work, which has gone untouched, is deciding what to point the cheap execution at. What is left when the rest compresses is taste. Taste is an old, slightly embarrassing word for the thing that was always actually doing the work. Not a list of features ranked on a roadmap. Closer to the small uncomfortable instinct that one of the five proposed features matters and the other four don’t, even when you cannot fully articulate why. The same instinct that wakes you up at 11pm on a Sunday with the feeling that the thing your team is excited about will not survive contact with users, and the willingness to say so on Monday morning at the risk of being wrong in front of everyone. Taste does not show up on a JD. It does not show up in a performance review. But it is the only product capability that gets more valuable as the rest of the work gets cheaper. If you are thinking about where to invest your time in this environment, that is the place. Not collecting more skills. Sharpening the judgment behind the skills you already have. Taste is built the same way it always was. You make calls. You watch them play out. Then you sit in the room when the consequences land, six months or two years later, and you are honest with yourself about whether you got it right or got lucky. There is no shortcut to that. But there never was. I have been getting calls wrong in public for twenty years. Some have aged well. Some, looking back, were lucky timing dressed up as judgment. The only thing that has improved is being able to tell the difference faster, the next time around. Roles will keep blurring, team sizes will keep falling, execution will keep getting cheaper. But none of that is the part that decides whether your product matters. The part that decides has finally come out from behind the org chart. Whether that is good news depends on whether you have been doing the work all along.

NewMay 8, 2026

AI compressed the build cycle. Now your team has nowhere to hide.

Every product team I have watched closely in the last eighteen months has gotten faster. About a third of them have gotten better. The other two-thirds have gotten faster at producing the wrong thing, and they are now producing it more frequently than ever. This is not a story about AI. It is a story about what AI revealed. For the last decade, the build cycle was slow enough that teams could maintain comfortable fictions about what they were building. The fictions could be six weeks long. By the time the feature shipped, the original assumption underneath it had aged out, the context had drifted, and nobody on the team had the appetite to ask whether the thing they were about to release still solved the problem they had originally set out to solve. But AI compressed that cycle to two days. And two days is not enough time to maintain a fiction. A SaaS roadmap that worked exactly as planned and still failed I want to tell you about a SaaS company in Bangalore. This was years before any of the AI conversation started, which is the point. The pattern was already there. Speed just made it loud. We had five enterprise clients whose logos went on our homepage. They asked, we shipped. The roadmap was essentially a list of their requests, prioritized by contract value. Story points up. Cycle time down. Every quarter looked excellent. Eighteen months in, three of those five clients churned. But the features were not bad. They worked exactly as specified. The problem was that the underlying job those clients were hiring our product to do had shifted, and we had not noticed because we were so good at executing what they asked for. The PM and I did a post-mortem. We could trace, almost month by month, the moment the misalignment had started. Around month seven, one of the clients had asked for something that did not quite fit our model. We built it anyway. By month fourteen, we were a custom development shop with a SaaS pricing model. None of us had said it out loud. But we all knew. The slow build cycle gave us a place to hide. Every quarter, the question “are we still building the right product?” got buried under the question “did we ship what we committed to?” The second question is easier to answer. So we kept answering it. Speed did not cause this. Speed made it visible. Here is what AI did. It removed the laundering. When a feature took six weeks to ship, the team had time to forget why it was being built in the first place. By the time it was in production, the original premise had aged out. Nobody wanted to relitigate. Process, in this version, is a kind of amnesia. But when a feature takes two days to ship, the premise is still warm. The assumption you made on Monday is sitting in front of you, fully rendered, on Wednesday. You can see whether it survived contact with reality. You either confront the gap, or you ship anyway, and the wrongness compounds at the new speed. This is what I see across teams in 2026. The fast teams are not the winning teams. The winning teams are the ones whose internal honesty caught up with their build velocity. But the losing teams are the ones whose velocity ran ahead of their truthfulness, and who are now producing wrongness at industrial scale. A friend of mine runs design at a Series B startup. She told me her most useful meeting is now a thirty-minute conversation on Friday afternoon where the team looks at what they shipped that week and asks one question. Not “did it ship on time” or “did the metrics move.” The question is: “is this what we said we were building three weeks ago, and if not, when did it stop being that?” She said it took four months for the team to answer the question honestly. The first three months, everyone hedged. The most important person in the kitchen does not cook I keep coming back to a professional kitchen during dinner service. Watch one for ten minutes and you will see something that maps almost perfectly onto a product team in 2026. The line cooks are fast. They have to be. But the speed of the kitchen is not set by the fastest cook. It is set by the slowest correct dish on the table. If the steak is ready and the fish is not, the steak waits. If the steak goes out without the fish, the table eats badly. The expediter, who does not cook, is the most important person in the room. They call the order. They hold the plates. They send food back when it is wrong. But their real job is to ask, before the food goes out, whether this is what the table actually ordered. A kitchen without an expediter does not get faster. It gets messier. The cooks ship dishes at their own pace. The diners do not return. Most product teams in 2026 are kitchens without expediters. They have replaced the expediter with velocity charts and AI agents that can plate faster. But they have not replaced the expediter with anyone willing to hold the pass and ask the question. What the honest teams do differently I do not have a model for you. I have a description of what I see in the teams that have figured this out. They have made the act of looking at the work faster than the act of building it. The premise gets tested against reality on the same timeline as the feature gets shipped. There is no six-week gap where the question can quietly disappear. They have stopped confusing client satisfaction with product correctness. The clients who keep asking for features are not necessarily telling you the truth about what they need. The Bangalore team I was on had five very satisfied clients who were halfway out the door. And they treat the speed as a stress test, not a goal. The build cycle in 2026 is not a competitive advantage. It is the floor. Everyone is fast now. But the advantage is in what the speed reveals, and whether the team is willing to look at it. Holding the pass The product question in 2026 is not whether your team is fast enough or adaptive enough. It is whether your team can survive seeing itself clearly. The Bangalore team I was on lost three clients before we were willing to look. We were not slow. We were not unadaptive. But we were unwilling, for fourteen months, to ask each other a question we already knew the answer to. The expediter, in the end, is the person willing to hold the pass and ask it.

NewMay 1, 2026

The art of persuasive disagreements

After twenty years in my career, I’ve learned that knowing how to disagree is a skill. Not just a skill, but an art. Knowing how to bring up a disagreement, being persuasive about it, holding the room while you make your case, and actually moving the decision is, more than anything, an art. And it’s one of the biggest reasons some careers compound and others don’t. This isn’t only about work, by the way. The same thing plays out at home. With your partner, your parents, the friend who keeps making the wrong call. Most of us never learn how to do this well in any room. We pick up the technical stuff at work. PRDs, sprints, presentations. We pick up the relationship stuff at home through trial and a lot of error. But the actual moment of disagreement, the one where something real is on the line, mostly gets left to instinct. And instinct gives you three default ways to handle it. None of them work very well. I know because I’ve used all three. Then there’s a fourth way, which is the one this piece is about. Being Silent (everyone’s favourite) The first default is silence. You have a take, but you don’t say it. The meeting ends, and later you tell a colleague what you really thought. Maybe you complain about it on Slack. The decision moves on without your input. I did this for years when I was younger. I would sit in a room, watch something I disagreed with, and just not bring it up. Sometimes I told myself I wasn’t sure enough. Sometimes I told myself it wasn’t my place. Mostly I just didn’t want the friction. And here is the part nobody warns you about: you don’t grow out of this. Senior people still do it. They just hide it better. The same thing happens at home. Your partner suggests something, you have a real concern, and you go “yeah, sounds good.” A week later you’re annoyed about it, and the annoyance has nothing to do with the actual decision anymore. It’s about the fact that you didn’t speak up. The decision is just where the resentment found a place to land. What does silence cost you? Your sharpest read of the situation. The team hired you because of how you think. Your partner chose you because of how you think. But if that thinking stays in your head, what was the point. The hardest thing about silence is that nobody else knows it’s happening. From the outside, you look like someone who agreed. So the next time something similar comes up, the people in the room, or at the dinner table, assume you’re on board. And the gap between what you actually think and what they think you think gets a little wider every time. Being aggresive and loud The second default is the opposite. You do bring the disagreement into the room, but with too much heat. The argument turns into who’s right instead of what’s right. Even when your point is solid, what people remember later is how you sounded. I’ve done this one too. Mostly in my early thirties, when I confused having strong opinions with being effective. I would walk out of meetings thinking I’d made the case clearly. Then I’d hear, second-hand, that I’d been “a lot” in the meeting. That’s the polite way of saying you’re now the problem. Nobody was talking about my point anymore. They were talking about me. It happens at home too. The argument with your partner where you won the point but lost the evening. The fight with a parent where you were right about the thing, but the rightness didn’t matter because of how you got there. Years later, nobody remembers what the argument was about. They just remember that it was bad. The cost of being loud is bigger than losing one argument. People stop bringing things up around you. They route conversations away from you. Your partner stops mentioning the small stuff because the small stuff sometimes turns into a big thing. Your team starts pre-aligning before meetings so you don’t have surprises in the room. But you don’t even see any of this happening. From your side, you just notice that fewer interesting conversations are coming your way. You assume the room got quieter. The room didn’t. It just got quieter around you. And here’s the part that took me longest to learn. Being loud is rarely about caring more. Most of the time, being loud is about being less comfortable holding a disagreement quietly. The volume is a tell that you haven’t figured out how to make the case without it. You fake it! From the outside, this one looks like you’re handling things well. You raise the concern. Someone acknowledges it. The decision moves on, and to anyone watching, the system worked. I call this concern theatre. At work it sounds like, “I just want to flag a concern about the timeline.” Someone says, “noted, let’s track it.” It goes into a doc somewhere. Then the team ships on the original timeline anyway. You didn’t disagree. You went on the record. Those are not the same thing. There’s a real difference between being heard and being logged. Being heard changes the decision, or at least changes how the room thinks about it afterwards. Being logged just gets your concern written down somewhere, so later, when things go sideways, you can scroll back to the doc, point at it, and feel like you did your part. The home version of this is even more familiar. Your partner asks where you want to go for dinner. You say “I’m fine with whatever,” knowing full well you’re not fine with whatever. They pick a place. You go. You don’t enjoy it. And later, the thing you didn’t say comes out somewhere else. You snap at them about something small. You bring up something from last week. The dinner wasn’t really the issue. The silence was. I’ve done this at work, in both directions. I’ve raised concerns I knew weren’t going anywhere, just so I’d be on record when things broke. And I’ve been the senior person nodding and saying “good point” because I didn’t have the energy to push, or because I’d already decided and just wanted the meeting to end. This is the worst of the three because it can run for years without anyone catching it. From the outside, it looks like a healthy team. Or a healthy relationship. People are talking. Concerns are being raised. Nothing is being suppressed. But nothing is being changed either. And when the concern turns out to be right, you don’t get credit for being right. You just get the receipt. The receipt feels like vindication for about a day. After that, it just feels like you watched the thing happen and chose to be on file instead of in the way. What is the right way? Here’s the part that took me years to figure out. Disagreeing well is not a personality thing. It’s a few habits. I’ll give you four. Say what you’re disagreeing about, before you start arguing. Before you make your case, name the specific thing you’re pushing back on. Something like: “Before I disagree, I want to make sure I’m disagreeing with the right thing. The part I have a problem with is the timeline. Is that the bit we’re deciding right now?” What this does is enormous. It pulls the room’s attention to the exact piece you’re going after, so your case doesn’t get lost in a wider conversation. It tells the people across from you that you’ve thought about this, which softens them. And it forces you to be precise. You can’t hide behind a vague “I have concerns.” You have to commit to a specific thing. Same move works at home. Instead of “we need to talk about the dishes,” try “I want to talk about how chores get split. The dishes are just where I’m noticing it.” Now you’re not arguing about dishes. You’re talking about the actual thing. The reason this habit works is that most disagreements lose energy by being aimed at the wrong target. Naming the target first means everything you say after lands on the thing you actually care about. Make the other person’s point before you make yours. Before you say why you disagree, say why they think what they think. Out loud. In your own words. As well as they could say it themselves, ideally better. Here’s what that sounds like in a meeting. Your PM wants to ship in two weeks and you think it’s a bad idea. Instead of starting with “I don’t think we should ship in two weeks,” you start with: “I get why two weeks makes sense. We’ve already announced the date, the team’s tired of this project, and pushing it back makes us look indecisive in front of leadership. So shipping fast has real upside. But here’s why I’m still nervous about it…” Now you make your case. What this does is change the temperature of the conversation. The person you’re disagreeing with is no longer defending themselves, because you just made their argument for them. Their guard drops. They start listening to your side instead of preparing their next response. And when you do disagree, your case lands harder, because you’ve already shown you understand what you’re pushing back on. Same thing at home. Before saying “I don’t think we should visit your parents this weekend,” try “I know it’s been a while since you’ve seen them, and you’ve been wanting to introduce them to the new place. So this weekend isn’t random. But I’m wiped, and I think I’d be bad company. Can we look at next weekend instead?” Same disagreement. Completely different conversation. This is the move that turns loud people into persuasive people. Loud people argue with the weakest version of the other side, because it’s easier to win against. Persuasive people argue with the strongest version, because that’s the one that actually has to be answered. Sleep on it before you make your full case. This one is not about staying quiet. Staying quiet is the silence problem we already covered. This is about timing. When you feel a disagreement land in the moment, your instinct is to win it right there. Don’t. The version of you arguing in the meeting is dealing with the temperature of the room, the sting of being overruled in front of people, the ego of the person across from you. That version is loud, defensive, and rarely persuasive. So flag it live, but don’t argue it live. Something like: “I want to sit with this one before I’m fully on board. Can I come back to you on it tomorrow?” That’s it. Now you’ve gone on the record without going to war. You haven’t gone silent. You’ve bought yourself a night. Then sleep on it. The next morning, two things will be clearer. Whether the disagreement still feels real, and what the strongest version of your case actually is. Some of what felt urgent will be gone, and that’s fine. Those weren’t the real disagreements. The ones that survive the night are the ones worth bringing back. And the version of you bringing them back, calm, with a clean argument, is much more persuasive than the version that would have argued it hot. This works the same at home. Most fights that feel huge at 11pm are not the same fight at 9am. The move isn’t to swallow the disagreement at 11pm and pretend it didn’t happen. The move is to say “I don’t want to get into this now, but I want to talk about it tomorrow morning.” Then actually do it. The reason this habit works is that disagreements raised hot get answered hot. Disagreements raised cool get answered cool. You control which one happens by controlling when you make your real case. Disagree, then commit. When the decision goes the other way, you have a choice. You can keep arguing. Or you can switch to making the chosen path woaggressiverk. Switch. That’s the move. Not by going quiet. Not by sulking. By actively trying to make the thing succeed. The first one keeps you arguing past the point where it helps. The second one earns you trust the next time you bring something up. This is true at work. It is also true in any relationship that lasts. But if you commit before you’ve made your case, you’ve just done concern theatre. The compounding effect Twenty years in, I’ve come to think of disagreement as one of the few things that compounds. Every time you do it well, the next one is a little easier. Every time you do it badly, the next one is a little harder. The people I’ve watched build real influence at work, and real trust at home, are not the loudest in the room or the calmest. They’re the ones who treated this as something to learn, not something to survive.

The Process Trap

McDonald's solved one of the hardest problems in business history. How do you serve the same burger to a million people, across thousands of locations, staffed by people who have never met each other, and have it taste exactly the same every single time? The answer was process. Specific, documented, non-negotiable process. Every patty the same weight. Every fry cooked at the same temperature for the same number of seconds. Every wrapper folded the same way. You don't need to be a good cook to work at McDonald's. You need to follow the process. That's the point. It works brilliantly. It might be the most successful operational system ever built for food. But take that same system and try to run a kitchen where the goal is excellence rather than consistency, and something quietly breaks. The cook who stops tasting and starts timing. The chef who follows the recipe instead of reading the dish. The kitchen that produces the same thing every time, reliably, competently, and never once produces anything worth going out of your way for. The same process that creates consistency at McDonald's would kill a good restaurant within a year. I've watched a version of this play out in product teams more times than I can count. And the part that makes it hard to fix is that the people who bring it in almost always mean well. Most product teams don't fail loudly. They slow down. Gradually, the team that used to ship things that surprised people starts shipping things that are fine. Solid. Nothing embarrassing. Nothing remarkable either. When you ask what changed, the answer is rarely a bad hire or a wrong strategy. It's usually a good hire. Someone brought in to bring order to the chaos, who had done it before at a company with a name people recognise, and who arrived with a system that made complete sense on paper. Better prioritisation. Clearer documentation. Stakeholder sign-off baked into the process early rather than causing fires at the end. Every piece of it reasonable. The chaos clears. And something else clears with it. Process people have good intentions. That's what makes them dangerous. I worked with a product leader once, brought into a mid-sized software company after a period of what the board called "productive chaos." The team had been shipping fast but inconsistently. Some things landed brilliantly. Others were half-baked and had to be quietly walked back. The board wanted steadiness. He delivered it. Within six months the team was running like a machine. Every two-week work cycle planned in advance. Every feature backed by a document that had cleared four approvals before anyone wrote a line of code. Every decision written down with a reason attached. The chaos was gone. So was most of the thinking. What I noticed, spending time with the team about eight months in, was that the designers and product managers had stopped having the kind of conversations that produce good products. The hallway debates about whether they were solving the right problem. The "what if we tried this instead" moments that usually got dismissed but occasionally changed everything. Those conversations had nowhere to go in the new system. They didn't fit any of the boxes. The team wasn't unhappy. They were busy. Visibly, measurably busy. Hitting their deadlines. Closing their tasks. Moving work from one stage to the next. But nobody was asking whether the stages were pointing in the right direction. The thing process replaces is the thing you actually hired people for. Steve Jobs talked about this once, in an interview most people haven't seen. He called them process people. His point wasn't that they were lazy or incompetent. It was more unsettling than that. They genuinely believe the process is the work. They've been in enough places where good process and good results happened at the same time that they've confused one for the other. The McDonald's cook doesn't need to understand why the fry temperature matters. They need to set the timer. That's correct for McDonald's. But a product designer needs to understand why a design decision matters. If they're just following steps, you haven't scaled thinking. You've replaced it. Product craft is the ability to hold a problem in your head from multiple angles at once and make judgment calls that can't be written down. You can write down the output of that judgment. You can't write down the judgment itself. When a process-driven leader comes in and builds a system around the written outputs, it looks like structure. It is structure. But the thinking that produced those outputs is no longer required. The system runs on its shadow. The tell is usually invisible until it's obvious. At a business software company I spent time with a few years back, the head of product had inherited a team that had grown fast and badly. No clear ownership of who was responsible for what, roadmaps that overlapped, features being built by two teams who didn't know about each other. Real problems. She fixed them. She was genuinely good at fixing them. Clear ownership, a single consolidated roadmap, a prioritisation system the whole team understood and actually used. About a year later, the CEO asked me what I thought about the product direction. I told him what I'd observed: the team was well-run, the process was clean, and the last year of output had been, without exception, the most predictable and the least interesting in the company's history. He went quiet for a moment. "I thought that was just a coincidence," he said. It wasn't a coincidence. Predictability and originality aren't opposites, but the process that creates one can quietly starve the other if nobody notices it happening. The tell is almost always the same. When a process-driven leader has been in place for a while, the team stops bringing problems to them. They bring fully-formed solutions instead. Pre-packaged, already justified, ready to slot into the approval process. Because the system rewards things that fit, not things that challenge. And the leader reads those proposals, approves the ones that meet the bar, pushes back on the ones that don't, and feels, reasonably, that they are doing their job. They are doing their job. That's the trap. The other kind of operator exists, and they're extraordinary. Not every leader who's good at scaling a team is a process person. This is the part that gets missed. The best product leaders I've worked with, the ones who could take a struggling team and turn it into something that shipped great work consistently, weren't building systems around written outputs. They were building conditions for good thinking. That's a different problem to solve entirely. A leader who scales through coaching doesn't ask "what process stops us shipping bad work?" They ask "what does this designer need to think more clearly? What is this product manager not seeing yet? What conversation is this team avoiding that they need to have?" The results look similar from outside. Clearer ownership. Better prioritisation. Fewer things built and quietly shelved. But the mechanism underneath is completely different. One scales compliance. The other scales judgment. The franchise kitchen and the restaurant kitchen can look identical from the car park. You find out which one you're in when you taste the food. Craft isn't one leadership style among three. It's the floor. There's a framework that gets discussed in product circles where product leaders are sorted into three types: craftspeople who care about the product, operators who care about scale, and visionaries who care about the future. It's a useful map. But it has a flaw. It treats craft as a personality preference, something some leaders have and others compensate for with systems or vision. That's the wrong way to think about it. A leader who understands product craft deeply can build a system that makes their team sharper. One who doesn't can only build a system that makes their team more compliant. A visionary who understands craft can push the team toward ambitious ideas that are also real. One who doesn't produces a roadmap that sounds exciting in a meeting and ships as a mess six months later. Craft is not one option. It's what everything else either builds on or doesn't. The companies that treat it as optional make a quiet decision that usually surfaces about two years later, in the form of a product that nobody can explain why it stopped being interesting. By that point the connection is hard to see. I've seen it traced back. It's an unglamorous conversation. Usually someone goes back through old notes and finds the exact point where the team stopped asking the hard questions. Almost always, there's a hire that happened about six months before that point. A McDonald's kitchen running perfectly is genuinely impressive. Hundreds of people, millions of orders, zero variation. But nobody drives across town for a McDonald's. They stop in because it's there and they know what they'll get. The product teams worth working on, and the products worth building, are the ones people go out of their way for. Process gets you consistency. It doesn't get you that.

Product Teams & Org DynamicsApril 14, 2026

The photography moment

The people who grieved hardest when digital photography arrived weren’t casual snappers. They were darkroom people. The ones who had built their whole practice around chemistry and timing and light. Who knew by feel how long to leave a print in the developer tray. Who understood the specific satisfaction of watching an image slowly appear on a blank sheet of paper in a red-lit room, like a secret the photograph was deciding whether to tell you. Digital didn’t just change the tool. It made the room itself unnecessary. For a while, the grief was loud. Forums full of people explaining why film captured something digital couldn’t. Why the process mattered. Why something real was being lost. They weren’t entirely wrong. Something was being lost. But here’s what nobody in those forums was saying: photography was about to get ten times bigger. I think about the darkroom people every time a founder or designer tells me they’re worried about what AI is going to do to their career. The fear is always the same underneath. Not laziness. More specific than that: the fear that the years they spent getting good at something are about to count for less. I had that fear too. Still do sometimes. But I think it’s pointed at the wrong thing. This happens every time a new tool arrives. Not just with photography. Every generation of builders gets a version of this moment. A tool shows up that does cheaply and quickly what used to require years of practice and real money. The people who built their careers on the old way feel the ground move. What usually follows surprises everyone. When photography went fully digital, the number of photographers didn’t shrink. It exploded. Phones made everyone a photographer. Which sounds like it should have destroyed the profession. Instead it created a much larger audience that eventually learned to tell the difference between a good photograph and a lucky one. The professionals didn’t disappear. The category grew around them. The same thing happened when software like PageMaker and Quark arrived in the late eighties and let anyone design a flyer on a computer, which terrified professional print designers at the time. Same pattern when home recording software let musicians make albums in their bedrooms. Same pattern again when tools like Webflow started letting people build websites without writing code. More people doing something doesn’t diminish the people who do it well. It usually creates a bigger audience that eventually learns to tell the difference. The grief is real. The fear is misdirected. The darkroom photographers who struggled weren’t wrong that something was lost. The ritual mattered. The slowing-down mattered. The specific knowledge of how different papers responded to different chemistry was real expertise that didn’t just transfer to editing software overnight. But the ones who stayed stuck were the ones who kept arguing about what had been lost, rather than asking what had just become possible. Digital photography changed what the medium could be used for. It made iteration fast enough that you could experiment in ways that would have been financially stupid on film. It opened photography to people who could never have afforded a darkroom. Whole new genres appeared. New platforms. New ways for images to move through the world. The darkroom photographers who made it through weren’t the ones with the least attachment to the old process. Some of them loved film deeply and kept shooting it on weekends. What they had was clarity about why they picked up a camera in the first place. They were making images that did something. The darkroom was just where those images used to come from. The hard part isn’t learning the tools. The founders and designers I see struggling most with AI mostly understand the tools fine. That’s not where it’s stuck. It’s stuck because they built their sense of professional value around a specific kind of effort. The hours spent. The craft it required. The difficulty of the thing as evidence that it mattered. AI is cheap and fast. And if your identity as a builder is tied to how hard building is, cheap and fast feels like a direct attack on whether what you make means anything. I know that feeling from the inside. Early in my career I was working on a consumer app, and I spent about three weeks obsessing over a single transition animation between two screens. The timing, the easing curve, how the elements moved in relation to each other. I told myself it was craft. Looking back, it was ego. The users never noticed. They were trying to complete a task. Nobody opens an app hoping to admire the transition animations. The difficulty had become the point. Which meant I was building for myself and calling it user-centred design. AI removes the difficulty tax on building. That’s uncomfortable if your identity is attached to paying that tax. But if what you actually care about is the thing you’re making and the people it’s for, it’s a gift. The darkroom people who found their footing weren’t the ones who abandoned film entirely, and they weren’t the ones who refused to touch a digital camera. They were the ones who got honest about why they started. For most of them, the answer had nothing to do with chemistry or developer trays or the red-lit room. It was simpler than that. They wanted to make someone feel something when they looked at an image. They wanted to capture a moment before it disappeared. The darkroom had been how. It was never the why. If you’re a founder or a designer and AI has been keeping you up at night, that’s the question worth asking yourself. Why did you start building? Not “how do I stay relevant” or “which tools should I learn next.” Those are fine questions but they’re downstream of this one. Answer this one honestly and the others get easier. The room changed. The light didn’t.

Product Design & Craft TopicsApril 3, 2026

Your job title is a cage

Walter Murch edited films with a razor blade. Not metaphorically. Literally. He would hold strips of celluloid up to the light, mark a frame with a grease pencil, cut with a blade, and splice the pieces together by hand. He did this for Apocalypse Now. He did it for The Godfather. He won an Oscar for it. When digital editing arrived, his entire physical world changed. The light tables went. The splicing blocks went. The specific feeling of holding a scene in his hands before deciding what to cut, that went too. Murch switched. He became one of the first major editors to fully embrace Avid, the software that moved editing from physical film to a screen, and went on to win another Oscar. But the part that gets missed when people tell this story as a triumph of adaptability: Murch didn’t succeed because he learned new software. He succeeded because he had always known, somewhere underneath the razor blade and the celluloid, that his job was never really about the cut. It was about what the audience felt when the cut happened. Most job titles in product are secretly descriptions of an instrument. “Product designer” means, in most teams, the person who works in Figma. “Product manager” means the person who writes the PRD, which is the document that describes what gets built and why, and runs the weekly sprint. “Researcher” means the person who conducts the interviews. The title describes the method. It doesn’t describe what the role is actually for. This was fine for a long time. When the only person who could produce a designed interface was the person with ten years of design training. When the only person who could make sense of user research was the person who had sat through fifty interviews. AI is cutting that thread. Fast. And the people who feel it most are the ones who built their professional identity around being the person who operated the instrument. Your title describes how you delivered value, not what value you carry. Early in my career I was at a company where the head of design had been there for eleven years. He had built the design system from scratch. Every component, every visual rule, every repeating pattern in the product had passed through his hands at some point. When new hires joined, the unofficial orientation involved someone quietly telling them: when he speaks in a design review, you listen. When the company brought in an AI tool that could generate screen variations from a text prompt, he was the most resistant person in the room. Not loudly. He was too experienced for loud resistance. But in every discussion about the tool, his questions circled back to quality, craft standards, the risk of shipping something that didn’t meet the bar. He wasn’t wrong that the bar mattered. But what he was really doing, without quite saying it, was defending the gatekeeping function his expertise had always performed. His value to the organisation was partly that nothing got through without him. The AI didn’t just threaten his craft. It threatened his position as the person you couldn’t go around. That’s a different problem. And it needed a different solution than better prompting. But he never quite named it, so he never quite solved it. The job title said “Head of Design.” What it really meant was “the person whose judgment this organisation has agreed to trust on visual and interaction decisions.” The first description is about the instrument. The second is about the outcome. Only one of them stays true when the instrument changes. The editors who disappeared had confused their hands for their minds. When Avid arrived in editing rooms in the early nineties, it didn’t just replace the razor blade. It changed what editing cost. A cut that used to take two days could happen in two hours. You could try things you would never have tried on celluloid because trying something on celluloid cost real time and real money. The creative space got bigger overnight. Some editors found this liberating. Others found it terrifying in a way they couldn’t fully explain. The ones who struggled weren’t always the ones who resisted learning the software. Some of them learned it fine. They struggled because the thing that had made them valuable, that slow, deliberate, expensive judgment of knowing exactly which cut to make before you made it, was suddenly worth less. You didn’t need to be certain anymore. You could just try it. Certainty had been the asset. The asset became a liability. I’ve watched a version of this in almost every product team I’ve spent serious time with. The senior PM whose value was holding the entire product history in their head. Knowing without checking what had been tried, why it failed, what the team had already ruled out. When AI tools started doing that same synthesis faster and more completely than any person could, the PMs who thrived were the ones who understood that their real asset was judgment, not memory. The ones who struggled were the ones who had built their identity around being the person who remembered everything. Memory isn’t judgment. It’s just what judgment used to require. The title becomes a cage when you start defending it instead of expanding it. At a software company I know well, the research team had a running tension with the product team about who owned user insights. The researchers felt anything involving user data should come through them. The product team was increasingly pulling insights from AI tools that analyse recorded user sessions, where you watch real people navigate your product, and making decisions without a formal research process. Both sides had legitimate points. But the argument they were actually having, dressed up in language about process and rigour, was about territory. About who got to be the person whose job it was. The researchers were defending a title. The product team was solving a problem. Titles are useful. They signal expertise, set expectations, create accountability. But the moment you start making decisions primarily to protect what the title implies, rather than to produce what the title is supposedly in service of, something has gone wrong. The film editor who insists a cut should only be made a certain way because that’s how editors make cuts is not thinking about the audience anymore. They’re thinking about being an editor. I’ve done this. Everyone who’s been in a senior role long enough has done this. You stop asking “what does this product need” and start asking “what does someone in my position do here.” It’s subtle. It feels like professional standards. It is, at its core, fear dressed up in process. The tell is always the same: you know you’re defending the title when the outcome you’re optimising for is your own continued indispensability. Murch didn’t adapt by learning software. He answered a harder question first. Murch wrote and spoke often about what editing was actually for. Not the technique, not the tools. The purpose underneath. His answer, in plain terms: find the moments in a performance that feel true, then put them in an order that lets the audience feel what the story needs them to feel. The razor blade, the light table, the Avid software, all of it was just how you got there. The getting there was the job. Once you are clear on that, the tool question becomes simple. You use whatever gets you to the true moment. If that’s Avid, you use Avid. If it’s a razor blade on a Sunday afternoon because you love the feel of it, that’s fine too. But the instrument is not the identity. Most product people haven’t answered this question for themselves. Not because they’re not thoughtful. The question just never felt urgent before. When the instrument and the outcome were bundled together, inseparable, you never had to pull them apart. They’re pulled apart now. A product designer whose answer is “I help people accomplish something they couldn’t do easily before” is in a completely different position than one whose answer is “I design screens in Figma.” A PM whose answer is “I make sure we’re building the right thing in the right order” is in a different position than one whose answer is “I write the PRD and run the sprint.” Same titles. Completely different relationship to what’s coming. The resistance is never really about the tools. When I’ve had this conversation with designers and PMs, and I’ve had it more times than I can count over the last two years, the real sticking point is never AI. It’s identity. “If I’m not the person who makes the design decisions by hand, who am I?” It’s an honest question. It deserves an honest answer rather than a motivational poster about growth mindsets. The job title was always a simplification. “Designer” and “PM” are labels that bundled a set of tasks together with the judgment required to do those tasks well, then gave the whole thing one name, as if it were one thing. AI is now picking up the tasks. The judgment is what’s left. What’s left isn’t less. But it is different. And different requires a different answer to “who am I at work.” The editors who made it through the digital transition weren’t the ones with the best attitude about change. They were the ones who, somewhere in the middle of everything shifting, got honest about which part of the work they actually cared about. Which part gave them the feeling of having done something real. For Murch, it was finding the true moment in a performance. Getting to that moment faster was not a threat. It was just more time to look. What’s your version of that? Not the task. Not the deliverable. Not the thing your title says you do. The thing underneath it. Most people reading this will think the point is to be more open to AI tools. It isn’t. The tools are the easy part. The hard part is what Walter Murch had to figure out in an editing room in 1991, holding a razor blade he’d used for twenty years, looking at a screen that could do in two hours what had taken him two days. Not: should I learn this? But: what was I actually doing here? Answer that honestly, and the rest gets easier. Avoid it, and the title you’ve been protecting quietly becomes the thing that holds you in place.

Product Leadership & CareerMarch 25, 2026

The expertise trap

The surgeons who resist robotic surgery the most aren’t the mediocre ones. They’re the brilliant ones. The ones who spent fifteen years developing hand precision that other surgeons describe with something close to reverence. The ones who can close a cranial incision so cleanly that residents gather just to watch. These are the surgeons who look at the da Vinci robotic system and feel, before they can articulate anything, a faint and genuine nausea. The robot is more accurate than any human hand. The data on this is not ambiguous. And yet the resistance is real, and it is not stupid. Because what the robot is taking isn’t just a task. It’s a life’s work. It’s twenty years of the thing that made you the person everyone calls when it matters most. This is exactly what is happening to the best designers and product people right now. Not the average ones. The exceptional ones. The ones who have spent a decade developing a sense of interface so refined they can feel a bad interaction pattern before they can name it. The ones whose Figma files other designers screenshot and study in their free time. The ones who take real, earned pride in the quality of their craft. These are the people who open an AI design tool, let it generate a few options, look at the output, and quietly close the tab. The output wasn’t good enough. That part is often true. But it’s not the reason they closed the tab. What you know lives in your body, not your brain. Cognitive scientists call it procedural memory. The kind of knowledge that stops needing your conscious mind once it’s fully in you. Riding a bicycle. Touch-typing. The way you navigate your childhood home in the dark without turning on a light. Design expertise is mostly procedural memory. I realised this working with a junior designer on a consumer onboarding flow. She’d built something technically correct: right components, right hierarchy, spacing that matched the system’s rules exactly. But it felt wrong in a way I couldn’t immediately explain. I sat with it for ten minutes trying to find the language. The problem was the visual weight on the second screen. Users’ eyes would scan left-to-right, drop down, scan again, and land on an element that created a tiny hesitation just before the main action button. A fraction of a second, invisible unless you’d trained yourself to feel for it. She couldn’t see it because she hadn’t yet built the internal library that would let her feel it. I couldn’t explain it quickly because the knowledge lived below language. That’s expertise. And it’s genuinely extraordinary. But when an AI generates twenty variations of that same flow in four minutes, the procedural knowledge that took ten years to build becomes one input among many. The expert’s advantage shifts from execution to selection. From making to judging. Most designers I know haven’t made peace with that shift yet. Not because they’re obstinate. Because nobody warned them that their most valuable skill and their most dangerous blind spot were the same thing. Designers should be solving for a layer that no longer needs them. At a product company I spent time with a few years back, the senior designer was genuinely exceptional. The kind of person who notices a two-pixel misalignment in a file shared for developer handoff, which is the point in the process where a designer passes their work to the engineers who’ll build it, and fixes it before saying good morning. The team adored her. The quality of the product’s interface was, measurably, because of her. When the company started using AI tools to generate initial design explorations, she did something interesting. She spent more time than ever on craft. Every screen she personally touched became more meticulous, more detailed, more precisely considered. Her output, on a per-screen basis, got measurably better. Her output, on a per-week basis, got measurably smaller. She was doing the equivalent of a surgeon insisting on hand-suturing every wound while the robotic system waited in the corner. The work was more beautiful. It was also slower, harder to scale, and increasingly invisible to the people evaluating what the team was actually shipping. This is the expertise trap in its clearest form. The more you double down on the thing you’re brilliant at, the more you risk optimising for a problem the market has already started solving differently. But the trap isn’t fear, exactly, and it isn’t laziness. It’s something more honest than that. She loved the work. And the work was genuinely good. The problem is that love of execution and love of outcome are not the same thing. They feel identical when you’re the best at the execution. They diverge sharply when execution is no longer the scarce resource. The robot didn’t take the surgeon’s precision. It took the feeling of precision. Something real is lost when surgical robots take over from hands. The surgeons who object aren’t entirely wrong about that. What they’re describing, even if they can’t quite name it, is the physical experience of the work itself. The specific sensation of tissue resistance under a blade. The confidence of trained hands moving through a procedure they’ve performed five hundred times. That felt knowledge gets replaced by something more mediated, more distant, more like operating a very precise machine than doing surgery. But what doesn’t get replaced is the judgment underneath it. When to operate and when not to. What a good outcome looks like for this patient specifically. What the scan is telling you that the numbers aren’t. The instrument changed. The intelligence it required did not. I think about this every time a designer tells me they’re worried AI will take their job. My honest answer, which I don’t always say directly, is this: it will take the part of your job you were always slightly too proud of. The pixel manipulation. The component construction. The part that felt most like craft because it was most tactile, most visible, most satisfying in the moment of doing it. But it won’t take your taste. It can’t. Taste isn’t a skill you learn in a course. It’s the slow accumulation of every right and wrong call you’ve ever made or watched someone else make, compressed into judgment you can deploy without knowing you’re deploying it. You can’t generate it. You can only earn it, slowly, over years of caring about the wrong things until you figure out which things are actually right. The designers who matter most in five years will be the ones who make taste the primary work, rather than the thing that happens between the frames. Keeping your hands is fine. Making your hands the point is not. Some people will read this as an argument to abandon craft entirely and pivot to AI prompt engineering. It isn’t. A surgeon who spends Sunday afternoons on simulations because they love the feel of it, because it sharpens something in them that matters, is doing something worth preserving. Some things are worth doing for how they feel, not just what they produce. But a surgeon who performs a procedure by hand when robotic assistance would measurably reduce patient risk, because they need to feel the instrument, has turned their love of craft into the patient’s problem. That’s the line. Early in my career, I spent months obsessing over interaction details that, I can say honestly now, nobody ever noticed. Micro-animations that would have required frame-by-frame analysis to appreciate. Hover states refined to a resolution that lived entirely below conscious perception. I was putting craft into things at a depth no user would ever reach. I’m not ashamed of it. It taught me things I still use. But I was also, if I’m being direct about it, building beautiful things for myself and calling it user-centred design. I have the Figma files to prove it. They’re gorgeous. They’re completely useless. The expertise trap isn’t that you love what you do. The expertise trap is when what you love becomes the thing you’re protecting, even when the work would be better served by letting some of it go. One designer uses AI and brings their taste to bear on what it generates. Another treats AI as a threat and builds more carefully by hand to prove a point. Both are making a claim about where value lives. Only one of them is right about where the work is going. The hands were never the point. When robotic surgery arrived, the question surgeons kept asking was: should we keep using our hands? It was the wrong question. The right one was: what were the hands always actually for? Precision, most surgeons would have said. And they’d be right. But precision in service of what? Someone going home instead of to an ICU. A damaged system repaired. A person who walked in scared walking out with a plan. Once you name the real purpose, the instrument question gets much simpler. You use whatever gets the patient home. Sometimes that’s your hands. Sometimes it’s a robot. Often it’s both, taking different roles across different moments in the same procedure. Designers are circling a version of this right now, mostly without realising it. The argument in most product teams isn’t really about AI tools. It’s about where the value of design actually lives. Which is a question the industry has never had to answer precisely because execution and judgment used to be bundled together. The same person who had great taste was also the one who could build what the taste demanded. AI unbundles them. And suddenly the question everyone avoided becomes the only one that matters. What is the design actually for? Not what are you designing. What is the act of design, as a practice, ultimately meant to produce? If the answer stops at “a well-crafted interface,” you’ve put the hands at the centre. And the hands, it turns out, were always the means, not the thing. The neurosurgeons who adapted best didn’t abandon their hands. They just stopped believing the hands were the point. Precision was the instrument. The patient was always the point. Most of them knew this somewhere. They just hadn’t had to say it out loud until the robot arrived and made the distinction impossible to ignore.

Product Design & Craft TopicsMarch 6, 2026

What lunchboxes taught me about product distribution

Every morning in Mumbai, roughly 5,000 men in white cotton kurtas and Gandhi caps fan out across the city's suburbs. They knock on doors. They collect tin lunchboxes. They load these lunchboxes onto bicycles, carry them to railway stations, sort them by colour codes painted on the lids, load them onto trains, unload them at different stations, sort them again, and hand-deliver them to office workers at their desks. By 1pm, 200,000 lunchboxes have reached 200,000 people. By evening, the empty boxes travel back the same way. No app. No GPS. No algorithm. No venture capital. The error rate is one misdelivered lunchbox in every 16 million transactions. Harvard Business School wrote a case study about it. Not because of the technology. But because of the complete absence of it. The dabbawalas of Mumbai have been doing this since 1890. And the reason I keep thinking about them has nothing to do with logistics or supply chains or operational excellence, which is what everyone else writes about when they discover this story. I keep thinking about them because they understood something about products that the entire tech industry is about to learn the hard way. Building the product was never the hard part. Getting it to the right person, at the right time, reliably, repeatedly, at a cost that doesn't kill you? That's the hard part. That's the whole game. Every failed product I've worked on in twenty years across startups and enterprises had the same root cause. It wasn't bad design. It wasn't bad engineering. It was bad distribution. The product worked. It just never reached the people it was built for. And in a world where AI just made building almost free, distribution is about to become the only thing that matters. 1. Building got cheap. Distribution didn't. Here's a conversation I've had four times in the last six months. A founder shows me something they've built. An AI tool that does something genuinely impressive. Summarises legal contracts. Generates personalised workout plans. Automates competitor analysis. The demo is slick. The underlying model is sharp. I'm nodding along, because the product is actually good. Then I ask: "How are people finding this?" Silence. A pause. Then some version of: "We're going to do some content marketing. Maybe Product Hunt. We'll figure it out." They won't figure it out. Not because they're not smart. But because the problem they're ignoring is harder than the problem they just solved. They've spent three months building something impressive and zero days thinking about how it reaches the people who need it. AI has collapsed the cost of building to near zero. A solo founder with Claude and a weekend can ship what took a team of twelve six months to build in 2019. I've watched this happen in real time. The prototyping phase that used to take weeks now takes hours. The gap between idea and functional product has never been smaller. But here's what hasn't changed: the cost of getting someone to notice, try, trust, and keep using your product. That's the same as it ever was. Maybe worse, because now there are a thousand other founders who also had a productive weekend. The irony is almost painful. We've been telling founders for years that execution is everything, that ideas are cheap, that the hard part is building. But we were wrong about which part of execution was hard. Building was the part we could engineer our way out of. Distribution is the part that requires patience, relationships, and systems that don't scale the way engineers want them to. The dabbawalas inverted the whole equation in a way that I think is quietly profound. They don't make the food. They don't care about the recipe. Some home cook in Borivali makes the meal, packs it into a tin box, and hands it over. The dabbawalas' entire business is the distribution layer. The product is outsourced. The distribution is the company. Most product teams operate with exactly the opposite assumption. They pour 90% of their energy into the product and treat distribution as a phase that comes after. "First we'll build something great, then we'll figure out how to get it to people." This is like a dabbawala saying, "First let's perfect the lunchbox design, then we'll figure out how to deliver it across Mumbai." The dabbawalas understood something that most product teams still haven't: the meal doesn't matter if it never arrives. 2. The best distribution systems are boring by design. The coding system the dabbawalas use hasn't fundamentally changed in decades. Colours, numbers, and symbols painted on tin lids. Each marking tells the dabbawala where the box was picked up, which train it goes on, which station it gets off at, and which building it's headed to. A semi-literate worker can read this code and route a lunchbox across a city of 20 million people. It is, by any startup standard, aggressively uninteresting. Nobody is trying to disrupt the handoff at Churchgate station. Nobody is building a better coding system. Nobody is pitching investors on "Uber for dabbas." They just do the same thing, six days a week, fifty-one weeks a year, and it works. We don't talk about this kind of thing in product. We romanticise innovation. We celebrate the clever feature, the beautiful interface, the breakthrough technology. Nobody writes a breathless LinkedIn post about their activation email sequence or their customer onboarding checklist. But those boring systems are often the difference between a product people try and a product people keep. I learned this at Freshworks, watching the difference between products that had strong distribution engines and products that didn't. The ones that grew weren't necessarily the ones with the best features. They were the ones where the entire journey from "I heard about this" to "I can't stop using this" had been thought through with the same obsessive care that a designer would give to a hero screen. The onboarding. The first-value moment. The expansion triggers. The stuff nobody puts in their portfolio. But that work is invisible. It's the plumbing. Nobody wins a design award for a well-structured onboarding sequence. Nobody gets promoted for making the referral loop 15% more efficient. And so talented people avoid it, because it doesn't feel like real product work. I've been guilty of this myself. Early in my career, I would have considered distribution work beneath the craft of product design. I was wrong. It is the craft. Everything else is a sketch until distribution makes it real. Sound familiar? It should. It's the same prestige problem that makes designers avoid internal tools. Distribution work is the internal tooling of growth: essential, unglamorous, and perpetually under-invested in. Nobody has ever disrupted a reliable distribution system by making it more interesting. They've disrupted unreliable ones by making them more boring. More repeatable. More consistent. The dabbawalas know this. The best growth teams know this. But most product teams haven't figured it out yet. They're still chasing the clever hack when what they need is a boring system that works every Tuesday. 3. Distribution is a network problem, not a technology problem. The dabba system is structured as autonomous units of about 25 people each. Flat hierarchy. Decentralised decisions. Each dabbawala knows his 30-40 customers personally. He knows which floor they work on, what time they take lunch, which colleague will accept the box if they're in a meeting. The system's reliability comes from relational trust and local knowledge, not from centralised control or sophisticated tracking. Each dabbawala is essentially a node in a distribution graph. And the graph works because the nodes are human. I think about this when I see startups pour money into paid acquisition as their primary distribution strategy. Performance marketing. Google Ads. Instagram campaigns. The funnel mindset: pour money in the top, hope customers drip out the bottom. It works, up to a point. But it's expensive, it's fragile, and the moment you stop spending, the tap turns off. The distribution systems that compound are networks, not funnels. Slack grew because one team inside a company adopted it, and then the team next to them saw it in action, and then the whole floor was using it. Figma spread through design teams the same way. Not because of a brilliant ad campaign. But because of human-to-human transmission. Someone showed someone else, and that person showed someone else. No one asked them to. The product moved through the network the way gossip moves through an office: irresistibly. I spent five years at Adobe, and one thing I noticed was how differently products grew depending on whether they had a network distribution mechanism or a funnel distribution mechanism. The products with network effects (Creative Cloud's collaboration features, for instance) grew in ways that felt almost organic. But the products that relied on traditional marketing grew in ways that felt like pushing a boulder uphill. Every month you had to push again. Stop pushing, and the boulder rolls back. The dabbawalas don't have a growth team. They have 5,000 people who each know 30 doors to knock on. That is a growth team. And it costs almost nothing to maintain, because the network sustains itself through relationships, not through ad spend. This is the part that's hardest for product people to accept. The best distribution strategy might not require a single clever growth hack. It might require building something that naturally flows through human networks. Something people show to other people. Not because you asked them to. But because they can't help it. 4. The real moat is the last mile. In the dabba system, the train journey across Mumbai is the easy part. Predictable. Scheduled. The same route every day. But the hard part is the last mile: the walk from the station to the specific desk on the specific floor of the specific building in a crowded business district. That final stretch is where the system earns its reputation. The dabbawala who handles the last mile doesn't use a bicycle. The streets near the offices are too narrow, too packed with people and handcarts and autorickshaws. He carries the crate on his head. He adapted to the constraint. He doesn't wish the streets were wider. He doesn't build a better cart. He carries the crate on his head because that's what the last mile requires. In product terms, the last mile is activation. Getting a user from "I downloaded this" to "I can't live without this." And it's where most products quietly die. I once worked on an IoT product at Schneider Electric, a thermostat application for home users. The product itself was solid. The interface was clean. The engineering was sound. But the last mile, getting a non-technical homeowner to connect the device to their Wi-Fi, pair it with the app, set their first schedule, and actually trust it enough to stop adjusting the thermostat manually, was brutal. We lost more users in that last-mile stretch than at any other point in the journey. We'd built the train. We hadn't built the walk through the crowd. I've seen this pattern repeat across twenty years and more products than I can count. The teams that obsess over the product but treat activation as a checkbox. The beautifully designed app that nobody uses past day three. The powerful tool that churns at 40% in the first month because the distance between "signed up" and "got value" is too far, too confusing, or too forgettable. But here's what's interesting: the teams that do get the last mile right almost never do it through better technology. They do it through better understanding of the specific, messy, human context their users live in. They study the narrow streets. They learn which floor the customer sits on. They adapt to constraints instead of wishing them away. Building the product is the train ride. Distribution is the walk through the crowd with a crate on your head. And most teams spend 90% of their energy on the train and wonder why nobody's eating lunch. Every morning, a dabbawala in Andheri picks up a tin lunchbox from a home kitchen. He doesn't know what's inside. Doesn't need to. His job is to make sure it arrives warm, on time, at the right desk. He's been doing this for years. He'll do it again tomorrow. There is something in that repetition that the product world hasn't learned to value. Not the meal. Not the recipe. Not the ingredients. But the daily act of carrying it from where it was made to where it is needed. The unsexy consistency of showing up at the same door at the same time. The lunchbox arrives warm. That's the whole product.

Markets & Industry DynamicsFebruary 28, 2026

Your onboarding is your product.

Nobody ever fell in love on a second date that almost didn't happen. First dates are brutal, efficient sorting machines. Research on speed dating shows that people form a judgement within the first four minutes. Not an impression. A judgement. The rest of the evening is mostly spent confirming what they already decided while the appetisers were arriving. And here's the part that matters for anyone building a product: the people who fail on first dates almost always fail for the same reason. They spend the whole time talking about themselves. Their job. Their hobbies. Their impressive marathon time. Their opinions on craft beer. They treat the date like a presentation. Forty-five minutes of "let me tell you about me" and then genuine surprise when there's no second date. But your product's onboarding does the same thing. And it's just as unattractive. Most onboarding flows are designed as introductions. "Welcome to our product. Here's what we do. Here's how it works. Here's a tour of the features. Here's a tooltip pointing at a button you'll never click. Now please fill out this form so we can personalise your experience, which really means so we can segment you for marketing emails." I've sat in rooms where teams spent weeks designing these flows. Beautiful illustrations. Smooth animations. A friendly mascot who waves at you. Genuinely impressive craft, all in service of answering a question the user never asked. But the user didn't open your product wondering "what does this do?" They opened it wondering "does this understand my problem?" That's a fundamentally different question. But the gap between those two questions is where most products quietly die. Not with a dramatic failure. Not with a crash or an error message. With a shrug. A closed tab. A user who signed up, looked around for ninety seconds, felt nothing, and left. I wrote recently about the shift from MVP to MVE, from minimum viable product to minimum viable experience. This is where that shift lives or dies. Not in your feature set. Not in your roadmap. In the first ninety seconds after someone gives you a chance. At a SaaS company I worked with a few years ago, we had what the team proudly called a "comprehensive onboarding experience." Four screens of setup. A welcome video. A guided tour that walked you through every major feature before you could touch anything. The team had spent an entire quarter building it. Our completion rate on the onboarding flow was 73%. The team celebrated. But here's what they didn't celebrate: of the users who completed the full onboarding, fewer than 30% came back the next day. They'd sat through the entire presentation, nodded politely, and never returned. We'd built the equivalent of a first date where one person delivers a TED talk about themselves for twenty minutes and then says, "So, should we do this again?" The other person smiles, says "definitely," and then blocks your number in the car park. The onboarding wasn't broken. It was thorough. It was polished. It was entirely about us. The turnaround, when it came, was almost embarrassingly simple. A junior designer on the team, someone who'd been at the company for maybe four months, asked a question in a review meeting that nobody had thought to ask: "What if the first thing the user sees is their own data instead of our features?" That's it. That was the whole insight. Instead of opening with a tour, we opened with an import. Instead of showing users what the product could do, we showed them what the product could do with their stuff. The first screen after signup became a single prompt: bring in your existing work. No tour. No tooltips. No mascot. The user's first experience went from "let us tell you about ourselves" to "we already know why you're here." Retention after day one nearly doubled. Not because we'd added a feature. Because we'd subtracted everything between the user and the moment they felt the product understood their problem. The best first dates are the ones where someone asks you a genuinely good question in the first two minutes. Not because asking questions is a technique. Because it signals something rare and specific: this person is paying attention to me, not performing for me. I've spent twenty years designing products across startups and enterprises, and in almost every case, the pattern is the same. The teams that obsess over their onboarding as a feature tour are solving for comprehensiveness. The teams that obsess over the first moment of recognition are solving for retention. Comprehensiveness feels responsible. It feels like good product management. You're being thorough. You're educating the user. You're reducing support tickets. But thoroughness is not the same as care. Showing someone every room in the house is not the same as making them feel welcome at the door. The metric that actually predicts whether someone stays is not "did they complete the onboarding?" It's something much simpler and much harder to measure: did they feel, within ninety seconds, that this product was built for someone like them? I've started calling this the recognition moment. The point where a user stops evaluating and starts using. Where the internal question shifts from "what is this?" to "oh, this is for me." Everything before that moment is friction. Everything after it is momentum. Most products never reach it. But not because they're bad products. Because they buried the recognition moment under a welcome video and a four-step setup wizard. The teams getting this right are not building better onboarding. They're eliminating the distance between signup and recognition. They're asking: what's the fastest path to showing this user that we understand why they're here? And then they're cutting everything that sits between the user and that moment. Sometimes that means showing real data on the first screen instead of sample data. Sometimes it means asking one smart question instead of ten. Sometimes it means doing less on purpose so the user can feel more on arrival. It's the same instinct that makes a great first date great. Not the performance. Not the rehearsed stories. The moment where someone makes you feel like they actually showed up to meet you, not just to be seen. Your onboarding is not an introduction to your product. It's your product's first answer to the only question that matters: do you understand why I'm here?

Product Design & Craft TopicsFebruary 14, 2026

When your user and your customer are different people

A tenant lives in an apartment. They care about whether the hot water works, whether the walls are thin enough to hear every argument next door, whether the heating actually turns on in December. They care about the things you care about when you live somewhere. The landlord owns the apartment. They care about the yield, the property value, the lease renewal rate. They care about the things you care about when you own something. Both have a relationship with the building. But when the landlord decides to renovate, they're not fixing the plumbing for the current tenant's comfort. They're upgrading the kitchen so they can charge the next tenant more. And if you've ever lived through a renovation you didn't ask for, contractors showing up at 8am, your hot water vanishing for a week, the hallway smelling like paint for a month, you know exactly what it feels like to be a user of a product that's being optimised for someone else. The building is changing around you. But not for you. Most digital products work this way. The user lives in the product. They navigate it every day. They develop habits, preferences, workarounds. But the product is being renovated for someone else entirely. And until you understand who that someone else is, nothing about the product's decisions will make sense. In most products, the person using it and the person the company is optimising for are not the same person. This isn't a bug. It's the business model. 1. Paying customers can be the product too "If you're not paying, you're the product." Everyone knows this line. It's become the default explanation for why ad-supported platforms feel hostile. Social media, free email, free search: your attention is sold to advertisers. You are the inventory. Fine. But the split goes much deeper than free-versus-paid. Enterprise SaaS is the clearest example. The person using the CRM eight hours a day is not the person who bought it. The sales rep needs the tool to not waste their time. The VP of Sales who signed the contract needs reporting dashboards, forecasting accuracy, and a sense of control. These are different needs. They look similar in a pitch deck. They are not similar in daily use. But when they conflict, the signature on the contract wins. Every single time. Not because anyone sat in a room and said "the user doesn't matter." But because the incentive structure already made that decision before the meeting started. I watched this play out at a SaaS company I worked at. The product team had two options for a dashboard redesign. Option A was faster, cleaner, and users loved it in testing. Option B had more executive-facing analytics widgets. Option B shipped. Not because anyone disliked Option A. Because the renewal conversation happened with the VP, not the sales rep sitting in the product every day. The product roadmap follows the signature on the contract. If that's not the person using your product, you've already chosen sides. 2. Your business model decides who your user is before your product team does There are three dominant models in digital products, and each one defines "user" differently. It's worth seeing them side by side, because the pattern becomes obvious once you do. Ad-supported products (social media, search, free tools): The user is the inventory. The advertiser is the customer. The product's job is to maximise time-on-platform so there's more inventory to sell. Every design decision that increases engagement is rational under this model, even if it comes at the user's expense. The outrage algorithm isn't a failure of values. It's a success of economics. Enterprise SaaS (B2B, procurement-driven): The user is the operator. The buyer is the customer. The product's job is to make the buyer look smart for purchasing it. Features that impress in a quarterly review get prioritised over features that reduce the daily friction of the person actually clicking the buttons. Platforms and marketplaces (ride-sharing, delivery, freelance): Neither side is the customer in the traditional sense. The platform optimises for the transaction itself. Drivers, riders, restaurants, couriers: all are inputs being optimised, not people being served. Everyone thinks the platform works for them. But the platform works for the platform. It's like a football stadium. The fans came for the match. But the sightlines are optimised for camera angles, the breaks in play are timed for ad slots, and the premium seats face the broadcast cameras, not the pitch. The fans are the atmosphere. The broadcaster is the customer. The fans just don't know it, because they're too busy enjoying the game to notice who the building was actually designed for. Your business model doesn't just determine how you make money. It determines who your product actually serves. Everything else is a story you tell yourself. 3. The ride-sharing test that tells you everything Here's where this gets personal for anyone who builds products. At a ride-sharing company I worked with, the product team ran an experiment that measurably improved driver satisfaction. Better route suggestions, fewer forced pickups, slightly more control over their shift. Drivers loved it. But rider conversion dipped by a small margin. The experiment was killed in the next sprint review. The comment in the meeting was revealing: "We don't optimise for supply happiness. We optimise for transaction completion." Nobody in that room was being cruel. The PM wasn't a villain. The data team wasn't heartless. The business model had already decided who mattered. The drivers were users. The transaction was the customer. And the experiment, no matter how good the outcomes were for drivers, was never going to survive a framework that didn't have a row for "supply happiness." But this dynamic isn't exclusive to Big Tech. It's in your product too. The founder who builds for investors instead of users during fundraising season. The PM who ships the feature that demos well over the one that works well. The designer who optimises the signup flow for conversion rate, not user comprehension. The startup that redesigns its pricing page to maximise enterprise upsells while making the free tier progressively harder to find. I've spent 20 years across startups and enterprises, from Adobe to Freshworks to early-stage companies with five people in a room, and in nearly every case, the user/customer split exists. The shape changes. The severity varies. But the split is always there. The only difference is whether the team has named it or not. Nobody in the room is being cruel. The business model has already decided who matters. 4. User advocacy isn't about always choosing the user. It's about always knowing when you're not. Here's the part where I'm supposed to tell you how to fix this. I can't. Not in the way you'd want. The user/customer split isn't something you eliminate. Ad-supported products have advertisers. Enterprise products have buyers who aren't users. Platforms have transaction economics. That's reality. Pretending otherwise doesn't make you ethical. It makes you confused. But you can be honest about where the split lives. And that honesty changes everything about how you build. The best product teams I've worked with didn't pretend they were building for the user when they were building for the buyer. They made the trade-off visible. They said it out loud in the room: "This decision serves the buyer. Here's what we're giving up on the user side. Here's how we'll rebalance next quarter." No theatre. No pretending the quarterly analytics dashboard was really about "empowering" the sales rep. That's not cynicism. That's clarity. And it's the difference between a product team that slowly loses its users' trust without understanding why, and one that makes hard trade-offs with its eyes open. User advocacy isn't about always choosing the user. It's about always knowing when you're not. And saying so. The tenant never stops caring about the plumbing. The landlord never stops caring about the yield. The best products aren't the ones that pretend there's no split. They're the ones that know exactly where it lives and make the trade-off on purpose. Not by accident. Not by org chart. Not by pretending the tenant and the landlord want the same thing. They never do.

Product StrategyJanuary 30, 2026

The removal economy

In the early 2000s, airlines discovered something remarkable. You could take a product people already paid for, break it into pieces, and sell each piece back to them separately. Checked bags. Seat selection. Meals. Legroom. Boarding priority. Overhead bin space. The flight itself got cheaper. Everything around it got more expensive. And here's the part that made the whole thing work: the core product didn't change at all. A plane still took you from one city to another. You still sat in a chair. You still arrived. But somewhere between 2001 and 2010, "a flight" stopped being a product and became a platform for selling you back things you used to get for free. The real genius was the psychology of it. Passengers used to complain about the in-flight sandwich. It was terrible. Everyone agreed. But when they started charging $9 for it, people bought it anyway. Turns out a bad sandwich you got for free was an annoyance. A bad sandwich you chose to buy was a purchase. Same sandwich. Different revenue line. Tech companies watched this happen. And they learned. But they got better at it, because when an airline removes your free checked bag, you notice immediately. It's right there on the receipt. When a phone manufacturer removes your SD card slot, they call it courage. When a SaaS company kills a free tier, they call it simplification. When a laptop maker designs a battery you can't replace, they call it innovation. The most profitable product decisions of the last decade haven't been about building new things. They've been about removing old things and selling the replacement. There's a name for this pattern worth remembering. Call it the Removal Economy. And if you build products for a living, you've almost certainly been in the room where it happens, even if nobody called it that. Removing a feature is more profitable than building one The economics of removal are strangely elegant once you see them clearly. When you build a new feature, you add cost on every dimension. Development. QA. Documentation. Support tickets. Maintenance. Cognitive load in the product. Server costs. Every new feature is a small ongoing tax on the entire organisation. When you remove a feature, you subtract all of that cost. But here's the part that makes CFOs smile: if the removed feature created a dependency, you can now sell the replacement. You're improving margins on both sides of the ledger simultaneously. Costs go down. Revenue goes up. No new feature in history has that return profile. Consider this. Apple removed the headphone jack from the iPhone in 2016. AirPods launched the same year. By 2024, the wearables and accessories category (driven largely by AirPods) was generating over $23 billion annually. The removal of a component that cost less than a dollar to include created a product line worth more than most companies. That's not a side effect. That's the strategy. I watched this playbook run at a SaaS company I worked at a few years ago. The product had a free reporting dashboard that was, frankly, pretty decent. Users liked it. Support tickets were low. It worked. But the margins weren't there, and the analytics team had built something better behind a paywall. So the free tier disappeared in Q2. The paid analytics add-on launched in Q3. Same roadmap. Same planning cycle. The internal pitch never once used the word "monetise." It was all about "simplifying the core experience" and "reducing surface area." Revenue went up 18% that quarter. In the all-hands meeting, they called it a product improvement. In the finance review, they called it what it was. The most honest sentence in product strategy is: "We removed it so we could sell it back to you." But nobody ever says that in the meeting. They say "simplify." The difference between courage and extraction is about $159 Not all removal is the same. And this is where the conversation usually gets lazy. The viral post that kicked off this discussion (43,000 likes and counting) listed a string of "peak capitalist" product decisions: SD card slots, headphone jacks, chargers, repairability. And the implication was clear: companies are greedy, users are getting squeezed, tech is broken. But that framing misses something important. Some removal genuinely makes the product better. The trick is knowing which is which. There's a spectrum here, and it has two ends. On one end: legitimate simplification. The removed feature is replaced by something better, at no additional cost to the user. Apple killed the floppy drive in 1998. That was foresight. The floppy was dying, USB and the internet were already better, and users gained more than they lost. Nobody mourns the floppy drive. Nobody mourns the physical keyboard on smartphones, either. The touchscreen was a genuine leap. These removals made the product better, full stop. On the other end: extraction. The removed feature is replaced by a purchase. The user's experience stays the same or gets worse, unless they open their wallet. The headphone jack disappears, replaced by AirPods at $159. Chargers vanish from the box, sold separately for $19. SD card slots are eliminated, replaced by iCloud storage at $2.99 a month, forever. Repairability is engineered out, replaced by AppleCare subscriptions. The diagnostic is simple. When a company removes something and the replacement is free, that's progress. When the replacement has a price tag, that's the Removal Economy. It's the equivalent of a restaurant removing the bread basket from the table and adding a $4 "artisan bread selection" to the menu. The bread didn't get better. The margin did. And the waiter will tell you it's about "elevating the dining experience." Every single example in that viral post falls on the extraction side of the spectrum. That's not a coincidence. That's a pattern. And the fact that 43,000 people recognised it instantly tells you something important about where trust stands between tech companies and the people who use their products. Courage is removing something your users don't need anymore. Extraction is removing something your users still need and charging them to get it back. The meeting where nobody says "should we?" because everyone is asking "can we?" Here's where this gets uncomfortable for anyone who builds products for a living. And that includes me. Removal decisions don't feel predatory from inside the room. They feel rational. There's a business case. There's a slide deck with projections. There's a metric that goes up and to the right. The PM presenting the proposal isn't twirling a villain's moustache. They're doing their job. The problem isn't that someone in the room is evil. The problem is that the room is optimised to answer two questions: "Can we do this?" and "What's the revenue impact?" Nobody's job depends on asking "Should we do this?" and "What's the trust impact?" Those questions don't have a row in the spreadsheet. They don't show up in the OKR review. So they don't get asked. I've been in one of these rooms. A product I worked on had a free API integration that a chunk of our user base relied on. It wasn't glamorous. It wasn't growing. But it worked, and people depended on it. The team proposed sunsetting it and routing users to a paid marketplace instead. The business case was clean. The integration was expensive to maintain. The marketplace had better margins. The PM presented it as "retiring a legacy feature." Three people in the room had reservations. I was one of them. Nobody raised them, because the VP had already endorsed the direction and the quarterly targets were aggressive. You learn to read rooms in this industry, and this room had already decided. Short-term revenue spiked. The next two quarters looked great. But twelve months later, two of the largest enterprise customers had quietly built their own workaround and were actively evaluating competitors. They didn't leave because the product got worse in some measurable way. They left because they felt the product was no longer on their side. One of them told our account manager, almost exactly: "We stopped trusting the roadmap." The removal funded one quarter. The trust loss cost three years of pipeline. In my experience across multiple companies, the decision to remove is almost never framed as a trade-off. It's framed as an optimisation. And optimisations don't require the same scrutiny as trade-offs. They get approved, not debated. That framing gap is where the real damage happens. The most dangerous product meeting is the one where everyone agrees it's just an optimisation. Optimisations don't get debated. They get approved. Every removal is a withdrawal from the trust account, and trust accounts don't send low-balance warnings Every product relationship runs on a trust account. Features, reliability, fair pricing, the feeling that the company is building for you and not just from you: these are deposits. Every removal that benefits the company more than the user is a withdrawal. But trust accounts don't work like bank accounts. There's no balance notification. No overdraft alert. No friendly email saying "Your trust balance is running low, please make a deposit." Users absorb one withdrawal. Then another. Then another. They don't complain proportionally. They don't send you a linear signal that things are getting worse. And then they leave. Or they post something that gets 43,000 likes. It's like how bridges fail. They don't sag gradually and give engineers time to reroute traffic. They hold, and hold, and hold. And then they don't. Structural engineers call this brittle failure. Product teams experience it as churn that "came out of nowhere." But it didn't come out of nowhere. It came out of every small withdrawal nobody was tracking. If you're a PM, a designer, or a founder reading this, the Removal Economy isn't just a Big Tech problem you can point at from a safe distance. It's in your product, too. Every subscription tier you "simplify," every free feature you sunset, every integration you deprecate, every pricing change you frame as an improvement: each one is a decision on this spectrum. The question isn't whether the revenue math works. The revenue math always works in the short term. Removal is the easiest win in product strategy. That's precisely why it's dangerous. The question is what you're withdrawing from the trust account. And whether you can afford the balance when it comes due. Trust accounts don't send low-balance warnings. They just close. The airlines unbundled everything. Bags, seats, food, legroom, boarding order, overhead bin space, the right to bring a coat. They won every spreadsheet. They optimised every revenue line. And now flying is something three billion people endure, not enjoy. The product is cheaper on paper. The experience is hollowed out. The margins are better than ever. That's the Removal Economy's final act. You optimise the revenue model until there's nothing left worth paying for. The question for anyone building a product today isn't what else you can remove. It's what you can't afford to.

The Business of ProductsJanuary 3, 2026

Minimum Viable Experience: Why "does it work?" is the wrong question

The First Bite Is the Whole Restaurant You never really decide whether a restaurant is good during the main course. You decide during the bread. The water. The first thirty seconds after you sit down. Maybe it's how quickly someone acknowledged you. Maybe it's the weight of the glass in your hand, or the fact that the bread was warm instead of room temperature. You didn't come for the bread. But the bread told you everything about whether the kitchen cares. Great restaurants know this. The amuse-bouche, that tiny thing the chef sends out before you've even ordered, isn't about feeding you. It's about making a promise. It says: we thought about this. We thought about you. Stay. Most product teams have never heard of an amuse-bouche. They're in the back, obsessing over the main course, while the bread at the table is stale and nobody has taken the order. The MVP was always a cooking metaphor, even if nobody framed it that way. Ship the minimum dish. See if anyone eats it. If they do, improve the recipe. But that metaphor assumed something important: that people would sit down in the first place. That they'd give you the benefit of the doubt long enough to taste the food, even if the plates were paper and the ambiance was a folding table. That assumption is dead. In 2026, your users don't walk into an empty restaurant and wait patiently for the first course. They glance through the window while walking past seventeen other restaurants on the same street. They'll give you maybe ninety seconds. If the window looks uninviting, they keep walking. They never see the menu. AI made it easy for everyone to open a restaurant. Which means the street is now very, very long. I've watched this play out at close range over the last couple of years. Teams that build something genuinely functional, genuinely useful, and then watch it flatline. Not because the product is bad. Because the first experience doesn't feel like anything. A founder I spoke with last year had built a solid workflow tool. Clean architecture, fast performance, real utility under the hood. But the onboarding was a four-step form followed by an empty dashboard. His first-time users were landing on a blank screen with a button that said "Create New Project" and no context for why they should. He'd built a great kitchen. But the dining room was an empty warehouse with fluorescent lighting and a sign that said "food is available." His activation numbers were awful. Not because the product was wrong. Because the first bite was missing entirely. This is what I think the shift from MVP to MVE actually means, and it's simpler than most people make it. MVP asked: what's the least we can build to test whether this works? MVE asks: what's the least experience that makes someone feel this was built for them? The difference is subtle but it changes everything downstream. MVP is about function. Does it work? Can it handle the use case? MVE is about care. Does it feel considered? Does the first interaction communicate that a human being thought about what it would be like to arrive here for the first time? I spent five years designing enterprise products where the MVP mindset was gospel. Ship the feature, measure adoption, iterate. And for a while it worked, because enterprise buyers had switching costs and procurement cycles that kept them patient. They'd tolerate a rough v1 because leaving was expensive. But even that's changing. I've talked to enough SaaS teams recently to know that enterprise buyers are getting less patient, not more. When your competitor can ship a polished alternative in weeks instead of quarters, the grace period for a rough first experience is shrinking everywhere. The restaurant analogy holds all the way down, and this is the part that matters most. A great amuse-bouche is not expensive. It's not complex. It's a single bite that communicates intention. One perfect thing, served with thought. The cost is almost nothing. The signal it sends is everything. The same is true for your product's first experience. You don't need to build more features. You probably need fewer. You need the first interaction to do one thing clearly and make the user feel like they've arrived somewhere that was expecting them. That might be a pre-populated dashboard instead of a blank one. It might be one smart default instead of ten configuration options. It might be a single sentence of copy that says "here's what this does and here's why it matters to you" instead of a four-step tutorial that nobody will finish. The minimum viable experience is not about polish. It's not about adding animations or illustrations or a friendly mascot. It's about reducing the distance between "I just signed up" and "oh, I see why this exists." Every product team I've worked with overestimates how much patience a new user has and underestimates how quickly the judgement happens. It doesn't happen when they've explored three features. It happens during the bread. The teams that are getting this right aren't spending more time building. They're spending more time on the first ninety seconds. They're treating the initial experience as the product, not as the hallway you walk through to reach the product. That's a design problem. But it's also a strategy problem. Because if your first bite doesn't earn a second, it doesn't matter how good the main course is. Nobody sends back the entree at a restaurant they already left.

Product Design & Craft TopicsDecember 27, 2025

The death of the MVP mindset

The Demo Tape Doesn't Matter Anymore In 1994, if you were a band in a garage in Bombay or Baltimore, the hard part wasn't writing a good song. The hard part was recording it. Studio time was expensive. Equipment was scarce. Mixing and mastering required people who owned machines that cost more than your apartment. So the demo tape meant something. If you had one, it proved you could actually make music. It was your ticket to being taken seriously. Labels listened to demo tapes because the tape itself was evidence of commitment, resourcefulness, and at least a basic level of competence. Today, a seventeen-year-old with a laptop and a cracked copy of Ableton can produce a track that sounds better than most studio recordings from the 1990s. The demo tape is worthless. Not because music got worse. Because making music got easy. The question is no longer "can you make a song?" The question is "can you get anyone to hear it?" This is exactly what happened to the MVP. And most product teams haven't caught up. The MVP was built for a world where building was expensive. The Minimum Viable Product made sense when shipping software was genuinely hard. When building the first version of something required months of engineering, real infrastructure costs, and significant upfront investment, the MVP was a smart way to de-risk. Ship the smallest thing that works. See if anyone uses it. Learn. Iterate. The MVP wasn't really about the product. It was about the question: can we build this at all? I remember working on a product years ago where the MVP took five months. Five months of engineering, design, QA, and more standups than I want to think about. When we finally shipped it, the fact that it existed and functioned felt like a victory. And it was. Because building the thing was the hard part. But that was a different era. And I don't think it's coming back. Building is now the easy part. That changes everything. AI has collapsed the cost of building a first version of almost anything. A solo founder can go from idea to working prototype in a weekend. A PM can build a functional demo without writing a line of code. A designer can ship a front-end that would have taken an engineering team three sprints two years ago. This is genuinely exciting. But it also means the MVP, as we've traditionally understood it, is answering a question nobody is asking anymore. "Can we build this?" is no longer the risky bet. Of course you can build it. Everyone can build it. Your competitor can build it. A college student in Kochi can build it over a long weekend while simultaneously failing to do their laundry. The risky bet has moved. It's no longer "can we ship this?" It's "can we get anyone to care?" Can you distribute it? Can you find the people who need it? Can you get them to try it? Can you make them come back? Can you do all of that for less money than those people will ever pay you? That's the new validation question. And most MVPs don't even attempt to answer it. The graveyard is full of functional products. Here's what I've noticed over the last few years, across multiple teams and companies I've been close to. The products that fail aren't failing because they don't work. They're failing because nobody knows they exist. I talked to a founder recently who had built something genuinely clever. Clean interface. Real problem being solved. Fast, reliable, well-designed. He'd spent four months building it and was proud of the craft. I asked him how he was planning to get users. He paused, then said, "I figured I'd post it on Product Hunt and see what happens." That's not a distribution strategy. That's a prayer. And he's not unusual. He's the norm. Most builders, especially technical ones, treat distribution as the thing that happens after the real work is done. Build the product, then "do some marketing." As if marketing is a condiment you add at the end rather than the main ingredient you plan around from day one. The MVP mindset trained a generation of product people to believe that if you build something good enough, people will find it. That was always a little optimistic. In 2026, it's delusional. Validation now means proving distribution, not function. If I were starting a product today, the first thing I'd build isn't the product. It's the audience. I'd want to know, before writing a single line of code or pushing a single pixel, whether the people I'm building for actually exist in a place I can reach them. Can I find them? Can I talk to them? Will they listen? Do they already gather somewhere, a subreddit, a Slack community, a newsletter, a Discord server, where I can show up and earn attention before I have anything to sell? That's the new MVP. Not a minimum viable product. A minimum viable path to the customer. Because the product is the easy part now. The demo tape is free. Anyone can record one. The question that separates the bands that make it from the bands that play to an empty room is the same question that separates the startups that scale from the ones that quietly shut down: Can you get anyone to listen? The best product I ever worked on wasn't the most technically impressive one. It wasn't the most beautifully designed one. It was the one where we knew exactly who it was for and exactly where to find them before we built a single screen. That felt like cheating at the time. Now I think it's the only way to play.

Product StrategyDecember 6, 2025

The middle management crisis nobody's preparing for

The Switchboard Is Empty In 1950, there were roughly 350,000 switchboard operators in the United States. Their job was simple and essential: you picked up the phone, told them who you wanted to talk to, and they physically connected your wire to the right socket. Every call in the country passed through a human being sitting at a board, making the connection by hand. By 1980, the job was nearly gone. Not because the operators were bad at it. Not because a machine did it cheaper. But because direct dialing made the connection automatic. The call still happened. The conversation still happened. The complexity that required a human in the middle simply evaporated. Nobody replaced the switchboard operator. The world just stopped needing one. I think about this a lot when I look at how product teams are structured today. The coordination layer had a reason to exist. That reason is shrinking. For the last fifteen years, the standard product team has worked like this: a PM talks to stakeholders and translates business needs into requirements. A designer translates requirements into interfaces. An engineer translates interfaces into code. And somewhere in between, a layer of people exists whose primary job is making sure all that translation doesn't break down. Project managers. Scrum masters. Team leads. Program managers. People whose calendars are a mosaic of alignment meetings, status syncs, dependency check-ins, and "quick chats" that are never quick. I've been that person. I've also managed that person. And I want to be honest about something: most of the complexity that justified these roles was artificial. It existed because the gaps between disciplines were wide enough that someone had to stand in them and direct traffic. The PM couldn't see what the designer was building in real time. The designer couldn't understand why engineering estimated eight weeks for something that "looked simple." The engineer couldn't talk to the customer without three layers of context. So we hired people to carry context across these gaps. Meeting by meeting. Slide by slide. Jira ticket by Jira ticket. That was a reasonable solution to a real problem. But AI is closing the gaps. This isn't about AI replacing managers. It's quieter than that. Here's where the conversation usually goes sideways. Someone says "AI will replace middle managers" and the entire room gets defensive. That framing is wrong, and it lets people dismiss the real shift. AI isn't replacing managers. It's removing the friction that made management necessary at the scale we built it. When a PM can prototype a working concept in an afternoon, they don't need a two-week design cycle to see whether the idea has legs. That's one alignment meeting gone. When a designer can ship a functional feature without waiting for an engineering sprint, that's one project manager's dependency map that just got simpler. When an engineer can synthesize customer feedback using AI tools instead of waiting for the research team's quarterly report, that's one status sync that doesn't need to happen. None of these changes "replace" a manager. Each one just removes a tiny piece of the complexity that the manager was hired to coordinate. Remove enough pieces and you're left with someone whose calendar is still full but whose impact has quietly hollowed out. I worked with a team once where the project manager was genuinely talented. Organized. Respected. Good with people. But as the team adopted better tools and the PM started prototyping directly with engineering, the project manager's role slowly shifted from "the person who makes things happen" to "the person who documents that things happened." Nobody said anything. The standups continued. The sprint reports still landed in inboxes. But everyone in the room could feel the change. The switchboard was still staffed. The calls just weren't coming through it anymore. The identity crisis is the real crisis. Here's what makes this different from other "AI and jobs" conversations. When AI automates a task, like writing a first draft or generating test cases, the person can learn a new task. That's adaptation. It's uncomfortable but manageable. But when AI removes the complexity that justified your role's existence, that's not a task problem. That's an identity problem. A lot of middle managers I've known, including past versions of myself, built their professional identity around being indispensable connectors. The person who "knows where all the bodies are buried." The person who can get the VP on the phone. The person who translates between engineering and design so that neither side has to learn the other's language. That identity felt earned. And it was. The problem is that "earned" and "still necessary" are not the same thing. The switchboard operators of the 1950s were skilled. They memorized hundreds of local numbers. They could connect a call faster than any machine of that era. They were genuinely good at their jobs. Their skill was never the question. The question was whether the world still needed a human in that particular seat. What actually survives. I want to be clear about what I'm not saying. I'm not saying management doesn't matter. I'm not saying leadership is obsolete. I'm not saying you should fire your project manager on Monday. What I am saying is that the version of middle management that exists primarily to coordinate information between specialized silos is running on borrowed time. The silos are collapsing. The information is flowing faster and more directly. The gaps are narrowing. The managers who will thrive are the ones who were never really coordinators in the first place. They were decision-makers. Mentors. People who could look at a messy situation and say "here's what we're actually doing and here's why." People whose value was judgment, not logistics. But if your primary contribution to a team is making sure information gets from Point A to Point B, and AI is making that transfer automatic, the honest conversation to have with yourself isn't "how do I protect my role." It's "what else am I capable of?" That's not a comfortable question. But it's a more useful one than pretending the switchboard still needs you. The calls are still happening. The connections are still being made. The work is still getting done. It's just routing itself now.

Product Teams & Org DynamicsNovember 20, 2025

The org chart is a lie.

An orchestra needs a conductor. It needs first violins sitting in front of second violins. It needs the woodwinds to the left and the brass to the right. Everyone has sheet music. Everyone plays their part. Nobody improvises. And if the oboist suddenly picks up a trumpet mid-performance, the whole thing falls apart. A jazz band works differently. There's a loose structure, sure. Someone counts off the tempo. But after that, the bassist can solo. The pianist can comp. The drummer can lead. The sax player reads the room and decides, in real time, whether this moment needs melody or space. Nobody asks permission. The music is better because the roles are fluid. Most product teams in 2026 are orchestras. Rigid seating. Fixed parts. A conductor who controls the tempo. But the work has become jazz. Here's what I mean. For the last two decades, the product team org chart has looked roughly the same. A PM writes the spec. A designer makes the screens. An engineer builds what's been specced. QA tests it. They all meet on Tuesdays to politely disagree about scope, then ship something three weeks late that nobody's fully happy with. This structure made sense when each of these skills took years to develop and couldn't be faked. The PM couldn't prototype because prototyping required code or advanced Figma skills. The designer couldn't query a database. The engineer couldn't run a user interview without accidentally leading every question. But AI just handed everyone a second instrument. The PM can now prototype a working concept in an afternoon. The designer can ship a functional front-end without waiting for engineering. The engineer can synthesize user research, generate test scripts, and explore design alternatives before the designer has even opened their laptop. The boundaries that justified the org chart are dissolving. And most companies are pretending they aren't. The org chart protects roles, not outcomes. I worked with a product team a few years ago where the designer and the PM were in a cold war over who "owned" the product vision. The designer felt it was a design-led question. The PM felt it was a strategy-led question. They each made decks. They each presented to leadership. They each lobbied allies in Slack channels they thought the other didn't know about. (They both knew.) The product, meanwhile, sat in a backlog gathering dust while two smart people argued about whose name went on the thing. That team didn't have a skills problem. It had a territory problem. The org chart had drawn lines, and those lines had become fences, and those fences had become identities. The PM was protecting "PM-ness." The designer was protecting "designer-ness." Neither was protecting the user. This is what org charts actually do in most companies. They don't organize work. They organize ego. They tell people what's theirs and, more importantly, what isn't. And the moment someone crosses a line, even to help, the immune response kicks in. "That's not your lane." "Let's keep the roles clean." "I think we should respect the process." The process. The process is a polite word for "the way we've always done it, and I'd prefer not to think about whether it still makes sense." AI didn't create the problem. It just made it impossible to ignore. The truth is, rigid role boundaries were always a bit of a fiction. The best PMs I've ever worked with could sketch interfaces on a whiteboard that were better than half the wireframes I'd seen from junior designers. The best designers I've known understood business models well enough to challenge the PM's assumptions in ways that made the product sharper. The best engineers I've worked alongside had more user empathy than some researchers I've met. Great product people have always been jazz musicians. They just had to pretend they were in an orchestra because the org chart demanded it. What AI has done is make the pretending harder. When a PM can go from idea to clickable prototype in two hours using AI tools, the old argument of "well, the PM doesn't have the design skills to do that" evaporates. When a designer can write and deploy a simple feature without filing a Jira ticket and waiting three sprints, the old argument of "well, the designer can't build" evaporates too. The walls are coming down. And the people most threatened aren't the ones without skills. They're the ones whose entire identity was built on being the only person in the room who could do a specific thing. That's a hard sentence to sit with. But I think it's the truest one in this piece. The question nobody in leadership is asking. If your PM can prototype, your designer can ship, and your engineer can research, what exactly is the org chart protecting? It's not protecting quality. Quality comes from taste, judgment, and experience, not from job titles. It's not protecting speed. Speed comes from fewer handoffs, not more. It's not protecting the user. The user doesn't care if the person who fixed their problem was a PM, a designer, or an engineer who got curious on a Friday afternoon. What the org chart is protecting is comfort. The comfort of knowing your lane, your title, your territory. The comfort of a Jira board that assigns work to roles instead of to problems. The comfort of never having to say "I don't know how to do that yet, but I could probably learn it by Thursday." I get the appeal. I do. Clarity is comforting. Knowing your job description is comforting. But comfort and speed rarely live in the same room. And right now, the companies that are shipping fastest are the ones where people pick up whatever instrument the song needs, not the one their job title says they play. The org chart isn't going to disappear. I'm not naive enough to believe that. Companies need structure. People need roles. Somebody has to know who approves the budget and who talks to the customer when things go sideways. But the org chart should describe how decisions flow, not how skills are fenced off. It should be a routing system, not a caste system. The jazz band still has a bandleader. Someone still counts off the tempo. They just don't tell the bassist she's not allowed to solo.

Product Teams & Org DynamicsNovember 5, 2025

CAC as the silent killer

The Full Restaurant That Goes Bankrupt There's a restaurant in every city that has a line out the door every Friday night. The food is good. The reviews are strong. The Instagram photos look incredible. And then, fourteen months in, it closes. Not because nobody came. Because too many people came for the wrong price. The owner spent so much on delivery app commissions, influencer dinners, and first-visit discounts that every full table was actually a small loss wearing the costume of a small win. The dining room looked like success. The spreadsheet looked like a funeral. This is how most funded startups die. Not with an empty product. With a full one that costs more to fill than it's worth. The number that kills companies isn't burn rate. It isn't churn. It isn't even revenue. It's CAC, the cost of acquiring a single customer. And the reason it kills so quietly is that nobody wants to look at it while growth is happening. Growth feels like progress. A chart going up and to the right is the most powerful anaesthetic in business. It numbs you to the fact that you're paying four dollars to earn one. I've watched this happen from the inside, more than once, at companies that were not run by amateurs. Growth is not the same as health. At a SaaS company I worked for previously, unit economics weren't a theoretical exercise. They were the daily weather report. When you're competing against giants who have more money, more brand recognition, and more salespeople than you can count, every dollar you spend acquiring a customer has to earn its way back within a window that doesn't bankrupt you while you wait. I remember sitting in a room where someone presented a campaign that had driven a wild spike in trial signups. The room was thrilled. High-fives were emotionally implied, if not physically exchanged. Then someone asked what the conversion-to-paid rate was. The silence that followed was the loudest thing I've ever heard in a meeting. The cost per paying customer was roughly three times what we'd recover in the first year. The campaign was killed that afternoon. But here's what stuck with me: the instinct in the room, for a brief moment, was to celebrate. The signup graph looked beautiful. It took one person asking one uncomfortable question to reveal that the beauty was bankrupting us. Most teams never ask that question. They frame the signup graph, put it in the quarterly deck, and move on to the team offsite. A product with users who cost more to acquire than they'll ever return isn't a product. It's a charity with a login screen. Scale makes the problem worse, not better. There's a comforting myth in startups: "We'll fix unit economics at scale." The idea is that once you're big enough, the cost of acquiring each customer will naturally drop. Sometimes that's true. More often, it's the story founders tell investors while hoping the math sorts itself out by Series C. At a marketplace company I worked with previously, distribution efficiency wasn't a nice metric the finance team tracked on Tuesdays. It was existential. When you're fighting for users on both sides of a marketplace across cities with wildly different economics, the cost to acquire and retain can spiral in ways that don't show up until you zoom out. I watched teams run promotions that looked brilliant at the city level. Great adoption. Strong engagement. But when you pulled back to the regional view and factored in the real subsidy costs, some of those "winning" cities were quietly bleeding out. Scale didn't fix this. Scale photocopied it across more cities. The companies that survived were the ones that asked the uncomfortable question before they expanded, not three quarters after. CAC is a culture problem disguised as a finance problem. This is the part nobody writes about. CAC isn't just a number on a dashboard. It's a mirror of how your entire company thinks about growth. In teams where marketing, product, and finance operate in silos, CAC quietly balloons because nobody owns the full picture. Marketing optimises for leads. Product optimises for activation. Finance shows up three months later with bad news and a spreadsheet that nobody wants to open. I've been in enough of these rooms to recognise the choreography. The marketing lead presents acquisition numbers. The product lead presents engagement numbers. The finance lead presents the burn. And nobody in the room connects the three into one honest story. It's like watching three people describe different parts of the same car crash from different windows. The fix isn't a better dashboard. It's a better question, asked earlier and asked louder: what does this customer cost us, and what will they ever be worth? If the answer to the second question is smaller than the first, nothing else matters. Not your NPS score. Not your feature roadmap. Not your Series B. Not even your Ping-Pong table. The honest math is always unpopular. Every team I've worked with that eventually got unit economics right had one thing in common: someone was willing to be the least popular person in the room. Unpopular enough to kill a campaign that was "working." Unpopular enough to say the new market isn't ready. Unpopular enough to tell the board that the number everyone is celebrating is actually the number that's going to sink them. CAC honesty is career-risk honesty. Telling a founder that their growth is unsustainable is like telling a chef that the restaurant is full but the food is priced wrong. Nobody wants to hear it. The dining room is packed. The music is playing. The waitlist is long. But the spreadsheet doesn't care about the atmosphere. The best product I ever worked on wasn't the one with the most users. It was the one where every user was worth more than it cost to find them. That's a quieter kind of success. It doesn't trend on Twitter. It doesn't get a TechCrunch headline. It doesn't make for a great keynote story. But it does have one thing going for it. The lights are still on.

The Business of ProductsOctober 31, 2025

Recovery is not the opposite of work. it is the condition that makes work worth doing.

In my first startup, I once stayed up for thirty-six hours straight to finish a product specification that, I was certain, could not wait another day. I remember the pride I felt walking into the morning meeting, red-eyed and holding a cold cup of tea, ready to present what I had produced. The specification was eleven pages long. My co-founder read the first three, looked up, and said, very gently, "I think you need to sleep and rewrite this." He was right. The document read like it had been written by someone slowly losing the ability to form complete thoughts. Which, biologically, it had been. But I did not learn the lesson that day. I filed it as a funny story, proof that I was the kind of person who pushed through. It would take another fifteen years to understand what I was actually doing in those thirty-six hours. I was not pushing through. I was producing worse work while feeling more heroic about it. That is a dangerous combination. The ordinary world and the refusal For most of my career, rest was what happened after the work was done. Sleep was what I got when I could. Exercise was something I told myself I would return to once things calmed down. Things never calmed down, of course, which meant recovery was permanently deferred to a future that did not arrive. This was not unusual. It was the standard operating model for anyone building products in startup environments. The people who worked the longest hours got promoted. The people who left at six "did not have the fire." I believed this completely. But I could not see what I was not producing: the ideas I never had because my brain was too fatigued to make connections, the decisions I made poorly because my executive function was running on fumes. The results seemed to confirm my approach. I shipped things. I hit deadlines. But results are not the same as capacity. I was performing at a level I mistook for my best. You cannot measure the work you did not do. The first real signal arrived at Freshworks. I had been running at full intensity for months, managing a product redesign while handling stakeholder alignment across three time zones. Then I made a decision in a meeting that was so clearly wrong that two people immediately pushed back. I had approved a scope expansion that contradicted a constraint I myself had set two weeks earlier. My own notes showed it. But my memory of the conversation had been erased by fatigue. That should have been the wake-up call. But I refused it. I told myself it was a one-off, a bad week. The refusal is always the same story: you acknowledge the symptom and reject the diagnosis. Crossing the threshold What finally changed was not a single moment. It was a pattern I could no longer ignore. I started tracking my decisions against my sleep. Not formally, not with an app. Just a notebook where I recorded hours slept and, at the end of each day, noted whether I had made any decision I later regretted. The correlation was obvious within two weeks. On days when I had slept seven or more hours, my decision regret rate was close to zero. On days below six hours, it was closer to forty per cent. Nearly half my decisions on low-sleep days were ones I would later wish I could take back. The research said the same thing, but in language harder to dismiss. Moderate sleep deprivation produces cognitive impairment equivalent to a blood alcohol level that would make it illegal to drive. But we routinely celebrate people working in that state and call it dedication. The experiments and the ordeal I started with small, specific changes. Sleep became non-negotiable. Seven hours minimum, eight when possible. This meant leaving things unfinished, which felt physically uncomfortable, like walking away from a conversation mid-sentence. But the work I produced after proper sleep was so measurably better that the discomfort faded within a month. Movement came next. Not gym sessions or training programmes. Walking. Thirty minutes before opening a laptop. When I moved from Bangalore to Wayanad, this became easier in ways I had not anticipated. The hills, the quiet, the physical sensation of being in a place that did not vibrate with startup urgency. I started returning from morning walks with ideas I had not been able to produce at a desk. Walking in Wayanad was not exercise. It was a reset for the nervous system. The third experiment was deliberate rest during the working day. Not scrolling through a phone, which is stimulation wearing the costume of rest. Sitting on my balcony for ten minutes with nothing in my hands and nothing in my ears. The first few times, I felt guilty. Guilt is the tax that overwork culture levies on anyone who tries to stop. But the hardest part was not the practices. It was the identity shift. For years, I had been the person who worked through everything. That was not just a habit. It was a story I told about myself, one that other people confirmed and rewarded. Letting go of it felt like admitting weakness. Every founder I have mentored since has described the same friction. The practice of recovery is straightforward. The belief that you deserve it is the ordeal. I call the accumulated cost of ignoring recovery The Performance Debt. Like technical debt, it compounds invisibly. Your decisions get slightly worse. Your creativity narrows. Your patience shortens. Each individual day of under-recovery is survivable. But the compound effect across months degrades the one asset you cannot outsource: your judgment. The Performance Debt is the most expensive debt in a knowledge worker's life. The return I do not want to overstate the transformation. I did not become a different person. But I became a more accurate version of the person I was pretending to be during the years I was not recovering. When I mentor founders now, I talk about recovery the way coaches talk about training cycles. Elite athletes do not train every day at maximum intensity. They periodise: high load, then recovery, then adaptation. The recovery is not the absence of training. It is where the adaptation happens. Cognitive work follows the same pattern. But almost nobody treats it that way. The insight does not arrive during the twelve-hour day. It arrives during the walk, the sleep, the deliberate nothing. Structured Recovery Cycles are not a wellness programme. They are a performance protocol. Sleep, movement, and deliberate rest are direct inputs to the cognitive performance that professional effectiveness requires. But most organisations still reward the person who skips recovery and punish, socially if not formally, the person who protects it. That misalignment is the reason so many talented product people operate at sixty per cent of their capacity while believing they are at a hundred. Recovery is not the absence of work. It is the condition that makes work worth doing. The best work of your life will not come from the night you pushed through. It will come from the morning after you chose to stop. And if that sounds like a small, quiet thought to end on, perhaps that is the point.

Productivity & Working MethodsOctober 1, 2025

Vibe coding makes you faster, not smarter about what to build

The founders building fastest right now are also failing fastest. That sounds like a contradiction. It is not. The tools available today mean a non-technical founder can go from idea to working prototype in a weekend. Sometimes faster. The friction between "I had a thought in the shower" and "here is a functional app" has been compressed to almost nothing. But the result is not a generation of founders shipping great products. The result is a generation of founders shipping three, four, five things in rapid succession, each one solving a problem that does not exist for anyone except the person who built it. Speed without direction is just expensive wandering. The speed trap I have been mentoring a founder over the past few months who is the living embodiment of what I call the speed trap. He is sharp, energetic, has a background in digital marketing, and discovered vibe coding tools around the start of the year. In two months, he built three separate products. A scheduling tool for content creators. A client feedback portal for freelance designers. A habit tracker with a social accountability feature. All three worked. That is the remarkable part. The tools were good enough that each product was genuinely functional. You could sign up, use the features, complete workflows. He had screenshots, demo videos, landing pages. He posted each one on social media and got encouraging replies from friends and fellow founders. But encouragement from friends is not validation from users. But none of them had users. Not real ones. Not the kind who come back the next day without being prompted. He showed the scheduling tool to a dozen content creators, and they all said some version of "nice, but I use Notion for this." The feedback portal got polite interest from exactly zero freelance designers who were willing to pay. The habit tracker competed with roughly four hundred existing apps, and his differentiator was a social feature that nobody asked for. Three products in two months. All functional. All solving problems nobody had. The speed trap is the belief that building faster means learning faster. It does not. Building faster means you can produce more artifacts in less time. But artifacts are not learning. Learning happens when you talk to people, watch them struggle with a real problem, and understand why their current solution is not good enough. That process cannot be compressed by any tool, because it runs on human time. The judgment gap Here is the thing that the vibe coding conversation keeps avoiding: the bottleneck for non-technical founders was never their inability to write code. It was their inability to determine what was worth building. I call this the judgment gap. The gap between having the capacity to build something and having the judgment to know whether that something should exist. Vibe coding closes the execution gap beautifully. It does not close the judgment gap. And the judgment gap is where products die. Product judgment is a strange skill to describe because it does not look like a skill from the outside. It looks like instinct. A founder with strong product judgment can glance at a prototype and say "this is wrong" without being able to fully articulate why. She can listen to a user describe a problem and hear the unspoken constraint behind the stated one. She can look at a roadmap and feel which feature is load-bearing and which is decoration. But product judgment is not instinct. It is pattern recognition, built from years of watching products succeed and fail, years of sitting with users and noticing the gap between what they say and what they do. It is the kind of knowledge that accumulates slowly and cannot be prompted into existence. No AI tool has a shortcut for twenty years of watching people use things. Giving a nervous driver a faster car does not improve their judgment at intersections. It just means they arrive at the wrong turn sooner. What the tools actually accelerate I have been using AI tools in my own work from Wayanad for the better part of a year now. The honest answer about what they accelerate is more specific than the hype suggests. They accelerate the parts of my work that were already strong. Execution. Prototyping. Turning a clear idea into a tangible thing I can test. When I know what I am building and why, the tools are extraordinary. I can produce in an afternoon what used to take a week. But that speed only matters when the direction is right. The constraint of implementation has genuinely dissolved. But the tools do absolutely nothing for the parts that require two decades of pattern recognition. Knowing which problem to solve. Knowing when a solution is wrong even though it looks right. Recognising the moment when user feedback is pointing toward a surface complaint when the real issue is structural. Sensing that a product direction feels promising in a demo but will collapse under the weight of real usage patterns. Those judgments have not gotten faster. They still take the same amount of thinking, the same amount of sitting with uncertainty, the same amount of being wrong before being right. The speed trap catches founders who confuse building speed with thinking speed. My mentee with three products in two months was building at an extraordinary pace. But his thinking was still at the pace of someone who had never shipped a product to real users. The tools accelerated his output. They did not accelerate his understanding. The uncomfortable prescription The advice that nobody in the vibe coding discourse wants to hear is this: before you open Cursor, before you write your first prompt, before you touch any tool at all, you should spend at least two weeks doing nothing but talking to the people you think you are building for. Not showing them prototypes. Not pitching them on your vision. Talking. Listening. Watching how they currently solve the problem you think you have identified. Asking what is painful and then sitting with the answer long enough to understand whether it is a real pain or a polite complaint. Two weeks of conversations will not feel productive. There is nothing to screenshot. Nothing to post on social media. No demo to share. But those two weeks will do something that no vibe coding tool can do. They will tell you whether the thing you are about to build should exist. The judgment gap is not something you close with faster tools. You close it with slower, more deliberate thinking about what the problem actually is, who actually has it, and why they would choose your solution over the thing they are already doing. That thinking is the hard part. It was always the hard part. But it will remain the hard part long after the tools have gotten ten times faster than they are today. But here is the quiet truth underneath all of this. The founders who have strong product judgment and access to vibe coding tools are building remarkable things at remarkable speed. The tools are not the problem. The sequence is the problem. Judgment first, then speed. Not the reverse. The speed trap is not a failure of tools. It is a failure of sequence. And the sequence, unglamorous as it sounds, starts with the people you are building for, not the tool you are building with.

Building & FoundingSeptember 30, 2025

Psychological safety as a shipping variable, not a culture initiative

I once sat in a product review at a SaaS company in Bangalore and watched a team present a feature that I knew, with near certainty, was solving the wrong problem. The research did not support it. The usage data pointed somewhere else entirely. But the feature was the VP's idea, and the VP was in the room, and nobody, including me, said a word. We nodded. We offered minor suggestions about button placement and copy. We talked about everything except the one thing that mattered. That feature shipped six weeks later. It took four months to admit it had failed. I have thought a lot about what that silence cost. Not in abstract cultural terms. In weeks. In engineering hours. In customer trust that took a quarter to rebuild. The silence had a price, and the price was measurable. But it never appeared on any status report or sprint retro because it was the kind of cost that teams absorb without naming. The fear tax There is a phrase circling product leadership conversations: psychological safety. It usually shows up in the context of HR programmes, team health surveys, and culture decks. Slides with stock photos of diverse teams laughing in a well-lit conference room. The framing positions it as something warm and aspirational. A nice thing to have. A values initiative. But that framing is wrong. Psychological safety is not a culture initiative. It is an operational variable. It determines how fast your team can ship, how many bad decisions compound in silence, and how much rework you absorb because someone was too afraid to say the obvious thing at the obvious time. Fear is the most expensive line item that never appears on any team's budget. I call it the fear tax. Every team pays it. Most teams do not know how much. What Boeing taught me about silence At Boeing, I worked on aviation fleet management tools. The aviation industry has a specific relationship with speaking up, because it is not theoretical. In aviation, a culture of speaking up exists because the alternative is catastrophic. A maintenance engineer who notices an anomaly and stays quiet because the senior engineer seems confident is not being respectful. That engineer is creating operational risk. The entire safety reporting infrastructure in aviation is built on the principle that hierarchy cannot override information. But here is what struck me. The systems that enable speaking up in aviation are not motivational. Nobody gives a TED talk about psychological safety at an airline maintenance facility. The systems are structural. There are anonymous reporting channels. There are mandatory pre-flight checklists where every team member has an explicit role to flag concerns. There is a culture where challenging a senior colleague's assessment is not brave. It is expected. The structures remove the personal cost of speaking up so that the information can flow. Product teams do not have this. In most product teams I have worked with, the cost of challenging a senior person's idea is entirely personal. You weigh the insight against the relationship. And most of the time, you stay quiet. Not because you are weak. Because the system has made speaking up expensive and staying quiet free. That is a structural problem, not a character problem. The silence cost at Freshworks At Freshworks, I watched the fear tax play out in a way that still makes me wince. We were building a feature for an enterprise onboarding flow, and a junior designer on the team noticed a critical usability flaw during the prototype phase. The flow required users to complete seven steps before seeing any value. The designer knew, from the research she had done two months earlier, that users typically dropped off after step three. But the feature was the VP of Product's priority. He had championed it in the leadership meeting. His name was on the quarterly plan. She said nothing. The feature shipped. Customer complaints started arriving within two weeks. Support tickets spiked. The team spent a full quarter reworking the flow, stripping it back to three steps, essentially building what the junior designer had known was right before the original version shipped. The silence cost was not abstract. It was a quarter of engineering and design time. It was the morale hit to the designer herself, who watched her instinct proven right at exactly the pace that made it feel worst. But here is the thing that bothered me more than the wasted quarter. The VP was not a bad leader. He would have listened if she had raised it. Probably. But "probably" is the problem. She could not be sure, and she could not afford to be wrong about the social dynamics. The fear tax is not about whether leaders are actually punitive. It is about whether the team believes they might be. Perception is the operating variable, not intent. The operating theatre test There is a useful parallel outside the product world. In operating theatres, surgical checklists exist because a nurse who notices the surgeon is about to cut on the wrong side needs a structural mechanism to speak up. Without it, the nurse is weighing her observation against the surgeon's authority, her career risk against the patient's safety. That is not a culture problem. That is an operational failure. The checklist removes the personal cost and creates a moment where challenge is expected, not tolerated. Product teams need the equivalent. Not a culture poster. Not a Slack channel called "psychological-safety." (I have seen both, and neither works.) A structural mechanism where disagreement is a step in the process, not an interruption of it. The best teams I have worked with did this in small, boring ways. A standing question in every product review: "What is the strongest argument against shipping this?" Asked with silence afterward, long enough to be uncomfortable. A pre-mortem before every major launch: "It is six months from now and this has failed. Why?" A rule that the most junior person speaks first on design critiques, before seniority anchors the conversation. None of these are warm. None of them feel like a culture initiative. But that is the point. Psychological safety that depends on the leader's personality is fragile. Psychological safety that is built into how the team operates survives a bad day, a tense quarter, a leadership change. The cost nobody budgets for The fear tax compounds. A junior designer stays quiet once. She stays quiet again. An engineer who was overruled dismissively stops raising concerns. A product manager who flagged a strategic risk and was told to focus on shipping learns to focus on shipping. Each individual moment is small. But the compound effect is a team that only surfaces information the leadership already agrees with. I have seen this in enough organisations to recognise the symptoms. When every product review ends with agreement, something is wrong. When nobody pushes back on the quarterly priorities, somebody is afraid. When the only feedback that surfaces is the feedback that confirms what was already decided, the silence cost is running and nobody is counting it. The teams that ship well are not the ones where everyone gets along. They are the ones where disagreement is cheap and silence is expensive. That inversion does not happen because someone gave a talk about trust. It happens because someone redesigned the process so that the information flows regardless of who holds the title. Fear is a tax on shipping. You can pay it in silence, or you can redesign the system so it stops accruing. But you cannot motivate your way out of a structural problem, no matter how many offsites you run.

Product Teams & Org DynamicsSeptember 29, 2025

AI trust is contextual, not categorical

The same person who lets an AI suggest their driving route will refuse to let an AI recommend where to invest their money. The same product manager who uses an AI writing assistant without a second thought will demand to review every word of an AI-generated customer communication before it goes out. The same hiring manager who happily delegates resume screening to an algorithm will physically recoil at the suggestion that the algorithm should pick which candidates get interviews. This is not inconsistency. This is rationality. And it breaks most of the assumptions product teams are currently building on. The binary assumption But there is a comfortable fiction in product development right now: that users either trust AI or they do not. That trust is a disposition, a setting, something you measure once with a survey and then design for across your entire product. Teams build a single onboarding experience to "establish trust in AI." They run research asking users how comfortable they are with artificial intelligence. They get a number. They treat it as a constant. But trust in AI is not a constant. It is a variable that shifts with every feature, every decision, every moment where the stakes change. I watched this play out at Grab in the most vivid way I have encountered in my career. The Grab problem At Grab, we had AI running across multiple features in the same application. Route optimisation used AI to suggest the fastest path to a destination. Payment features used AI for fraud detection and transaction recommendations. Same users. Same app. Same underlying technology branded the same way. But users trusted the route suggestions without hesitation. A wrong route costs you ten minutes. You can see the mistake happening in real time. You can override it. The stakes are low, the error is visible, and the decision is reversible. Every condition for easy trust is met. But payment decisions were a different world entirely. When AI flagged a transaction or recommended a payment method, users pushed back. They wanted to see why. They wanted to override. They wanted a human involved. A wrong payment decision could cost real money, could lock an account, could create a problem that took days to resolve. The stakes were high, the error was invisible until it was too late, and the decision felt irreversible. Same users. Same day. Completely different trust. The team initially designed a single "trust in AI" onboarding flow. One set of explanations about how the AI worked, applied uniformly across the product. But it had almost no effect. Not because the explanations were poor. Because explaining AI in general does not address the user's actual concern, which is always specific: what happens if this particular decision is wrong, and can I fix it? That is when the pattern became clear. I call it the trust gradient. Trust in AI is not a single line on a graph. It is a spectrum, and the position on that spectrum shifts at every point where the stakes change. The question a user is really asking, whether they articulate it or not, is simple: what do I lose if this is wrong, and how easily can I get it back? The stakes test I have been advising a product team building an AI-powered hiring tool, and they hit the same wall from a completely different direction. Hiring managers loved the AI for resume screening. Sorting through three hundred applications to surface the top fifty? Brilliant. Let the machine do it. The stakes of a screening error are low: a good candidate might get filtered out, but the hiring manager never sees what they missed, and the process moves forward regardless. The cost of a mistake is invisible, which makes it psychologically cheap. But when the team proposed that the AI should generate a shortlist of candidates for interviews, the reaction was immediate and visceral. Hiring managers refused. But not because they thought the AI would do a poor job. Because putting a candidate in front of a hiring panel is a high-stakes decision that affects a real person's career. If the AI includes someone who is a poor fit, that is a wasted interview. If it excludes someone who is a strong fit, that is a missed hire. And the person making the recommendation (or in this case, the algorithm) is visible and accountable in a way it was not during the anonymous screening phase. The team had to build completely different trust mechanisms for different stages of the same workflow. For screening, they could run AI quietly in the background with minimal explanation. Users were comfortable. For shortlisting, they had to show the AI's reasoning, allow human overrides at every step, and frame the output as a suggestion rather than a decision. Two stages of the same process. Two entirely different trust architectures. The cost of treating them as one was a product that nobody would use past the screening stage. Altitude and landing There is a useful way to think about this. Pilots trust autopilot at cruising altitude. The plane is stable, conditions are predictable, corrections are small, and the pilot can take over at any time. But during landing, when the margin for error shrinks, when the consequences of a mistake are irreversible, when environmental variables multiply, most pilots want their hands on the controls. Same system. Same plane. Same pilot. Different stakes. Trust is not a setting you switch on. It is a gradient you earn at every point of risk. Product teams building AI features need something I have started calling the stakes test. Before designing the trust layer for any AI-powered feature, ask three questions. What does the user lose if the AI is wrong? How quickly can they detect the error? And how easily can they reverse it? If the loss is small, the error is visible, and the reversal is easy, trust comes cheaply. If the loss is large, the error is hidden, and the reversal is difficult or impossible, trust must be earned with transparency, control, and the visible option to override. But most teams do not segment their trust design this way. They build one explanation for how the AI works. One onboarding flow. One level of transparency applied uniformly. And then they wonder why users happily adopt some AI features and refuse to touch others within the same product. But the answer is not that some users trust AI and some do not. The answer is that the same user trusts AI differently depending on what they stand to lose. Every feature has its own trust equation. The teams that understand this build for the gradient. The teams that do not build for a fictional user who either trusts everything or trusts nothing, and that user does not exist. What trust actually looks like I have spent twenty years watching people interact with products they did not fully understand. From oil rig operators using interfaces designed by people who had never been on a rig, to enterprise buyers evaluating software they would never personally use. Trust, in every case, was not a general feeling. It was a series of specific moments where the product either earned confidence or lost it. But AI does not change that. It just makes the moments more frequent and the stakes more varied within a single product. The team that gets this right is not the one with the best AI model. It is the one that understood, feature by feature, decision by decision, what the user was risking, and built the right amount of trust for that specific risk. Trust is always specific. The products that remember this are the ones people keep using.

User & Buyer PsychologySeptember 20, 2025

The PM who can prototype has a different career ceiling than the one who cannot

The product managers with the most influence in their organisations right now are not always the best strategists. They are not always the best communicators, either. They are the ones who can show instead of tell. This sounds like a minor distinction, something you might nod at and then forget. But it is not minor. It is the difference between a PM who asks for permission and a PM who creates conviction. The Three-Week Meeting Problem At Freshworks, I watched a debate about a feature direction drag on for three weeks. Three weeks of meetings, Slack threads, and documents that got longer without getting clearer. The engineering team had one opinion. The design team had another. The commercial team had a third. Nobody could agree because each person was imagining a slightly different version of the same words. Then a PM on the team did something unusual. She went home on a Thursday evening, opened a prototyping tool, and built a clickable version of her proposed solution. Not a polished product. Not something you would show a customer. A rough, ugly, obviously incomplete prototype that you could tap through and feel. She brought it to the Friday meeting. The debate ended in forty minutes. People stopped arguing about abstract descriptions and started reacting to a concrete thing. They could point at a screen and say "this part works, but this transition is confusing." The prototype did what three weeks of documents and discussions could not. It collapsed the gap between imagination and reality. A prototype resolves in minutes what a document debates for weeks. I have thought about that moment many times since. It was not really about the prototype itself. It was about the type of conversation it enabled. When you describe an idea, people respond with opinions. When you demonstrate an idea, people respond with reactions. Opinions are abstract and endless. Reactions are specific and convergent. The Show-Don't-Tell Advantage This is what I call the show-don't-tell advantage, and it is not a nice-to-have skill any more. It is a career accelerant. For decades, the PM role has been defined by the ability to describe. Write the spec. Draft the brief. Create the requirements document. Present the strategy deck. The PM was the person who articulated what needed to be built, and then someone else built it. The gap between the articulation and the artifact was filled by other people's interpretation. But interpretation is where things go wrong. Every PM has had the experience of writing a spec they believed was crystal clear, and then seeing the first build come back looking nothing like what they intended. Not because the engineer was incompetent. But because words are a lossy compression format for product ideas. They carry the shape but lose the texture. You write "a simple onboarding flow" and the engineer builds something that is technically simple. But simple to an engineer and simple to a first-time user are rarely the same thing. The PM who can prototype skips this translation loss entirely. She does not describe the onboarding flow. She builds a version you can tap through. The room stops debating what "simple" means and starts debating whether this specific flow feels right. That is a fundamentally better conversation. The Prototype Premium Something interesting is happening right now with AI coding tools. They have made basic prototyping accessible to people who cannot write production code. You do not need to be an engineer. You need to be specific about what you want, and willing to iterate. I mentor a junior PM who figured this out faster than most of her peers. She uses AI coding tools not to build production features, but to build rough working prototypes of her proposals before presenting them. While her colleagues walk into review meetings with slides and spec documents, she walks in with something the room can interact with. Her ideas get approved at roughly twice the rate of her peers. But it is not because her ideas are twice as good. It is because her stakeholders can interact with the concept instead of imagining it from a document. The prototype premium is real: the same idea, presented as a working prototype rather than a written description, is perceived as more credible and more ready for investment. This is not rational. But humans trust what they can touch more than what they can read. The gap between the PM who describes and the PM who demonstrates is the gap between permission and conviction. I realise this might sound like I am arguing that every PM needs to learn to code. I am not. A PM with no engineering background can now produce a functional prototype using AI tools and no-code platforms in an afternoon. The barrier is no longer technical skill. The barrier is willingness. Most PMs have spent their careers building the muscle of description: writing better specs, crafting sharper briefs, creating more persuasive decks. The muscle of demonstration is underdeveloped because it was, until recently, someone else's job. But it is not someone else's job any more. The Career Ceiling Is Real Here is where this stops being about a nice skill and starts being about career trajectory. The PM who can prototype holds a fundamentally different position in her organisation than the one who cannot. She can test an idea before committing engineering resources. She can resolve alignment debates by building rather than arguing. But more importantly, she is perceived differently. Senior leaders trust the PM who shows up with a prototype in a way they do not trust the PM who shows up with a document. Not because the prototype is better evidence. But because building one demonstrates conviction and ownership that a document does not. The PM who prototypes has skin in the game. The PM who writes a spec is, in some sense, asking someone else to take the risk of building. This perception gap compounds over time. The prototyping PM gets more ambitious projects and builds credibility faster. The spec-writing PM, equally talented, advances more slowly because her ideas always require an additional step of translation before they become real. It is not a talent gap. It is a demonstration gap. I have seen this at every company I have worked at. At Boeing, the people who could make ideas tangible commanded rooms differently than those who could only describe ideas eloquently. At Schneider Electric, the IoT thermostat work moved fastest when someone put a working interaction in front of the team rather than explaining how it should feel. Showing beats telling, every time. The Skill That Is No Longer Optional The product management profession has always been about bridging gaps. Between users and engineers. Between business goals and technical constraints. But there is one more gap that most PMs have never been asked to bridge: the gap between idea and artifact. The PMs who bridge it are playing a different game. And increasingly, they are winning it. The tools are available. The learning curve is measured in weeks, not years. The only question left is whether you are willing to stop describing what you want and start showing it. Not because describing is wrong. But because showing changes the room in ways that describing never will. Some skills are career enhancers. Prototyping, for a PM, is becoming something closer to a career requirement. Not because anyone will put it in a job description. But because the PM who can do it will always be standing in a slightly different place than the one who cannot. That difference in position, small at first, is the kind that determines where you end up.

Product Leadership & CareerSeptember 18, 2025

The Market bifurcated between vertical specialists with proprietary Data and horizontal tools heading toward zero

The products doing the most sophisticated work with AI right now are, paradoxically, the least threatened by it. And the simplest, friendliest, most user-loved tools on the market are the most exposed. That inversion tells you nearly everything you need to know about where software value is heading. For years, the spectrum from horizontal to vertical was a smooth gradient. A CRM sat at one end. A fleet maintenance system for a specific aircraft type sat at the other. Everything in between occupied some point on the continuum, and the conventional wisdom was that horizontal tools had the larger addressable market while vertical tools had stickier customers. Both could prosper. Both had defensible positions. That continuum just snapped in half. The Data Moat AI did not create a new kind of competition. It created a new kind of test. The test is simple: can your product's core value be replicated by an AI agent that has access to a general-purpose language model and an API? If the answer is yes, your product is now competing against a marginal cost that approaches zero. If the answer is no, you may be more defensible than you were before AI arrived. But most founders have not yet asked themselves which side of that test they sit on. The products most likely to survive are the ones AI cannot replace because AI does not have their data. At Boeing, I worked on products embedded in aviation maintenance workflows. These were not elegant consumer experiences. The interfaces were dense, technical, built for specialists who understood regulatory frameworks, fleet-specific maintenance histories, and safety-critical decision trees. The data inside those systems was accumulated over years of operation, tied to specific aircraft, specific routes, specific regulatory jurisdictions. No general-purpose AI model could replicate it because the data did not exist anywhere else. It lived inside the product, generated by the product's use, and was inseparable from the domain it served. I remember a conversation with a maintenance engineer at a customer site who described their system as "ugly but irreplaceable." He was not being sentimental. He was being precise. The system's value was not in how it looked or how it felt to use. It was in what it knew. Decades of fleet-specific maintenance records, regulatory compliance histories, failure pattern data. An AI agent could be trained to understand aviation maintenance in general. But it could not replicate the specific data that this system had accumulated for this airline's specific fleet. That is the data moat. Not a theoretical concept. A structural reality. The products with proprietary, domain-specific data generated through years of customer operations are becoming more defensible, not less, as AI capabilities expand. AI needs data to be useful. But the data these systems hold is precisely the data AI does not have. The Interface Vulnerability But the other side of the split is brutal. Products whose primary value lies in providing a well-designed interface for tasks that AI can now perform directly through an API are facing an existential question. Not a competitive question. An existential one. At Freshworks, I saw this positioning from the inside. The CRM competed heavily on user experience. Ease of onboarding. Clean interface. Intuitive workflows. Those qualities won deals. Sales teams would demo the product next to clunkier enterprise competitors and the reaction was immediate: this feels better. That feeling translated into purchase decisions, especially at the SMB and mid-market level where buyers had less patience for complex deployments. But the interface was the product's moat. Not its data. The customer data lived in the customer's own account, portable, exportable, not structurally unique. What made the product sticky was that people liked using it. When switching costs were high and moving to a competitor meant retraining an entire team, that liking was worth a great deal. But what happens when an AI agent can interact with any CRM through an API, performing the same tasks a human sales rep performed, without ever seeing the interface? When AI can operate any interface via API, the value of the interface converges toward zero. That is the interface vulnerability. The very quality that made horizontal tools popular, their ease of use for human operators, becomes irrelevant when the operator is not human. An AI agent does not prefer one CRM's interface over another. It does not experience frustration with a clunky workflow. It interacts through APIs, and at the API level, most CRMs look functionally identical. The Split in Practice The bifurcation is not theoretical. It is visible in real numbers. Products deeply embedded in deterministic, high-stakes workflows are holding their valuations. But products providing a UI layer for tasks that AI can perform via API are seeing their multiples compress. The market is pricing the split before most product teams have acknowledged it exists. I have watched this play out from both sides of the divide. At Boeing, nobody was worried about AI replacing the maintenance management platform. The suggestion would have been absurd. But absurd is not the same as irrelevant. It was absurd specifically because the regulatory context made it impossible. Every maintenance action on a commercial aircraft is governed by regulatory requirements so specific that a general-purpose AI, no matter how capable, cannot make the decisions those systems support without the domain data those systems contain. But at Freshworks, the conversation would have been different. A CRM that wins on interface quality is a CRM that loses when the interface stops mattering. And the interface stops mattering precisely when the entity using it does not experience interfaces the way humans do. Nobody at Freshworks was having that conversation when I was there. The per-seat model was growing. The product was winning deals on user experience. But the foundation of that competitive advantage, the assumption that a human would always be the one interacting with the software, was never examined. Because it did not need to be. Until now. Where the Value Lives It is not about being vertical or horizontal in the traditional sense. It is about whether your product contains something that AI cannot access from the outside. Proprietary data. Regulatory context. Domain-specific intelligence generated through years of customer operations. Those are the moats that hold. But they are moats you cannot build in a hurry. The interface vulnerability does not mean that all horizontal tools will disappear. Some will adapt. Some will find new sources of value beyond the interface layer, perhaps by becoming the data layer themselves, or by embedding so deeply into customer workflows that the switching cost becomes structural rather than experiential. But the ones that remain primarily an interface for tasks AI can perform directly are on a trajectory that the market has already begun to price. The data moat is not a strategy you can adopt in a quarter. It is the result of years of operating in a domain, accumulating knowledge that exists nowhere else, building products so deeply embedded in specific workflows that removing them would mean losing the data itself. That is what defensibility looks like when capability is no longer scarce. Some products were always going to survive this shift. They just did not know it yet, because the quality that made them resilient, their depth rather than their breadth, was the same quality that made them unfashionable during the years when growth meant going horizontal.

Markets & Industry DynamicsAugust 23, 2025

Cloud costs vs revenue: The profitability gap in AI products

The most dangerous thing that can happen to an AI product is that people actually use it. That sounds wrong. It is not. In most software businesses, more users means more revenue, and marginal costs stay flat or decline. A SaaS product serving ten thousand users costs roughly the same to run as one serving five thousand, give or take a few database queries. But AI products do not work that way. Every inference call, every model query, every generated response costs real money. More users means more cost. Proportionally. Sometimes more than proportionally. And yet the pricing models most teams are using were designed for a world where marginal costs were negligible. That is the gap. And it is widening. The usage penalty I spent a few months earlier this year advising a team building an AI-powered document analysis tool. Smart people. Good product instincts. They had built something genuinely useful: upload a contract, get a structured summary with risk flags in under a minute. Users loved it. But we tracked inference costs per API call with an obsessiveness that bordered on paranoia. Every query to the model, every token processed, every response generated had a price tag. We built a spreadsheet that modelled costs at a thousand users, ten thousand, a hundred thousand. The maths did not work. At their current pricing (a flat monthly subscription of forty dollars per seat), every heavy user was costing more to serve than they were paying. The light users subsidised the heavy ones, but the heaviest users were growing fastest. Which is exactly what you want in a product. Except it was also exactly what would destroy the margin. The team had a term for it. They called it the usage penalty. The better your product performs, the more people use it. The more people use it, the more it costs. But revenue stays flat because the pricing model was built for a world where serving one more user cost almost nothing. This is not a new problem in the abstract. Telecoms dealt with something similar decades ago: bandwidth costs scaled with usage while customers expected flat-rate plans. But the AI version is sharper, because inference costs are not just high. They are unpredictable. A simple query might cost a fraction of a penny. A complex one might cost fifty times that. And you often cannot tell which it will be until the model has already processed it. A bakery that loses money on every loaf Think about a bakery. Every loaf of bread requires flour, energy, labour. If the bakery sells more bread, it buys more flour. That is obvious. Nobody expects a bakery to absorb unlimited flour costs while charging the same price per loaf. But that is precisely what most AI product pricing does. It says: pay us a fixed monthly fee, and use the product as much as you want. The team absorbs the flour costs. For light users, the margin works. For heavy users, every additional loaf is a loss. The bakery analogy breaks down in one important way, though. A baker knows roughly how much flour each loaf needs. An AI product team often does not know how much inference a given user session will consume until it has already been consumed. It is like running a bakery where some customers order a baguette and others order a seven-tier wedding cake, and you have to serve both at the same price. You would go broke. That is what is happening. The profitability inversion I saw a version of this at Freshworks, years before AI costs were part of the conversation. As the product grew and moved from small-team customers into larger deployments, infrastructure costs scaled in ways nobody had modelled accurately. The assumption had been that costs would grow linearly. They did not. Growth brought complexity: heavier usage patterns, more data, higher support load, bigger compute requirements. Revenue grew. But costs grew faster than anyone had predicted during the early, scrappy phase. The team adjusted. Pricing changed. Architecture changed. But the lesson stuck with me: the economics that work at a thousand users often break at a hundred thousand, and the break is not gentle. It is sudden. You cross a threshold and the model inverts. Revenue is still growing, and somehow profitability is shrinking. I have come to think of it as the profitability inversion, and it is one of the least discussed structural risks in product. With AI products, the profitability inversion arrives earlier and hits harder. Traditional SaaS had the luxury of relatively flat marginal costs, so the inversion usually showed up at extreme scale. AI products can hit it within the first year. Sometimes within the first quarter after launch. Success is the thing that breaks the model, which is a sentence I never expected to write about a product doing well. What the spreadsheet misses Most teams model AI costs as a line item. They estimate average inference cost per query, multiply by projected usage, and compare against projected revenue. The spreadsheet looks manageable. But the spreadsheet misses three things. First, usage is not average. Power users consume disproportionately. And power users are often the ones you most want to keep, because they are the ones who tell other people about the product. Penalising them with usage caps or throttling feels like punishing your best customers for liking you too much. Second, model costs change. Sometimes they drop (which is great). Sometimes the product team wants to upgrade to a more capable model, and costs jump. The roadmap and the cost model are in tension, and the cost model usually loses because nobody wants to ship a worse product to save on inference. Third, the competitive pressure is real. If your competitor offers a similar product at a flat rate and absorbs the cost (funded by venture capital or cross-subsidised by another business line), you are in a pricing war where the floor is set by someone who is willing to lose money longer than you are. That is not a product problem. That is a survival problem. The uncomfortable question There is no clean answer here. Usage-based pricing feels fair but alienates users who want predictability. Flat pricing feels friendly but breaks at scale. Tiered models split the difference but create complexity that small teams struggle to manage. I have watched three teams wrestle with this in the past six months alone. The ones making progress share a common trait: they treat pricing as a product problem, not a finance problem. They test pricing the way they test features. They instrument cost per session with the same rigour they apply to conversion funnels. They accept that the pricing model will change multiple times in the first two years, and they build for that flexibility instead of locking in a structure too early. Nobody has solved this yet. The teams that will figure it out are the ones honest enough to look at their own spreadsheets and say: this does not work at scale. And then redesign before scale arrives, not after. That takes a specific kind of courage. The kind where you look at a product people love, with metrics going in the right direction, and admit that the economics underneath are quietly rotting. Most teams wait until the rot is visible. By then, the options are worse. The best time to fix the model is when everything looks fine. That is also when it is hardest to convince anyone it needs fixing.

The Business of ProductsAugust 16, 2025

AI solved the wrong bottleneck

In the summer of 2018, a restaurant in Bangalore installed a kitchen automation system that could plate dishes in half the time of a human line cook. The owner was thrilled. Throughput doubled. Orders left the kitchen faster than ever. But the reviews got worse. Not immediately. Over a few weeks. Diners started describing the food as "fine" and "nothing special," which in restaurant terms is a death sentence delivered politely. The problem was not the plating speed. The chef had started skipping the tasting step. With the machine handling output so quickly, there was pressure to keep the pipeline fed, and the contemplative moment where the chef adjusted the seasoning got compressed, then eliminated. The kitchen was producing food faster. But nobody was thinking about whether the food was good. I keep returning to that story because it is the most precise analogy I have found for what is happening in product teams right now. Why: the constraint was never production Here is the uncomfortable truth that the AI productivity conversation has been sidestepping for eighteen months. The quality constraint in product work has never been the speed of producing outputs. It has always been the quality of thinking that precedes those outputs. A product brief that takes three hours to write is not slow because writing is slow. It is slow because thinking takes time. The PM has to sit with the problem, identify the real constraint, consider second-order effects, test assumptions against what they know about the customer, and arrive at a position they can defend. The writing is just the last step. But it is the step that AI has accelerated. AI solved the wrong bottleneck. Production was never the constraint. Thinking was. I tested this on myself earlier this year and the results were clarifying in a way I did not enjoy. I used an AI tool to generate a product strategy document for a side project. The output arrived in ninety seconds. It was well-structured, clearly written, and entirely reasonable. But when I sat with it for an hour, I realised I disagreed with the core framing, and I only discovered my disagreement because I forced myself to read the document slowly and interrogate each assumption. The AI had produced a plausible strategy. But it was not my strategy. It had not emerged from my thinking. It had replaced my thinking. The document looked like a decision. But no decision had been made. How: speed without thought produces volume without value The pattern I have been watching across product teams in 2025 is what I have started calling the production illusion: the appearance of high output masking a decline in thinking quality. Teams are producing more documents, more briefs, more specs, more decks. The volume is up. But the thinking density per document is down. At Schneider Electric, years before AI tools existed, I saw a version of this same pattern created by a different cause. The product team had implemented a new documentation template that made it faster to produce specs. The template had pre-filled sections, standard language, and dropdown menus for common choices. Output tripled. But the specs started converging toward a mean. Every document looked professional. None of them contained a genuinely original insight about the customer problem. The template had made it easier to produce specs without making it necessary to think through them. The tool had optimised the wrong step. That is exactly what AI is doing now, at far greater scale. I mentor junior PMs, and I have started noticing a specific tell. The ones using AI to generate first drafts produce documents that are smoother, better organised, and more polished than anything I wrote at their career stage. But when I ask them to explain the reasoning behind a particular decision in their brief, there is a pause. Not the pause of someone organising their thoughts. The pause of someone encountering a question about something they have not actually thought through. The document has an answer. But the person who produced it does not. That is the production illusion at work. What: separating thinking from production The practice gaining traction among senior product people I speak with is deceptively simple. Separate the thinking phase from the production phase, and use AI only in the second. The thinking phase is the messy part. It is the hour you spend staring at a whiteboard, the twenty minutes of writing and deleting the same paragraph, the conversation with a colleague where you realise your original framing was wrong. This phase produces no visible output. It looks unproductive. It is the phase where actual product decisions get made. The production phase is everything that follows: structuring the document, drafting the prose, formatting the deck, generating the diagrams. This is where AI genuinely helps. It can turn rough thinking into polished output faster than any human. But it cannot do the rough thinking for you. Or rather, it can produce something that looks like rough thinking. The appearance of thought is not thought. I have been calling this the thinking phase, which sounds almost redundant when you say it out loud. Of course there is a thinking phase. But the point of naming it is that it is the phase most at risk of being skipped, precisely because AI makes the next phase so fast that the gap between "I have not thought this through" and "I have a finished document" has nearly disappeared. At Nike, I once watched a design lead present a concept that was visually stunning and strategically incoherent. Someone in the room asked how long she had spent on it. "About two days," she said. A colleague leaned over to me and whispered, "I think she spent two days on the pixels and about ten minutes on the problem." That dynamic existed long before AI. But AI has made it possible to compress those two days into two hours while still spending only ten minutes on the problem. The ratio has got worse, not better. The honest accounting I am not arguing against AI tools. I use them daily. They have made specific parts of my work genuinely faster, and I would not go back. But I have also learned where they help and where they deceive, and the distinction is not complicated. AI helps when you have already done the thinking and need to produce the output. It deceives when you have not done the thinking and it produces the output anyway. The output looks the same in both cases. The product decisions embedded in one have been earned, and the product decisions embedded in the other have been fabricated by a language model that has no stake in whether they are right. The teams I see struggling most right now are not the ones avoiding AI. They are the ones using it before they have earned their own clarity. They prompt an AI tool with a vague sense of the problem and receive a crisp-sounding document, and the crispness of the output persuades them that the thinking has been done. But it has not. The thinking was skipped. The production just happened to look good. The product teams doing their best work in 2025 are the ones who have learned to sit with the discomfort of the thinking phase. They stare at blank pages. They write bad first paragraphs. They argue with colleagues about framing. They do the slow, unglamorous work of figuring out what they actually believe before they ask a machine to articulate it beautifully. Speed is a gift when you know where you are going. When you do not, it just gets you to the wrong place faster.

Productivity & Working MethodsAugust 1, 2025

The Mentorship Deficit: Who trains the next generation when entry level hiring has stopped?

I was, by any reasonable measure, a terrible product person in my first year. I did not know how to write a requirements document. I could not read a P&L statement. I once presented a feature roadmap to a room of petroleum engineers that was so disconnected from their reality, one of them asked if I had ever seen an oil rig. I had not. But I had Rajan. Rajan was a senior product lead at the petroleum company who had no formal obligation to teach me anything. He was not my manager. There was no mentorship programme on a slide deck somewhere. He simply decided, for reasons I still do not fully understand, that he would invest his time in making me less useless. He dragged me to offshore platform visits. He made me sit with rig operators for entire shifts, watching them interact with the monitoring software we were supposedly building for them. He would review my product specs line by line, not to correct the formatting, but to challenge the thinking behind every decision. That mentorship was informal, unpaid, and more valuable than every formal training programme I have attended since. Combined. The Margins Have Been Eliminated Here is the thing about mentorship that nobody wants to admit: it was always a side effect. Nobody is hired to mentor. That is the problem. Mentorship happens in the margins, and the margins have been eliminated. When companies stopped hiring junior product managers, they did not just remove entry-level roles from their headcount. They removed the conditions under which mentorship naturally occurs. A senior PM with two junior reports teaches them things, not because it is in their OKRs, but because it is faster than watching them fail. But a senior PM surrounded entirely by other senior PMs has no reason to teach anyone anything. Everyone is supposed to already know. The mentorship deficit is not a training problem. It is a structural one. I advise a B2B startup where the entire product team consists of senior external hires. Every PM has eight to twelve years of experience. On paper, it is a dream team. In practice, it is a team of strangers who each brought their own playbook from their last company. Nobody mentors because everyone was hired to execute, not to develop others. Last quarter, their most experienced PM left for a competitor. Reasonable enough. People leave. But what followed was six months of the remaining team rediscovering decisions, contexts, and customer relationships that had lived entirely inside that one person's head. There was no junior PM who had been shadowing her. There was no mid-level person she had been developing. The context debt, all that accumulated knowledge, simply vanished. Six months of rebuilding what one junior PM sitting in meetings could have preserved. Who Owes the Next Generation? The people most vocal about the mentorship deficit are, with depressing consistency, the people who benefited most from mentorship themselves. I include myself in this group. The mentorship I received from Rajan at the petroleum company shaped how I think about product work to this day. Every time I insist on watching real users before designing, that is Rajan's voice in my head. Every time I push back on a roadmap built from assumptions instead of observation, that is a lesson from those offshore platform visits. But here is the uncomfortable question: have I done the same for enough people coming behind me? Honestly, not enough. And I suspect most senior product people, if they are being truthful, would say the same. The mentorship deficit is not something happening to us. It is something we are doing. When I was at Boeing, working on interfaces for maintenance crews who wore thick gloves and worked in dim hangars, the entire product culture was built on institutional knowledge transfer. The engineers who had spent decades in aviation did not hoard their expertise. They shared it constantly, often by pulling a younger colleague aside and saying, "Let me tell you why we do not design it that way." That knowledge transfer was not optional. In aviation, what you do not pass on can literally cause failures. Product management does not have cockpit alarms when knowledge transfer breaks down. It has something quieter and harder to detect: a slow degradation of judgment across the organisation. The Context Debt Compounds The next generation of product leaders is not being developed. It is being skipped. Think about what this means in three years. The mid-level product managers who would normally be stepping into leadership roles do not exist. Companies skipped that cohort entirely. So when current senior leaders move on (and they will), the bench is empty. The response will be to hire more senior externals. Who will arrive with no organisational context. Who will spend six months learning the domain. Who will build their own processes from scratch because nobody documented why the existing ones were built the way they were. The context debt compounds. Every cycle of external-hire replacement adds a layer of lost institutional memory. And every layer makes the organisation a little more fragile, a little more dependent on individuals rather than systems. I watch this pattern at three different companies I advise. It is the same story each time. Brilliant senior hires who are productive from week one on execution but take months to understand why certain product decisions were made. The "why" never got written down because the person who knew the "why" was too senior and too busy to document it, and there was no junior person around to absorb it through proximity. Mentorship is not charity. It is how organisations maintain continuity. Without it, every departure is a minor amnesia event. What Filling the Gap Actually Looks Like This is not a call for companies to restart their graduate programmes out of altruism. The maths is simpler than that. One junior PM costs a fraction of a senior hire and, if developed properly, becomes a mid-level PM with deep organisational context in two years. That mid-level PM with context will outperform a newly hired senior PM without context on almost every internal decision. Not because they are smarter. Because they know where the bodies are buried. But filling the mentorship deficit requires senior product people to accept a role they were not hired for. It means spending an hour a week with someone who asks questions you consider basic. It means letting a junior PM sit silently in a stakeholder meeting and then spending twenty minutes afterward explaining the subtext. It means treating knowledge transfer not as a nice-to-have but as part of your actual job. The startup I advise eventually hired two junior PMs after losing that senior PM and her six months of context. The team lead told me it felt like a step backward. Two people who needed training, who slowed down meetings with questions, who required code reviews of their product specs. But four months later, when another senior PM went on extended leave, the transition was almost invisible. The junior PMs had absorbed enough context through proximity, through all those "basic" questions, through sitting in meetings and watching, to keep the work moving. That is not a coincidence. That is the mentorship deficit being quietly, unglamoriously repaid. Nobody will give you a promotion for mentoring a junior PM. Nobody will add "developed the next generation of product leaders" to your performance review. The return on mentorship is measured in years, not quarters, and most organisations have lost the patience for that kind of arithmetic. But the arithmetic does not care about your patience. It runs whether you are counting or not.

Product Leadership & CareerAugust 1, 2025

Hire for taste, not craft: What AI actually replaces on a product team

The most skilled person on your team may no longer be the most valuable one. Craft was the differentiator. The designer who could execute a pixel-perfect prototype, the engineer who wrote clean code on the first pass, the copywriter who nailed tone without a brief. Those people were worth their weight in equity. But something has shifted beneath every hiring conversation in product. AI can now do craft. Not all of it. Not perfectly. Well enough, though, and fast enough, that raw execution skill is no longer the scarce resource it was. The question product leaders should be asking is not who can build the best version of this. It is who can tell me whether we should build it at all. The craft floor I have started calling it the craft floor. The craft floor is the minimum level of execution quality that AI tools have made universally accessible. Two years ago, producing a high-fidelity prototype required a senior designer with years of practice. Today, a junior designer with Figma and an AI assistant can produce something that looks almost indistinguishable. Writing clean front-end code once required specific expertise. Today, an AI coding tool can generate it from a description. Here is what the craft floor does to hiring. It compresses the value of execution skill. When everyone can produce work that clears the quality bar, the bar stops being a differentiator. It becomes the floor, the minimum. The thing that gets you into the room but no longer determines who wins. And what wins, increasingly, is something harder to test for, harder to teach, and impossible to automate. Taste. Two designers, one quarter At Adobe, we hired two designers in the same quarter. One of them, I will call her Priya, had exceptional craft skills. Her prototypes were flawless. Her visual design was precise to the pixel. She could take a brief and produce something polished faster than anyone I had worked with. In a portfolio review, she was the obvious hire. The other designer, I will call her Meera, had less polish. Her prototypes were rougher. Her visual sensibility was good but not remarkable. In her first month, she killed a feature. Not dramatically. She just looked at the problem the team was solving, talked to three customers, and said this is not the right thing to build. She could not articulate exactly how she knew. She was right. The data confirmed it six weeks later. Within a year, Meera had measurably more impact. Not because she was a better designer. Because she kept the team from building three features that would have failed. She saved months of engineering time and opportunity cost. Priya built beautiful things. Meera built the right things. The gap between those two contributions is what I have come to call the taste premium. The taste premium is the disproportionate value created by people who can distinguish between work that is good and work that matters. Craft is the ability to execute well. Taste is the ability to know what is worth executing. And in a world where AI has raised the craft floor for everyone, the taste premium is widening fast. The intern who could execute anything I have been mentoring a junior designer who started as an intern. She picked up AI tools faster than anyone I have seen. She could generate interfaces, write copy, build interactive prototypes, all at a pace that would have been senior-level output three years ago. Her craft, amplified by AI, was genuinely impressive. But she built a polished, beautiful interface for a feature that solved no real problem. The screens looked professional. The interactions were smooth. And the entire thing was a solution searching for a problem that did not exist. When I asked her why she had built it, she said the brief mentioned it as a possibility and the AI tools made it easy to explore. She could execute anything. She could not tell when something was wrong. That is the craft floor in action. The tools gave her the ability to produce far beyond her experience. They could not give her the instinct to stop and ask whether the output was worth producing. The craft was there. The taste was not. Two guitarists can play the same piece. One hits every note with technical precision, every chord clean, every transition smooth. The other leaves notes out. Pauses where the sheet music says to play. Holds a silence one beat longer than expected. The first guitarist is skilled. The second one is an artist. The difference is not what they can play. It is what they choose not to play. Craft is what AI can replicate. Taste is what it cannot. Product teams are full of people who can play every note. AI has made that easier than ever. But the people who know which notes to leave out, which features to kill, which elegant solution to reject because it solves the wrong problem, those people are the most valuable on any team. And most hiring processes are not selecting for them. What hiring for taste actually looks like But if taste is the new premium, most hiring processes are still testing for craft. Portfolio reviews evaluate visual quality. Take-home exercises measure execution speed. Technical interviews test implementation skill. All of these assess whether someone can build something well. None of them assess whether someone can tell you what not to build. Hiring for taste means asking different questions. Not "show me your best work" but "show me something you decided not to ship, and why." Not "how would you design this feature" but "how would you decide whether this feature should exist." Not "walk me through your process" but "tell me about a time your process told you to stop." But here is the harder truth. Taste is difficult to interview for because it looks like confidence without evidence. When Meera said the feature was wrong in her first month at Adobe, she did not have a spreadsheet to support it. She had a feeling informed by years of watching users, an instinct she could not fully explain. That kind of judgment makes hiring managers nervous. It is easier to evaluate a pixel-perfect prototype than a well-reasoned no. But the well-reasoned no is worth more now than it has ever been. Because AI can produce the prototype in minutes. Nobody can automate the judgment that says this prototype solves the wrong problem. The split that is coming The craft floor will keep rising. AI tools will get better at generating code, design, copy, and research summaries. Every execution task that can be described can eventually be automated. But this is not a threat to product people. It is a filter. It is separating the people whose value was in execution from the people whose value is in judgment. And judgment, the instinct for what is right and worth shipping, is the thing no model is coming for. The best product people I have worked with, across petroleum, aviation, SaaS, and retail, all shared one trait. They knew when to stop. They could look at a well-crafted solution and say this is not it, without a metric to prove them right in the moment. They were usually proven right later. That is taste. It is pattern recognition refined by years of watching things succeed and fail. It is the residue of experience that no training data can replicate. The teams that hire for it will build things that matter. The ones still hiring for craft will build things that look good. Those are not the same outcome.

Product Teams & Org DynamicsAugust 1, 2025

Clarity debt compounds faster than any other kind

In the 1960s, Brasilia was built from nothing in forty-one months. The city plan was elegant: a central axis for government, residential superblocks radiating outward, each neighbourhood self-contained with its own schools and shops. The architects had a clear thesis. A modern capital for a modern nation. But the city grew faster than the plan anticipated. Satellite cities sprang up around the original design, each with its own logic, its own infrastructure, its own relationship to the centre. By the 1980s, the greater Brasilia metropolitan area housed millions of people who had no connection to the original urban thesis. Visitors would ask, "What is the idea behind this city?" and the honest answer had become: it depends which part you are standing in. The plan was still there, buried under decades of pragmatic expansion. Nobody could see it any more. And: the world where products grow Product organisations follow this pattern with a reliability that would be funny if it were not so expensive. A startup begins with a thesis so clean you could write it on a napkin. We solve this problem, for these people, in this way. Everyone on the team can recite it. Customers repeat it back to you in their own words. Sales closes deals by saying the thing, because the thing is obvious and true. And then the company succeeds. Features arrive. A pivot adds a second use case without retiring the first. An enterprise deal produces a custom module. A partnership introduces capabilities that serve a different audience. Each decision is rational. Each expansion is justified. But the explanation of what the product is, the sentence that used to fit on a napkin, gets longer and less convincing with every quarter. Nobody notices because nobody is tracking it. I have started calling this clarity debt. Like technical debt, it accumulates through reasonable decisions made under time pressure. But unlike technical debt, nobody files a ticket for it. There is no dashboard that turns red when your positioning statement stops making sense. Clarity debt compounds faster than technical debt. And unlike technical debt, nobody is tracking it. But: the narrative falls behind At Freshworks, I lived inside this problem. The product began as a customer support tool. You could explain it in one breath: a modern helpdesk for growing businesses. But the company expanded into CRM, then IT service management, then marketing automation. Each product made sense on its own terms. But when you stepped back and asked "What is Freshworks?", the answer depended entirely on which team you were talking to. Support would give you one answer. Sales another. Marketing a third. Product management a fourth. The CEO a fifth. None of them were wrong. That was the painful part. I call this the five-answers test. Ask five people across functions to explain what your product does in two sentences. If the answers do not sound like they describe the same company, you do not have a messaging problem. You have a clarity debt problem. The product has grown faster than the narrative that explains it, and nobody has done the integration work of weaving the new pieces into a story that coheres. The mechanism of accumulation The reason clarity debt compounds is that shipping is continuous and narrative integration is not. A team can ship a feature in two weeks. Rewriting the positioning to account for that feature and the three before it requires someone to sit down, look at everything the product has become, and write a new version of the story. That work is slow, politically difficult, and produces nothing that shows up in a sprint review. So it gets deferred. One quarter, then another. At Adobe, I saw what happens when the deferral runs long enough. The product I was working on had accumulated two years of features, partnerships, and audience shifts since the last time anyone had formally updated the positioning. The marketing site described a product from 2019. The sales team had developed its own pitch, which bore limited resemblance to what marketing was saying. The product team used internal shorthand that customers would not have recognised. Three versions of the truth, each maintained by a different function, none of them quite right. When someone finally convened a working group to write a unified positioning document, it took eleven weeks. Not because the writing was difficult. Because the conversations were. People had genuinely different beliefs about what the product was, and those beliefs had diverged for so long that reconciling them felt less like alignment and more like negotiation. Eleven weeks to agree on three paragraphs. That is the interest payment on two years of clarity debt. Therefore: someone has to own this The pattern is consistent across every company I have worked with or advised. The zero-to-one stage produces effortless clarity. The product is small enough to hold in one person's head. But somewhere between product-market fit and the fourth major expansion, the narrative breaks. New hires take longer to explain the product than to learn the codebase. Customers describe you by naming the specific feature they use rather than the problem you solve. Your own team starts hedging when someone at a dinner party asks what their company does. Those are symptoms. But the root cause is structural: nobody owns the narrative the way someone owns the architecture. At my first startup, we built a product that did three things well. But when a prospective investor asked my co-founder to explain it, the explanation ran past ten minutes and still had not landed. I sat in that room thinking: if the two people who built this cannot explain it in ninety seconds, the problem is not the investor's patience. We had shipped faster than we had thought. We had a product. We did not have a story. That experience taught me something I still carry. Speed without narrative is just accumulation. The companies that manage clarity debt well share one discipline. They treat the product narrative as a living artefact, not a marketing deliverable that gets written once and filed. They ask one question regularly: can someone who joined last month explain what we do and why it matters, in language a customer would recognise, within their first fortnight? If the answer is no, the debt is growing. What it really costs Most teams file clarity under "communications" and move on. But the real cost is not confused messaging. It is confused building. When the narrative is unclear, everything is potentially in scope. Features get approved because nobody has a shared framework for saying no. Roadmaps expand because the boundary between what the product is and what it is not has gone soft. The product becomes Brasilia's satellite cities: each part makes sense locally, yet the whole no longer tells a story. The most expensive features I have ever seen built were features that should never have been considered, in a product that had lost the ability to say what it was. I do not think most organisations will resolve their clarity debt until they stop treating it as a branding exercise and start treating it as a product decision. What are we, now, in language a stranger could repeat back? Not what we were. Not what we aspire to be. What are we, after all the growth and the pivots and the reasonable compromises? The answer is always shorter than people expect. But arriving at it requires the kind of honest, slightly uncomfortable conversation that growing companies keep deferring, one more quarter, one more feature, one more pivot, until the debt is so large it feels like starting over. It does not have to be that expensive. But it usually is.

Communication & Storytelling July 30, 2025

The jobs to be done resurgence: What users hire products to do vs what teams think they are building

The most dangerous competitor you will face this year does not have more features than you. They have fewer. This should be counterintuitive. Product teams spend enormous energy expanding capability, adding integrations, broadening scope. The assumption is that the product with the broadest coverage wins. More features means more use cases. More use cases means more customers. More customers means the strategy is working. But users do not switch to better products. They switch to more precise ones. That sentence explains more lost deals, more churned accounts, and more market share erosion than any competitive analysis deck I have ever read. And it is the reason jobs-to-be-done thinking is having a resurgence right now, at the exact moment when AI is making it trivially easy to build products that do one specific thing extremely well. The breadth trap I watched this play out at Freshworks in a way that still bothers me. The CRM product was built to do everything. Email, phone, chat, social media, analytics, workflows, reporting. The pitch was compelling: one platform for your entire customer engagement stack. No more switching between tools. No more data silos. Everything in one place. On paper, it was a strong strategy. But in the market, something else was happening. A competitor, much smaller, had built a tool that did one thing: email sequences for outbound sales. That was it. No phone integration. No social listening. No analytics dashboard. Just email sequences, done with obsessive precision. The templates were better. The scheduling was smarter. The deliverability was higher. The reporting on open rates and reply rates was tighter and faster. And they were capturing the exact segment we were losing. The sales team kept saying we needed to improve our email features. But that framed it as a feature gap, which it was not. The real issue was a job gap. Those users were not hiring a CRM. They were hiring a tool to run outbound email sequences. And when you are hiring for a specific job, you do not want the generalist who can do a bit of everything. You want the specialist who has done that one thing a thousand times. It is the same reason you choose a surgeon over a GP when you need a specific procedure. The GP understands your whole body. The surgeon understands your specific problem. When the stakes are high enough, precision wins every time. I call this the breadth trap. The belief that adding more capability makes a product harder to leave. In reality, breadth makes a product easier to replace in any single dimension. The broader you go, the more surface area you expose to a competitor who goes deeper on the one thing that matters most to a specific user. Precision as a switching trigger Here is what makes JTBD thinking so urgent right now. AI has collapsed the cost and time required to build a product that does one job exceptionally well. A year ago, building a specialised tool for a narrow use case required a funded team and months of development. Today, a solo founder with the right instinct can ship something in weeks that does a single job better than an incumbent's version buried inside a platform. The proliferation of AI alternatives is not creating better products across the board. It is creating more precise products for more specific jobs. But most incumbent teams do not see it this way. They see a new competitor and ask: do they have feature parity? The answer is almost always no. And the team relaxes. But feature parity is the wrong question. The right question is: do they do the specific job our users hired us for better than we do? That question produces a very different answer. At Schneider Electric, I worked on an IoT thermostat. Our product did one job: maintain a comfortable temperature with minimum energy consumption. That was the job users hired it for. Control the temperature. Save on the energy bill. Simple. Competitors had products with ten additional features. Lighting control. Security cameras. Voice assistant integration. Their product roadmaps were impressive, full of connected home visions and feature expansion plans. But users hired a thermostat to control temperature. Our product beat competitors with far broader capability because it did the one job users cared about with more precision. The interface was clearer. The energy savings were more visible. The scheduling was more intuitive. When you are cold and you want to be warm without spending too much, you do not want a smart home hub. You want a thermostat that works. Nobody ever hired a product to do everything. They hired it to do one thing they could not do themselves. What teams think they are building vs. what users are hiring The gap between what a product team believes they are building and what users actually hire the product for is the most expensive misalignment in product work. It is also the most common. Teams build for the vision. Users hire for the job. At Freshworks, the vision was a unified customer engagement platform. But a significant portion of users had hired it to send outbound emails effectively. At Schneider Electric, the vision was a connected smart home component. But users had hired it to keep their house at the right temperature without thinking about it. The vision is not wrong. But it is not the job. JTBD thinking forces an uncomfortable question: if a user could hire anything to do this one job, would they still choose your product? Not your platform. Not your brand. Your product, for this one task. If the answer is not a confident yes, you have a precision problem, regardless of how broad your capability is. This is what I call the precision advantage. It is not about building less. It is about understanding what the user actually hired you for, and being so good at that one thing that switching to a broader alternative feels like a downgrade. The hard part about doing less The precision advantage sounds simple. It is not. Because every product team faces the same gravitational pull toward more. More features get requested by sales. More integrations get demanded by enterprise buyers. More capability gets pitched in board meetings as competitive positioning. The entire organisational incentive structure pushes toward breadth. But every feature you add that is not the core job dilutes your precision. It adds complexity to the interface, cognitive load for the user, and surface area for a competitor to beat you on the one dimension that actually matters. The hardest product decision is not what to build. It is what to refuse to build, knowing that the refusal protects the one thing your users actually hired you for. I have gotten this wrong more often than I have gotten it right. At Freshworks, I was part of the team that kept adding capability because the sales org said we needed it. At Schneider Electric, we had the discipline to stay narrow, and it worked. The difference was not intelligence or strategy. It was honesty about what users were actually hiring us to do. Products do not die because they lack features. They die because they lose clarity about the job they were hired to perform. And in a market where AI is making it easier every month to build a more precise alternative, clarity about the job is not a strategic luxury. It is the only defensible position. The teams that will hold their ground are not the ones with the biggest feature lists. They are the ones who can answer a four-word question without hesitating: what job, done well?

User & Buyer PsychologyJuly 11, 2025

Subscription fatigue and the case for model diversification

The subscription model is the most successful pricing innovation in the history of software. It is also, increasingly, the thing users resent most about the software they use. That is not a contradiction. It is a consequence. For two decades, subscriptions solved genuine problems. They replaced large upfront costs with manageable monthly payments. They gave vendors predictable revenue. They gave buyers lower barriers to entry. Everyone won, for a while. But the model that made individual products accessible made the collective cost of modern digital life quietly unbearable. One subscription is a convenience. Fifteen subscriptions is a tax. The subscription model works until the customer starts counting. The stacking problem I notice it in my own life first. Every quarter, I sit down and look at the recurring charges on my accounts. Design tools, writing tools, cloud storage, music, project management, analytics, email marketing, two different video platforms, a notes app I barely open. Each one felt reasonable when I signed up. Together, they feel like a second rent. But here is the thing: I am also someone who has built products that charge subscriptions. I understand the economics. I know why recurring revenue matters for forecasting, for fundraising, for building a team you can actually pay next month. I have sat in the rooms where the revenue model was decided, and "subscription" was always the answer because it was always the safest answer. The problem is not that any single subscription is wrong. The problem is that every product arrived at the same answer independently, and the user is the one who has to carry the total. I call this the subscription ceiling. It is the point at which adding another subscription to a user's stack triggers active resistance rather than passive acceptance. And we are past it. Not approaching it. Past it. What Grab taught me about pricing assumptions The subscription ceiling is not just a Western, high-income market phenomenon. When I was working with Grab in Southeast Asia, the resistance was even more pronounced, and it taught me something I had not expected. In markets like Indonesia, the Philippines, and parts of Malaysia, many users operate on prepaid financial models. They add credit to their phones when they can afford it. They pay for things as they use them. The idea of committing to a fixed monthly payment for something they might not use every day felt alien. Not difficult. Alien. We had features that users loved when they used them. But wrapping those features inside a subscription created friction that had nothing to do with the product's quality. It had everything to do with the model's assumptions about how people relate to money. The team explored pay-per-use options for specific features. Not as a downgrade from the subscription. As an alternative that matched how people actually spent. The results were striking. Usage went up. Revenue per transaction went down, but total revenue grew because the addressable base expanded. More people were willing to pay something than were willing to pay monthly. That experience broke something in my thinking. I had assumed subscriptions were universally optimal because every SaaS playbook said they were. But a playbook written for San Francisco does not transfer cleanly to Jakarta. The model has to fit the user's relationship with money, not just the vendor's relationship with Wall Street. The buffet problem There is a useful analogy in restaurants. The all-you-can-eat buffet works for customers who want volume and variety. The prix fixe works for customers who want a curated experience at a known price. And ordering a la carte works for customers who want to pay only for what they choose. No serious restaurant operator believes one model fits all diners. But for a decade, software acted as if the buffet was the only option. The buffet model (unlimited access, flat monthly fee) is brilliant when users consume heavily and feel they are getting more than they pay for. But when usage drops, or when the user only needs one specific dish, the buffet starts to feel wasteful. The customer looks at their plate, looks at the price, and starts doing maths. That is the moment the subscription stops feeling like a bargain and starts feeling like a trap. Products are hitting that moment more frequently now. Users who signed up for a full-featured platform but only use two features are asking a fair question: why am I paying for the rest? Model sprawl is not a strategy The tempting response is to offer everything. A free tier. A monthly subscription. A usage-based option. An annual plan with a discount. An enterprise tier with custom pricing. A one-time purchase for specific outputs. I have watched teams do this, and the result is almost always confusion. For the user, the pricing page becomes a puzzle. For the team, billing complexity eats into the operational simplicity that subscriptions were supposed to provide. Support tickets about pricing go up. Conversion rates go down. The finance team starts building spreadsheets that nobody fully trusts. Model sprawl is not a strategy. It is the absence of one. The teams getting this right are not offering every model simultaneously. They are choosing deliberately. They are asking which model matches how their specific users experience value from the product, and they are building around that answer. A project management tool where users log in daily and rely on it as infrastructure? Subscription makes sense. The value is continuous, and the model reflects that. But a design asset marketplace where a user needs a specific template once a quarter? A per-purchase or credit-based model respects how value is actually consumed. The question is not "subscription or not." The question is "when does the user feel they received value, and does the payment model match that moment?" The honest recalibration I do not think subscriptions are dying. That framing is as overblown as the framing that subscriptions were going to replace every other model. What is dying is the assumption that subscriptions are the default. The assumption that recurring revenue is always the right revenue. The assumption that the model that works for the vendor also works for the user. The best product teams I have spoken to recently are treating their revenue model the way they treat their product design: as something that deserves research, testing, and iteration. They are running pricing experiments the same way they run feature experiments. They are talking to churned users not just about what features they missed but about whether the payment structure itself was part of the reason they left. This is harder than it sounds. Building billing infrastructure for multiple models is expensive. Forecasting revenue across mixed models is messy. Explaining a hybrid model to investors who want a clean ARR number is awkward. But the alternative is watching a growing segment of your users silently resent the way you charge them, which is a slow-moving retention problem that no feature improvement will fix. The subscription was never the product. It was always just the container. When the container stops fitting what is inside it, the smart move is not to keep stuffing. It is to find a better container, or to offer more than one. Some users want the buffet. Some want a la carte. The product that insists everyone sit at the same table eventually finds itself eating alone.

The Business of ProductsJuly 4, 2025

The AI PM became the highest-paid and fastest growing product specialisation

Here is a pattern I did not expect to see in the hiring data this year. The highest-paid product managers in the market, the ones commanding between $286K and $569K at senior levels, are disproportionately people without computer science degrees. An analysis of over 18,000 AI PM hires tells the story plainly: 60% of the people filling these roles did not come from traditional technical backgrounds. The most lucrative product specialisation in a generation is not being won by the people everyone assumed would win it. That should make you curious about what is actually going on. The technical credential myth The default assumption in most hiring conversations is that AI PM roles require deep ML knowledge. Candidates assume they need to understand transformer architectures and training data pipelines to be taken seriously. Hiring managers put "technical background preferred" on job descriptions out of instinct more than evidence. The entire market has organised itself around a belief that turns out to be wrong more often than it is right. I call this the technical credential myth. It is the assumption that proximity to the technology is what makes an AI PM effective. But the data contradicts it. And my experience contradicts it even more directly. At Grab, I worked alongside product people building AI-driven features across ride-hailing and food delivery. The features were technically sophisticated: dynamic pricing, demand prediction, route optimisation, fraud detection. Every one of them required deep interaction between product teams and ML engineers. But the PMs who performed best in those rooms were not the ones who could discuss gradient descent or explain a loss function. They were the ones who could look at the AI's output and say, "That is wrong." Not because they understood the model's architecture. Because they understood the user's context. When a demand prediction model suggested surge pricing in a neighbourhood during what looked like a spike in ride requests, the PM who had spent three years understanding rider behaviour in Southeast Asian cities could look at the data and say, "That is a temple festival. Demand will drop in forty minutes, not rise. Do not surge." The ML engineer could not have known that. The PM with domain knowledge could. The best AI PMs are not the ones who understand the model. They are the ones who understand the problem the model is trying to solve. The domain advantage This is where the career opportunity sits, and most product people are walking past it. But the domain advantage is not a vague soft skill. It is the accumulated expertise in a specific problem space that allows a PM to exercise judgment about AI outputs in ways that no amount of technical training can replicate. A product designer I have been mentoring made this transition in a way that surprised everyone except me. She had spent ten years working in healthcare technology, designing clinical workflow tools for hospital systems. No computer science background. No ML coursework. When she told people she was interviewing for AI PM roles, the response was usually polite scepticism. But she understood something most technically credentialed candidates did not. She knew how a nurse thinks at 3am during a shift change. She knew which clinical data points are reliable and which ones are routinely entered incorrectly because the system makes accurate entry too slow. She knew that a recommendation engine suggesting medication interactions needs to account for the fact that doctors will override it 40% of the time, and that the override rate is not a bug but a feature of how clinical judgment works. She got the role. Within six months, she was outperforming PMs who had spent years studying machine learning. Not because she was smarter. Because her judgment about the problem space was deeper, and in AI product work, judgment about the problem space is the whole game. Technical credentials got people into the room. Domain expertise is what keeps them there. What AI PM actually requires The confusion about AI PM skills comes from a misunderstanding about what the role actually involves. A traditional PM works with deterministic systems. You define requirements, engineers build them, the feature does what you specified. The feedback loop is tight and the outputs are predictable. But AI PM work is fundamentally different. You are working with probabilistic systems. The outputs are not guaranteed. The same input can produce different results. The model will be wrong sometimes, and being wrong is not a failure state, it is an expected operating condition. The PM's job is not to make the model right. It is to decide how right the model needs to be, what happens when it is wrong, and how the user should experience both of those states. But this is a judgment problem, not a technical one. It requires the ability to sit with ambiguity. Most product people trained in deterministic environments find this deeply uncomfortable. They want clear requirements and binary outcomes. AI products do not work that way. The PM who thrives in AI product work is the one who can say, "This model is 87% accurate, and for this use case, that is good enough, but we need a fallback experience for the 13% where it fails." That sentence requires product judgment, user understanding, and risk tolerance. It does not require knowing how the model works under the hood. But it also requires a specific kind of intellectual honesty. The temptation in AI product work is to defer to the model. The model says X, so we ship X. The PMs who fall into this trap are usually the ones with the strongest technical backgrounds, because they trust the model's reasoning more than their own judgment about the user. The PMs who resist this trap are usually the ones with domain expertise, because they have an independent basis for evaluating whether the model's output makes sense. Why this matters for your career The AI PM market is not slowing down. The compensation data is not a temporary spike. Organisations are building AI into every product category, and they need product people who can make judgment calls about systems that behave probabilistically. The supply of people with that specific combination of skills (product thinking, domain expertise, comfort with ambiguity) is much smaller than the demand. But here is what most career advice gets wrong about this moment. The path into AI PM work is not a bootcamp on machine learning fundamentals. It is not a certificate in prompt engineering. Those things are not useless, but they are not the differentiator. The differentiator is the domain advantage: years of accumulated expertise in a problem space that gives you judgment no course can teach. But if you have spent a decade in fintech, healthcare, logistics, education, or any other domain where AI is being applied, you already possess the most valuable asset in the AI PM market. You just do not recognise it as such, because the market has been telling you that technical credentials matter more. The data says otherwise. The technical credential myth has cost good product people years of hesitation. They waited to learn things they did not need to learn before applying for roles they were already qualified to fill. The domain advantage was there all along, hiding in plain sight, disguised as mere experience. The best career moves rarely look like credentials on paper. They look like the slow accumulation of judgment in a domain where that judgment turns out to be exactly what the market needs, right when it needs it most.

Product Leadership & CareerJune 30, 2025

Vibe coding changes who can be a founder, not just how fast founders can build

In 1991, a four-track cassette recorder cost about the same as a month's rent. If you wanted to make an album, you saved up, bought the machine, learned to use it, and produced something that sounded like it was recorded in a bedroom. Because it was. The equipment was a gate, and the gate kept most people out. By 2005, GarageBand shipped free on every Mac. The equipment gate was gone. Anyone with a laptop could produce music that sounded professional. The number of people making albums exploded. But the number of people making great albums did not change much. The constraint had shifted. It was no longer about whether you could produce a track. It was about whether you had something worth producing. I keep thinking about that shift when I watch what is happening with vibe coding. The founder access shift Tools like Cursor, Lovable, Replit Agent, and Claude Code have done something the startup world discussed for a decade without achieving. They have removed the technical co-founder requirement for the earliest stages of building a software product. A person with a clear problem, decent product instincts, and no programming experience can now build a working prototype in weeks. Not a mockup. A functional product that real users can touch. I call this the founder access shift. For years, the first question every non-technical person with a startup idea heard was: "Do you have a technical co-founder?" If the answer was no, the conversation was effectively over. The idea might have been brilliant. The market insight might have been correct. But without someone who could write code, the idea stayed on a whiteboard. That gate is now open. The market has responded. The vibe coding tools sector has reached $4.7 billion, and the growth is not coming from engineers working faster. It is coming from people who were never engineers building things that previously required them. But here is what I have noticed, working with founders who use these tools: removing the building constraint did not remove the constraints that actually determine whether a product succeeds. It just exposed them more quickly. What the tools handle and what they do not A founder I mentor, a former operations manager with deep expertise in logistics for mid-size Indian manufacturers, came to me in February with an idea for a production scheduling tool. She had no engineering background. No technical co-founder. Six months ago, that would have been the end of the conversation. Instead, she used Cursor and Claude Code and had a working MVP in three weeks. Three weeks. The tool handled the database design, the basic interface, the core scheduling logic. She described what she wanted in plain language, iterated through versions, and shipped something her former colleagues could use. But here is what the tools did not do. They did not tell her which features to prioritise. They did not tell her that the scheduling view she had designed was confusing to everyone except people who thought about logistics the way she did. They did not tell her that the three manufacturers she had shown it to were polite rather than enthusiastic. They did not tell her that her pricing was wrong. Building is no longer the bottleneck. Knowing what to build is. She had domain expertise and a real problem. Those two things gave her a significant advantage over the typical non-technical founder who starts with an idea rather than a lived understanding of the pain. But even with that advantage, the gap between a working prototype and a product people would pay for was filled with judgment calls that no AI tool could make for her. What to include, what to leave out, how to talk about it, who to sell to first. I call this the taste bottleneck. Vibe coding compressed the execution layer to near zero. But taste (the ability to know what is good, what is right, what a specific user needs in a specific moment) remains entirely human. The tools can build anything you describe. The question is whether what you describe is worth building. Building from Wayanad with AI I have experienced this tension myself. Working from Wayanad, using AI coding tools to prototype ideas, I have felt both the exhilaration and the limits. The exhilaration is real: I can move from concept to working prototype in a day. I can test an idea without hiring anyone, without waiting for anyone. But the limits are equally real. The tools are extraordinarily capable at producing what you ask for. They are not capable of telling you that you are asking for the wrong thing. I have built prototypes that were technically functional and strategically pointless. Beautiful solutions to problems nobody had. The speed of building made it easy to skip the thinking that should have come first: who is this for, what job does it do, why would they choose this over what they currently use? Vibe coding democratised the how. It did not touch the what or the why. The founder access shift means more people can build. That is genuinely good. The gates that kept non-technical founders out were not meritocratic. They were structural. Plenty of people with the right insight, the right domain knowledge, the right instinct for what a market needed were locked out because they could not write code and could not find someone who could. But those people can now build. The playing field has changed shape. The new founder profile But the taste bottleneck means that building is now the easy part. And when building is easy, everything that was previously hidden behind the difficulty of building becomes visible. Distribution. Positioning. Pricing. The ability to sit with a product that is 80% right and know which 20% to fix and which to leave alone. It is not about using vibe coding tools efficiently. Efficiency in building was never the differentiator. It is about what you bring that the tools cannot generate: a specific understanding of a specific group of people with a specific problem, combined with the taste to know what a good solution feels like before the data confirms it. That profile looks different from the traditional technical founder. It looks more like the operations manager I mentor, who spent a decade inside the problem before she tried to solve it. It looks like someone whose advantage is not that they can code, but that they know something about the world that most people do not. The gates are open. But the question was never really about the gates. Some will bring tools and energy and a vague sense that they should be building something. The tools will serve them well for about three weeks, until the prototype is finished and the real work begins. Others will bring a decade of domain knowledge, a clear view of a problem nobody has solved well, and the taste to know when a solution is genuinely right. The tools will serve them too. But the tools will not be what makes the difference. The difference will be everything the tools cannot do.

Building & FoundingJune 28, 2025

Designing for a system that can't explain itself

In aviation, there is a concept called the glass cockpit problem. When analogue instruments were replaced by digital displays in the 1980s and 1990s, the screens gave pilots more information than they had ever had access to. More data, faster updates, cleaner presentation. The information environment improved in every measurable way. But something unexpected happened. Certain categories of error increased. Pilots who had developed deep intuitive understanding of analogue instruments, who could read the subtle behavioural signals of a gauge before the number changed, were now reading summaries produced by a system. The system was accurate. But it had introduced a layer between the pilot and the raw state of the aircraft. And in edge cases, when the system itself was confused or failing, the pilots were slower to recognise it than they had been before the displays arrived. The instruments had become too good at presenting confidence. Even when confidence was not warranted. I think about that problem often now. Because it is exactly what product teams are being asked to solve with AI-native features, and almost nobody in the conversation has the language for it yet. The design challenge that has emerged quietly over the past year is not how to make AI features usable in the conventional sense. Usability, in the legacy meaning of the word, is mostly solved. Users understand buttons and flows and feedback states. The patterns exist. Teams know how to apply them. The new problem is something different: how do you design for a system whose internal state is genuinely unknowable, even to the people who built it? How do you communicate confidence levels to a user when the system's confidence does not map cleanly to the kind of certainty a human would express? How do you design for error in a system where the errors are not predictable, reproducible, or always recognisable as errors? These are not usability questions. They are epistemic design questions. The field has useful instincts for the first kind. But it does not yet have a settled vocabulary for the second. The failure mode I have seen most consistently in AI feature implementations is what I have started calling the false floor. The system presents its output in the visual language of certainty: clean typography, structured layout, confident prose. Nothing in the presentation signals that the system might be wrong, incomplete, or operating at the edge of its actual capability. The user trusts the output at face value. The output is wrong, or partially wrong, in a way that is not self-evident. The user acts on it. Something downstream breaks. But the design team did not build a dishonest interface. They built the same interface they would have built for any feature. The problem is that the same visual language that communicates confidence accurately for a deterministic system communicates it inaccurately for a probabilistic one. The cockpit was not lying. But it was presenting uncertainty in the language of certainty, and the difference killed people. What does it look like to design honestly for a system that cannot fully explain itself? Some of the answers are tactical. Surfacing confidence signals. Designing explicit correction pathways. Making the provenance of AI-generated output visible rather than presenting it as a final answer. These are real improvements and they matter. But the deeper answer is a shift in how designers think about their own role in the relationship between user and system. For most of the history of product design, the designer's job was to reduce friction. To make the path from user intent to user outcome as short and smooth as possible. That instinct produced enormous value. It produced the clean, fast, intuitive products that raised the baseline and got us to the seatbelt problem. But AI systems sometimes require friction. Not because friction is good. But because the absence of friction can produce unwarranted trust in a system that has not earned it. The design of appropriate resistance, the moment that asks the user to confirm, to verify, to apply their own judgment before acting on a system output, is a design decision as important as any flow optimisation. The Boeing engineers who saw the glass cockpit problem eventually introduced features that were deliberately harder to dismiss. Alerts that required active acknowledgment. Displays that showed instrument disagreement rather than resolving it into a single confident reading. Friction as a trust mechanism. Product designers building AI features are being asked to solve a problem that the field's existing language was not built for. The old vocabulary, usability, affordance, feedback, findability, assumes a system that behaves deterministically in response to user input. AI features do not. The new vocabulary is still forming. But the question at the centre of it is not "how do we make this easier to use?" It is "how do we help the user know when to trust this, and when to check?" That is a harder design brief. But it is the right one.

Product Design & Craft TopicsJune 13, 2025

When building is cheap and fast, the minimum viable experience replaces the minimum viable product

The smartest idea in startup history has become the most dangerous one. The minimum viable product was a brilliant idea for an era when building was expensive. Building is no longer expensive. And the concept that once protected founders from wasting time and money is now the reason many of them fail before anyone gives their product a second look. Eric Ries gave us a discipline of restraint. Build the least you can, ship it, learn from real users, iterate. The logic was airtight because the constraints were real. Every feature cost weeks of engineering and coordination across teams that could barely ship a login screen in a quarter. Asking "what is the least we can build" was not laziness. It was wisdom. But the world that made that question wise has quietly disappeared. AI tools have compressed the cost of building a functional product to something close to trivial. A single person can now ship in days what used to require a team of five working for months. The hard part is no longer whether you can build it. The hard part is whether anyone stays past the first thirty seconds. The experience floor I learned this the painful way, years before anyone was talking about AI tools or the death of the MVP. Early in my career, I worked on a product that did exactly what it promised. It was a scheduling tool for field teams at a petroleum company. You could assign tasks, view routes, and confirm completions. The engineering was solid. We shipped it to operations managers who spent their days coordinating rig maintenance crews across remote sites. They used it once. Exactly once. The tool worked. But the onboarding dropped users onto a blank dashboard with no guidance. The labels used our internal terminology, not theirs. One operations manager told me, with the kind of blunt honesty you only get from someone who works on oil rigs, "I opened it, stared at it, closed it, and went back to Excel." The product was viable. The experience was not. That distinction did not have a name back then. Now it does. I call it the experience floor: the minimum level of experience quality that a user unconsciously requires before giving a new product any real attention. Fall below it and nothing else matters. The user has already decided this was not built for them. The floor has moved Five years ago, the experience floor was low. Users understood that new tools would be rough. They expected missing features, clunky onboarding, placeholder copy. But that patience was rational only because they knew building was hard. Roughness signalled ambition, not neglect. But AI has compressed build times so dramatically that roughness no longer signals "early stage." It signals "low effort." The user's internal logic has shifted without anyone announcing it. If everyone can build quickly now, why does this feel unfinished? Users do not compare your product to what you could build later. They compare it to what they are using now. A founder I mentor learned this in February. She built an MVP using AI coding tools in just under two weeks. Task management for freelance translators. Solid problem, validated with interviews, real need. She shipped it to a group of forty translators she had recruited through a professional community. The feedback was devastating. "This feels like a demo, not a product." "Why would I switch from Trello for this?" "It works, but it does not feel like anyone thought about how I actually work." Nobody said the features were wrong. But every single response compared her product to tools that had been refined over years. The experience floor had moved. But she had shipped below it, and no amount of functional correctness could compensate. The MVE shift This is what I call the MVE shift. The question is no longer "what is the least we can build." The question is "what is the least experience that makes someone feel this was built for them." It is not about building more. It is about building differently. The minimum viable product asked founders to focus on functionality. Does it work? Can the user complete the core task? The minimum viable experience asks founders to focus on the first three minutes. Does the product greet the user in a way that earns trust? Does the first interaction produce a small win, not just a successful function call? But most founders hear "experience" and think "polish." Polish sounds like months of additional work, like hiring a design team, like premature optimisation. But the MVE shift is not about polish. It is about intent. It is the difference between a blank dashboard that says "Create New" and a guided first step that says "Let us set up your first translation project together." That difference costs days, not months. But it changes everything about whether a user comes back. What the MVE actually requires The experience floor is not about competing with the visual refinement of a company that has raised fifty million dollars. It is about three specific things. First, the product needs to feel intentional. The user should sense within thirty seconds that someone thought about their situation before building this. But intention is not communicated through features. It is communicated through onboarding copy, a pre-filled example that matches a use case, or a single sentence on the landing page that names a frustration accurately. Second, the first interaction needs to deliver a small win. Not a feature tour. A moment where the product responds in a way that feels useful. My mentee went back and added one thing: after creating the first project, her tool showed an estimated timeline based on word count and language pair complexity. Two days to build. But it was the moment every beta tester pointed to as "when I understood why this existed." Third, and this is the one most founders miss, the product needs to respect the user's time. Rough onboarding and empty states that require the user to figure everything out are not signs of an early product. They are signs of a product that values the builder's time over the user's time. But none of this requires a larger team or more time. It requires redirecting two weeks of effort from features that can wait to moments that determine whether anyone stays. The discipline is the same The irony of the MVE shift is that the underlying discipline is identical to what Ries taught. Restraint. Focus. Ship the minimum. Learn fast. But the definition of "minimum" has changed. Minimum used to mean minimum functionality. Now it means minimum experience that clears the experience floor. The founder I mentored went back and spent twelve days on three things: a guided onboarding flow, copy that addressed the specific anxiety freelance translators have about project scoping, and that one small moment of estimated timeline after the first project creation. She relaunched to the same forty translators. Conversion from signup to completed first project tripled. Not because the product underneath had changed. Because the experience earned trust in the first three minutes. If you are sitting with something you are about to ship, the MVE shift is not asking you to do more work. It is asking you to do different work. Onboarding that guides instead of abandons. Copy that speaks instead of labels. One moment that makes the user feel seen. You are not competing with Notion's feature set or Trello's years of refinement. You are competing with the feeling those products create in someone's first sixty seconds. That is a smaller problem than you think, and a far more solvable one.

Building & FoundingJune 13, 2025

The world is not converging on one technology stack, and it probably never was.

In the 1840s, Britain's railways ran on a standard gauge of four feet eight and a half inches. But the Great Western Railway, designed by Isambard Kingdom Brunel, used a broad gauge of seven feet. Both networks grew rapidly. Both attracted investment and passengers. And when they finally met at interchange stations, passengers had to get off one train, walk across a platform, and board a different train on different tracks. Cargo had to be unloaded and reloaded. The gauge incompatibility was not a technical problem anyone failed to solve. It was a political and commercial choice that created two parallel systems, each internally coherent, each unable to interoperate with the other. Something similar is happening in global technology right now, and the DeepSeek moment made it impossible to ignore. The DeepSeek Signal When DeepSeek demonstrated competitive AI capabilities built on different infrastructure assumptions, different training approaches, and different data foundations, the reaction in the Western technology press was a mixture of surprise and alarm. But the real significance was not that a Chinese lab had built something impressive. It was that the something impressive operated on entirely different foundations. The assumption of convergence, the belief that the world would eventually run on one technology stack, was always more hope than observation. For two decades, it looked plausible. American cloud infrastructure dominated globally. Silicon Valley's product patterns became default worldwide. Google, Amazon, and Microsoft set the standards that everyone else built on. But that era is ending, and it is ending not because of a single event but because of a slow accumulation of divergences that the DeepSeek moment crystallised. The stack fracture is not coming. It is here. Parallel Tracks What does the stack fracture look like in practice? It looks like two (and increasingly more than two) complete technology stacks operating on different assumptions about data, identity, payments, regulation, and user expectations. In one stack, cloud infrastructure runs on AWS, Azure, or Google Cloud. Identity verification uses Western standards. Payment rails connect through Stripe or traditional banking networks. Data residency follows GDPR or similar frameworks. AI models are trained on English-language data with Western content moderation norms. In the parallel stack, cloud infrastructure runs on Alibaba Cloud or Huawei Cloud. Identity verification uses national ID systems with different privacy frameworks. Payment rails run through WeChat Pay or Alipay. Data residency follows Chinese cybersecurity law. AI models are trained on Mandarin-language data with different content filtering approaches. These are not two versions of the same system. They are two different systems, built on different foundations, optimised for different contexts, and increasingly unable to interoperate cleanly. The interoperability gap is growing, not shrinking. At Grab, I learned this lesson at a smaller scale, and it shaped how I think about every "global" product claim I have encountered since. We built products that operated across multiple Southeast Asian markets. On paper, these were similar countries in the same region. In practice, every market was a different world. Payment infrastructure varied wildly. In Singapore, credit cards were common. In Indonesia, bank transfers and cash-on-delivery dominated. In Vietnam, the regulatory environment for fintech was different from Thailand's, which was different from the Philippines'. User behaviours diverged in ways that no single product design could accommodate. The assumption that one product could serve all these markets with minor localisation was, to put it politely, optimistic. To put it accurately, it was wrong. "Global" products are actually collections of local adaptations held together by a shared brand and a shared codebase. The adaptations are where the real work happens. The Assumption of Convergence The assumption of convergence has been the default mental model for technology strategists for most of the internet era. The logic seemed airtight. Networks benefit from interoperability. Standards tend to consolidate. The internet itself was proof that open, shared protocols would win. But that logic was always conditional, and the conditions are changing. Networks benefit from interoperability when the political incentives favour openness. When they do not, networks fragment. The internet was proof of convergence only during a period when the major powers found convergence convenient. That period is over. Product teams that assume a single global standard are building on ground that is already splitting. I see this daily now. From Wayanad, I work with founders building products for both Indian and international markets. The infrastructure assumptions are already diverging, and these founders feel it in operational terms that no analyst report captures. Payment rails are different. India's UPI system processes billions of transactions on infrastructure that has no equivalent in the US or Europe. Identity verification works differently. India's Aadhaar system creates a foundation for digital identity that operates on completely different principles from Western approaches. Data residency requirements are becoming stricter, with India's own data localisation rules adding another set of constraints. The fracture is not hypothetical for these founders. It is their daily operating reality. But here is what makes this moment different from previous regional divergences. The AI layer is splitting too. When DeepSeek demonstrated that competitive AI could emerge from a different data environment, a different regulatory framework, and a different set of infrastructure dependencies, it signalled that the most important technology layer of this decade will not converge. It will fork. What Product Teams Get Wrong The most common mistake I see in product strategy today is treating the stack fracture as a future risk rather than a present reality. Teams plan for "global launch" as though global still means one product, one infrastructure, one set of assumptions. It does not. But the second mistake is more subtle. Some teams respond to the fracture by deciding they will only build for one market. That sounds pragmatic. But it is also a bet that your chosen market will be the one that matters most in ten years, and that is a bet with far less certainty than it had five years ago. The founders I work with who are getting this right are not choosing sides. They are building with the fracture in mind from the beginning. Modular infrastructure assumptions. Payment and identity layers that can be swapped. Data architectures that accommodate different residency requirements without requiring a complete rebuild. It is not elegant. It is expensive and complicated. But it is honest about the world as it actually is, rather than the world that convergence promised. The messy version is the accurate one. The Tracks Are Laid Brunel's broad gauge lasted until 1892, when Britain finally standardised. But standardisation only happened because one nation had the political authority to impose it. The global technology stack has no such authority. No single government can mandate that the world converge on one set of infrastructure standards, one set of data practices, one set of AI foundations. The assumption of convergence was comforting. It simplified strategy, reduced complexity, and made "global" a meaningful product category. But comfort is not the same as accuracy. The tracks are being laid in different gauges, and this time, there is no single authority that can order them torn up and relaid. Product teams will build for one world, or they will build for several. That choice, quiet as it seems today, will determine which products still travel freely a decade from now.

Markets & Industry DynamicsJune 7, 2025

Domain expertise outperforms credentials as the real career differentiator

The product people with the most certifications are becoming the least differentiated. Read that again, because it runs counter to nearly a decade of career advice. For years, the conventional wisdom in product management was clear: collect frameworks, earn certifications, master the tools. Build yourself into a Swiss Army knife of product skills. Be the person who can run a design sprint on Monday, write a PRD on Tuesday, analyse a cohort chart on Wednesday, and facilitate a stakeholder alignment session on Thursday. Generalism was the strategy. Breadth was the moat. But the moat just drained. The Generalist Plateau AI did something that nobody predicted with quite this speed: it made competent execution available to everyone. The PM who spent three years mastering SQL to pull user data now watches a junior colleague type a natural language prompt and get the same query in seconds. The one who prided herself on crisp PRDs discovers that a well-prompted AI produces a structurally identical document. The frameworks, the templates, the operational muscle memory that took years to build, all of it now sits at the generalist plateau, the point where broad skills stop differentiating. This is not a complaint. It is a market observation. The people who are panicking are the ones who built their entire career identity around execution skills. They are the ones refreshing job boards and finding that every posting now says something like "deep experience in healthcare delivery systems" or "background in freight logistics operations" or "understanding of regulatory compliance in financial services." The postings are not asking for better frameworks. They are asking for domain knowledge that cannot be prompted out of a large language model. The question is not what PM skills you have. It is what domain nobody else understands as well as you do. What Boeing Taught Me About Irreplaceable Knowledge At Boeing, I worked alongside engineers and product people who had spent twenty, sometimes thirty years in aviation. They knew things that no certification programme teaches. They knew why a specific maintenance workflow existed (because of an incident in 1997 that changed inspection protocols). They knew which regulatory bodies would flag a UI change (because they had sat through the audits). They knew that airline maintenance crews wear thick gloves, work in dim hangars, and need buttons large enough to press without removing their gloves, not because someone wrote it in a persona document, but because they had stood in those hangars and watched. When AI tools started entering the product workflow, something interesting happened. Those domain experts did not become less valuable. They became more valuable. The tools could generate wireframes, draft requirements, and prototype interactions at remarkable speed. But the tools could not tell you whether a proposed interface would pass an FAA inspection. They could not predict that a particular workflow change would conflict with union agreements about maintenance shift protocols. They could not flag that a data display format, perfectly logical in software terms, would be unreadable to a technician lying on their back under a fuselage. AI commoditised execution. It did not commoditise knowing what a cardiac surgeon needs at 3am during an emergency procedure. The Boeing domain experts did not think of their knowledge as a career differentiator. They thought of it as just knowing their job. But "just knowing your job" turned out to be the thing the market valued most, precisely because it was the one thing that could not be automated or acquired through a weekend course. The Generalist's Reckoning I mentored a product designer named Priya who was, by every standard measure, excellent. Her portfolio was diverse. She could work across B2B and B2C. She had experience in mobile, web, and even a brief stint in hardware. She had completed two product certifications. Her interview skills were polished. She was good at everything. But good at everything turned out to mean expert at nothing. Priya spent four months on the job market in early spring. She kept losing out in final rounds to candidates who had deep domain expertise, a fintech specialist here, a healthcare product lead there. The feedback was always some version of the same sentence: "We loved her skills, but the other candidate understood our industry." She called me after her third rejection, frustrated. She had done everything the career advice said to do. She had broadened her skills, diversified her experience, built a range of competencies. And the market was now telling her that range was not enough. We talked through her career history, looking for the thread she had been ignoring. Before product design, Priya had spent three years at a logistics company, doing operations before she transitioned into design. She knew warehouse management systems. She understood the difference between last-mile and first-mile delivery. She could talk about order fulfilment in the concrete language of someone who had actually watched packages move through a sorting facility. She had treated that logistics experience as a past life. I told her it was her future. Priya rebuilt her portfolio and positioning around logistics and supply chain product design. Not exclusively, but as her primary domain lens. Within a year, she had three competing offers from companies building logistics technology. Not because her design skills had improved (they were already strong) but because she paired those skills with domain knowledge that hiring managers could not find easily. The domain premium is real. It is the market's way of saying: we can teach someone our frameworks, but we cannot teach them ten years of knowing what a warehouse operations manager needs. Why Depth Beats Breadth Now The instinct for most product people is to resist specialisation. It feels limiting. It feels like closing doors. Every career coach told you to stay broad, stay flexible, stay adaptable. And that advice was correct for a world where execution skills were scarce and valuable. But that world ended. Quietly, without a formal announcement, sometime in the last eighteen months. The product professionals who are thriving right now are the ones who went deep. Healthcare PMs who understand clinical workflows and regulatory pathways. Fintech PMs who can explain clearing and settlement systems from memory. Logistics PMs who know why a route optimisation algorithm fails in rural Southeast Asia (I learned this one at Grab, where the map data in some regions was so unreliable that the algorithm's "optimal" routes sent drivers down roads that did not physically exist). Depth is not a limitation. It is a moat that AI cannot drain. This does not mean general product skills are worthless. They remain necessary. You still need to run a sprint, write a spec, analyse data, communicate with stakeholders. But those skills are now the floor, not the ceiling. They get you into the building. Domain expertise is what gets you the offer. The generalist plateau is real, and most product people are standing on it right now, looking around at a crowd of equally qualified professionals, wondering why the market feels so crowded. The answer is that it is crowded, at that altitude. The air thins considerably when you climb into genuine domain expertise. Fewer people up there. More oxygen. Better view. The career question worth sitting with is not "what skills should I add?" It is "what domain have I been accumulating knowledge in, possibly without realising it, that I should double down on?" The answer is usually hiding in plain sight, in the industry you keep gravitating back to, in the problems that hold your attention longer than they should, in the meetings where you notice things that your generalist colleagues miss. The most valuable thing you know might be the thing you have been treating as background noise.

Product Leadership & CareerJune 6, 2025

The weekly review is not a productivity trick. It is how you stop drowning.

The most productive product people you know are not working more hours than you. They are not using a better task manager. They are not running on discipline you lack or caffeine you have not discovered. They are doing one thing you are probably not doing, and it takes less than an hour a week. They are reviewing. Not reviewing their work. Reviewing their commitments, their assumptions, and the gap between what they think they are doing and what they are actually doing. That distinction matters more than any tool or method you will encounter this year. The problem you already know you have If you manage more than one workstream, you know a specific kind of anxiety. It sits in the background like a low hum. You cannot quite name it. But it shows up as a recurring sense that something important is slipping, that your week is being shaped by whoever shouts loudest rather than by what matters most. You are not imagining it. Something is slipping. But the issue is not that you are careless or disorganised. The issue is structural. I call it The Accumulation Trap. In product roles, demands arrive faster than they can be processed. Commitments stack up across Slack threads, meeting notes, casual hallway promises, and the half-formed ideas you told yourself you would get to later. Each one feels manageable. But collectively, they form a debt that compounds silently until something breaks. The Accumulation Trap does not punish you immediately. It punishes you eventually, and always at the worst possible moment. I learned this the specific, humiliating way at Freshworks. We were running three parallel workstreams, and I was confident I had it all in hand. I tracked tasks in a tool. I had a system (or thought I did). But one Friday afternoon, our VP asked about a partnership integration we had discussed three weeks earlier, one where I had committed to delivering design specifications by end of month. I had no memory of making that commitment. None. There it was in the meeting notes, in my own words. The specifications were not late. They had never been started. The commitment had been made in a meeting, lived briefly in my short-term memory, and then been overwritten by the next forty things that arrived. That was the week I started doing a weekly review. Not because I read a productivity book. Because I had been embarrassed in a room full of people I respected. What a weekly review actually is The version gaining traction in product circles is not a general-purpose life audit. It is specific, and its specificity is what makes it work. Four steps, done once a week. The timing matters less than the consistency. But the sequence matters a great deal. First, you review every open commitment. Not just the ones in your task manager. The ones in Slack, in meeting notes, the ones you said yes to verbally and never wrote down. This step alone produces a kind of productive horror. The gap between what you think you have committed to and what you have actually committed to is, in my experience, never less than 30 per cent. Second, you capture anything still held in your head. Ideas, concerns, questions, follow-ups. Your brain is a terrible storage device. It is an excellent processing device, but only when it is not also trying to remember seventeen things. Third, you identify the single most important thing for the coming week that is not currently on your calendar. Not the most urgent. The most important. These are almost never the same thing. Fourth, you note any decision that has been deferred and now needs resolution. Product work generates deferred decisions at an astonishing rate. Should we cut that feature? Should we escalate that blocker? Left unexamined, deferred decisions accumulate into strategic fog. The weekly review is where you name them. I think of this four-step practice as The Clarity Sweep. Its value is not in the doing. Its value is in the gap it reveals between your mental model of your week and the reality of your week. Why product people specifically need this Every profession has its cognitive load. But product work has a particular quality that makes it uniquely vulnerable to the Accumulation Trap: the inputs are constant, varied, and arrive from every direction. Engineering has questions. Design has decisions. Sales has requests. Leadership has priorities that shifted since last Tuesday. A weekly review is not a luxury for people in this position. It is the minimum viable mechanism for maintaining intention. But here is the part that took me years to understand. The review does not make you more efficient. It makes you more intentional. Those are different things, and the difference is the entire point. At Grab, I watched a product lead who seemed to operate with a calm that the rest of us found almost suspicious. We were all running the same number of workstreams across Southeast Asian markets, drowning in the same volume of Slack messages. But she never seemed surprised by anything. She never dropped commitments. She never scrambled on a Monday morning. When I asked her about it, she described a practice almost identical to what I have outlined above. Every Sunday evening, forty-five minutes, at her kitchen table with a cup of tea and a notebook. She reviewed everything. She identified the one thing. She named the deferred decisions. Then she closed the notebook and went to bed. "It is the only time all week when I am thinking about my work instead of reacting to my work." That line stayed with me. The resistance you will feel The weekly review sounds simple. It is simple. But most product people who try it stop within three weeks. First, it feels slow. In a role that rewards responsiveness, sitting still for forty-five minutes feels like standing in the rain while everyone else runs for cover. But the people running are getting wet too. They just do not notice until they arrive somewhere important, dripping. Second, the review produces discomfort. When you honestly catalogue your open commitments, you discover things you have been avoiding. Decisions deferred because they are hard. Promises you cannot keep. The review does not create these problems. It makes them visible. Visibility is uncomfortable, which is why people stop doing the thing that produces it. Third, it requires admitting your memory is not enough. Senior product people tend to believe they can hold everything in their heads. This belief is both flattering and false. But it persists because the failures it produces are distributed across weeks, not concentrated in a single visible moment. The weekly review is not a productivity trick. It is the mechanism that converts chaos into choices. The compounding effect is not obvious for the first month. But by month two, something shifts. You start your weeks knowing what matters rather than discovering it on Tuesday. You stop making promises you cannot keep, because you can see the full picture rather than the fragment that arrived most recently. The weekly review does not give you more time. It gives you more clarity. And in a role where the quality of your decisions is the thing you are actually paid for, clarity is the variable that changes everything else. Somewhere between the third and fourth month, the low hum goes quiet. Not because the demands have stopped arriving. Because you have finally built a practice that is larger than the chaos it contains.

Productivity & Working MethodsJune 1, 2025

Stated preferences vs actual behaviour: The feedback trap

I once spent three months at Adobe leading a research programme that would, I was absolutely certain, produce the clearest product direction our team had seen in years. We interviewed forty-two enterprise users. We ran surveys. We held workshops with sticky notes and dot voting and all the sacred rituals of user-centred design. The findings were unambiguous: users wanted deep customisation. They wanted control over layouts, workflows, toolbars, and default settings. They wanted the product to bend to how they worked, not the other way around. So we built it. An elaborate customisation layer. Flexible layouts, configurable panels, adjustable defaults for nearly everything. The engineering team spent months on it. We were proud. But then we shipped it. And 94% of users never touched any of it. Not a single customisation option. They opened the product, used the defaults, and carried on with their day exactly as they had before we gave them everything they said they wanted. The research was technically accurate. Users genuinely believed they wanted customisation. They were not lying in those interviews. But the gap between what people say they value and what they actually do when the moment arrives is so wide you could lose an entire product roadmap inside it. We did. The feedback trap This is a pattern I have seen repeated at every company I have worked at, and every company I have advised. I call it the feedback trap: the belief that what users tell you in research is a reliable predictor of what they will do in the product. It sounds reasonable. It feels rigorous. But it produces a specific, expensive failure mode. You build with confidence for a user who does not exist. The fictional user is the person described by your research data. They care about privacy. They want granular control. They read the settings page. They compare options before choosing. They make deliberate, considered decisions about every feature they engage with. But the real user is late for a meeting, has fourteen browser tabs open, chose the first option that looked reasonable, and has never once opened the settings page of anything on their phone. User feedback is a story users tell about themselves, not a report on what they actually do. And the story is always more flattering than the reality. But this is not dishonesty. It is something more interesting. When you ask someone in an interview what they value, they give you their aspirational self. The version of them that reads ingredient labels, uses a password manager, and would absolutely pay for premium features. But aspiration is not behaviour. The person who tells you they care deeply about data privacy is the same person who clicked "accept all cookies" fourteen times before lunch. But not because they stopped caring. Because caring takes effort, and effort competes with everything else in their day. What the shopping trolley knows There is a well-known problem in nutrition research. Ask people what they eat, and they will report a diet that is healthier, more varied, and more intentional than anything their shopping trolley would confirm. The answers are different people. One is the person answering the survey. The other is the person standing in the supermarket aisle at six in the evening, tired, hungry, and reaching for whatever is fastest. But product research has the same problem. The interview room is the survey. The product is the supermarket aisle. At my first startup, we learned this in the most painful way possible. We had a small but loyal user base, and we did what every responsible product team does: we talked to them. We ran interviews. We asked what features they wanted. Three specific requests came up repeatedly, across dozens of conversations. Build these three things, the users told us, and you will have something special. So we built all three. We shipped them over the course of two months, each one announced with the confidence of a team that had listened carefully and responded. Adoption across all three was near zero. Not low. Near zero. The features sat in the product like furniture in a room nobody enters. But here is the part that still bothers me. The features users actually adopted, the ones that drove engagement and retention, were things nobody had asked for. They came from session recordings. From watching what people actually did in the product, where they got stuck, where they abandoned a task, where they repeated the same action three times because the flow did not match their mental model. The friction they experienced but never articulated in an interview was where the real product opportunities lived. The two research modes I am not arguing that user feedback is useless. I am arguing that it answers a different question than most teams think it answers. Feedback tells you what users believe about themselves. Behaviour tells you what users actually do. You need both. But if you have to choose (and most teams, with limited resources, do have to choose), behaviour wins every time. The teams I have seen build the best products treat user interviews as hypothesis generators, not hypothesis validators. What a user says in an interview is a starting point for observation, not a conclusion to design from. You hear "I want customisation," and instead of building customisation, you ask: why do they think they want it? What problem are they actually trying to solve? And then you watch them use the product and see whether the problem they described matches the problem they experience. But most teams do not operate this way. Most teams treat research findings as requirements. The users said they wanted it. The data supports it. The roadmap is clear. And six months later, the feature sits unused, and nobody can explain why. Every product I have seen fail because of misread user intent followed this exact sequence. The research was rigorous. The methodology was sound. The team listened carefully. And they built for the fictional user, the aspirational, considered, preference-articulating version of their customers, rather than the real one. Where the truth lives But the uncomfortable reality is that users cannot tell you what they will do. Not because they are unreliable witnesses. Because they do not know. The gap between intention and action is not a research flaw. It is a feature of how human decision-making works. We overestimate our own rationality, our own consistency, our own willingness to do the thing we said we would do. The best product researchers I have worked with have a specific habit. They treat every stated preference as a question, not an answer. Someone says "I want more control"? That is not a design brief. That is an invitation to find out what "control" means when the person is tired, distracted, and trying to finish a task before their next meeting. At Adobe, we eventually removed most of the customisation layer. But not because we stopped believing in user choice. Because we realised that the choice users were actually making, consistently and overwhelmingly, was to not choose at all. The best default is the one that makes the decision for the user so they never have to think about it. That is not removing control. That is understanding what control looks like when it meets real life. The fictional user wants options. The real user wants to be done.

User & Buyer PsychologyMay 29, 2025

Building something, anything, as proof of intent: The prototype as co founder pitch

A screenwriter I know spent two years trying to get meetings with producers in Mumbai. She had three scripts, all polished. She sent query letters, attended industry events, cornered people at after-parties and delivered her pitch in the three minutes before they made an excuse to refill their drink. Nothing worked. Then she took her weakest script, borrowed a friend's camera, recruited two theatre actors who owed her favours, and shot a twelve-minute short film over a weekend. The sound was uneven. One of the actors kept looking at the wrong camera. But within a month, three producers contacted her. The same people who had ignored her scripts wanted to talk. Nothing about her talent had changed. What changed was the signal. She had moved from "someone who writes scripts" to "someone who makes films." The doing was the proof. I keep thinking about that story when I watch non-technical founders try to recruit co-founders. The credibility threshold There is a moment in every non-technical founder's journey that I call the credibility threshold. It is the point at which the people you need (engineers, investors, early customers) stop evaluating your idea and start evaluating you. Not your pitch. Not your market analysis. You. A pitch deck cannot cross the credibility threshold. I have watched dozens of founders try. The deck describes a problem, proposes a solution, shows a market size number borrowed from a research report, and ends with an ask. The person on the other side listens politely, asks a question or two, then says "interesting" and never follows up. I can almost set my watch by the pause before "interesting." It is the most diplomatic rejection in the startup vocabulary. But a working prototype, even an ugly one, crosses the credibility threshold almost immediately. It does not answer the question "is this a good idea?" It answers a different question: "Is this person going to do the work?" The deck says "I had an idea." The prototype says "I could not stop myself from building it." Those are not the same sentence. They are not even the same conversation. Six months of silence, three weeks of building One of the founders I mentor, a woman with a decade of experience running operations for a logistics company in Chennai, spent six months trying to find a technical co-founder. She had a strong idea: a tool that helped small manufacturers track and reconcile purchase orders across multiple suppliers. She had watched her former employer struggle with this using spreadsheets for years. She understood the problem deeply. Her deck was genuinely good. Clean, specific, grounded in real operational pain. She took it to startup meetups, WhatsApp groups, LinkedIn messages to engineers she admired. Six months. Dozens of conversations. The response was always warm and always noncommittal. "Sounds interesting, keep me posted." "Let me think about it." Nobody said no. Nobody said yes. Then she spent three weeks using AI coding tools to build a rough prototype. The interface had default styling. Some features were half-built. But it worked. You could enter a purchase order, match it against supplier invoices, and flag discrepancies. The core workflow functioned. Within a month, two engineers had reached out asking how they could get involved. Not because the prototype proved the product would work. But because the prototype proved she was serious. It crossed the credibility threshold that six months of polished slides could not. A prototype does not prove your product will work. It proves you have started. That distinction is worth more than most founders realise. The difference was not in the idea. The idea had been the same for six months. The difference was in the signal. The deck said "I need your help to make this real." The prototype said "I have already started, and I am looking for someone to build this with me." The first is a request. The second is an invitation. What I learned at my first startup I remember this dynamic from my own experience, years before AI tools existed. At my first startup, we spent months pitching advisors and early customers with slides. Beautiful deck. Market research. Clear problem articulation. And we got polite nods and very few commitments. Then we built something. It was ugly. The kind of ugly that makes a designer (which I am) physically uncomfortable. But it was real. You could click through it, see data, experience what we were trying to build in a clumsy and imperfect way. Every conversation changed after that. Advisors who had been noncommittal started giving specific feedback. Potential customers who had said "keep me posted" started saying "can you add this feature?" The questions shifted from abstract ("what is your go-to-market?") to concrete ("what happens when a user does this?"). Concrete questions mean someone is mentally using your product. Abstract questions mean someone is mentally evaluating whether to ignore you politely. But the most important thing the prototype did was change how people treated us. We went from "people with an idea" to "people who are building something." We were no longer asking for belief. We were asking for participation. The intent signal I call this the intent signal, and I have come to believe it is the single most underrated asset a non-technical founder can create. The intent signal is what a prototype communicates beyond its functionality. It says: I cared enough about this problem to build something. I did not wait for permission. I did not wait for a co-founder. I did not wait for funding. I started. That signal is disproportionately powerful because most people do not start. Most people with startup ideas talk about them. Some write decks about them. A few post about them on social media. But very few actually build something, no matter how rough, and put it in front of other people. The act of building is rare enough that it functions as a credibility signal independent of what you built. But the intent signal has a counterintuitive quality. The prototype does not need to be good. It needs to be real. A polished deck communicates that you are good at making decks. A rough prototype with misaligned buttons communicates that you have started building the actual thing. Co-founders and investors are not looking for someone who can present well. They are looking for someone who will persist. I have seen this with angel investors too. At the pre-seed stage, they are not evaluating your technology. They are evaluating your probability of still working on this in twelve months. A working prototype is stronger evidence of persistence than any slide about founder-market fit. The bar has moved The interesting thing about AI coding tools in this context is not that they make prototypes better. It is that they make prototypes possible for people who could never build them before. The intent signal used to be accessible only to technical founders or those with enough money to hire a developer. That gate has opened. But the signal still works for the same reason it always worked. It is not about the code. It is about what the act of building communicates about the person who built it. The founders I mentor who arrive with a working prototype, even a terrible one, have better conversations and attract better collaborators than those who arrive with a deck. Every time. The prototype does not close the deal. But it opens a door that no amount of slides can open. Building something is not proof that your product will succeed. It is proof that you are the kind of person who builds. And in the earliest stages, that is the only proof that matters.

Building & FoundingMay 22, 2025

The Seatbelt nobody notices

In 1968, the United States government made seatbelts mandatory in all new passenger vehicles. Adoption was slow. Wearing a seatbelt felt optional to most drivers for another decade. But by the early 1990s, the cultural shift was essentially complete. Seatbelts became automatic. Invisible. An assumption so foundational that a car without them would be unthinkable. And nobody buys a car because it has seatbelts. Not one automotive marketing campaign has ever led with seatbelt availability. No consumer rates a car highly because the seatbelt mechanism was particularly smooth. The feature is there. It is required. It is noticed only when it is missing or when it fails. It has become, in the language of product development, table stakes. This is where UX has arrived. And the profession has not fully worked out what to do about it. The argument that has been circulating with increasing seriousness this year is that the return on investment in UX has declined. Not because good UX stopped mattering, but because the baseline has risen so steeply that the marginal value of additional investment is harder to demonstrate. Users no longer reward usability with loyalty the way they once did. They punish poor usability with abandonment, but they do not celebrate excellent usability as exceptional. It has become expected. Jakob Nielsen made a version of this argument recently and it generated the predictable reaction: one camp treating it as evidence that UX was always overrated, another defending the discipline as if the argument itself were an attack. Both reactions missed the point. The argument is not that usability doesn't matter. It is that usability has become a threshold rather than a differentiator. You need to clear it to be in the game. But clearing it no longer wins the game. I remember when this felt different. Early in my career, designing a product that was genuinely easier to use than its competitors was a commercial argument in itself. You could point to the onboarding flow, show the drop-off comparison, and make the case that design was directly moving the number. The competition was often so poor that good design stood out by default. That gap has closed. Not everywhere and not completely, but enough that the old argument has lost its automatic credibility. The product category I spent two years working in at a SaaS company had, by the time I left, four direct competitors with user research programmes, design systems, and UX teams that were doing serious, careful work. The baseline experience across all five products was genuinely comparable. In that environment, usability is no longer the differentiator. Something else has to be. But this is not a crisis. It is a maturity signal. And the way a discipline responds to maturity reveals something important about whether it has built its identity on craft or on novelty. Medicine has always had table-stakes expectations. A doctor who correctly diagnoses a straightforward illness is not celebrated for exceptional skill. But medicine did not conclude that diagnosis no longer matters. It concluded that the differentiation now lives in the harder cases, the novel presentations, the problems that require judgment rather than pattern matching. UX is moving into exactly that territory. The straightforward cases, the standard flows, the conventional navigation patterns, these are increasingly handled by mature patterns, design systems, and now AI-assisted generation. The differentiation lives elsewhere. It lives in the edge case that the pattern cannot handle. In the user population whose mental model doesn't match the assumption baked into the template. In the product category that is genuinely new and has no established convention to follow. In the moment when doing the expected thing would be technically correct but wrong for this specific user in this specific context. That is not less important work than what came before. But it is different work. And it requires designers who have built their professional identity on judgment rather than on being the person in the room who knows what good usability looks like. The seatbelt is not a failure of automotive safety. It is proof that safety worked well enough to become invisible. That is not a diminishment. That is the goal of any well-designed system. The question for UX is what happens next, now that the seatbelt is fitted and nobody is talking about it. The answer is not to make the seatbelt fancier. It is to find the next problem that hasn't been solved yet. Those problems exist. But finding them requires looking past the table stakes toward the territory where the baseline has not yet arrived.

Product Design & Craft TopicsMay 12, 2025

Writing as thinking: The cognitive tool we are outsourcing before we understand it

In 2019, at Freshworks, I wrote the single worst product brief of my career. I had been asked to build the case for a new feature direction that would require pulling engineers from two active projects. I sat with a blank document for an hour. I typed a paragraph, deleted it, typed another, deleted that, and produced four pages that read like a man arguing with himself. My manager read it the next morning and said, very gently, "I think you are still figuring out what you believe." He was right. But here is the part I did not understand until much later. By the time I finished that miserable draft, I understood the problem differently than when I started. The brief was terrible. The thinking it forced was not. Somewhere around the third deleted paragraph, I realised my original framing was backwards. The feature I wanted to propose was solving a symptom, not a cause. I would not have seen that if I had not been forced to put my reasoning into sentences that refused to cooperate. I did not sit down knowing what I thought and then write it down. I sat down confused, and the act of writing showed me what my confusion was actually about. The ordinary world For most of my career, writing was just overhead. Product briefs, strategy documents, design rationales, meeting pre-reads. Nobody called these cognitive activities. They were the paperwork that surrounded the real work of building products. But it was never just paperwork. The thinking happens invisibly, embedded inside the act of composing sentences. You start a brief believing you understand the problem. By the third paragraph, you discover a gap in your reasoning that was not visible until you tried to explain it to an imaginary reader. That discovery is the work. The document is just the residue. I call this the first-draft tax. It is the cognitive cost of forcing yourself to turn vague intuitions into specific, ordered sentences. It is slow. It is uncomfortable. It is occasionally humbling when you realise that your confident opinion evaporates the moment you try to write it down. But the tax is where the thinking happens. Skip the tax, skip the thinking. The call that sounds like a gift AI writing tools are now offering to eliminate the first-draft tax entirely. Describe your product direction in three sentences, receive a polished brief in thirty seconds. The output reads like it was written by someone who understood the problem thoroughly. But the person who prompted the brief did not go through the cognitive process that writing forces. They received clarity without earning it. I tested this myself earlier this year. Instead of writing a brief from scratch, I described a product concept to an AI tool and asked it to generate one. The result was impressive. Clear problem statement, logical flow, reasonable assumptions. But when I sat with the document, something felt wrong. Not factually wrong. Epistemically wrong. The brief was articulate about a problem I had not yet fully understood. It had the shape of finished thinking without any thinking having been done. I have started calling this borrowed clarity: the appearance of having thought something through without the actual process of thinking it through. The document looks like understanding. But nobody did the understanding. It is a receipt for a meal nobody cooked. The ordeal At Adobe, I worked with a product manager named Kavitha who wrote every first draft by hand, in a notebook, before typing anything. Her colleagues found this eccentric, even performatively old-fashioned, like insisting on a quill pen. But her briefs were consistently the sharpest in the organisation. When I asked her why, she said something that has stayed with me since: "If I cannot explain it without a backspace key, I do not understand it yet." That line contains the whole argument. Writing is not the recording of thoughts already formed. It is the process by which thoughts become formed. The resistance of the blank page, the requirement to choose one word over another, the need to put ideas in sequence, these are not obstacles to thinking. They are thinking. And they are precisely the elements that AI-generated first drafts eliminate. I have started noticing the difference in briefs I review. The ones written from scratch, even when rougher, contain genuine insight somewhere in the middle. A paragraph where the author clearly worked through a contradiction or arrived at something unexpected. The AI-assisted briefs are smoother but flatter. The author prompted, reviewed, approved. But they did not wrestle. The first-draft tax is not a bug in the writing process. It is the feature. What to protect I am not arguing that AI has no place in product writing. That would be absurd, and I limit myself to one absurd position per quarter. AI is excellent for editing, restructuring, and turning a rough draft into something presentable. But there is a critical distinction between using AI to improve thinking you have already done and using AI to replace thinking you have not done. The first is a tool. The second is a shortcut that produces documents without producing understanding. Product work is, at its core, a thinking discipline. The brief is not the deliverable. The understanding is the deliverable. The brief is the mechanism by which understanding gets produced. When we outsource the mechanism, we risk outsourcing the understanding along with it. I mentor junior PMs, and I give them a specific instruction: write your first draft without AI. Sit with the blank page and struggle. Let the struggle reveal what you do not yet understand. Only after you have a draft that represents your own thinking should you use AI to sharpen or polish it. Some of them look at me the way you might look at someone recommending you churn your own butter. I understand the reaction. But the ones who follow it consistently report the same thing: they did not realise how much of their thinking was happening during the writing. They thought the thinking came first and the writing came second. It does not. That is the first-draft tax doing its job. The return There is a version of this that sounds like technological conservatism, like arguing that calculators will rot your arithmetic. But the analogy does not hold. Calculators automate computation, which is mechanical. Writing is the process by which ambiguous, half-formed ideas get forced into clarity through the friction of language. There is no mechanical step to skip. The effort is the product. I think about that brief at Freshworks, the one that took ninety minutes and read like an argument with myself. If I had prompted an AI tool with the same information, I would have received a polished document in seconds. But I would not have discovered that my framing was backwards. I would have had a document. I would not have had understanding. The convenience is genuine. The speed is real. But the question product teams have not yet thought to ask is: what are we losing when we stop paying the first-draft tax? The answer is not polish or craft. It is the thinking itself. Writing has always been the cheapest cognitive tool available to anyone who works with ideas. It requires no software, no facilitator, no meeting room. Just a willingness to sit with a blank page and let it show you what you do not know. The strange thing about outsourcing that process is that you do not notice what you have lost until much later, when a decision fails and you trace it back to a brief that sounded clear but was never thought through.

Communication & Storytelling May 1, 2025

Outcome-based pricing: Paying for results, not access

There are two kinds of lawyers in the world. The first bills you for every hour spent on your case, win or lose. The second takes nothing upfront and charges only if you win. Same profession. Same courtroom. Completely different relationship with the person paying. The hourly lawyer has no structural incentive to resolve your problem quickly. Every extra hour is revenue. The contingency lawyer, on the other hand, only eats if you eat. Their incentive is perfectly aligned with yours: get the result, get paid. Skip the result, get nothing. That is not a legal distinction. That is a pricing architecture distinction. And it is the exact fault line running through software right now. The access trap For most of its history, software has been sold like the hourly lawyer. You pay for the right to use it. Seats, licences, monthly fees. Whether the software actually solves your problem is, commercially speaking, your concern. The vendor's obligation ends at the login screen. I spent years inside this model and never questioned it. At Boeing, we built fleet management tools for aviation clients. The software tracked maintenance schedules, parts inventories, operational readiness. But here is what I noticed in every single client conversation: nobody talked about the software. They talked about aircraft uptime. They talked about how many planes were operational on a given morning. They talked about the cost of a grounded aircraft sitting on tarmac burning money at several thousand dollars per hour. The software was a means. Uptime was the end. But we charged for the means. That is what I call the access trap. It is comfortable because nobody has to prove anything worked. The vendor delivers the tool. The buyer uses the tool. Whether the tool actually produces the outcome both parties presumably care about is a question that lives in the gap between them, unanswered and unpriced. But the gap is closing. The resolution economy Intercom's decision to charge per resolved support ticket is the clearest signal of what is shifting. Not per seat. Not per message sent. Per resolution. The customer pays when the AI actually fixes the problem. If it does not fix the problem, the customer pays nothing. This is not a pricing tweak. It is a structural inversion. The vendor now carries the risk that used to sit entirely with the buyer. And that changes everything about how the product gets built, measured, and improved. When you charge per resolution, you cannot afford ambiguity about what a resolution is. You cannot afford a product that sort of helps. You cannot afford to ship features that look good in a demo but collapse under real conditions. Every unresolved ticket is revenue you did not earn. The feedback loop between product quality and commercial outcome becomes immediate and unforgiving. Access was the old currency. Outcomes are the new one. But outcomes require something access never did: proof. The measurement problem nobody wants to talk about Here is where the theory gets uncomfortable. A few years ago, I was mentoring a founder building a hiring platform. She had a sharp instinct: charge companies only when a candidate they hired through the platform stayed past the 90-day mark. Pay for the outcome, not the access. Elegant on a whiteboard. But the questions started immediately. What if the candidate left because the company had a terrible onboarding process? What if the hiring manager changed their mind about the role? What if the candidate got a better offer from somewhere else? The "outcome" her platform was pricing against depended on dozens of variables she could not control. She spent four months trying to define "successful hire" in a way that was fair to both sides. She never found a definition that survived contact with reality. Eventually, she moved to a hybrid model: a base fee for access, with a bonus tied to retention. Not pure outcome-based. But honest about the limits of what she could measure and guarantee. That is the lesson most outcome-based pricing advocates skip past. When the outcome is clean and attributable (a support ticket is resolved, a flight is on time, a transaction completes), outcome pricing works beautifully. But when the outcome is fuzzy, shared, or influenced by factors outside the vendor's control, it creates a measurement problem that can poison the relationship it was supposed to improve. The access trap is comfortable because nobody has to prove anything worked. But the outcome trap is a different kind of danger: it forces you to prove something you might not fully control. What this means for product teams If you are a product leader thinking about outcome-based pricing, the first question is not commercial. It is architectural. Can your product reliably measure the outcome you want to price against? Not approximately. Not with caveats. Reliably. At Boeing, the answer was surprisingly clear. Aircraft uptime is measurable, timestamped, and attributable. A fleet management system that demonstrably improved uptime by even a small percentage could justify a price tied to that improvement. The maths was legible to everyone in the room. But most products do not have outcomes that clean. A project management tool makes teams more productive. Probably. A design tool helps designers work faster. Maybe. An analytics platform helps companies make better decisions. Possibly. The further you move from a concrete, measurable, attributable outcome, the harder outcome-based pricing becomes. This is why the shift is happening fastest in AI products. AI-driven customer support (like Intercom's model) produces a binary, trackable result: the ticket was resolved or it was not. AI-driven code generation can measure whether the code compiles and passes tests. The outcome is not a feeling. It is a data point. But for every product where the outcome is a data point, there are ten where it is a judgment call. And judgment calls make terrible pricing metrics. The honest middle ground The products that will get this right in the next few years will not be the ones that go fully outcome-based overnight. They will be the ones that build measurement into the product from the start, treating attribution and tracking as first-class product problems rather than afterthoughts for the finance team. They will also be the ones honest enough to admit where their influence ends. A support AI can own the resolution. A hiring platform cannot own the retention. Knowing the difference between those two is not a pricing decision. It is a product maturity decision. The resolution economy is not replacing the access economy everywhere. It is replacing it where outcomes are clean, attributable, and worth more to the buyer than the access itself. That is a smaller territory than the hype suggests. But it is growing. The real question is not whether your product can charge for outcomes. It is whether your product can prove them. And for most teams, that question has never been asked aloud, because the access model never required it. Now it does.

The Business of ProductsApril 27, 2025

The correct translation

There is a specific failure mode in automated translation that professional translators call a correct wrong answer. The sentence is grammatically sound. The vocabulary is accurate. Every word maps to an accepted equivalent in the target language. And the translated sentence means something subtly but completely different from what the original intended. The machine did not make an error by any measure available to it. But a human reader of both languages, familiar with the culture the sentence was written inside, would catch it immediately. Because the correct answer requires knowing something that was never in the text. I keep coming back to that failure mode as I watch what is happening to design tools right now. Figma's AI features can now generate complete interface layouts from a text prompt. The outputs are technically competent. They follow grid systems, apply typographic hierarchy, apply consistent spacing. Show the output to someone who does not design for a living and they will often say it looks professional. Show it to a senior designer with ten years of experience shipping products and they will tell you, usually within thirty seconds, what is wrong with it. Not that it looks bad. But that it is optimised for legibility at first glance rather than usability over time. That it has solved the visual problem without engaging with the interaction problem underneath it. That it is the correct wrong answer. This distinction is subtle and it is everything. I was working with a team last year that was using AI tools to accelerate early-stage design exploration. The tools were genuinely useful for generating layout options quickly, for getting to a range of directions without spending three days on each one. The speed was real and the efficiency gains were real. But something started happening around the third week. The team was moving fast through options but converging slowly on decisions. The AI could generate ten directions in two hours. But evaluating those ten directions, understanding which ones were actually solving the right problem and which ones only looked like they were, that work was taking longer than it had before. The generation had accelerated. The judgment had not. In the end, the project took roughly the same amount of time it would have taken without the tools. The shape of the work had changed. But the total cognitive load had not moved. What AI tools accelerate in design is the production of surface. Layout, visual treatment, component selection, spacing systems. These are real skills and they take real time, and getting faster at them has genuine value. Nobody who has spent an afternoon wrestling with an auto-layout bug will be nostalgic for the hours those bugs consumed. But surface is not the job. Surface is the visible layer of a decision that happened somewhere earlier and deeper. Why this information hierarchy and not another. Why this interaction model given what we know about how this specific user population reads and clicks and makes errors under pressure. Why simplicity here and detail there, and what the user needs to trust to make the next step. Those decisions require context that was never in the prompt. They require the scar tissue of watching users fail at things that seemed obvious. They require the specific knowledge of what went wrong the last time someone tried this approach in this category. No tool has that. The designer does. The conversation about automation and craft in design keeps getting framed as a binary. Either AI replaces design work, or craft is safe. Both positions are wrong and both produce the wrong response. The work that is being automated is real work. It took real skill. Designers who built professional identities primarily around production speed are going to feel this change acutely, because the thing they were faster at is now less differentiated. But the work that is not being automated is also real work. And it is, arguably, the more important work. The framing of the problem. The recognition that the generated output is technically correct but contextually wrong. The judgment that the brief itself needs to be challenged before the solution gets built. A translator who catches the correct wrong answer is not doing less work than the machine. They are doing different work. Harder work. Work that requires something the machine structurally cannot have: the knowledge of what was meant. That is still the designer's job. But only if they decide it is.

Product Design & Craft TopicsApril 8, 2025

The Pub that's been open thirty years isn't running ads

For most of the last decade, growth meant one thing. New users. New signups. New trials. The metric at the top of the dashboard was always some version of the same number: how many people came in this month who weren't here last month. Every team I worked with in that period had a version of this conversation in their quarterly reviews. Acquisition was the engine. Everything else was performing a supporting role, gratefully. Every day, product and marketing teams built around the same assumption: the path to a bigger business ran through a bigger top of funnel. More reach, more signups, more chances to convert. The growth playbook was written for a world where attention was cheap, CAC was manageable, and a user who churned could be replaced by three more arriving behind them. It was a sensible playbook. But it was written for conditions that have quietly stopped being true. Until the math stopped working. CAC started climbing in a way that felt gradual and then suddenly didn't. The users coming in through paid channels were converting at lower rates. The ones who were converting were staying for shorter periods. The economics that had made acquisition-led growth feel like a permanent strategy started revealing themselves as something more contingent: a set of market conditions that had been unusually favourable for an unusually long time. Because of that, teams started looking at the other side of the equation. Because of that, the question that had been sitting quietly in the background for years finally forced its way into the planning conversation: what does it actually cost to keep someone versus what does it cost to find someone new? Until finally, the answer was uncomfortable enough that it required a different strategy entirely. And the teams that started rebuilding around retention are discovering something that changes the shape of the whole business. There is a pub near where I grew up that has been open for thirty-one years. It has never run an advertisement. It has never had a loyalty programme. It does not have a social media presence worth mentioning. It is full most evenings. The owner's answer, when I asked him about it once, was simple enough that it took me a while to understand what he was actually saying. "The regulars bring the new people," he said. "I just have to make sure the regulars want to come back." That's the retention economy stated plainly. The regular customer is not just a revenue stream. They are a distribution channel, a quality signal, and a credibility mechanism that no acquisition spend can replicate. The pub that fills up because of its regulars is a fundamentally different business from the pub that fills up because of a discount promotion. Same number of covers. Different economics. Different durability. But most product businesses have been running the discount promotion model and calling it growth strategy. And then wondering why the regulars aren't showing up. The specific thing that changes when a team genuinely reorients around retention isn't the dashboard. It's the product decisions. An acquisition-oriented product is optimised for the first impression. The landing page, the onboarding flow, the moment of signup. Everything downstream of that is important but treated as secondary. The machine is built to fill the top of the funnel and hope enough makes it through. But a retention-oriented product is optimised for the twentieth visit. What does the user need after they already know how to use it? Where does the product create new value as the user's workflow matures? What makes coming back feel different from staying away? Those are different design questions. And they produce different products. But most teams don't discover that until they've spent three years writing roadmaps for the wrong user. I worked with a team this year who had been acquisition-focused for three years and decided to make the shift. The first thing that changed was where they pointed their user research. Instead of interviewing people who had just signed up, they started spending time with users who had been active for more than a year. What kept them? What had changed about how they used the product over time? What would make them recommend it to someone else without being asked? The answers produced a roadmap that looked almost nothing like the previous one. Not because the product was broken. But because the previous roadmap had been written for a user who didn't exist yet. The new one was written for the user who was already there, already invested, and already deciding whether to stay. The economic case for this shift is straightforward enough that it's almost embarrassing it took rising CAC to force the conversation. But most finance teams were measuring acquisition cost because it's easy to measure, not because it's the right number to optimise for. A retained user costs almost nothing to keep relative to what it cost to acquire them. Their value compounds over time as they expand usage, upgrade tiers, and refer others. Their feedback is more honest because they have enough context to know what's actually wrong rather than what's confusing on the first visit. And their presence makes the product better for everyone around them, in the same way that a pub full of regulars makes a better evening for the first-timers who've just walked in. Most acquisition teams know this abstractly. But knowing it abstractly and building a product around it are different things. The acquisition model treats users as a flow. But the retention model treats users as an asset. Both metaphors have limits. But the teams thinking in assets for the last two years are looking at their unit economics with a different expression than the teams still trying to outrun their churn rate with new signups. One of those expressions is considerably calmer. Acquisition will always matter. New users are how products grow, and growth still matters. But acquisition without retention is a description of a bucket with a hole in it. And the teams spending this year figuring out how to make the bucket hold water will build something more durable than the ones still optimising the tap. The pub doesn't need to run ads. It needs to be worth coming back to. That's the whole strategy.

Product StrategyApril 7, 2025

The same skill in a different room

The first time I pitched to investors, I wore a different shirt. I do not mean metaphorically. I actually changed my shirt before the meeting because some part of my brain had decided this was a fundamentally different kind of performance. Different audience, different stakes, different rules. The investor pitch was a founder activity. The internal strategy pitch was a product management activity. Everyone around me seemed to agree. Books about fundraising sat on a different shelf from books about stakeholder alignment. The two disciplines had separate vocabularies, separate templates, separate anxieties. But they required exactly the same skill. And nobody was teaching either version. Setup: two rooms, one silence Product leaders move between these two contexts more often than the industry acknowledges. You pitch a new initiative to your VP of Engineering on Tuesday. You pitch the same underlying thesis to a potential investor or board member on Thursday. The Tuesday room has a whiteboard and leftover coffee. The Thursday room has a conference table and sparkling water. The furniture changes. The cognitive task does not. I spent years not seeing this. At Freshworks, my internal pitches were structured around roadmap logic: here is what we have built, here is what we should build next, here is why. The format was sequential. The energy was explanatory. When I later found myself pitching to external stakeholders for a side venture, I scrapped that entire approach and built something that felt more like a sales narrative: big vision, market opportunity, competitive moat, financial projections. I treated the two formats as different disciplines because the rooms looked different. But the pitch that failed at Freshworks and the pitch that failed with investors failed for the same reason. Neither one made the proposed decision feel inevitable. Both presented information and hoped the audience would arrive at the right conclusion on their own. The audiences did not arrive. They nodded politely and moved on. Information does not produce decisions. Structure does. Conflict: discovering the symmetry The moment of recognition came at Adobe, and it came through someone else's success rather than my own failure. A colleague named Priya was pitching an internal initiative that required pulling resources from two revenue-generating projects. The room was sceptical. She had maybe fifteen minutes of genuine attention before the conversation would drift toward why this was too risky. She did not start with her solution. She started with the problem, and she described it so specifically that two people in the room visibly shifted in their seats. Not "the market is changing." More like "we are losing fourteen percent of our enterprise renewals because the onboarding experience breaks at exactly the point where the customer's admin tries to configure permissions, and we know this because here are the support tickets." She then walked through three alternative approaches, explaining clearly why each one would not work. By the time she arrived at her proposed direction, the room had already mentally eliminated the alternatives. Her recommendation felt like the room's conclusion. It was the cleanest internal pitch I had ever seen. Four months later, Priya left to co-found a startup. I sat in on one of her early investor pitches. She used the same structure. Not the same slides. The same architecture underneath. Specific problem, elimination of alternatives, a recommendation that felt discovered rather than proposed. An angel investor in the room said yes before the Q&A. Persuasion architecture is the same skill whether the room has a whiteboard or a term sheet. I started calling this the pitch symmetry: the structural identity between any two situations where you need someone to make a decision they were not already planning to make. The surface details change. The underlying architecture does not. The three elements nobody teaches Persuasion architecture, as I have come to understand it, has three elements. They are the same in every room. The first is the problem claim. Not a market overview. Not a trend summary. A specific, felt articulation of the problem that makes the audience care before you have proposed anything. Most pitches rush past this. But the problem claim is the load-bearing wall. Without it, everything you build on top is decorative. The second is the alternative elimination. You walk through the other approaches and explain, with evidence, why they fall short. This is where most internal pitches fail entirely. Product people present their solution as if it exists in a vacuum. But your engineering lead is already thinking about the alternatives. If you do not address them, she will address them for you, and her version will be less charitable than yours. The third is the inevitability arc. The sequence must create the feeling that the decision you are proposing is not a preference or a gamble but a logical conclusion. The audience should feel like they arrived at the answer themselves. Investor pitches that miss this get polite interest and no cheques. Internal pitches that miss this get tentative approvals that die quietly in execution because nobody felt genuinely committed. I have now watched this pattern in boardrooms at Nike, in product reviews at Freshworks, in investor meetings for early-stage startups I advise. The pitch symmetry holds every time. Resolution: the skill in the gap The reason nobody teaches persuasion architecture is that it sits in a disciplinary gap. Business programmes teach financial modelling. Design programmes teach visual storytelling. Product management courses teach prioritisation and roadmap mechanics. But the skill of constructing an argument so that the conclusion feels discovered by the audience rather than imposed by the presenter belongs to none of these fields. It is assumed to be something people absorb through experience, like learning to read a room or knowing when to stop talking. Some people do absorb it. Priya clearly had. But most do not. I have mentored interns and junior PMs who could write a flawless product brief but froze the moment they had to stand in a room and move someone from scepticism to conviction. The writing was clear. The thinking was solid. But the architecture of persuasion was missing, and nobody had told them it existed as a distinct, learnable skill. I once sat in a review where a junior PM presented twelve minutes of beautifully organised data about why we should change our onboarding approach. The room thanked her and moved on. Nothing happened. Three weeks later, a more senior colleague pitched the same change in five minutes, structured entirely around the problem claim and the elimination of alternatives. It was approved that afternoon. Same idea. Same evidence. Different architecture. The gap between being right and being convincing is where most good ideas go to die. Product organisations measure many things. But they do not measure whether their people can construct a case that makes a decision feel inevitable. They assume the data will do the work. The data does not do the work. The data is the material. The architecture is what holds it together. There is something quietly reassuring about recognising the pitch symmetry. It means you do not need to learn two skills. You need to learn one skill and carry it with you. The room will change. The furniture will change. But the architecture that moves a person from scepticism to conviction has always been the same, whether you are asking for funding or asking for faith.

Communication & Storytelling April 6, 2025

PLG + SLG hybrid: When self-serve meets enterprise sales

The first time I realised we had a problem, I was sitting in on a call with enterprise procurement at Freshworks. The buyer, a mid-level IT manager at a logistics company, had pulled up our pricing page and was reading it out loud to us. Slowly. With the energy of someone trying to assemble furniture using instructions translated through four languages. "So this tier includes five agents, but your sales rep quoted us fifty seats with a different per-agent price, and the website says I can start free with up to ten. Which one is the real price?" I did not have a good answer. Neither did anyone else on the call. That moment was a small, specific symptom of a much larger problem. The product had been built for self-serve. Small teams could sign up, try it, pay with a credit card, and start using it within an hour. It worked beautifully for that motion. But as the company grew and started pursuing larger accounts, a sales team appeared. And the sales team had different pricing, different packaging, different terms. The self-serve product and the enterprise sales process were not designed to coexist. They had been stitched together after the fact, and the seams showed. Act One: the food truck that wanted to be a restaurant Every product-led growth story starts the same way. You build something useful. People find it. They sign up, use it, pay for it. No salespeople required. The product does the selling. It is elegant, efficient, and deeply satisfying for anyone who has spent time in the slow, expensive machinery of traditional enterprise sales. But then something happens. A larger company shows interest. They want the product, but they also want a contract, an SLA, custom onboarding, invoicing through their procurement system, a dedicated account manager, and a security review that takes three months. They do not want to put a credit card in and start a free trial. They want to buy the way large companies buy. PLG and SLG are two different organisms sharing one body. One breathes through speed, simplicity, and low friction. The other breathes through relationships, negotiation, and long cycles. The instinct is to run both. The reality is that running both is like a food truck owner who gets popular and decides to open a fine dining restaurant using the same kitchen, the same menu, and the same staff. The ingredients might overlap. But the operation is fundamentally different, and pretending otherwise produces a terrible version of both. Act Two: the motion collision This is where the chaos lives. At Freshworks, I watched this collision happen in real time. The self-serve pricing was designed to make small teams say yes quickly. Low entry price, transparent tiers, instant access. But when the sales team quoted enterprise deals, they used different bundles, volume discounts, and annual contracts that looked nothing like what was on the website. Enterprise buyers who had started as self-serve users found themselves in a confusing middle ground: they could see one price online and were being quoted a completely different structure by a human. The pricing page that made sense for startups confused enterprise procurement. Procurement teams are trained to find inconsistencies. When they see a public price that differs from a quoted price, they do not think "oh, that is the self-serve tier." They think they are being overcharged. Or they think the sales rep is undercutting the standard price, and they push for more. But the pricing was not even the hardest part. The product itself had been built for the self-serve motion. Onboarding was automated. Billing was monthly, by credit card. There was no concept of a multi-year contract, a purchase order, or an invoice that needed to go through three levels of approval. Bolting enterprise billing onto a self-serve billing system is like attaching a trailer to a bicycle. It technically connects. It does not work. I have been mentoring a founder who learned this the painful way. She had built a solid self-serve analytics tool. Hundreds of small teams paying monthly. Good retention. Then a Fortune 500 company wanted to buy it for three hundred users. Great news, in theory. But the billing system could not generate an invoice. It could not handle annual contracts. It could not accommodate the client's requirement for net-60 payment terms. The founder spent two months building billing infrastructure instead of product. She told me, with the weary honesty of someone who has been in the weeds too long, that she had accidentally built two companies and neither one was working properly. That is what I call the billing Frankenstein. You start with a clean, simple billing system designed for one motion. Then you bolt on pieces for the other motion. Custom invoicing here. Contract management there. A manual process for enterprise renewals that someone runs out of a spreadsheet. Before long, you have a system that no single person fully understands, held together by duct tape and good intentions. Act Three: the uncomfortable coexistence Here is the thing nobody wants to hear. There is no clean solution. The companies that make the hybrid work do not eliminate the tension. They accept it and build walls around it. They run two motions with two distinct operational tracks. Self-serve has its own pricing, its own onboarding, its own billing, its own success metrics. Enterprise has its own. The product is shared. Almost everything else is separate. But that is expensive. It means two sets of processes. Two billing systems, or at least two configurations of one. Two onboarding experiences. Sometimes two support teams. For a startup trying to move upmarket, the cost of running both motions properly can feel disproportionate to the revenue the enterprise motion generates in its first year. The alternative is worse. Trying to force both motions through one system produces the confusion I saw at Freshworks, the billing problems the founder I mentored hit, and a customer experience that satisfies nobody. Enterprise buyers feel like they are using a consumer product with a contract stapled to it. Self-serve users feel like the product is getting heavier, slower, more complicated, because it is. Every enterprise feature request adds weight to a product that was built to be light. The teams I have seen handle this best share a specific discipline. They decide, explicitly, which motion is primary. Not both. One is the core. The other is the extension. If PLG is primary, the enterprise motion is a layer on top, with its own pricing and process, but the product stays optimised for self-serve simplicity. If SLG is primary, the self-serve motion becomes a trial mechanism for enterprise pipeline, not an independent revenue line. The moment you treat both as equally important, you get the worst version of each. What stays quiet Most product teams I talk to about this are already in the middle of it. They have a self-serve product generating revenue. They have an enterprise pipeline generating interest. And they have a growing sense that the two things are pulling the organisation in opposite directions. The hardest part is not the billing system. It is not even the pricing. It is the identity question underneath: what kind of company are you? A product-led company that also sells to enterprises? Or an enterprise company that also has a self-serve option? Those are different businesses with different centres of gravity. The ones that stall are almost always the ones that refuse to choose. Every hybrid model is a negotiation between two versions of the same company. The negotiation never ends. But it goes better when someone names the terms.

The Business of ProductsApril 5, 2025

The Companies profiting most from AI disruption are not the ones building AI products

The companies capturing the most value from the AI revolution are not the ones using AI to build remarkable new products. They are the ones selling the compute, the cloud, and the APIs that everyone else needs to build those products. Microsoft, Alphabet, and Amazon have remained resilient or grown during a period when application software companies are being repriced downward. The picks-and-shovels sellers are thriving. The miners are struggling. This should not surprise anyone who has watched platform economics play out before. But it does, because every generation of technology builders convinces itself that this time the platform layer will stay neutral. It never does. The Colonisation Pattern There is a pattern so consistent across technology markets that it deserves a name. I call it the colonisation pattern, and it works in three stages. First, a platform enables third-party builders by providing APIs, distribution, and infrastructure. Second, it observes which applications built on top of it gain traction and generate revenue. Third, it absorbs the most successful patterns into native platform capabilities, competing directly with the companies it enabled. This is not conspiracy. It is incentive structure. At Adobe, I watched the colonisation pattern from the inside. Creative Cloud was both a product and a platform. Third-party developers built plugins and extensions that extended Photoshop, Illustrator, and the rest of the suite. Some of these plugins were brilliant. They solved real problems that Adobe's core product team had not prioritised. Users loved them. Revenue flowed. But that revenue was a signal, not a reward. But here is what happened next, and it happened with a reliability that you could set a calendar by. The product team would notice which plugins had the highest adoption. They would study the interaction patterns. And within eighteen to twenty-four months, a native version of that capability would appear in the next major release. The plugin developers who had built the market for that feature were suddenly competing with a free, integrated alternative that shipped pre-installed to every Creative Cloud subscriber. The platform is never neutral. It is patient. And patience, at scale, is the most effective competitive strategy. I do not say this with moral judgement. I was on the platform side. The logic was entirely rational. Why allow a third party to capture value from a use case that your platform made possible, when you could capture it yourself with zero customer acquisition cost? The answer, from inside the building, was obvious. You would not. But that obvious answer, applied systematically, creates a market dynamic that third-party developers rarely anticipate until they are already inside it. The Other Side of the Table At Freshworks, I experienced the colonisation pattern from the other side, and the view was considerably less comfortable. We built products that depended on platform integrations. Salesforce, Google Workspace, Microsoft 365. These integrations were not optional features. They were the connective tissue that made our products useful in enterprise environments. A customer service tool that does not connect to email, calendar, and CRM is not a customer service tool. It is a standalone application that nobody will adopt. But every integration was also a strategic vulnerability. Every time we built a deep connection to a platform, we were simultaneously making our product more valuable to customers and more visible to the platform owner. We were showing them exactly which workflows their users cared about, exactly which data connections generated the most activity, and exactly where value was being created on top of their infrastructure. Every strategic decision at Freshworks was shaped by a question that nobody wanted to say out loud: what happens when the platform owner decides to build this themselves? The answer was always the same. When Microsoft or Google decided to offer a native version of a capability we provided, they could reach every existing user at zero marginal distribution cost. We had to sell. They had to ship an update. But that is not a fair race. The competitive dynamics were not unfair in any legal sense. But they were structurally asymmetric in a way that no amount of product quality could overcome. The Platform Paradox in the AI Era What makes the current moment different is not that the colonisation pattern is new. It is that the AI era has accelerated the pattern and concentrated its effects. The companies profiting most from AI disruption are the ones selling the infrastructure that makes disruption possible. Microsoft sells Azure compute and embeds Copilot across its application suite. Amazon sells AWS infrastructure and offers Bedrock for model deployment. Google sells cloud compute and integrates Gemini into Workspace. Each of them is simultaneously the infrastructure provider, the platform owner, and an application competitor. This is the platform paradox: the platform profits from the disruption it enables, and then uses those profits to colonise the application layer that the disruption was supposed to create. Application-layer companies building on these platforms face a version of the same dilemma I experienced at Freshworks, but with higher stakes and faster timelines. If you build an AI-powered application on Azure, your success is visible to Microsoft. If you build on AWS, Amazon sees your usage patterns. If you build on Google Cloud, Alphabet knows which workloads are growing. The infrastructure providers have perfect information about which application categories are worth entering. They are not guessing about market demand. They are reading it directly from their billing data. The Dependency Question The standard advice for startups has always been to build on platforms, because that is where the distribution is. But the standard advice assumes that the platform will remain neutral long enough for you to build a defensible position. That assumption is becoming harder to justify. I am not arguing that companies should avoid platform dependencies entirely. That is not practical. Almost every modern software product depends on cloud infrastructure, identity providers, and communication platforms that it does not control. The dependency is structural. You cannot opt out of it. But you can be honest about what it means. Building on a platform is not a partnership. It is a tenancy. And the landlord is always watching the most successful tenants to decide which businesses to enter next. The platform paradox means that your growth, if it becomes visible enough, is the signal that triggers your competition. The companies that survive the colonisation pattern do so not by avoiding platforms, but by building value that the platform cannot easily replicate. Proprietary data, deep domain expertise, workflow-specific integrations that are too niche for the platform to bother absorbing. But even specificity has limits when the platform decides to go broad. The defence is not scale. The defence is specificity, guarded by the knowledge that it is temporary. Where the Value Settles Every technology era has its version of this dynamic. The PC era concentrated value in the operating system layer. The mobile era concentrated it in the app store owners. The cloud era concentrated it in the infrastructure providers. The AI era is following the same script, with the same companies capturing the same structural position. The application layer is where the innovation happens. But the platform layer is where the value collects. This has been true for decades, and no amount of disruption has changed it. The disruption changes what gets built. It does not change who profits. There is something almost poetic about it. The most creative period in software development in a generation is producing enormous value, and most of that value is flowing downward, into the infrastructure layer, rather than staying with the builders who created it. The platform was never neutral. It was always just waiting to see what worked.

Markets & Industry DynamicsApril 1, 2025

The multi-stakeholder problem: Initial advocates and final decision-makers want different things

The most dangerous moment in an enterprise sale is when the champion tells you the deal is done. It is not done. It is not close to done. What has happened is that one person inside the buying organisation, usually a mid-level manager or a team lead, has fallen in love with your product. They have seen the demo. They have used the trial. They have imagined how much better their daily work would be. And they have told you, with genuine conviction, that this is going to happen. But the person who signs the budget has never seen the demo. They have never used the trial. They do not care how the interface feels. They care about three things: what does it cost, what does it replace, and what happens if it goes wrong. The champion and the decision-maker are having two completely different conversations about your product, and your product team is only hearing one of them. Act One: twelve people, twelve criteria Enterprise buying groups now average twelve or more people. More than half of final decision-makers sit at VP level or above. Nearly eight in ten purchases require CFO approval. These are not statistics. They are the terrain. The product champion, the person who found your product, tried it, and decided it would solve their problem, typically sits two or three levels below the person holding the budget. The champion evaluates the product on experience: does it work, does it feel right, does it make my job easier. The decision-maker evaluates the product on risk and return: does it reduce cost, does it integrate with what we already have, does the vendor look stable enough to bet on. These are not two perspectives on the same question. They are answers to two entirely different questions. And most product teams build for one audience while assuming the other will simply follow. I call this the champion gap. The distance between the person who loves your product and the person who controls the budget. The wider the gap, the more likely the deal dies in a room your product team never enters. Act Two: two rooms, two losses At Adobe, I watched this play out in a way that still bothers me. We had a product that a design team at a large financial services firm wanted badly. The lead designer had spent weeks building an internal case for it. She had documented the workflow improvements, mapped the time savings, shown how the product fit into their existing tool stack. By every measure that mattered to her team, this was the right product. The CFO killed it in a single meeting. Not because the product was wrong. But because the ROI case was not there. The design lead had built a case for adoption. The CFO needed a case for investment. She had explained how the product would improve her team's work. The CFO wanted to know how much it would save the company in hard dollars over three years, how it compared to the incumbent vendor's renewal pricing, and what the switching cost would be if the product failed to deliver. Those were not questions the design lead had prepared for, because nobody on our side had equipped her to answer them. The product was perfect for the user and invisible to the buyer. That is a product failure, not a sales failure. At Freshworks, I saw a different version of the same gap. We were selling into a mid-market enterprise, and the product champion was a support operations manager who loved the interface. He had run a trial with his team. Satisfaction scores were high. He was convinced. But when procurement entered the conversation, the entire language changed. But procurement did not ask a single question about user experience. Not one. They wanted to know about vendor stability: how long had the company been profitable, what was the revenue trajectory, what happened to customer data if the company was acquired. They wanted contract flexibility: could they exit after year one without penalty, were there caps on price increases, who owned the integrations. They wanted to know whether the company would still exist in three years. These are not unreasonable questions. But they are questions that live in a completely different universe from "the interface is intuitive and my team loves using it." The champion was selling the experience. Procurement was buying the risk profile. I started calling this the boardroom inversion. The moment an enterprise deal moves from the team that will use the product to the function that will approve the spend, every evaluation criterion flips. What made the product attractive to the champion (beautiful design, easy onboarding, intuitive workflow) becomes irrelevant or even suspicious to the decision-maker. A product that feels too easy can signal immaturity to a procurement team evaluating for enterprise readiness. Winning the room and losing the boardroom is the most common way good products die in enterprise. Act Three: building for both rooms The instinct here is to say "build a better ROI story." But that is only a piece of it, and not even the most important piece. The product teams I have seen close this gap do something more structural. They design the product experience for the champion and the buying collateral for the decision-maker as two parallel workstreams, not an afterthought tacked onto the sales cycle. Think of it like an architect designing a building. The architect designs the floor plans for the tenants, the people who will live and work in the space every day. But the architect also designs the maintenance plans, the energy efficiency projections, and the structural warranties for the building owner. If the architect only designs for the tenants, the building never gets approved. If the architect only designs for the owner, the building gets built and nobody wants to live in it. Most product teams are designing only for the tenants. The practical difference looks like this. Product teams that win both rooms build ROI cases into the product itself, not just into the sales deck. They include admin dashboards that surface cost savings and efficiency metrics in language a finance team recognises. They provide security and compliance documentation that procurement can evaluate without scheduling a call. They make it easy for the champion to build the internal case by giving them the materials that speak the decision-maker's language. Not marketing collateral. Evidence. But the deeper shift is about empathy, and this is where most product teams resist. The person using your product and the person paying for it are having two completely different conversations about it. Respecting both conversations, genuinely and structurally, means accepting that user delight is necessary but not sufficient. The CFO at that financial services firm was not wrong to kill the deal. She was doing her job. We had not done ours. The gap that never fully closes The champion gap does not disappear. It exists in every enterprise deal because the people closest to the problem and the people closest to the budget occupy structurally different positions with structurally different incentives. But no amount of product polish resolves that tension, because the tension is not a flaw. It is how organisations make decisions when the money is large enough to matter. The product teams that understand this stop trying to eliminate the gap and start designing for it. They accept that they are building for two audiences who will never fully agree on what matters. They equip the champion without abandoning the decision-maker. They build evidence alongside experience. It is a harder way to build. But the enterprise deals that actually close are never won in a single room.

User & Buyer PsychologyMarch 25, 2025

How to monetise AI features without destroying margins

A founder I mentor called me in January, genuinely excited. She had shipped an AI-powered analysis feature inside her B2B product. Users loved it. Engagement was up. She was calling to celebrate. Then she showed me the numbers. The AI feature was the most popular thing in the product. It was also the most expensive thing to run. Every time a user triggered the analysis, an inference call hit her cloud bill. The subscription price had not changed, because the AI feature was bundled into the existing plan. She had given away the most expensive capability in her product for free, and users were doing exactly what you would hope they would do with something valuable: using it constantly. The more successful the feature became, the less money the business made. I sat on that call thinking: I should have told her this three months ago. The margin paradox This is a pattern I am seeing everywhere, and it has a shape worth naming. I call it the margin paradox. The better your AI feature works, and the more users adopt it, the worse your unit economics become. In traditional software, usage scaling was almost free. Server costs existed, but they were flat and predictable relative to revenue growth. But AI features are not traditional software. Every inference call has a real, measurable cost. Those costs do not flatten the way traditional infrastructure costs do. They scale linearly with usage, and sometimes worse than linearly depending on model complexity. The Monetization Monitor data tells the story plainly. Roughly 80% of companies have shipped AI features. But 70% say the delivery costs are undermining profitability. The industry shipped first and asked about costs second. Now the bill is arriving. The inference tax At Schneider Electric, years before the current AI wave, I encountered a version of this problem in a different costume. We were building an IoT thermostat product where compute happened partly on device and partly in the cloud. Every connected device generated data that required processing. And the cost of that processing was not a rounding error. It was a line item that grew with every device we sold. But nobody had modelled what would happen to the cost per user at scale. When we did the maths, the answer was sobering. There was a threshold beyond which every new user made the product less profitable than the one before. I started calling this the inference tax: the cost that scales with every unit of intelligence your product delivers. For the IoT thermostat, it was processing cycles per device. For today's AI features, it is tokens per query, model calls per session, API fees per inference. The label changes. The structural problem does not. The founder I was mentoring hit this wall faster than we did at Schneider, because AI inference costs are higher per unit than IoT processing ever was. But the shape of the problem is identical. You built something users want. The more they use it, the more it costs you. And your pricing model was designed for a world where usage was essentially free. Think of a restaurant that adds a truffle menu. The chef is proud of it. Customers come specifically for the truffle risotto. But truffles are expensive. Every plate served costs more to prepare than the restaurant charges. The regular menu subsidises the truffle menu, and the more popular it becomes, the worse the overall margin gets. This is what most companies have done with AI features. They built the truffle menu, priced it as part of the regular menu, and hoped the prestige would compensate for the cost. Prestige does not pay cloud bills. The cost of intelligence is the new cost of goods sold. And most product teams have not internalised this yet because they come from a world where the marginal cost of software was effectively zero. In that world, bundling more features into an existing subscription was always the right move. More value, same price, better retention. But in a world where features have real marginal costs, that instinct is destructive. What the pricing has to do If you are sitting with this problem (and statistically, you probably are), the path forward is not a single model. It is a set of decisions your product team and finance team need to make together. The first decision is visibility. You need to know, at the feature level, what your AI capabilities cost to serve. Most teams I talk to cannot answer this. They know their total cloud spend. They do not know what a single AI-assisted search costs them. Without that visibility, every pricing decision is a guess. The second decision is segmentation. Some users trigger inference calls hundreds of times a day. Others barely touch them. Flat pricing across both groups means your most engaged customers are your least profitable ones. The most dangerous AI feature is the one your users love and your margins cannot survive. The third decision is the pricing architecture itself. You can meter AI usage directly. You can tier access so heavier usage requires a higher plan. You can price AI features as a distinct add-on. Or you can build outcome-based pricing where the customer pays when the AI delivers a measurable result, not when it runs. But here is the part most teams skip. The pricing architecture has to reflect the cost structure, not just the value perception. If customers expect flat pricing and predictable bills, metering can destroy the experience. The right model aligns three things simultaneously: what the feature costs you, what the customer is willing to pay, and how the customer wants to pay. Getting one of those three right is easy. Getting all three right is the actual job. What Schneider taught me that still applies At Schneider, we eventually found our way to a model that worked. We tiered the product so that compute-intensive features sat in a premium plan with pricing that reflected the actual cost of serving them. We did not apologise for it. The customers who valued that depth paid for it. The customers who did not stayed on the standard plan and remained profitable. But the real lesson was earlier than the pricing fix. It was the moment the product team and the finance team sat in the same room and looked at the same numbers. That meeting had not happened before. Product had been building for the user. Finance had been watching the margin. But neither had the full picture until they sat together. I told the founder the same thing. Sit with whoever holds the cost data and look at the per-feature numbers together. The conversation will be uncomfortable, because you will learn that some of the features you are most proud of are the ones the business can least afford to keep giving away. That is not a reason to kill those features. It is a reason to price them correctly. The discipline underneath The companies that will get AI monetisation right are not the ones with the cleverest pricing models. They are the ones that accept a truth the traditional software industry never had to confront: the cost of serving intelligence scales with usage, and pricing must account for this or the business will slowly bleed. Every previous era of software let product teams treat margin as someone else's problem. AI does not. The inference tax is real, it compounds, and it does not care how elegant your product is. The question is not whether your AI features are good enough to charge for. But whether you have the discipline to charge what they cost before the margin paradox becomes the margin collapse.

The Business of ProductsMarch 19, 2025

The job description nobody sent you

There is a version of product management that most people entering the field were trained for, and a version that is quietly becoming the job. The gap between them is widening. But most PMs are discovering the new version not through a job description or a promotion conversation. They're discovering it through a gradually increasing list of meetings they weren't in two years ago. The revenue review. The pricing discussion. The conversation about whether a particular segment is worth the cost to serve. The board question about unit economics that gets forwarded to the product team because nobody else in the room had a credible answer. This is why the shift matters, and it's worth being direct about it before getting into how it plays out. Product management was designed, in its modern form, for a world where the product team's job was to ship. Shipping was the output. Revenue was someone else's problem. The PM owned the roadmap. The commercial team owned the number. Both sides were evaluated on their own lane, and the two lanes ran in parallel, occasionally merging at a QBR and then diverging again until the next one. That model made sense when software was sold annually, in large contracts, by sales teams who owned the customer relationship from first call to renewal. The product team's job was to make something worth selling. But selling it was a different department's problem. The model broke down as distribution shifted to self-serve, as products became the primary channel for their own growth, and as the line between what the product does and what the business earns became impossible to separate cleanly. A product that fails to convert a free user isn't a UX problem. It's a revenue problem. A feature that increases engagement but doesn't contribute to retention isn't a success metric. It's a cost. A roadmap that doesn't account for what it costs to serve a particular segment isn't a product strategy. It's a wish list with a due date. The PM who understands those distinctions is operating as a general manager. But the PM who doesn't is operating as a well-intentioned feature factory, and the organisations that have figured this out are starting to staff and evaluate accordingly. I've worked with two PMs in the past year who are navigating this transition, in very different ways. The first one resisted it. She'd been in product for eight years, was genuinely excellent at her craft, and felt that being pulled into commercial conversations was a distraction from the work that actually mattered. Every time a revenue question landed in her team's direction, she redirected it. That's a commercial question, she'd say. She wasn't wrong. But she was losing influence every time she said it, because the organisation was starting to evaluate her team on commercial outcomes whether she accepted the brief or not. Being right about the boundaries of your job description is a strange way to lose a seat at the table. The second one leaned into it. He had no formal background in finance or commercial strategy, but he started asking a specific question in every roadmap conversation: what does it cost us if this doesn't work, and who bears that cost? Not to become an accountant. But to understand which decisions had commercial stakes and which ones were purely craft decisions. Over eighteen months, he became the person leadership called when a pricing conversation needed someone who understood how users would respond to it. Not because he was the best commercial thinker in the room. Because he was the only person who knew both sides of the equation. The difference between them wasn't skill. It was appetite for scope. The PM-as-GM model asks things of the role that the traditional version didn't. It asks for ownership of the revenue contribution, not just the feature set. Which means understanding CAC and LTV well enough to know whether the product decisions being made are building toward a sustainable unit, not just a growing one. It asks for accountability on cost, not just velocity. Which means knowing what it costs to build and maintain what the team is building, and whether the value being created justifies that cost. Most PMs have never been asked to think this way. But the ones being asked now are finding it uncomfortable and clarifying in equal measure. And it asks for a point of view on profit, not just growth. This is the hardest shift. Growth has been the dominant language of product thinking for a decade. But profitable growth is a different question, and it requires tradeoffs that growth thinking is specifically designed to defer. None of this requires a PM to become a CFO. But it does require caring about the business at a level of specificity that most product training doesn't prepare people for. The title of General Manager is being used loosely in this conversation. It's worth being precise about what it actually means. A GM doesn't just run a function. They run a business. They're accountable for the inputs and the outputs. They hold a P&L. Most PMs are not in that position, and most organisations aren't asking them to be. But the direction of travel is clear, and the gap between where PMs are being asked to operate and where most of them were trained to operate is closing faster than most people expected. The PMs who will have the most influence over the next few years are the ones who can speak the full language of the business their product operates in. Not just the language of users and features, which they already speak fluently. But the language of revenue, cost, and the relationship between them. That's a learnable set of skills. It just requires accepting that learning them is part of the job. The description didn't arrive in your inbox with the rest of the onboarding materials. But it's the job.

Product StrategyMarch 19, 2025

Rebuild or retrofit: Two bets, One question nobody is asking

There are two product teams I want to tell you about. They work in different companies, in different cities, and they've never met each other. But they're running the same experiment right now, and the results are starting to diverge in ways that are worth paying attention to. Both teams were facing the same pressure at the start of this year. Competitors were shipping AI features. Users were asking why the product wasn't doing what other tools were starting to do. Leadership was asking the same question in slightly different language. Something had to change. Team A decided to rebuild. Not gradually. Not by adding AI to what existed. They made the call that their existing architecture was built around assumptions that AI had made obsolete, and that layering capabilities onto an outdated foundation would produce something worse than starting over. They started a parallel build. New data model, new interaction patterns, new assumptions about what the product was fundamentally for. Team B decided to retrofit. They took their existing product and began adding AI capabilities systematically. A summarisation feature here. An intelligent suggestion layer there. An AI-assisted workflow in the part of the product where users spent the most time. Fast, incremental, shipped to users within weeks rather than months. I've been watching both teams for the better part of six months. And the thing I want to tell you is that neither of them is obviously winning. But they're losing in completely different ways. And understanding why tells you more about this decision than any framework I've seen published on the subject. When you renovate an old building, you work within constraints that were set by someone else's decisions. The load-bearing walls are where they are. The plumbing runs where it runs. Every improvement you make is a negotiation with the original architecture, and some of the things you want to do simply aren't possible without tearing out something structural. Skilled renovators know which constraints are real and which are just unfamiliar. The best ones can take a building that looks tired and make it feel new without touching the bones. But there are limits. There are always limits. And the renovator who doesn't know where the limits are will spend money on surfaces while the foundations stay problematic. New builds have different problems. No inherited constraints, but no inherited advantages either. Every decision has to be made from scratch. The timeline is longer than anyone admits at the start. And the gap between the architectural vision and the lived reality of the building tends to widen in proportion to how ambitious the vision was. Team A is building new. Team B is renovating. But both are discovering that they underestimated what the work actually required. The new build team underestimated the timeline. The retrofit team underestimated the seams. Team B's AI features are live. Users are engaging with them. Some of them are genuinely useful. But six months in, the product feels like two things sitting next to each other rather than one thing that thinks. The AI suggestions arrive without context about what the user was doing before. The summarisation feature works on content that the rest of the product wasn't designed to process in that way. There are seams. Users feel them even when they can't name them. The team knows this. They're iterating. But each iteration is another negotiation with the original architecture, and the original architecture was designed for a user who navigated, clicked, and waited. It wasn't designed for a user who expects the product to anticipate. Team A is still building. The parallel product is later than the original timeline, because parallel products are always later than the original timeline. The existing product is getting some maintenance but no new features, which is creating its own set of problems with the current user base. The new build is impressive in the parts that are done. But the parts that are done are not yet a complete product. And the distance between an impressive partial build and a shippable product is not always as short as it looks from the inside. Here is the question both teams should have asked before they made their decision, and that most teams making this decision right now are not asking clearly enough. What do your users actually need AI to do? Not what can AI do in your product. Not what are competitors doing. Not what would make the most impressive demo. What does the person using your product at nine in the morning, trying to do a specific thing, need the product to do differently than it does today? Because the answer to that question determines which bet is right. But it's a different answer for different products, and most teams skip it because it requires sitting with users in a way that slows down the decision. If the answer is: users need the product to get out of their way, anticipate their next step, and work with information they haven't manually entered, then the retrofit is going to keep producing seams. The foundation wasn't built for a product that anticipates. Rebuilding might be the honest answer. But if the answer is: users need the product to do specific things faster, surface specific information more easily, and reduce friction in specific workflows, then the retrofit can deliver that. And delivering it in months rather than years is not a compromise. It's a different, valid bet. The strategic error isn't choosing wrong between native and augmented. It's choosing without asking what the user actually needs the AI to do, and then building toward that with honesty about what the current architecture can and cannot support. Both teams will probably be fine. They're smart, they're paying attention, and the pressure that forced the decision is real and worth responding to. But the teams I've seen make this decision well didn't start with the architecture. They started with the job. What is the product supposed to do for the person using it. What is AI uniquely able to contribute to that job. And what would have to be true about the product's structure for that contribution to feel like part of the product rather than a feature sitting on top of it. Answer those questions honestly, and the rebuild-or-retrofit decision tends to make itself. Skip them, and you'll be having this conversation again in eighteen months. With a more complicated codebase and the same fundamental question still open.

Product StrategyMarch 10, 2025

The one page brief changed how I think about trust

The most powerful document in product leadership is also the shortest. Not the strategy deck. Not the quarterly business review. Not the ten-page product requirements document with its carefully numbered sections. A single page, structured simply: what we know, what we do not know, the options available, and a recommendation with reasoning. It sounds almost insultingly basic. But the product leaders I trust most are the ones who produce these consistently, and the reason has nothing to do with the format. You cannot write a clear one-page brief on a topic you do not yet understand. That is the point. Why: trust comes from visible thinking There is a persistent confusion in product organisations about what builds trust. Most people assume it accrues from experience, from credentials, from a track record of being right. But credentials get you into the room. They do not keep you there. What keeps you there is the repeated demonstration that you have done the thinking before you started talking. I learned this the expensive way at Schneider Electric. A product director I worked with was sharp and right more often than not. But he operated entirely through verbal arguments. He would arrive at meetings with strong opinions, no written pre-read, and expect the room to follow his logic in real time. Some weeks it worked. But the weeks it did not, the trust eroded a little. Then a little more. Within six months, the leadership team had quietly started routing decisions around him. Not because his judgement was poor. Because nobody could verify his reasoning after the meeting ended. Being right is not enough if the room cannot retrace how you got there. The one-page brief solves this. But not because of the format. Because of what the format demands. To fill a single page with what you know, what you do not know, your options, and your recommendation, you must have done the thinking. You cannot bluff your way through four sections on one page. I call this the preparation signal. A one-page brief, handed out before a meeting begins, communicates something no verbal argument can: I respected your time enough to do the hard work in advance. That signal, repeated consistently, is how trust compounds. How: compression as a thinking discipline The discipline of compressing a complex problem onto a single page is not a writing exercise. It is a thinking exercise. Most people discover this the painful way when they first attempt it. At Grab, I introduced the one-page brief format for cross-functional decisions. The reaction was predictable. Two senior product managers told me, separately, that a single page could not capture the complexity of their problems. I told them that if they could not fit the essential shape of a problem onto one page, they had not yet understood it well enough to ask a room for a decision. They were not pleased. But something shifted within a few months. Meeting times dropped. A decision that previously required sixty minutes of presentation started resolving in twenty. But the second change was harder to measure and more important. The people writing the briefs started arriving with a different kind of confidence. Not the confidence of someone who has prepared more slides than anyone else. The confidence of someone who has already stress-tested their own reasoning before the room tested it for them. The brief did not make them smarter. It made their thinking visible. This is what I call the clarity threshold. There is a point in understanding a problem where you can explain it on one page. Below that threshold, you need more pages because you are still sorting out what you believe. Above it, you need fewer. The one-page constraint forces you to reach the threshold before you enter the room. Most other formats let you cross it during the meeting, on the audience's time. Nobody likes discovering that the presenter is figuring out what they think in real time. Everybody has sat through that meeting. What: the format in practice The format has four sections. No exceptions. What we know. The facts, the data, the things that are established and not in dispute. This section is always shorter than people expect, because separating what you know from what you assume shrinks the list considerably. What we do not know. The gaps, the uncertainties, the places where data is missing or inconclusive. This is the section most people resist writing. It feels like an admission of weakness. But it is the section that builds the most trust. Acknowledging what you do not know is the fastest way to earn credibility with senior leaders who have been burned by false certainty before. Options. The realistic paths forward, typically two to four. Not every idea the team brainstormed. Each described in two to three sentences with the key trade-off stated plainly. Recommendation with rationale. What the author would do and why. Not a hedge. A clear position, defended briefly, that gives the room something specific to push back on or modify. If the recommendation reads like something nobody could disagree with, it is not a recommendation. It is a platitude. That is it. One page. What happened when it worked At Grab, a colleague wrote a one-page brief for a pricing decision that had been circling the organisation for weeks. Three meetings had already been held. Each ran the full hour. Each ended with "let us think about this more." The brief she wrote was not brilliant prose. But it laid out the four options with their trade-offs so clearly that the fourth meeting lasted twelve minutes. The VP read the page, asked one clarifying question, chose option two, and moved on. Twelve minutes for a decision that had consumed three hours of leadership time. The brief did not make the decision easier. It made the decision visible. A product leader at a company I advise adopted this practice for every cross-functional decision. Within six months, other teams started requesting her involvement in decisions outside her remit. Not because she had authority. But because her briefs gave people confidence that the thinking had been done. That confidence, built one page at a time, became a form of authority no title could replicate. Why most people find one page harder than ten The paradox is real. Most product people find it harder to write one page than ten. A longer document lets you bury uncertainty in detail, surround a weak argument with supporting material, and hope the reader does not notice which parts are solid and which are filler. But a single page has nowhere to absorb that. Every sentence is visible. Every gap is exposed. This is exactly the discipline. The people who resist the format are almost always the people who have not yet finished thinking. Not because they are lazy. Because thinking is hard, and most organisational cultures do not distinguish between having thought about something and having thought it through. I think about a meeting early in my career where I walked in with a twelve-slide deck and a lot of confidence. Forty minutes of presentation. Five minutes of questions. Zero decisions. A mentor pulled me aside afterwards and said something that stuck: "You told them everything you know. But you never told them what you think." That was the gap. I had presented information, not judgement. A one-page brief would have forced me to close that gap before I entered the room, because there is no space on a single page for everything you know. There is only space for what matters. The format is almost comically simple. That is what makes it hard. And that is what makes it work.

Communication & Storytelling March 2, 2025

The solo founder is now a structural archetype, not an edge case

"You need a co-founder." This has been the most confidently delivered piece of advice in the startup world for twenty years. It is also the least examined. The advice was never really about the founder. It was about the investor. A solo founder made VCs nervous. Two founders meant someone to share the risk, someone to cover the blind spots, someone to call when the first founder wanted to quit at 2 a.m. on a Tuesday. The co-founder requirement was a risk mitigation strategy dressed up as wisdom about team dynamics. For a long time, the disguise held because the underlying logic was sound. Building a product required distinct competencies that almost never existed in a single person. You needed someone who could write code, someone who could design, someone who could sell. Even a remarkably talented individual could cover two of these at best. The third required a partner, or the company had a structural gap that would eventually kill it. But that structural gap has closed. The solo operator model Sometime in the last eighteen months, a threshold was crossed. AI tools made it structurally possible for one person to operate across functions that previously required three to five people. I call this the solo operator model. It is not a trend piece. It is a structural shift in what is possible at the earliest stage of building a company. A solo founder can now generate working code from a specification, produce interface designs from a brief, draft marketing copy, and synthesise user research in a single afternoon. Not at the level of a deep specialist. But at a level that is good enough to ship, learn, and improve. Solo-founded startups with no venture funding rose from 22% of new US startups in 2015 to 38% last year. That is not a blip. The co-founder assumption was built for a world where the threshold was too high for one person to clear. The threshold dropped. But the assumption has not caught up. But the numbers tell you what happened. They do not tell you what it feels like. What I learned from working alone in Wayanad I have been running my own version of this experiment. After leaving a senior role in Bangalore, I moved to Wayanad and built my working life around AI tools that handle the jobs I used to delegate. Research, design direction, writing, strategy, prototyping. I do not have a team. I have tools, a small circle of trusted people I call when I need a second perspective, and a rhythm of work that would have been impossible five years ago. The advantages are real. Speed is the most obvious one. When there is no coordination overhead, no alignment meeting, no Slack thread debating a decision that one person could make in ten minutes, you move at the speed of your own thinking. I once spent three days at a previous company trying to get four people aligned on a product brief I could have written in an afternoon. That kind of friction disappears entirely when you are the only decision-maker. But the costs are real too. And they are the ones that the celebrations of solo founding conveniently leave out. The hardest part of working alone is not the workload. It is what I call the judgment gap: the absence of someone to pressure-test your thinking. You make a strategic choice, and there is no one to argue with. You ship something, and there is nobody to turn to and say "was that right?" The absence of friction feels like freedom at first. But then you realise that some of your best decisions were forged in exactly that friction. The judgment gap is not about loneliness, though loneliness is part of it. It is about the quality of your decisions degrading slowly in ways you cannot see, precisely because there is no one positioned to show you. Solo founding is not about doing everything alone. It is about deciding what only a human needs to do. That distinction matters. The solo founders who struggle are the ones who interpret "solo" as "isolated." But the ones who succeed build informal advisory relationships, communities of practice, and selective collaboration. They work alone on execution. They do not think alone on strategy. Meera and the scheduling tool from Mysore A founder I mentor, Meera, runs a SaaS product from Mysore that handles appointment scheduling for independent physiotherapy clinics. Not the kind of product that gets breathless coverage. But it solves a real problem for a specific group of people, and Meera understood it because she spent six years managing her mother's physiotherapy practice before deciding to build for the market she already knew. No co-founder. No venture capital. No team beyond herself and what she calls, with a dry smile, "my AI department." She used AI tools for code generation, handled design with component libraries and good instincts, and ran customer support through phone calls (because her users, clinic owners in their fifties and sixties, do not use Slack and are suspicious of chatbots). She reached profitability in nine months. Not venture-scale profitability. But enough to pay herself, cover her costs, and reinvest. But Meera will tell you without hesitation what almost broke her. Not the code. Not the marketing. The silence. The weeks when no new clinic signed up and there was nobody to reassure her that the trajectory was normal. The moment she almost changed the entire pricing model because one loud customer complained, and there was no partner to say "that is one customer, not a pattern." The evening she nearly quit, not because the business was failing, but because success felt hollow when there was nobody to share it with. She solved it the way most successful solo founders do. She found her people outside the company. A monthly video call with three other solo founders she met through a product community. Weekly check-ins with a mentor (that would be me, though I suspect she values my questions more than my answers, which is probably correct). A WhatsApp group of clinic owners who give her feedback that functions like partnership even though it is technically a customer relationship. The solo operator model works. But it works because Meera designed around its weaknesses, not because those weaknesses do not exist. The question has shifted The co-founder assumption is not dead. There are products and markets where a solo founder will genuinely struggle. But for the growing category of software products aimed at specific, well-understood markets, built with modern tools, sold directly to end users, the co-founder requirement has become optional. Not wrong. Optional. The question was never whether one person could build a company. It was whether the infrastructure existed to make it structurally viable. Now it does. But viability is not the same as ease. The judgment gap does not disappear because AI handles your code generation. The loneliness does not dissolve because you have a productive Tuesday. The solo founders building something durable right now, from small towns and spare bedrooms and kitchen tables, are not the ones who pretend the model has no costs. They are the ones who design around those costs deliberately. They build the friction back in, through advisors, through communities, through the discipline of asking someone "tell me why this is wrong" before committing. The question is no longer whether a solo founder can compete. The evidence on that is clear enough. The question is whether you can build the structures around yourself that prevent good independence from becoming quiet isolation. That is a design problem. And like most design problems, it rewards the people who take it seriously.

Building & FoundingMarch 1, 2025

Writing specs for AI Agents

Product managers spent years complaining that engineers misread their specs. Ambiguity led to arguments, rework, and the occasional feature that bore no resemblance to what anyone had intended. Everyone agreed: specs should be clearer. Then AI coding agents arrived and started reading specs exactly as written, interpreting every sentence with perfect literalness and zero charitable assumption. That turned out to be worse. The old contract For most of the history of product management, a spec was a conversation starter, not a build instruction. The PM wrote a document. The engineers read it. Where it was vague, they asked questions. Where it contradicted itself, they flagged it. Where it was incomplete, they filled in the gaps using shared context, team norms, and institutional memory. I call this charitable interpretation. It was never written into any process document or onboarding guide. But it was the invisible layer that made product development work. Every successful product I shipped at Freshworks relied on it. My specs were clear enough, specific enough, and complete enough for a smart engineer who knew the product to build the right thing. But they were nowhere near complete enough for a reader who had no prior context, no memory of last quarter's decisions, and no ability to infer intent from tone or organisational culture. They were written for collaborators. Not for compilers. That distinction did not matter until the readers changed. The moment everything surfaced I watched a PM go through this realisation earlier this year. She had written a spec for a notification preferences feature, and by the standards we had all been trained on, it was solid. Clear user story. Well-defined acceptance criteria. Sensible scope. The kind of document any experienced engineer would have read, asked two or three clarifying questions about, and then built correctly. She fed it to an AI coding agent instead. The output was technically functional. Every acceptance criterion was met in the most literal sense imaginable. But the feature was wrong. Not subtly wrong. Visibly, almost comedically wrong, in a way that would have been funny if it had not cost three days of debugging and a missed sprint commitment. The spec said users should be able to "manage their notification preferences." The AI built a single toggle: notifications on, notifications off. But that was it. Technically, that is managing preferences. The spec said the interface should "display current settings." The AI rendered every setting the system tracked, including internal flags the user was never meant to see, in an alphabetical list with no grouping. Technically, those are current settings. Every line in the spec was honoured. Not a single line was understood. At Boeing, years earlier, I had seen spec ambiguity cause problems with human engineers too. A requirements document for an internal tooling project described a data validation step as needing to "confirm accuracy." Two different engineering teams interpreted "accuracy" differently, one as format validation and the other as value-range checking. But the difference was caught in a review meeting within a week. Someone asked a question. Someone clarified. The charitable interpretation layer did its work. With an AI agent, there is no review meeting. There is no question. There is just the output, built to spec and built wrong. Charitable interpretation debt This is what I now think of as charitable interpretation debt: the accumulated distance between what a spec says and what the team understands it to mean, bridged entirely by human judgement and shared context. For years, this debt was invisible because humans were always the readers. The collaboration layer absorbed the imprecision. Engineers and PMs sat in the same standups, shared the same Slack channels, built the same mental model of what the product should become. The spec was a starting point. It was never the final instruction. But when an AI agent becomes the reader, the debt comes due. All of it. At once. Every assumption left unstated becomes a potential defect. Every instance of "they will know what I mean" becomes a feature that works exactly as written and nothing like what was intended. The spec has to carry the full weight of the decision now, because there is no collaboration layer to catch what falls through. Ambiguity in a spec used to be a communication problem. Now it is a build defect. The precision flip I think of this shift as the precision flip. For twenty years, the best PM skill was knowing what to leave out of a spec. Brevity signalled respect. A forty-page PRD was the hallmark of a PM who did not trust their engineers. But now, what you leave out is what the AI gets wrong. The virtue flipped overnight. The instinct that made you effective last year is the instinct producing broken features this year. The solution is not writing more. But that is what most PMs try first. I have seen them respond to this problem by adding pages of specification, trying to anticipate every possible interpretation of every possible instruction. That produces a different kind of failure: a document so dense that important decisions are buried under procedural detail, and the AI treats every instruction with equal weight because every instruction is presented with equal weight. The skill that matters now is precision without volume. Saying exactly what you mean in exactly as many words as that requires. Not fewer. Not more. But the kind of precision that comes from having actually made the product decision before writing it down, rather than drafting something vague enough that the decision can be deferred to whoever builds it. The spec was always the product decision. We just did not notice because humans were generous enough to fill in the gaps. What the rewrite taught her The PM whose notification feature went sideways rewrote her spec the following week. Same feature. Same intent. But this time, every ambiguous term was defined. "Manage preferences" meant a screen with six toggleable categories, each with an on/off state and a frequency selector offering daily, weekly, or never. "Display current settings" meant showing only user-facing preference states, grouped by category, with the current selection highlighted. The spec was not meaningfully longer. It was more precise. The AI agent built it correctly on the first pass. She told me afterwards that the exercise changed how she thought about product decisions. "I used to think the spec described the decision," she said. "Now I think the spec is the decision." That is not a small distinction. It is the entire shift. I spent my career writing specs that left room for engineering judgement. That was the right approach for human collaborators. It signalled trust. It created space for engineering expertise to improve the product beyond what I had imagined. But that same approach, given to an AI agent, does not signal trust. It signals incompleteness. And the AI does not improve upon what you imagined. It executes what you specified. Nothing more. Nothing less. Nothing better. The PMs who are adjusting fastest have recognised something that the rest of the field will absorb over the next year: the writing is the building now. If you have not decided precisely what "manage" means, what "display" includes, and what happens when there is nothing to show, you have not finished making the product decision. You have deferred it to a reader that cannot decide. Product managers developed an instinct for productive ambiguity over many years, and that instinct was earned honestly. It served its purpose well. But the readers are changing, and the writing has to change with them. Not because the old way was wrong. Because the audience is different now, and writing for the audience you have is the oldest communication skill there is.

Communication & Storytelling February 28, 2025

Workflow redesign, not tool adoption, is what produces AI value for teams

In the 1980s, a wave of American manufacturers bought the same robotic welding systems that Toyota used. The machines were identical. The specifications matched. The output per unit of the robots was the same. But the American factories installed the new robots on their existing assembly lines, in the same sequence, with the same handoff points, feeding into the same quality inspection process they had used for decades. Productivity improved maybe fifteen per cent. Toyota, using the same machines, had improved productivity by multiples. The difference was not the machines. It was that Toyota had redesigned the entire line around what the machines could do. The Americans had added faster machines to a slow process. Toyota had built a new process around fast machines. That is the exact pattern playing out in product teams right now. The tool trap Organisations are adopting AI tools at extraordinary speed. By most estimates, the majority of product teams now use AI in some form: for code generation, for copy, for research synthesis, for design exploration, for test automation. The tools are everywhere. But the data tells a quieter, more uncomfortable story. Only about 39% of organisations report seeing enterprise-level financial impact from their AI investments. The rest have the tools. They have the licences. They have the training workshops and the internal champions and the executive sponsor who gave the keynote at the all-hands meeting. What they do not have is a different way of working. I call this the tool trap. The tool trap is the belief that adopting a better tool will produce a better outcome without changing the process the tool operates within. It is the manufacturing problem, restated for knowledge work. You buy a faster machine and run it on the same slow line. Three tools, same bottleneck At Freshworks, I watched a product team adopt three AI tools in a single quarter. One for code generation, one for user research synthesis, one for generating design variations. The tools were good. The team learned them quickly. Individual tasks got faster. A research report that used to take two days took four hours. A first-pass design that took a week now took two days. Code that required a full sprint to scaffold could be generated in hours. But the output of the team improved by maybe ten per cent. The code was generated faster, but it still went through the same three-stage review process with the same two approvers who met once a week. The research synthesis was faster, but it still entered the same prioritisation meeting with the same stakeholders arguing over the same backlog. The design variations were faster, but they still waited in the same approval chain that had been designed when producing one variation took a week. The tools were faster. The process was the speed limit. Every gain the tools created was absorbed by a process designed for a slower world. The team had not adopted AI badly. They had adopted it into a structure that could not use the speed. It was like putting a racing engine into a car with the parking brake on. The engine is not the problem. But the car is not going anywhere. Redesigning the line The teams seeing real returns from AI are not the ones with the best tools. They are the ones that asked a fundamentally different question. Not: how do we make our current work faster? Instead: if we were building this workflow from scratch, knowing what AI can do, what would it look like? That question produces a different kind of answer. It eliminates steps rather than accelerating them. It changes who does what. It restructures the sequence entirely. I experienced this firsthand when building productnatives. My original writing and research workflow had seven steps: identify the topic, research the existing conversation, outline the argument, write the first draft, revise, fact-check references, and edit. When I started using AI tools, I initially used them to speed up steps two and four. Research was faster. Drafting was faster. But the overall quality and speed of the output did not change as much as I expected. The bottleneck was not the research or the drafting. It was the sequence itself. So I redesigned the workflow from scratch. I eliminated three steps entirely and replaced them with a different sequence built around what AI could actually do well: hold context across multiple sources, generate structural alternatives quickly, and identify gaps in an argument before I had finished making it. The new workflow does not look like the old one made faster. It looks like a different process. And the output is meaningfully better, not because the tool changed but because the process changed. That is what I call the workflow dividend. The workflow dividend is the compounding return you get when you redesign a process around AI's actual capabilities rather than layering AI onto an existing process. The dividend does not come from the tool. It comes from the redesign. Why teams resist the redesign But most teams do not redesign. They adopt. And there are reasons for that. Redesigning a workflow is uncomfortable. It means admitting the current process has inefficiencies that people have been working around for years. It means changing responsibilities, which changes power dynamics, which changes who feels essential. It means facing the possibility that three of the seven steps in your process exist only because they always existed, not because they add value. But there is a deeper reason. Tool adoption is visible. You can report it. You can put it in a quarterly review: "We adopted three AI tools this quarter." Workflow redesign is harder to measure and harder to announce. Nobody gets promoted for saying "I eliminated the weekly design review because AI-generated variations made it redundant." That sounds like you removed something. It does not sound like progress, even when it is. But the gap between tool adoption and workflow redesign is where nearly all the value lives. The 39% of organisations seeing real financial impact from AI are not there because they bought better tools. They are there because they rebuilt the line. The question that matters The Freshworks team eventually got there. After a painful quarter of faster tools and unchanged results, someone (not me, to be clear, I take no credit for this) asked the obvious question: what if we stopped feeding AI output into a process designed for human speed? Within two months, they had restructured the review cadence, collapsed two approval stages into one, and changed the sprint structure to match the pace the tools actually enabled. Output improved by a factor that made the previous ten per cent look like a rounding error. But the tools had not changed. Not one new licence. Not one new feature. The process changed, and everything moved. Product teams keep asking which AI tools to adopt. The better question is which workflows to redesign. The tool is never the bottleneck. The process around it always is.

Product Teams & Org DynamicsFebruary 28, 2025

The T shaped generalist replaces the narrow specialist as the ideal team member

For most of the last two decades, the advice was clear: specialise. Go deep. Become the person who knows more about one thing than anyone else on the team. Build a reputation around a craft so narrow and so refined that nobody could question your seat at the table. That advice made sense because execution was expensive. When building a polished interaction or writing clean production code took weeks of skilled human effort, the specialist's depth was genuinely irreplaceable. The team needed someone who could do the thing at a level nobody else could match. But execution is getting cheaper by the month. And the bet that built an entire generation of product careers is starting to look like the wrong one. The specialisation trap Specialisation was a bet on execution staying expensive. That bet just lost. When AI tools can generate a high-fidelity prototype in an afternoon, write functional code from a design spec, or synthesise forty user interviews into a pattern map, the specialist's advantage does not disappear entirely. But it narrows. The gap between what a deep specialist produces and what a competent generalist with AI tools produces has compressed in ways that would have been absurd to predict even two years ago. I call this the specialisation trap. It is not that specialists are bad. It is that the conditions that made narrow specialisation the optimal career and team strategy have changed. The trap is continuing to invest in depth as if the economics of execution have not shifted underneath you. But the trap has a mirror image. The generalist's advantage has widened at the same rate the specialist's has narrowed. A person who can move between research, design, prototyping, strategy, and stakeholder communication, who has deep judgment in one area but functional fluency across several, has become structurally more valuable. The handoffs between specialists were always where products lost coherence. Every handoff is a translation. Every translation is a loss. The generalist reduces the number of translations a product has to survive. Adobe and two kinds of contribution At Adobe, I worked on a team that had both archetypes in sharp relief. We had a senior visual designer, one of the most talented people I have worked with, whose interface work was genuinely exceptional. Pixel-level precision. A deep understanding of typography, spacing, and visual hierarchy that bordered on instinctive. When she produced a screen, it was beautiful. There is no other word for it. On the same team, we had a mid-level designer who was not exceptional in any single dimension. Her visual design was good but not remarkable. But she could do something the specialist could not. She could sit in a user research session in the morning, synthesise the findings over lunch, adjust the prototype by afternoon, and present a revised direction to stakeholders before the end of the day. No handoffs. No briefs. No waiting for someone else to translate her work into the next step. The specialist produced higher-quality individual deliverables. But the generalist contributed more to the product. Her work moved faster through the system because she was the system. She did not need to wait for a researcher to interpret findings or a strategist to frame her recommendations. She held enough understanding across those domains to keep the work moving without the friction that handoffs create. When AI tools started arriving on the team, the dynamic accelerated. The specialist's visual design advantage narrowed because AI could handle much of the execution she had previously owned. Generating layout variations, producing component states, building responsive versions of a screen. These were no longer tasks that required her specific depth. But the generalist's advantage widened because her judgment across domains was something no AI tool could replicate. The tool handled craft. She handled context. I started thinking of this as the flex advantage. The value of being able to operate across the boundaries of your formal role, not because you are mediocre at everything, but because you are fluent enough in adjacent domains to reduce the coordination cost that specialists create. Broadening as identity threat A few years ago, I was mentoring a mid-career designer who was deep in interaction design. Genuinely deep. She could talk about state management, micro-interactions, and transition patterns with a precision that most of her peers could not match. But she had never touched user research. She had never been in a pricing conversation. She had never thought about how a design decision affected acquisition cost or retention metrics. I suggested she spend six months broadening. Sit in on commercial reviews. Run a few research sessions herself instead of consuming someone else's report. She resisted, and I understood why. Her specialism was her identity. It was the thing she was known for, the source of her confidence in a room full of senior people. Broadening felt like dilution. But six months later, her contributions in product reviews changed fundamentally. She stopped presenting interaction patterns as isolated craft decisions and started framing them in terms of what they meant for user retention, onboarding completion, and commercial conversion. She could speak to the implications of her work, not just the quality of it. The interaction design did not get worse. It got contextualised. The broadening did not replace her depth. It gave her depth a voice. She had been producing excellent work that nobody outside the design team fully understood, because she could not translate it into the language that product managers, engineers, and commercial leads used to make decisions. Now she could. The studio musician and the composer There is a useful analogy from music. A session musician who plays one instrument at an extraordinary level gets hired for recording sessions. Walks in, plays the part, walks out. Valuable. But the musician who plays three instruments and can compose, who can hear what a track needs before anyone articulates it, runs the studio. The session musician waits for instructions. The composer shapes the outcome. Product teams are filling up with session musicians. But the teams that ship coherent products, the ones where the output feels like a single mind designed it rather than a committee of departments, are led by people who can see across the full arc of the work. That does not mean depth is irrelevant. A generalist without depth is just someone with opinions about everything and mastery of nothing. The T-shape matters because the vertical bar, the area of genuine expertise, is what gives the horizontal bar credibility. But the horizontal bar is what gives the vertical bar relevance. What the bet actually was The question is not whether specialists still have value. They do. The question is whether building a team primarily around narrow specialists, each handing off to the next, is still the optimal structure. Increasingly, it is not. But AI is collapsing the cost of execution across domains. What remains expensive is judgment: knowing what to build, knowing when to stop, knowing how a design decision ripples through revenue, retention, and user trust. That kind of judgment does not live in a single discipline. It lives in the spaces between disciplines, in the person who has spent enough time in adjacent domains to see what the specialist, by definition, cannot. The mid-career designer I mentored did not become less of a specialist. She became a specialist whose work mattered more, because she could connect it to the outcomes the organisation was actually measuring. That is not dilution. That is completion. The specialist who only speaks one language will always need a translator in the room. The generalist who speaks three will sometimes be the one who decides what gets said.

Product Teams & Org DynamicsFebruary 25, 2025

The pricing meeting you weren't supposed to be in.

You got pulled into a meeting last quarter that wasn't on your usual circuit. Finance was there. Someone from revenue operations. A commercial lead you'd exchanged maybe four emails with in two years. The agenda said pricing review. You assumed you were there to answer questions about the product. You were not. You were there because someone senior had finally said what a few people had been thinking quietly for a while: the people setting the price have no idea how the product actually behaves, and the people building the product have no idea what the price is doing to user behaviour. You left that meeting with homework you hadn't expected and a vague sense that something structural had just shifted. That sense was correct. But most PMs who land in that meeting don't act on it until the second or third time they're summoned. For most of the history of software products, pricing was downstream of the product. The product team built the thing. The commercial team figured out what to charge for it. The two processes ran in parallel, occasionally intersected, and mostly stayed out of each other's way. The logic was defensible. Pricing felt like a revenue question. Product felt like a user question. Different problems, different teams, different Tuesdays. But the logic had a flaw in it that took years to surface. Pricing doesn't just decide what a product costs. It decides how users experience it. A free tier that gives users just enough to understand what they're missing creates a different relationship with the product than a free tier that actually lets them solve a real problem. A per-seat model shapes collaboration behaviour in ways that a flat subscription never will. A usage-based model creates anxiety at exactly the moments when users should be getting value, and that anxiety shows up in engagement data whether or not anyone in the product team has connected the two. Pricing isn't a number placed on top of the product. It's a design decision baked into the product. But for years, most product teams let someone else make it, and then wondered why the user behaviour wasn't behaving. I was brought in to look at a SaaS product about a year ago that had a retention problem nobody could diagnose. Engagement was strong in the first thirty days. Drop-off started around the six-week mark, consistent across cohorts, and the team had tried everything they could think of on the product side. New onboarding sequences. Improved empty states. A redesigned dashboard that tested well but didn't move the retention number even slightly. Everyone was frustrated. But nobody had looked at the pricing structure. When I finally did, the problem was visible in about twenty minutes. The product had a usage-based component that users hit at roughly the six-week mark as their workflows matured. Not a hard wall. A soft limit that triggered an upgrade prompt. The team knew about the limit. But what they hadn't connected was that the prompt was arriving at exactly the moment users were deciding whether this product was worth building their workflow around. The upgrade ask wasn't landing at a moment of success. It was landing at a moment of uncertainty. The user had invested six weeks. They were starting to get real value. And the product responded by asking them to make a financial commitment before they felt secure enough to make it. That's not a UX problem. That's a pricing timing problem. But it lived in the product experience, and nobody on the product team had the brief to look there. The PMs I'm talking to who are navigating this well aren't the ones who became pricing experts. That's a different job. But they are the ones who started asking a different question in roadmap sessions. Not just: what does this feature do for the user. But: what does this feature do to the user's relationship with the pricing model. Those are different questions. A feature that adds genuine value in isolation can create real friction when it interacts with a usage cap. A workflow improvement that increases engagement is a retention win only if the pricing model doesn't penalise the engagement it creates. The product and the pricing model aren't separate systems. But most product teams have been treating them that way, and the retention curves tell you exactly where the two systems are colliding. The shift being asked of product people right now isn't "become a commercial person." It's narrower than that. It's: understand how the structure of your pricing shapes the behaviour of your users, the same way you understand how the structure of your onboarding shapes it. Pricing is a UX decision made by a different team. The product person who understands that is operating at a level the one who doesn't simply can't reach. The meeting you got pulled into wasn't an accident. Someone in your organisation has started to notice the gap. But the question is whether you walk back into the next one with a point of view, or wait to be asked questions again. The product teams closing this gap are finding that retention numbers, upgrade rates, and expansion revenue start behaving differently when the people who understand user behaviour are in the room where pricing decisions get made. Not because PMs are better at pricing than commercial teams. But because no one else in that room is thinking about what the price does to the person using the product at ten in the morning when they're just trying to get their work done. That perspective belongs in the room. And right now, in most organisations, it isn't there yet.

Product StrategyFebruary 20, 2025

When the map became the Territory

For most of the twentieth century, navigation was a profession. Not just for sailors. For anyone moving through unfamiliar space. Taxi drivers in London spent two to four years acquiring what they called The Knowledge: every street, every shortcut, every one-way system in a city of eight million people. The exam was brutal. The failure rate was high. The people who passed carried something that could not be written down or easily transferred. It lived in the body, activated by landmarks and turns and the accumulated memory of ten thousand trips. Then GPS arrived. And The Knowledge stopped being a competitive advantage. It became a curiosity. Nobody stopped needing good navigation. The need is still there. But the skill migrated. It moved from the driver's head into infrastructure. Into software. Into a layer of the world that most people interact with without ever thinking about who designed it or how it works. I have been thinking about that migration a lot as the conversation about AI-native interfaces has moved from speculation to something more urgent. For thirty years, designing digital products meant designing screens. That assumption was so foundational it was invisible. You hired designers to make interfaces. Interfaces were visual. They had layouts, typography, components, flows. The craft of the discipline was the craft of making those elements work together for a human who could see and click. But the interface was always just the solution to a specific problem: how does a human communicate with a machine that cannot understand natural language? Screens and menus and buttons were a workaround. An elegant workaround, refined over decades into something genuinely expressive. But a workaround nonetheless. The workaround is starting to become optional. When I first used a conversational AI interface to accomplish something I would normally have done with a series of menus and clicks, my first reaction was not excitement. It was mild disorientation. The thing I was looking for, the next step, the option to select, the button to press, was not there. I was just talking. And the task was getting done. It took me longer than I expected to stop looking for the interface. That is not a trivial observation. I have been designing interfaces professionally for twenty years. The instinct to find the UI runs deep. But the instinct was built in response to a constraint that is, in some contexts, now lifting. What replaces it is a different kind of design problem. Not harder, exactly. But genuinely different. And the profession has not yet fully worked out what that difference requires. The question being asked loudly in design communities right now is whether screen-based design skills are becoming obsolete. This is the wrong question, and it is producing a lot of unnecessary anxiety alongside a lot of premature reassurance. The right question is: what is the actual design problem when the interface is a conversation, an agent, or a system that operates in the background? Some of the answers are familiar. Users still need to understand what a system can do. They still need to know when it has succeeded or failed. They still need to be able to trust it with appropriate calibration and correct it when it is wrong. These are design problems. But they are not screen problems. The craft shifts toward decision design. Toward the logic of how a system interprets ambiguous instructions. Toward the communication of uncertainty, confidence, and limitation in a medium that has no affordances in the visual sense. Toward the design of error, which in conversational interfaces is a completely different problem than a 404 page. None of this is simple. But none of it is outside what design has always done at its best. The London taxi drivers did not disappear when GPS arrived. But the ones who thrived were the ones who understood what navigation had always been about: getting someone from where they are to where they need to be, efficiently, with confidence, in conditions that are never quite the same twice. That is still the job. The instrument has changed. The designers who will carry the most influence through this shift are not the ones who are most skilled at visual interfaces, though that skill is still useful and will remain so for a long time. They are the ones who understand, at a fundamental level, what design has always been solving for. Not "how should this screen look?" But "how does a human make sense of something they have never encountered before, and what does a system owe them to make that possible?" That question has not changed. Every technology that replaces a previous interface asks it again, in a new form. The map is changing. But the territory is the same.

Product Design & Craft TopicsFebruary 13, 2025

The dark forest buyer: Researching in private, appearing only when ready

In Liu Cixin's science fiction, the universe operates on a single, brutal principle. Every civilisation hides. Not because they are weak, but because revealing your existence invites contact, and contact is dangerous. The universe is a dark forest where every civilisation is a silent hunter, watching, calculating, never announcing itself until it is ready to act. Survival depends on staying invisible.I think about this every time I look at buyer behaviour data.The dark forest buyer is not a metaphor I chose for drama. It is the most accurate description I have found for how modern B2B buyers actually behave. They research in private. They consume content without leaving a trace they are willing to be identified by. They visit pricing pages, read case studies, compare alternatives, talk to peers, and form opinions. All of it happens in silence. But by the time they reveal themselves to a vendor, the decision is not beginning. It is nearly finished. Why buyers hide The reason is not complicated. Buyers learned, through repeated experience, that engaging a vendor means entering a sales process. And sales processes, in most organisations, are designed to serve the vendor. The moment you fill out a contact form, you are in a pipeline. You get a call within the hour. You get emails. You get "just checking in" follow-ups. You get added to a nurture sequence that will outlive most houseplants.Buyers are rational. They adapted. They stopped filling out forms.But here is the part that should concern every product team: the buyers did not stop researching. They stopped being visible while they researched. The behaviour continued. The signal disappeared.At Freshworks, I saw this pattern in the analytics and it was unsettling. We had visitors who consumed fifteen, sometimes twenty pieces of content. Blog posts, comparison guides, integration documentation, the pricing page (multiple times). They did all of this without ever filling out a contact form, starting a trial, or requesting a demo. They were ghosts in the data. Present, active, deeply engaged, and completely silent.Then, one day, they would appear. A demo request. A trial sign-up. A direct email to sales. And when the conversation started, something strange would happen. The buyer already knew the product. They knew the pricing tiers. They knew which integrations we supported and which we did not. They had read the documentation more carefully than half the sales team. They were not arriving to learn. They were arriving to confirm.The most important sales conversation was happening when nobody from sales was in the room. The invisible evaluation I call this the invisible evaluation. The period where a buyer is actively, seriously evaluating your product, and your team has no idea it is happening. Your analytics might show anonymous traffic. Your content metrics might show page views. But there is no lead, no contact, no hand raised. The evaluation is real. The visibility is zero.But this is not a minor pattern at the edges of your funnel. This is the funnel, for a growing majority of B2B decisions.I experienced the same pattern from the other side when I started writing and building publicly after leaving my corporate role. I could see who was reading. Time on page, return visits, scroll depth. Some readers consumed everything I published for weeks before they ever reached out. When they did, the conversation was not an introduction. It was a continuation of something that had been happening in their heads for a month.The readers who became customers had been silently evaluating for weeks. They knew my perspective, my positions, my blind spots, my tone. They had already decided whether they trusted me. The first conversation felt like the fifth.But I only knew this because I was paying close attention to patterns in anonymous engagement. Most teams do not. Most teams measure leads, not ghosts. What the dark forest demands If the buyer is evaluating in private, your product has to speak for itself in a way that most products are not designed to. Every piece of content becomes part of the sales pitch. Every documentation page, every pricing page, every comparison chart, every public feature description. The buyer is reading all of it without a guide, without a sales engineer to walk them through it, without context about which features matter most for their use case.Your product experience is a sales conversation nobody from your team is present for.But most product-led experiences are still designed with the assumption that someone from the company will show up at some point to fill in the gaps. The onboarding assumes a sales conversation happened first. The pricing page assumes a human will explain the tiers. The documentation assumes the reader has context that only a demo would provide.But the dark forest buyer has none of that context. They are assembling it alone, from whatever you have made publicly available. And they are making a decision based on what they find.This puts enormous pressure on the quality and clarity of everything that is publicly visible. Not marketing pressure, where the goal is to generate a lead. Product pressure, where the goal is to be understood by someone who will never ask a clarifying question.At Freshworks, we eventually started treating the public product experience as if it were a sales conversation in its own right. Not gated content designed to capture an email address. Not pricing pages designed to push people toward "contact us." But genuine, complete, honest information designed for someone who would never contact us at all.It felt counterintuitive. The sales team worried we were giving away too much. But the buyers who arrived after consuming all of it were better qualified, faster to close, and more confident in their decision than those who had gone through the traditional sales process. They had already done the work. They just needed someone to say yes. What hides in the silence But the uncomfortable truth is that most product teams cannot answer a simple question: what does your product say about itself when nobody from your team is in the room? Not what your marketing says. Not what your sales deck says. What does the actual experience, the trial, the documentation, the public-facing product, communicate to someone who is evaluating in complete silence?Buyers are not absent from the funnel. They are hiding inside it.And they are hiding for a reason that should make every product team pause. They believe that revealing themselves will make the experience worse, not better. That the moment they raise a hand, they will be sold to rather than helped. That the sales process will be about the vendor's timeline, not the buyer's.The dark forest buyer is not a problem to solve. It is a verdict on how buyers experience your sales process. They tried it. They learned. They adapted by disappearing.The only question that matters is what your product says about you when you are not there to say it yourself.

User & Buyer PsychologyFebruary 13, 2025

The SaaSpocalypse: AI Agents began destroying the per-seat Subscription model's structural logic

The most successful business model in software history is being destroyed by its own customers. Not by a competitor with a better product. Not by an open-source alternative eating the margins. By the people who pay the invoices deciding, quietly and rationally, that they no longer need the thing they have been buying. That thing is the seat. The Seat Assumption For two decades, the entire SaaS industry operated on a single foundational premise. I call it the seat assumption: the belief that software value is consumed by human users, and therefore the right way to charge for software is per human who uses it. More users, more value, more revenue. It was clean. It was predictable. It was the foundation of every SaaS financial model, every board deck, every investor thesis in enterprise software. At Freshworks, I lived inside the seat assumption every day. Our product strategy was explicitly designed to increase seat counts within accounts. Features were evaluated, at least partly, on whether they would drive adoption by additional users in a customer's organisation. An integration that connected sales and support teams was not just a product improvement. It was a mechanism for turning a five-seat customer into a twelve-seat customer. The entire product roadmap had an embedded commercial logic: build things that create reasons for more people to log in. And it worked. For years, it worked beautifully. Land a small team, prove value, expand to adjacent departments, grow the contract. The compounding maths of per-seat expansion was the engine that drove SaaS multiples to 18x, 19x revenue at the peak. Investors were not paying for today's seats. They were paying for the assumption that there would always be more seats tomorrow. Nobody questioned the assumption. Why would you question a machine that prints money? But that assumption contained its own destruction. The Agent Substitution When an AI agent does the work that a human with a software license used to do, the license becomes a cost without a user. This is not competitive displacement. Nobody switched to a better CRM. Nobody found a cheaper alternative. The work that required a person sitting in front of a screen simply stopped requiring a person. Klarna announced it had replaced Salesforce's CRM with a homegrown AI system. The commentary focused on whether their internal tool was any good. But that is the wrong question. The right question is: what happens to a per-seat pricing model when the customer's strategy is to reduce the number of humans who need seats? But almost nobody in the SaaS industry was asking this question. They were still arguing about features. I call this the agent substitution, and it is structurally different from any competitive threat the SaaS industry has faced. A competitor takes your customers. The agent substitution eliminates your unit of pricing. The customer stays. The seats disappear. A founder I advise runs a B2B SaaS product that charges per seat. Solid product. Good retention. Growing steadily until three months ago, when one of their largest customers deployed AI agents across their operations team. The team went from twelve people to four. The subscription went from twelve seats to four. Overnight. Not because the product failed. Not because a competitor won the deal. Because the customer's AI strategy made eight of those humans, and their corresponding software licenses, unnecessary. The product did not fail. The pricing model failed. The Repricing The market has noticed. The median EV/Revenue multiple for public SaaS companies has compressed from the pandemic peak of 18-19x to 5.1x. That is not a correction. It is a structural repricing of the entire application software layer. But the repricing is not uniform. What the market is saying, in its blunt and unsubtle way, is that the seat assumption was not a business model. It was a temporary condition. A condition that held true only as long as software work required human operators. The moment that condition changed, the valuation framework built on top of it had to change with it. But here is what most of the commentary misses. The agent substitution does not threaten all SaaS companies equally. It threatens the ones whose entire value proposition is wrapped around the interface layer: the CRM that is valuable because humans interact with it, the project management tool that organises human workflows, the communication platform that connects human team members. When AI agents can perform those interactions through APIs without ever touching a user interface, the seat is not reduced. It is made irrelevant. The companies that are less exposed are the ones whose value lives in proprietary data, regulatory workflows, or domain-specific intelligence that an AI agent cannot replicate simply by accessing an API. But those are a minority. Most of the SaaS market was built for human users doing human-scale work in human-operated teams. That world is not ending tomorrow. But the financial markets are pricing as though it is ending eventually, and they are adjusting now. What the Numbers Cannot Show At Freshworks, I remember sitting in product reviews where we would celebrate a customer expanding from eight seats to twenty. The room treated it like a product win. More users meant the product was working. More users meant more value delivered. But looking back, what we were actually celebrating was the seat assumption holding true for another quarter. We were celebrating a condition, not a capability. The SaaS founder I advise is not panicking. She is rebuilding her pricing model around outcomes rather than access. But she told me something that stuck: "I spent three years optimising for seat expansion, and an AI agent undid it in a week." The speed is the part that catches people off guard. Competitive displacement happens over quarters. The agent substitution happens over a deployment cycle. There is a strange irony in all of this. The companies that built the best products, the ones that made software so useful that organisations built entire workflows around them, are now the most exposed. Because those workflows are precisely the ones that AI agents can automate. The better your product was at enabling human work, the more clearly it demonstrated that the human was the variable, not the software. But nobody saw it that way at the time. Success has a way of hiding the assumptions it depends on. Nobody planned this. The per-seat model was not a mistake. It was the right model for a world where software was a tool that humans operated. But the world where software is operated by humans and the world where work is performed by agents turn out to be different worlds with different economics. The question for every SaaS company is no longer how many seats they can sell. It is whether the seat is still the right unit of value at all. For a growing number of customers, the answer is already clear. The quiet part is that most of us who built products inside the seat assumption never questioned it. It was the water we swam in. Some assumptions only become visible when they stop being true.

Markets & Industry DynamicsFebruary 1, 2025

The most responsive leader on your team is probably the worst thinker

Here is a paradox that nobody in product leadership wants to confront. The person on your team who replies fastest, who is always available, who never keeps anyone waiting for a decision or a Slack response, is almost certainly doing their worst strategic thinking. Not because they are incapable. Because they have structured their days in a way that makes deep thinking nearly impossible. And the entire organisation reads their behaviour as exemplary. For years, responsiveness has been the implicit standard for leadership credibility in product organisations. The leader who answers within minutes is perceived as engaged. The one who replies in four-hour windows is perceived as checked out, or worse, as someone who does not care. This is not written in any performance review rubric. But it operates like doctrine. And most senior product people have internalised it so deeply that they do not even recognise it as a choice. It feels like the job. But every time you switch from one cognitive task to another, you lose approximately 23 minutes of refocus time. Not because you are slow. Because the brain needs to reload context, re-establish working memory, and suppress the residue of the previous task. That number comes from research at the University of California, Irvine, and it has been replicated enough times that arguing with it is like arguing with gravity. You can disagree. You will still fall. Responsiveness is a performance of engagement. Batching is the practice of it. The Responsiveness Trap I fell into this trap myself. For years. At Freshworks, I was the PM who replied to every Slack message within ten minutes. I wore it like a badge. My calendar was a patchwork of thirty-minute blocks separated by five-minute gaps that I used to clear notifications. I attended every standup. I was available for every "quick sync." I felt productive. I felt like I was on top of things. But my strategic output during that period was mediocre. I can say that now because I have the distance to compare it with what came later. The roadmap decisions I made were safe. The product direction memos I wrote were competent but unremarkable. I was so busy responding to the work that I never created the conditions for the kind of thinking that produces genuinely good strategic calls. I was present for everything. I was deep on nothing. The irony is that the organisation rewarded this. My responsiveness was visible. My shallow thinking was invisible. Nobody sees the strategy memo that could have been sharper if you had spent three uninterrupted hours on it instead of forty-five fragmented minutes. They only see the Slack reply that arrived in under two minutes. I have started calling this the responsiveness trap: the pattern where visible availability crowds out invisible quality, and the organisation cannot tell the difference because it only measures the visible part. Cognitive Batching The alternative that has been gaining serious traction among senior product people in early 2025 is cognitive batching. The idea is not new. Cal Newport wrote about deep work years ago. But the specific application to product leadership is different, because product work involves a wider range of cognitive modes than most knowledge work. Strategy writing, design reviews, one-on-ones, and customer escalations all draw on different mental resources. But the practice spreading now groups those modes together rather than interleaving them. All external communication happens between 2pm and 4pm. All strategy work happens on Tuesdays and Thursdays before noon. All one-on-ones are compressed into a single afternoon. The principle is that switching between similar tasks costs almost nothing, but switching between different types of cognition costs almost everything. At Grab, I worked with a product director named Wei Lin who was the most ruthless batcher I have ever seen. She checked email twice a day. She rejected roughly half of all meeting invitations. Her Slack status said "Replies between 2pm and 4pm SGT" and she meant it. Half the team thought she was disengaged. But her output was extraordinary. Her roadmap documents were the sharpest I had encountered at the company. Her quarterly planning sessions were the most efficient because she arrived having done real thinking in uninterrupted blocks, not thoughts cobbled together between meetings. The team that initially found her unavailability frustrating started to notice that when she did engage, the quality was different from everyone else's. She was not doing more work. She was protecting the conditions under which good work becomes possible. Why the Resistance Is So Strong If cognitive batching works this well, you might ask why it has taken this long to gain traction. The answer is cultural, not logical. Responsiveness is legible. Batching is not. When you reply to a message in two minutes, your manager sees it. Your peers see it. The person who asked the question sees it. But when you spend three hours in deep strategic thinking and produce a document that is 20 percent sharper than it would have been otherwise, nobody can see the counterfactual. Nobody knows the document could have been worse. They only see the document as it is and assume that is what you would have produced regardless. This is the measurement problem at the heart of the responsiveness trap. Organisations measure what is visible. Responsiveness is visible. Thinking quality is not. But nobody questions the incentive structure, and so it quietly rewards the behaviour that produces worse strategic output. I noticed this most acutely when I moved from Bangalore to Wayanad. The physical distance from an office meant that nobody expected me to be available for hallway conversations or impromptu syncs. For the first time in my career, the default was batched. Not because I had chosen it philosophically. Because geography had imposed it. But the change in my output quality was stark enough to be embarrassing. My writing got sharper. My product thinking got deeper. My strategic calls improved. The only variable was the structure of my days. I had not become smarter. But I had stopped fragmenting the intelligence I already had. I had been capable of this thinking all along. I had just never given myself the conditions to do it. The Permission Problem The hardest part of adopting cognitive batching is not the practice. It is the permission. Most product leaders feel they cannot batch because the organisation expects constant availability. But that expectation is usually assumed, not stated. When I have seen senior PMs explicitly tell their teams "I reply to messages between these hours, and I am unreachable outside them," the initial discomfort lasts about two weeks. After that, the team adapts. They learn to batch their questions too. They learn to solve more problems independently. They learn that an answer at 3pm is usually just as useful as an answer at 9:15am. But the PM has to go first. And going first feels like risk. The product leaders I respect most right now are the ones who have stopped performing engagement and started practising it. They are less responsive. They are less available. But the thinking they produce carries a weight that their always-on peers simply cannot match. The 23 minutes of refocus time is not a number you can negotiate with. It is the tax on every context switch. Most product leaders believe they are immune to it. They are paying it fifteen or twenty times a day without knowing it. Protecting the conditions for thinking is not a productivity technique. It is a professional obligation for anyone whose job is to think well on behalf of a product and the people who use it.

Productivity & Working MethodsFebruary 1, 2025

Building Is no longer the hard part

For most of the last decade, building a product was the filter. You needed engineers. You needed capital to pay them. You needed months of work before you had something a user could actually touch. The product itself was the barrier to entry. If you could ship something functional, you'd already done the hard thing. But that filter is gone. And most product teams haven't updated their strategy to account for what that actually means. The cost of building has collapsed faster than most organisations have restructured around the change. AI-assisted development has compressed timelines that used to take quarters into weeks. A two-person founding team can ship something functional faster than a team of twenty could two years ago. The infrastructure barrier that used to separate serious products from amateur attempts has effectively disappeared. But a cheaper product doesn't win by being cheaper to build. It wins by reaching the people who need it. And reaching people is still hard. In some ways it's harder than it's ever been, because everyone else is also shipping now. Which means the competitive question has changed entirely. Not "can you build it." But "can you get it to the people who need it before someone else does." I worked with a team last year who had built something genuinely good. Not good for a small team. Good, full stop. Clean architecture, a thoughtful onboarding experience, a core use case that solved a real problem faster than anything else in the market. Eighteen months after launch they had four hundred users. Not four hundred thousand. Four hundred. The product wasn't the problem. They knew their user. They'd validated the problem carefully. The feedback they were collecting confirmed they were solving something real and solving it well. But they'd spent ninety percent of their time and budget on the build and roughly ten percent thinking about how to get it to anyone. Their distribution strategy, when I asked them to walk me through it, turned out to be a launch on a startup listing site, a handful of LinkedIn posts, and the reasonable but insufficient belief that quality would find its own audience. It didn't. Quality almost never does. But teams keep trusting it to, because quality is the thing they built and it's easier to believe in something you made. There's something that happened in the music industry about fifteen years ago that maps directly onto this. Recording an album used to require a studio, a producer, and a budget that kept most artists out. Then home recording software got good enough that the studio became optional. Then production tools got cheap enough that the barrier essentially disappeared. Today, a song recorded in a bedroom can be sonically indistinguishable from one recorded at a major label facility. But the artists who broke through didn't break through because their recordings were good. They broke through because they understood distribution. The playlist placements, the collaborations with artists who already had audiences, the moments that looked accidental but weren't. The music was the entry ticket. Distribution was the game. Product is following the same curve, just faster. When building was expensive, being able to ship was a competitive advantage. But now that building is accessible to almost everyone, shipping is table stakes. The product teams treating quality as their moat are making the same mistake as the bedroom producer who records something brilliant and then waits to be discovered. Discovery is not a passive outcome of quality. It is a separate discipline. But most product teams don't have anyone whose primary job is to practise it. This matters more than it sounds like a restatement of what people already know, because most product organisations are still structured entirely around building. The roadmap is a building document. The sprint is a building unit. The metrics reported in the weekly review are building metrics: velocity, release cadence, features shipped. The team that gets resourced most heavily is the one doing the most building. But the question the market is asking now isn't about the build. It's about reach. Who already has the audience you need? What existing behaviour can your product attach to rather than replace? Where does your user already spend their attention, and is there a version of your product that meets them there instead of asking them to come to you? These are distribution questions. And in most of the organisations I work with, there is nobody whose primary job is to ask them. The product team owns the roadmap. The marketing team owns the channel. But the gap between them, the question of how the product itself creates the conditions for its own distribution, sits in no one's brief. The companies compounding right now aren't the ones with the best engineering teams. They're the ones who understood that product quality is the price of admission and distribution is the actual competition. Some got there by building products with natural viral loops, where using it alone is worse than using it with others. Some got there by owning a specific audience deeply before broadening. Some got there by partnerships that gave them reach they couldn't have built in the time available. But all of them understood something that the previous decade of product thinking made easy to forget: a product nobody can find is not a product. It is a prototype with a domain name. Building is no longer the hard part. Mistaking it for the hard part is the most expensive strategic error a product team can make right now.

Product StrategyFebruary 1, 2025

AI as context holder: The productivity gain nobody predicted

AI did not make the work easier. It made remembering easier. And that turned out to matter more than anyone expected. For all the discourse about AI generating content, writing code, and producing strategy documents, the most useful thing AI has done for my productivity this year has nothing to do with generation. It holds context. It remembers where I left off three weeks ago, what decisions were made, what open questions remained. That is not glamorous. But it has changed how I work more than any feature demonstrated on a conference stage. The conversation about AI and productivity has been fixated on output. How many words per minute. How many lines of code. How many slides. But the bottleneck for most product people was never output. It was the cost of returning to a problem after being away from it. Once upon a time For most of my career, I managed between three and five parallel workstreams at any given time. This is normal for product people. You have the main initiative, the exploratory track, the partnership discussion, the team issue that needs quiet attention, and the thing your VP asked you to look into that is not quite a project but is definitely not nothing. Each lives in a different context: different stakeholders, different documents, different stage of thinking. The cost of switching between them was never the switching itself. It was the re-entry. I call this the re-entry tax. Every time you return to a workstream after time away, you spend the first twenty to forty minutes reconstructing the mental state you had when you last worked on it. Where were we? What had we decided? What was I about to investigate before I got interrupted? The answers are scattered across Slack threads, meeting notes, documents with eighteen comment threads, and your own memory, which is the least reliable of the four. At Grab, I was running two product tracks while managing a cross-functional dependency that required weekly negotiation with three teams. Every Monday morning, I sat down intending to pick up where I left off on Friday. But Friday's context was gone. Not the facts. Those were in documents somewhere. The thinking. The particular way I had been framing a problem, the angle I was about to explore, the intuition I was developing about a user behaviour pattern. That kind of context does not survive a weekend. It barely survives a lunch break. I once spent an entire Monday morning re-reading my own notes from the previous Thursday, trying to reconstruct a line of reasoning that had felt clear forty-eight hours earlier. By noon, I had recovered roughly seventy per cent of it. The other thirty per cent was gone. Not lost in a dramatic way. Just quietly evaporated, like a conversation you mostly remember but cannot quite quote. That thirty per cent, across dozens of workstreams over months, adds up to a staggering amount of lost cognitive work. Every day, until one day The standard solutions to context-switching cost were all organisational. Block your calendar. Batch similar work. Reduce your parallel tracks. Good advice, genuinely. But impractical for most product roles, where the parallel workstreams are not optional. You do not run five tracks because you enjoy it. You run them because the work requires it. Earlier this year, I started doing something different. Instead of closing a work session and trusting my future self to remember the state of play, I began recording the session's context in an AI tool. Not a summary. A state capture. Here is where we are. Here are the open questions. Here is what I was thinking about exploring next. Here is the decision I was leaning toward and why. The first time I returned to a project after a week away and interrogated the context capture, the difference was immediate. Instead of forty minutes of re-entry, I was back in the problem within five. Not because the AI had solved anything. But because it had held the context that my brain had discarded. The thinking was preserved in a form I could re-enter, rather than reconstructed from fragments. I had accidentally built what I now think of as a persistent context architecture: a system where the cognitive state of a project is captured and made retrievable between sessions. Simple in design. Disproportionate in impact. Because of that The implications became clear within weeks. With the re-entry tax reduced, I could switch between workstreams without the cognitive penalty that had previously made parallel work so draining. My work on secondary tracks improved because I was no longer starting each session partially amnesiac. But more importantly, I started noticing things across workstreams that I had missed before. Patterns. Connections. A user insight from one project that was relevant to another. Those connections had always existed. But the re-entry tax had consumed the bandwidth that would have spotted them. At Schneider Electric, years earlier, I had watched a senior product leader maintain what she called her "project brain" in a paper notebook. Every Friday, she spent thirty minutes writing a status update to herself. Not to her manager. To her Monday-morning self. Here is my current hypothesis. Here is what I plan to test. Here is the thing I keep avoiding thinking about. It was brilliant. But it was manual, time-consuming, and dependent on her discipline to maintain it every week. AI makes her method scalable. The same practice, without the friction. Until finally The pattern I am seeing across PM communities is not people using AI to generate product briefs or write user stories. It is people using AI to hold project context between sessions. The use case is unglamorous. It will never make a keynote demo. But it addresses a specific, measurable, daily problem that every product person who manages parallel work recognises the moment you name it. The re-entry tax is real. We have all paid it. But most of us pay it multiple times a day without recognising it as a cost, because it disguises itself as "getting back up to speed," as though re-establishing your mental state were a natural part of the work rather than pure overhead. What has changed is that the tax has become optional. Not eliminated. But dramatically reduced for anyone willing to spend three minutes at the end of a session capturing where their thinking stands. The value is not in AI doing the thinking. It is in AI holding the context so you can think faster. Ever since then I have been mentoring junior PMs for years, and the advice I used to give about context-switching was defensive: reduce your parallel tracks, protect your focus time, batch similar work. Good tactics. But they treat the symptom without addressing the cause. Human memory is not designed to hold the cognitive state of five parallel projects across a week. We forget. Not the facts. The framing. The angle. The almost-formed thought. AI as context holder is not a breakthrough in artificial intelligence. It is a workaround for a limitation in biological intelligence. And workarounds, in my experience, tend to be the innovations that change daily practice. Not the spectacular ones. The practical ones. The most important thing AI has done for my work this year is something I would have found absurd to predict twelve months ago. It did not make me faster at writing or better at analysis. It remembers where I was. And that is what made the difference between five workstreams that drained me and five workstreams that fed each other. Some tools change what you can do. The best ones change what you can hold in your head while you do it.

Productivity & Working MethodsJanuary 21, 2025

AI compressing team size: The minimum viable team debate

Every conversation about AI and team size starts at the wrong end. It starts with headcount. How many people do we still need? How lean can we get? What is the minimum viable team? But the right question is not how few people you need. The right question is what kind of thinking your product requires and whether the people remaining can do it. Those are different questions. One is about efficiency. The other is about capability. And most organisations are answering the first one while hoping the second one takes care of itself. Why this matters more than headcount Data from Ravio shows AI-first startups operating with 34% leaner teams than comparable companies without AI at their core. That number is real. But the number alone tells you nothing useful. It tells you fewer people are required to produce a given quantity of output. It does not tell you whether the output is any good. I have been living this experiment from Wayanad. After leaving Bangalore, I built my working life around AI tools that, five years ago, would have required three people. I do my own research, design, writing, prototyping, and strategy work without a team around me. The tools handle the drafting, the data gathering, the formatting, the first passes at visual work I used to hand off to someone else. The freedom is real. I will not pretend otherwise. There is something genuinely liberating about moving at the speed of your own thinking, without waiting for handoffs, without scheduling alignment meetings, without the friction of coordinating five people's calendars to make a decision that one person could make in ten minutes. But there is a cost that took me months to recognise. Some decisions are worse when only one person makes them. Not because I lack experience. Because certain kinds of thinking require friction. They require someone asking the question you did not think to ask. They require the discomfort of another perspective that complicates your neat framework. The loneliest moment in building alone is not the silence. It is the decision you cannot pressure-test with anyone. I call this the compression effect. AI compresses the execution layer of team work: the production of artifacts, the generation of options, the speed of iteration. But it does not compress the judgment layer. The part where someone says "this is technically correct but strategically wrong." The part that requires a second brain in the room, not a second pair of hands. How compression actually works When a team shrinks, the roles that disappear first are the ones whose primary output was execution. The person who formatted the decks. The person who ran the first pass of user interview transcripts. The person who built the prototype based on someone else's specifications. AI handles those tasks well, often faster and more consistently than a human doing them for the eighth time on a Thursday afternoon. But here is what most teams discover three to six months after compression: some of those roles were not purely execution. The person who formatted the decks also noticed when the narrative did not hold together. The person who ran the interview transcripts also caught patterns that the lead researcher missed. The person who built the prototype also pushed back on interaction patterns that felt wrong. They were doing judgment work quietly, embedded inside their execution work. And nobody noticed until they were gone. I saw this play out with a startup founder I mentor. She cut her team from eight to four using AI tools for code generation, design iteration, and content production. For three months, it looked like a clean win. The velocity was the same. The burn rate was halved. The board was pleased. But around month four, subtle quality problems started surfacing. The product's onboarding flow had become generic. The copy across different features started sounding identical (because the same AI tool was generating all of it, and nobody was editing for distinctiveness). Design decisions were being made faster but reviewed less. Small inconsistencies accumulated. Not the kind that users report. The kind that users feel without being able to articulate. The missing people had not just been doing work. They had been doing thinking. The kind of thinking that shows up as taste, as pattern recognition, as the instinct to say "this does not feel right" before anyone can explain why. I call this the judgment gap. It is what opens up when compression removes the people whose real contribution was invisible because it was embedded in other tasks. You cannot see it in the sprint metrics. You see it in the product six months later, when everything works and nothing feels distinctive. What well-designed compression looks like The kitchen analogy is useful here. A restaurant reduces its kitchen staff from five chefs to two. For a while, the plates come out faster. Less coordination, fewer handoffs. But after a few weeks, a regular customer notices something. The dishes are competent. Some of them taste the same. The sauces have lost their variation. The plating is efficient and predictable. The two remaining chefs are producing more food, and the kitchen has lost the perspectives that made the menu interesting. That is what poorly designed team compression looks like in product work. High output. Low differentiation. But compression does not have to work this way. The teams I have seen handle it well do something specific. They compress execution aggressively, letting AI handle the production layer, the first drafts, the data gathering. But they protect judgment roles with equal aggression. They keep the person who decides what is worth building. They keep the person who talks to users and comes back with the insight that changes the roadmap, not the data that confirms it. Compression reveals which roles were about execution and which were about judgment. You can automate the first. You cannot afford to lose the second. But most compression decisions are not made with this distinction in mind. They are made with a spreadsheet. Who costs the most relative to their visible output? Who can be replaced by a tool? The problem with those questions is that visible output and actual contribution are not the same thing. The person with the lowest visible output might be the one whose judgment prevented three bad decisions last quarter. You would never know, because prevented decisions do not appear on anyone's dashboard. The new shape of teams The two-pizza team principle is being renegotiated. Not because it was wrong, but because the ingredients have changed. A team of four with AI tools can now produce the output of a team of eight. Production was never the constraint that determined whether products succeeded or failed. Judgment was. Taste was. The ability to ask whether the thing being built should be built at all. The teams that will build the best products in this environment will not be the smallest ones. They will be the ones that understood what compression could remove and what it could not. I think about this often, working from my desk in Wayanad. The AI tools around me make me faster, more prolific, more capable across domains that used to require specialists. But the best work I have ever done was never the work I did alone. It was the work that happened when someone else in the room made me reconsider something I was sure about. Compression is real. Its benefits are real. But so is the thing it quietly removes: the presence of another mind, thinking alongside yours, catching what you missed. That might be the hardest role to put on a headcount plan. It is also the one that matters most.

Product Teams & Org DynamicsJanuary 16, 2025

The work that doesn't show in the Portfolio

My third year working in product design, I believed something that I now recognise as both understandable and quietly destructive: that good work would win. Not that politics didn't exist. I could see it. But I believed it was a separate track from the design work itself. You did the research. You ran the workshops. You built the prototypes, tested them, iterated, arrived at a solution that genuinely served the user better than what existed before. And then the quality of that solution would carry it through the organisation, past the competing priorities and the executive who had a different opinion and the PM who was attached to a feature that the research had just undermined. The solution would win because it was better. I was wrong about this more often than I was right. The State of UX report that came out this year named something that most senior designers have known for a long time but rarely say plainly: designers are spending a significant portion of their working time on stakeholder alignment, internal negotiation, and the management of organisational dynamics. Not on design. On the conditions required for design to happen at all. The framing in the report treated this as a problem to be solved. Which it partly is. But it is also simply the reality of how consequential design gets done inside organisations of any complexity. The question is not how to eliminate politics from the design process. But the question of whether you treat political competence as a design skill or as a compromise of your professional identity matters enormously. The answer shapes your career in ways that craft alone cannot. I spent too many years choosing the second option. It cost me influence I could have used to do better work. The moment I remember most clearly came at a large enterprise, about four years into my career. I had been leading a redesign of a core workflow that was genuinely broken. The user research was unambiguous. The current flow required seven steps for a task that could be accomplished in three. Users were abandoning it at step four and finding workarounds that created downstream problems for the entire system. The solution was not complicated. We had tested it. It worked. Three steps, clear labels, half the time. But in the review meeting, a senior leader who had not been involved in the research asked why we were changing something that had been in the product for six years. It was not a hostile question. He just did not have the context. And I did not have the relationship with him that would have allowed me to answer it in a way that landed. The redesign got delayed for two quarters while we built the context I should have built before that meeting. Two quarters. For a fix that was ready in three weeks. But the delay was not his fault. It was a failure of preparation on my part, framed as resistance from the organisation. What I learned slowly, and mostly through failure, is that organisational influence is a design problem in the same way that user experience is a design problem. It has stakeholders with different mental models and competing needs. It requires research into what people believe, not just what they say. It demands iteration, because the first framing rarely lands perfectly. And it has failure modes: move too fast and you lose people, move too slowly and the window closes. The designers who navigate this well are not better politicians in the pejorative sense. They are better system thinkers. They have mapped the organisation the way they would map a user journey. They know where the decision points are, who owns each one, what each stakeholder's version of success looks like, and which conversations need to happen before the review meeting, not inside it. This is not a natural talent. It is a learnable skill. But most design education does not teach it, and most design career conversations do not name it as something to develop deliberately. Which means most designers learn it the same way I did: by watching good work get delayed, diluted, or killed, and eventually asking why. The portfolio problem is real. Everything that matters about political competence is invisible in a case study. You cannot show the coffee conversation that changed a stakeholder's framing two weeks before the presentation. You cannot show the six emails you sent to build a coalition before the roadmap review. You cannot show the moment you decided not to present a solution in a meeting because the room was not ready for it yet. But those decisions are often what determined whether the work got to ship at all. The work that shows in the portfolio is the work that survived the organisation. But what the portfolio cannot show is the designer's role in making that survival possible. And in most hiring conversations, that role goes entirely undiscussed. I still believe good design should win on its merits. But I no longer believe it wins automatically. And the gap between those two sentences is where most designers lose years they cannot get back. The merit has to be legible. The room has to be ready. And making the room ready is part of the job, whether it appears in the job description or not.

Product Design & Craft TopicsJanuary 13, 2025

The DeepSeek moment collapsed AI cost assumptions and redistributed competitive advantage overnight

In the early days of commercial aviation, aluminium was the material that defined what was possible. Every airframe, every structural calculation, every supplier relationship was built on the assumption that aluminium would always be the primary material and that its costs, processing requirements, and supply chains would set the boundaries of what aircraft could be built and at what price. At Boeing, I watched what happened when composite materials went from exotic and expensive to manufacturable and cost-competitive. It did not just change the material. It restructured the entire supplier network. Companies that had built decades of competitive position on aluminium expertise found that their advantage was not wrong, exactly. But it was suddenly less relevant than it had been the month before. That is what a cost floor collapse looks like. But in aerospace, the shift took years. In AI, it is happening in weeks. The infrastructure assumption Until last month, the AI market operated on a shared belief that was so widely held it had stopped being examined. Building a frontier-level model required billions of dollars in compute infrastructure, massive datasets, and engineering teams that only a handful of organisations could afford to assemble. The cost of being competitive at the frontier was the moat. If you could not spend at that level, you were not a serious player. But nobody asked what would happen if the cost dropped. NVIDIA's valuation reflected this assumption. The entire AI infrastructure trade reflected it. The venture capital flowing into AI startups reflected it. The competitive strategies of every company building on top of these models reflected it. The infrastructure assumption was the load-bearing wall of the AI market's competitive structure. DeepSeek just removed the wall. Their January release demonstrated frontier-level capabilities at a fraction of the cost that everyone assumed was the minimum. Not incrementally cheaper. Dramatically cheaper. The kind of cost reduction that does not adjust existing competitive positions. It scrambles them. Every moat built on the assumption that this technology will always be expensive has a trapdoor. DeepSeek just opened it. What actually just happened The market reaction was immediate and severe. NVIDIA repriced. The broader AI infrastructure trade repriced. But the repricing in public markets is the least interesting consequence. The more significant repricing is happening inside every company that built its strategy on the infrastructure assumption. I advise a startup founder who spent eighteen months building an AI product whose competitive moat was, fundamentally, a fine-tuned model. He had invested heavily in proprietary training data, custom fine-tuning pipelines, and the engineering expertise to run them. His pitch to customers was straightforward: our model is better at this specific task than anything you can access through a general-purpose API. That was true. But it was also, as of three weeks ago, a rapidly depreciating asset. He called me on a Tuesday afternoon. Not panicking, but thinking out loud in that particular way people think when they realise a foundational assumption has shifted. His moat was not the model. But he had spent eighteen months acting as if it were. His actual moat had been there all along. His moat was the domain data he had collected from eighteen months of customer interactions, the workflow integrations he had built, and the switching costs his customers would face if they tried to replicate what he had built with a cheaper model. The model was the part he had treated as irreplaceable. It was the most replaceable part of the stack. That realisation happened in a single afternoon. The cost floor collapse The cost floor collapse is not a new pattern. It has happened in solar panels, flat-screen televisions, genome sequencing, and, as I saw at Boeing, composite materials for aerospace. The pattern is consistent. An industry prices its competitive structure against a cost floor that everyone assumes is stable. A technological or methodological breakthrough drops the floor dramatically. The companies that built their position on the assumption that the floor was permanent find themselves exposed. The companies that built their position on something above the floor (domain expertise, distribution, customer relationships, workflow integration) discover that their advantages have actually increased in relative value. But what makes the DeepSeek moment different from a slow cost decline is the speed. Solar panel costs dropped over a decade. Composite manufacturing costs declined over years. The AI cost floor collapsed in what felt like a single news cycle. Companies that were making strategic bets last month based on cost assumptions that no longer hold are now in the position of having to re-examine those bets in real time. This is where it gets uncomfortable. The infrastructure assumption was never a moat. It was a temporary height advantage on ground that was always going to flatten. What this means right now The immediate question for every company building with AI is simple: what part of your competitive advantage depends on the cost of the underlying technology staying high? If the answer is "a significant part," you have a problem that did not exist four weeks ago. Not a theoretical future problem. A present one. But here is the part that matters more. The companies that are in the strongest position right now are not the ones that spent the most on AI infrastructure. They are the ones that built the most value in the layers above the infrastructure. The data they collected. The workflows they integrated into. The customer relationships they built while the infrastructure was expensive and access was limited. The domain expertise they encoded into products, not into models. The founder I advise is rewriting his investor narrative this week. But he is not rewriting his product. The product is fine. The customers are still using it. The workflows are still embedded. What changed is the story he tells about why his product is defensible. The old story was about the model. The new story is about everything around the model. It is a better story, honestly, because it is a truer one. The redistribution The most interesting consequence of the cost floor collapse is not who loses. It is how competitive advantage redistributes. When a technology becomes cheap, the value migrates to the layers closest to the customer. That is the consistent pattern across every industry where this has happened. Cheap steel made distribution and brand more valuable, not less. Cheap cloud computing made product design and user experience more valuable, not less. Cheap AI infrastructure will do the same. But only for the companies that built those layers before the floor dropped. But the redistribution is not automatic. It rewards the companies that already invested in those layers. It punishes the companies that assumed the infrastructure layer was where the value would permanently reside. The uncomfortable truth is that many of the most heavily funded AI companies of the past two years were built on the infrastructure assumption. They are the ones facing the hardest questions today. Nobody knows yet how far this repricing goes. We are in the first weeks, and the full implications will take months to become clear. But one thing is already visible. The assumption that frontier AI would always require billions of dollars in capital expenditure, the assumption that made this market legible and this competitive structure stable, is no longer operative. What remains when the cost advantage disappears is what was always underneath it: the quality of the problem you solve, the depth of your integration into the customer's work, and the trust you have built while everyone else was focused on the model. Those things were always the real moat. It just took a cost floor collapse to make that obvious.

Markets & Industry DynamicsJanuary 11, 2025

The product leader's public voice became a hiring signal, not just personal branding

Hiring managers google you before they read your resume. This is not a trend. It is a fact, and it has been one for long enough that pretending otherwise is a career risk. What they find when they search your name, or more precisely what they do not find, shapes the decision before the first interview. The question is whether you had any say in what they saw. The private excellence trap For most of my career, I believed the work would speak for itself. I built products at Adobe, shipped features at scale, made decisions that drove measurable commercial outcomes. I had the resume, the references, the stories. But none of that was visible to anyone who had not already worked with me. This is the private excellence trap: the belief that doing good work quietly is sufficient proof of your capability. It worked for a long time. In a world where hiring committees relied on referrals and structured interviews, internal excellence was enough. You could build a career entirely behind closed doors and trust that the people who mattered would find you. But that world is shrinking. The talent market for senior product roles has changed. Everyone who reaches the VP or CPO level has strong credentials. Everyone has shipped products, managed teams, and can tell a compelling story about a pivot they led. When the baseline is uniformly high, credentials stop being a differentiator. They become a minimum requirement. So hiring managers look for something else. They look for the public signal. What the public signal actually is The public signal is not about follower counts or viral posts. It is about evidence of thinking. When a hiring committee reads your Substack, they are not checking whether you are a good writer. They are checking whether you think clearly, whether you can structure an argument, whether you have genuine conviction about how products should be built. Writing is just the medium. Clarity is the message. I know a senior PM who learned this the hard way. He had spent twelve years building a strong track record at two well-known enterprise companies. His resume was impeccable. He made it to the final round for a VP of Product role at a Series C company. He did not get the job. The candidate who did had a weaker resume by conventional measures: fewer years, smaller teams, less revenue responsibility. But she had a well-read Substack where she wrote about product strategy with precision and conviction. She had given talks at three conferences in the previous year. The hiring committee told him, through a mutual contact, that her public writing demonstrated "clarity of thinking" that interviews alone could not establish. But here is the part that stings. They were not wrong. Interviews are a narrow window. You get sixty minutes to demonstrate how you think. The candidate who has published fifty essays on product strategy walks in with fifty additional data points already on the table. The candidate who has published nothing walks in with a resume and a handshake. But one has evidence, and the other has only claims. The Wayanad experiment When I left my corporate role and moved to Wayanad, I started writing publicly. Not because I had a content strategy or a personal branding plan. I wrote because I had opinions about product work that I had been sharing in meeting rooms for years, and I wanted to see if they held up before a wider audience. It felt like opening a shop window after years of working in a locked back room. The shift was immediate and startling. Within months, the quality and quantity of inbound opportunities changed in ways that fifteen years of corporate career building never achieved. People reached out who had read something I wrote and wanted to talk about a role, a consulting engagement, a speaking invitation. My writing was doing work that my resume could not, because it showed how I thought in real time, not just what I had accomplished in the past. But I want to be honest about something. The writing itself was not magic. It was not particularly polished in the early days. What mattered was that it existed. A resume says "I did these things." A body of public writing says "this is how I see the world." The second one is harder to fake. Why most product leaders still resist There are reasonable objections to writing publicly. Time is the obvious one. Senior product leaders are busy people, and carving out hours to write feels like a luxury when you are managing a team, shipping a product, and putting out fires simultaneously. But the time objection is often a cover for the real resistance: fear of being wrong publicly. Internal work is safe. You share an opinion in a meeting, and it lives and dies in that room. But put your thinking on the internet and suddenly anyone can disagree with you. Publicly. With their own audience watching. This fear is understandable. It is also exactly the thing that makes public writing valuable as a hiring signal. The willingness to stake a position where others can challenge it is, itself, evidence of confidence in your thinking. Hiring committees are not just reading what you wrote. They are reading the fact that you wrote it at all. Private excellence is no longer sufficient evidence of leadership capability. I have mentored product leaders who spent weeks perfecting a single essay, paralysed by the possibility that someone might poke a hole in their argument. But the ones who have built the strongest public signals publish regularly, accept that not everything will land, and treat disagreement as a feature rather than a threat. The mess is part of the proof. The resume runs out of space Your public voice is not personal branding. It is the only portfolio that matters when the resume runs out of space. And the resume always runs out of space, because a resume is a list of what you did, not a window into how you think. But I am not arguing that everyone needs to become a content creator. The product leader who writes one thoughtful essay a month carries more signal than the one who posts three times a day with nothing to say. Volume without substance is noise. Substance without volume is still substance. The distinction matters. What I am arguing is that the era of purely private careers at the senior level is closing. Not because the world has become shallow or attention-driven. But because when you are hiring for judgment, you want to see judgment exercised. A resume tells you someone was in the room. Public writing tells you what they did once they got there. I still talk to product leaders who believe that building great products is enough. That their track record will carry them. That the work speaks for itself. But the work does not speak. It sits in a locked filing cabinet, visible only to the people who were already in the room. The public signal is the shop window. And increasingly, the people doing the hiring are walking past the shops with nothing in the window, no matter how good the inventory inside. The best time to start building a public voice was five years ago. But the second best time is not today, exactly. It is the next time you have an opinion you would normally share only in a meeting room and you choose instead to write it down where anyone can find it. That single choice, repeated enough times, changes a career.

Product Leadership & CareerJanuary 1, 2025

Niching down is not limiting: it is the only path to early traction

The founders who built the biggest companies started by building for the smallest audiences. Freshdesk did not try to compete with Zendesk across every segment on day one. Basecamp did not launch as a project management tool for the Fortune 500. They picked audiences so specific that most investors would have called the market too small to matter. That is the niche paradox. The instinct to build for everyone feels like ambition. It feels like you are maximising your opportunity. But what it actually maximises is the difficulty of everything you do after shipping. Your marketing has to speak to too many people. Your product has to satisfy too many use cases. Your positioning becomes so vague that nobody hears it as being for them specifically. What the broadening trap looks like up close I call it the broadening trap, and I have watched it destroy early traction more often than any technical failure or funding shortfall. A founder I mentored earlier this year built a solid invoicing tool. The first version was designed for freelance accountants in India. Specific. Narrow. The kind of niche that makes pitch decks look unambitious. But the product knew exactly who it was for. The onboarding spoke directly to the workflow of a freelance accountant. The templates matched Indian tax requirements. The pricing fit a freelancer's budget. Word spread within that community because the product felt like someone had built it just for them. Because someone had. Then the founder got nervous. "We need to appeal to more people," he told me. He was looking at the total addressable market for invoicing software globally and feeling like his niche was a ceiling. So he broadened. Added features for small agencies. Changed the positioning to "invoicing for modern businesses." Made the onboarding generic enough to accommodate anyone. Conversion dropped within six weeks. Not crashed. Leaked, slowly, like air escaping a tyre. The product that had felt tailor-made now felt like every other invoicing tool. But the real damage was subtler. The freelance accountants who had been its most passionate users stopped referring it, because the product no longer felt like theirs. Meanwhile, a competing product that had launched two months later (serving only freelance accountants in India, the niche the founder had abandoned) grew faster with a fraction of the marketing spend. They did not have a better product. But they had a clearer answer to the question every potential user asks before signing up: is this for me? The broader you build, the harder you have to market. The narrower you build, the product markets itself. Freshdesk and the engine of specificity I saw the same pattern from the inside at Freshworks, back when the company was still called Freshdesk. The early product was not trying to be a customer support platform for everyone. It was built for small businesses that needed a helpdesk and could not afford Zendesk. That was the entire thesis. The specificity of that niche did three things that a broader positioning would have made impossible. First, product decisions became obvious. Should we build enterprise-grade SLA management or a simple shared inbox that a five-person team can set up in twenty minutes? The niche answers the question. No debate required. Second, the messaging wrote itself. "Customer support software for small businesses" is something a founder can say in one sentence and a potential customer can immediately evaluate. But compare that to "the modern customer experience platform," which means nothing and requires a sales conversation to decode. One invites a click. The other invites a yawn. Third, the community formed naturally. Small business owners talked to other small business owners. The referral loop was tight because users shared context, shared problems, shared language. But here is the thing about the niche paradox. The niche was never the ceiling. It was the launchpad. Freshworks expanded into mid-market and enterprise later, from a position of strength, with revenue, with customers, with a product refined by thousands of small business users. The expansion happened because the niche succeeded. Why the discomfort is a signal Every founder I have mentored who successfully niched down described the same feeling at the start: fear. Fear that the market was too small. Fear that they were leaving money on the table. Fear that a competitor with broader positioning would eat their lunch. That fear is real. But it is almost always wrong. The niche paradox works because specificity creates a kind of gravity. When a product is built precisely for a specific group, that group pulls the product forward. They refer it. They write about it. They become its marketing department without being asked, because they finally found something that was made for them. That is a force you cannot manufacture with advertising spend. It comes from fit. But the broadening trap works in reverse. When a product tries to serve everyone, nobody feels that pull. The marketing has to do all the work. Every user acquisition is paid for, with money or with effort. The unit economics of broad products in the early stage are brutal. Just a team pushing a boulder uphill, wondering why it refuses to roll. The narrower the niche, the faster the learning There is a second reason niching down accelerates traction, one that founders rarely discuss. Narrow niches produce faster feedback loops. When your users share a context, their feedback converges. You hear the same pain points from multiple users within weeks. You spot patterns quickly because the users are similar enough that their problems overlap. But in a broad market, feedback is contradictory. One user wants simplicity, another wants power features, a third wants integrations you have never heard of. You cannot learn fast when every signal points in a different direction. A niche is not a limit. It is a lens. It focuses your product, your marketing, your learning, and your energy on a space small enough to understand deeply. The founders who resist niching down spend months in confusion, pulled in every direction by users who want different things. But the founders who commit to a niche spend those same months building conviction, because every conversation reinforces and refines the same core understanding. The broadening trap will always be there, waiting for the moment your nerve falters. The niche paradox will always feel counterintuitive. But the founders who trust specificity over ambition in the early days are the ones who end up building the products that everyone eventually uses. They just did not start by trying to.

Building & FoundingDecember 27, 2024

Discovery and delivery running in parallel: the dual-track debate

The most expensive line of code is the one that works perfectly and solves a problem nobody has. It compiles. It passes tests. It ships on time. And it sits there, finished and untouched, while the team moves on to the next thing on the roadmap. I have written that line of code. I have been on the team that celebrated shipping it. I have watched the Slack channel fill with congratulations for a feature that, three months later, nobody could find in the analytics. Not because it was buried. Because nobody needed it. But the uncomfortable part is not that we built the wrong thing. The uncomfortable part is how confident we were that it was the right thing. The sequence trap Most product teams treat discovery and delivery as phases. First you figure out what to build. Then you build it. The logic feels airtight. How can you build something you have not yet defined? But the problem is not the logic. The problem is the gap between when discovery ends and when delivery finishes. In that gap, assumptions age, contexts shift, and the problem you validated in week one is not quite the same problem by week twelve. I call this the sequence trap. It is the structural habit of finishing your thinking before starting your building, and then never going back to check whether the thinking still holds. At Freshworks, we shipped an entire reporting module that took a full quarter to build. The spec was thorough. The engineering was clean. The design was, frankly, quite good. And post-launch analytics showed 8% adoption. Eight percent. Three months of a cross-functional team's time, and nine out of ten users never opened the thing. But here is what made it worse. We had validated the idea. We had talked to people about it. We had run it past internal stakeholders, product leaders, sales engineers, customer success managers. They all had opinions about reporting. Strong opinions. They told us exactly what the reporting module should look like, and we built precisely that. The problem was who we had validated with. We had validated with people who had opinions about the problem. We had not validated with people who had the problem. Internal stakeholders experience a product through the lens of support tickets and feature requests. Users experience it through the lens of their actual work. Those are different lenses, and they produce different answers. The reporting module solved a problem that existed in internal conversations. It did not solve a problem that existed in user workflows. And we did not discover that gap until the feature was live, the quarter was spent, and the data came back flat. Discovery debt compounds silently. You only see it when the thing you built sits there, finished and untouched. The surgeon analogy Think about a surgeon who operates first and diagnoses after. The procedure is technically flawless. The incisions are clean, the sutures precise. But the diagnosis comes back after the surgery, and it turns out the operation addressed the wrong organ. Nobody runs a hospital that way. You diagnose while you prepare. The scans, the bloodwork, the imaging, all of it runs in parallel with surgical preparation. By the time the patient is on the table, you know what you are operating on and why. But product teams do the equivalent of operating blind every time they commit a quarter of engineering time to a feature validated only by internal consensus. Dual-track agile proposes the alternative: run discovery and delivery at the same time. One track is always learning, the other is always building. What the learning track validates flows into what the building track ships. It sounds obvious. But in practice, most teams resist it. The resistance I mentored a startup founder last year whose team adopted dual-track after reading about it. They tried it for two weeks and nearly abandoned it. The engineers felt like discovery was slowing them down. The designers felt pulled between two tracks with competing demands. The founder told me it felt like they were shipping less, not more. But I asked them to stick with it. Not because I was certain it would work. Because the alternative, the thing they were already doing, had a track record. And that track record included three features in the previous six months that had shipped to minimal adoption. Three months in, something shifted. They had killed three ideas during discovery. Not after building them. Before writing any code. One was a pricing page redesign that user testing revealed would actually confuse their highest-value segment. Another was an onboarding flow that assumed new users cared about a feature that only power users valued. The third was a dashboard that the founder himself had wanted, which nobody else found useful. (That one stung. It always does when your own idea is the one that gets cut.) But here is the result. Every feature they shipped in those three months had measurably higher adoption than anything they had shipped in the previous six. Not because the engineering got better. Not because the designs improved. Because they stopped building things that did not need to exist. The discovery track had not slowed them down. It had prevented them from wasting the delivery track's time. The discovery debt Most teams measure shipping velocity. How many features per quarter. How many story points per sprint. How fast the backlog moves. But nobody measures discovery debt, the accumulating cost of building things that were never validated against real user problems. Discovery debt is invisible in the metrics teams track. It does not show up as a failed sprint. It shows up as a feature with 8% adoption sitting quietly in the product, maintained by engineers, documented by support, and used by almost nobody. It shows up as the slow erosion of team morale when people start to suspect that what they are building does not matter. But measuring discovery debt requires admitting that shipping is not the same as progress. That a team can ship on time, on scope, and on budget, and still fail. That velocity without direction is just speed in the wrong lane. The teams that run discovery and delivery in parallel are not slower. They look slower during the first month because some of their capacity is pointed at learning instead of building. But by month three, the difference is visible. They ship less. What they ship matters more. The adoption curves are steeper. And the engineers stop asking, quietly, in retros, whether anyone is actually using the thing they just spent six weeks building. There is a question that belongs at the start of every sprint planning session, before stories are estimated, before anyone opens Jira. Do we know this is the right thing to build? Most teams skip that question. Not because they do not care. Because asking it feels like it slows things down. Because the roadmap says this is next. Because a stakeholder is waiting. But the quarter will run out regardless. The choice is between spending it on something validated or something assumed. The sequence trap makes that choice invisible. Dual-track makes it explicit. The teams I admire most are not the ones that ship fastest. They are the ones that learned, sometimes painfully, that the fastest path to a product nobody uses is a team that never stopped to ask whether anyone needed it.

Product Teams & Org DynamicsDecember 20, 2024

The Indian and southeast Asian saas market matured from growth story to structural reckoning

I was at Freshworks when the narrative was at its peak. The company was growing fast, the product was genuinely good, and the mood inside the building was something closer to inevitability than optimism. Indian SaaS had arrived. The story wrote itself: world-class products, built with Indian engineering talent, sold at global enterprise prices. The margin advantage was structural and permanent. I believed it too. That is the thing about narratives. The best ones feel like facts until they stop being true. The arbitrage assumption The Indian SaaS story was built on an assumption: that the arbitrage between where you build and where you sell would hold forever. It did not. The arbitrage assumption worked like this. Hire engineers in Chennai or Bangalore at a fraction of San Francisco salaries. Build a product that competes directly with American incumbents. Sell it to the same global enterprise customers at roughly the same prices. The cost difference between building and selling was your structural margin advantage. It was supposed to be permanent because the talent was as good and the cost was always going to be lower. But permanent advantages have a habit of not being permanent. Indian engineering salaries have risen significantly over the past five years. The best talent in Bangalore now commands compensation that would not look out of place in a mid-tier American city. The arbitrage has not disappeared entirely. But it has narrowed to the point where it no longer functions as a moat. It functions as a modest head start that erodes with every hiring cycle. At Freshworks, I watched this play out in real time. The product was strong. The team was talented. But net revenue retention, the metric that separates a growing SaaS business from a business that is growing its way into trouble, was becoming harder to maintain. Enterprise customers who signed up during the initial land phase were not expanding at the rates the models assumed. Some were contracting. A few were leaving. The internal conversation and the external market conversation started diverging. Inside, the story was still about growth and opportunity. Outside, analysts and investors were asking harder questions about whether the growth would translate into the kind of durable margins that justify a premium valuation. The gap between those two conversations widened slowly, then all at once. Growth is a story. Margins are a fact. Two startups, one reckoning I advise two Indian SaaS startups from Wayanad now. They illustrate the reckoning perfectly. The first builds workflow automation for a specific vertical: mid-sized logistics companies in India and Southeast Asia. Four-person team. Narrow focus. Their customers are not glamorous, and their total addressable market would make a venture capitalist yawn. But their unit economics are clean. Customer acquisition cost is low because they sell through industry-specific channels where they have built genuine credibility. Retention is high because the product solves a specific, recurring problem that their customers cannot easily solve with a general-purpose tool. The second startup has more impressive numbers on the surface. Faster revenue growth, bigger customers, a slick brand presence. But their acquisition costs are unsustainable. They are spending nearly three times what the first startup spends to acquire each customer, and their retention numbers suggest that many of those customers will not stay long enough to justify the acquisition cost. The growth looks excellent in a pitch deck. It looks concerning in a spreadsheet that extends beyond the next fundraising round. The difference is not talent or product quality. Both have strong teams. The difference is that the first company was built on the assumption that it needed to be profitable. The second was built on the assumption that growth would solve everything. The arbitrage assumption, applied not just to cost structures but to strategy itself: grow fast enough and the economics will work themselves out eventually. Eventually is a word that does a lot of heavy lifting in startup pitch decks. It rarely survives contact with a tightening market. The growth narrative trap There is a pattern I have seen in every market correction. The companies that suffer most are not the worst companies. They are the companies whose narratives were furthest from their fundamentals. The growth narrative trap works like this. A company raises capital on the strength of a growth story. The growth story requires maintaining a specific growth rate. Maintaining that growth rate requires spending more on acquisition, expanding into adjacent segments, and pursuing customers whose fit with the product is questionable but whose revenue contribution is necessary. Each of these decisions degrades the underlying economics. But the narrative demands them. I watched this at Freshworks and I have watched it across the broader Indian SaaS market this year. Companies that were celebrated for their growth rates are being re-examined through the lens of net revenue retention, gross margins, and free cash flow. The re-examination is not gentle. But the reckoning is not a death sentence. It is a maturation event. The Indian SaaS market has produced genuinely excellent products and genuinely talented teams. The problem was never the products. The problem was the narrative layer that sat on top of the products, a layer that confused growth with health and valuation with value. The companies that will come through this reckoning are the ones that can answer a question the growth era never required them to ask: if you stopped spending on growth tomorrow, would your existing customers keep paying you? That question, unglamorous and uncomfortable, is the dividing line between a sustainable business and a growth story that happens to have a product attached. What the market is actually telling us The reckoning is not unique to Indian SaaS. It is not a story about geography. It is a story about what happens when any market built on cheap capital and optimistic assumptions meets a period of tighter capital and harder scrutiny. But there is something specific about the Indian SaaS experience that is worth naming. The pride was real. The ambition was earned. Indian founders built products that competed with, and in some cases outperformed, American incumbents. That is genuine and it matters. The mistake was not the ambition. The mistake was confusing a temporary cost advantage with a permanent structural moat, and building business plans on the assumption that the advantage would never erode. The first startup I advise from Wayanad will probably never make a headline. Four people, a niche product, sustainable growth. But it will be running five years from now, serving customers who rely on it, generating enough margin to fund its own development without external capital. The growth narrative trap does not apply to companies that never needed a growth narrative in the first place. The best products are not always the ones with the best stories. Sometimes they are the ones that never needed a story at all, just a customer with a problem and a product that solves it. That is a less exciting sentence than the one about Indian SaaS conquering global enterprise markets. But it might be a truer one.

Markets & Industry DynamicsDecember 15, 2024

The Data storytelling gap

Every product team I work with has more data than it knows what to do with. Dashboards are sharper than they have ever been. A junior PM can pull a cohort retention analysis today that would have required a dedicated data scientist three years ago. But the decisions are not moving. This is the quiet crisis at the centre of every product review that ends with polite nods and zero commitments. The analysis is rigorous. The charts are clean. The conclusions are correct. And yet the room does not shift. The budget does not move. The roadmap does not change. The data was presented. The story was not. I call this the narrative gap: the distance between what the data says and what the audience actually hears. The spreadsheet defence Most product people, when pressed on why a recommendation failed to land, retreat to what I think of as the spreadsheet defence. The data was right. The analysis was thorough. The conclusion was obvious to anyone paying attention. If leadership did not act, the problem must sit with leadership. But the problem is almost never with the data. It is with the delivery. At Freshworks, I watched a product lead present one of the most rigorously constructed analyses I had seen that quarter. She had done everything by the textbook. Usage data broken down by segment. Churn correlation mapped to feature adoption curves. A clear, defensible recommendation to sunset a feature that was haemorrhaging maintenance cost while generating negligible retention value. The slides were precise. The methodology was clean. Every single chart supported the argument. The room thanked her. And then nothing happened. For three months. She came to me afterwards, visibly frustrated. "The numbers are right there," she said. "What else am I supposed to show them?" That word, show, was precisely the problem. She had shown them data. She had not told them a story. She had walked into a room full of busy people who were juggling twelve competing priorities and expected them to do the interpretive work themselves. Data does not speak for itself. It never has. Someone has to speak for it. Data without a narrative is noise with a spreadsheet attached. And, But, Therefore The structure that separates data which moves decisions from data which gets filed is older than product management. It is arguably the oldest narrative structure humans use: And, But, Therefore. And: here is the world as it currently stands. Our product serves 14,000 active accounts. Engagement is stable. Revenue is growing at 8 percent quarter over quarter. Things are, on the surface, fine. But: beneath that stability, a specific pattern is forming. Our highest-value customer segment is showing a 22 percent decline in feature adoption over the past two quarters. They are not churning yet. They are disengaging. Slowly, quietly, and in exactly the segment that funds our expansion revenue. Therefore: if we do not address the engagement decline in this segment within the next two quarters, we will likely see churn acceleration in exactly the accounts that represent 40 percent of our expansion pipeline. Here is what we recommend. That is the same data the Freshworks product lead had. But it is wrapped in a structure that gives the audience a reason to care before they see the numbers, a reason to worry before they see the recommendation, and a reason to act before they leave the room. Most product people skip straight to the problem because the problem is what excites them. But senior stakeholders lack the context to understand why the problem matters unless you first establish what normal looks like. You need the "And" so the complication lands as a disruption, not a complaint. The "And" is not throat-clearing. It is load-bearing. What happened the second time The lesson crystallised for me at Adobe. I was presenting to a leadership group about a product direction that had been stuck in limbo for months. The first time I presented, I did what most product people do. I led with the analysis. Usage patterns, competitive positioning, a clear case for investing in a specific capability. The work was rigorous. Nobody disagreed with any of it. But nobody acted on it either. The numbers were right. The story was missing. Nothing moved. A colleague pulled me aside afterwards. He was not a product person. He was in marketing, of all places. And yet he understood something about that room that I did not. "You gave them a report," he said. "Give them a reason." So I rebuilt the presentation. Same data. Same recommendation. Same room, three weeks later. But this time I started differently. I opened with a specific enterprise customer who was using our product in a way we had not anticipated, and whose usage pattern represented a broader trend we were ignoring. I named the customer. I described what they were doing. I showed what would happen if we ignored the pattern and what would happen if we leaned into it. Then I brought in the data, not as the argument, but as the evidence supporting a story the room already cared about. Same stakeholders. Same data set. Entirely different outcome. The decision that had stalled for months was approved in that meeting. Not because I found better data. Because I found a better frame. Why the gap keeps widening The narrative gap persists because product culture rewards analysis, not storytelling. We train product people to be rigorous. We teach them to think in hypotheses, to validate with evidence, to present findings with statistical precision. But we do not teach them to build a narrative arc around those findings. We do not teach them that the audience's emotional state matters as much as the data's confidence interval. This is not a soft skill. It is possibly the hardest skill in the room. I have watched data-fluent teams lose funding to less rigorous teams who could tell a better story about what they were building and why it mattered. The team with the stronger narrative won the budget. The team with the stronger data did not. There is an uncomfortable truth lodged in that pattern. Being right is not enough. Being right and being compelling are different skills entirely, and the second one determines whether the first one matters. Senior stakeholders do not read data the way product people do. They are making decisions across dozens of competing priorities with limited attention. The product team that expects leadership to do the interpretive work is the product team that keeps losing budget reviews. But the team that walks in with a three-minute story supported by data, a story with a beginning and a complication and a clear recommendation, that team gets the resources. Every time. Product teams right now have more analytical capability than any prior generation of builders. The tools are better. The data literacy is higher. The dashboards are genuinely impressive. But the ability to shape all of that into a story that lands with a person who controls a budget has not kept pace. Not even close. Teams trust the data to speak for itself, and the data sits on a slide, mute, waiting for someone to give it a voice. The best product people I have worked with are not the ones with the deepest analytical chops. They are the ones who can take a complex data set and compress it into a story a senior leader remembers three days later when the actual decision gets made. The analysis gets you into the room. The narrative is what stays after you leave. Learning to tell that story is not a nice-to-have sitting adjacent to the real work. It is the real work. It always was.

Communication & Storytelling November 30, 2024

AI feature resistance: users don't trust what they can't explain

I spent three weeks at Schneider Electric watching users fight a thermostat. Not literally, although it sometimes looked that way. The product was an IoT thermostat with an automated adjustment feature. It learned the building's patterns, factored in outdoor temperature, occupancy data, and energy pricing to set the temperature at the optimal level. On paper, it was the smartest thing in the room. In practice, every facility manager we observed was overriding it. My first instinct was that they did not understand the value. That was me being arrogant, which I am moderately good at. The facility managers understood the value perfectly well. But when the thermostat dropped the temperature by two degrees at 2pm on a Tuesday, they had no idea why. Was it reacting to the outdoor temperature? The occupancy sensor? An energy pricing spike? A bug? They could not tell. And when you cannot tell why a system did what it did, you do not trust it. You override it. Users do not distrust AI because it is wrong. They distrust it because they cannot tell when it is right. Why: the psychology underneath This is not a technology problem. It is a human pattern that existed long before anyone put a language model inside a product. Think about the difference between a pilot and an autopilot. The plane flies the same route regardless. But passengers feel safe when a human is at the controls and nervous when the autopilot is engaged, even though the autopilot's error rate is lower. The reason is not competence. It is legibility. You can see the pilot. You can infer intent from a human face in a way you cannot from a system running silently behind a panel. The same dynamic plays out in every product shipping AI features right now. The AI might be accurate. But accuracy is not the currency of trust. Legibility is. If the user cannot form a mental model of why the system did what it did, the feature fails a test that has nothing to do with accuracy. It fails the trust test. I call this the explainability threshold. Every AI feature has one. Below that threshold, the user cannot predict what the system will do next. And unpredictability, in a tool someone depends on for their work, is not exciting. It is threatening. A system the user cannot predict is a system the user will avoid, work around, or override. Not because it is wrong. Because it might be, and they have no way to check. This is not the same as transparency in the way most product teams think about it. Showing a user that an AI model used fourteen data points and three neural network layers is not transparency. It is a spec sheet. The explainability threshold is simpler: can the user form a one-sentence explanation of why the system did what it did? If they cannot, you have not crossed the threshold. How: the black box penalty The penalty for failing to cross the explainability threshold is not complaints. It is silence. Users do not write angry support tickets about AI features they cannot understand. They quietly stop using them. I have been mentoring a founder who learned this the slow, expensive way. She built an AI recommendation engine for a B2B procurement tool. The engine was genuinely good. It analysed purchasing patterns, supplier reliability data, and pricing trends to suggest optimal vendors for each order. The suggestions were right more often than the manual process. By every technical metric, the feature was a success. But the usage data told a different story. Users were actively avoiding the AI suggestions. They would scroll past the recommendation panel, ignore the suggested vendors, and manually search for suppliers they already knew. Not because the recommendations were wrong. Because the interface offered no indication of why a particular vendor was being recommended. Was it price? Reliability? Delivery speed? Previous order history? The user had no idea. And in procurement, where a bad vendor decision can cost your company real money, "the AI said so" is not a reason anyone is willing to stake their reputation on. She called it a trust problem. But I told her it was a design problem wearing a trust costume. The AI was doing its job. The interface was not doing its job, which was to make the AI's reasoning visible enough for a human to evaluate it. That is the black box penalty. When users cannot see inside the system's reasoning, they apply a discount to everything it produces. Good recommendations get treated as suspect. Accurate predictions get double-checked manually. The AI feature becomes the colleague nobody trusts with real work, the one whose output everyone quietly redoes before passing it along. What: making the invisible visible At Schneider, we eventually did something embarrassingly simple. We added a one-line explanation to every automated adjustment. "Adjusting because outdoor temp dropped 5 degrees." "Reducing by 1 degree because occupancy is below 40%." "Shifting to off-peak energy rate." That was it. One sentence. No machine learning explainability dashboards. No detailed model breakdowns. But it worked. Just a plain-language reason the user could read in two seconds and either agree with or override. Override rates fell by more than half. The facility managers did not need to understand the model. They needed to understand the decision. Those are very different things, and most product teams building AI features are confusing one for the other. They invest in model interpretability (a research problem) when what users actually need is decision legibility (a design problem). But the founder I was mentoring had a harder version of the same challenge. Her recommendation engine could not always reduce its reasoning to a single factor. Sometimes the suggestion reflected a weighted combination of price, reliability, and delivery speed. The temptation was to show all the weights, which would have been accurate and completely useless. Nobody in procurement wants to interpret a radar chart before placing an order. What worked was highlighting the primary factor. "Recommended: lowest cost with 98% on-time delivery." Not the full picture. But enough of the picture for the user to form a judgment. Enough to cross the explainability threshold. The best AI feature is the one the user understands well enough to disagree with. That is the bar. Not accuracy. Not sophistication. The ability to look at what the system produced and say, "I see why you did that, but I think you are wrong." That disagreement is not a failure of the AI. It is proof the user trusts the system enough to engage with it honestly rather than ignore it entirely. The design problem nobody assigned Most product teams shipping AI features have a machine learning team and an interface design team. The machine learning team optimises for accuracy. The design team optimises for usability. But nobody is optimising for the gap between what the system knows and what the user can see. That gap is where trust lives and dies. The teams getting this right treat explainability as a design constraint, not a feature to be added later. They ask, before shipping any AI-driven output: can a user form a one-sentence explanation of why they are seeing this? If the answer is no, the feature is not ready. Not because the model is wrong. Because the interface has not done its job. Every AI feature your users ignore is a feature that failed the trust test before it ever got a chance to prove its accuracy. You cannot earn trust by being right. You earn trust by being understood. The explainability threshold is not a nice-to-have. It is the price of admission.

User & Buyer PsychologyNovember 14, 2024

The language nobody taught you

There is a meeting that happens in every product organisation, and designers are often not in it. Not because they weren't invited. Because when they were invited, they didn't make the case for staying. It's the meeting where budget gets allocated. Where headcount decisions get made. Where someone draws the line between what the company will invest in and what it will deprioritise. Designers often experience the output of that meeting as something that happens to them. A team gets cut. A project gets shelved. A roadmap gets reordered in ways that seem to contradict everything the design team just spent six months learning about users. And the response, in most design teams, is frustration. Followed by a Slack message. Followed by a resigned shrug and a new sprint. But the meeting was not rigged against design. Design just didn't show up in the room's language. And those are different problems with different solutions. I spent a long time believing that good work would speak for itself. This is a belief that design education quietly installs and almost never corrects. You build a portfolio. You learn the craft. You develop an eye. And somewhere in that process you absorb the idea that the quality of the work is its own argument. It is not. But the belief is understandable, because early in a career it is sometimes true. At a large enterprise I worked at, I watched a research project get defunded three weeks before it was due to deliver findings that would have directly informed a major product decision. The research was rigorous. The methodology was sound. The team had done everything right. But the research lead presented its value in design terms: user empathy, informed decisions, reduced rework. All true. All invisible to a CFO looking at a line item and asking what the return was. The project got cut. The product decision got made without the findings. And six months later, the product failed in exactly the ways the research would have predicted. That is not a research failure. That is a translation failure. But it is also not unusual. I have seen versions of that story at companies of every size, in every market I have worked in. The pattern is consistent: strong design work, weak business case, quiet defunding. Business literacy for designers is not about learning to love spreadsheets. It is about understanding that every design decision lives inside a commercial context, and that context has a language, and the people who control resources speak that language fluently. The language is not complicated. It has a small vocabulary: revenue, cost, retention, conversion, churn, margin, time to value. It connects decisions to outcomes in terms that are trackable. It answers the question "what happens to the business if we do this?" rather than "what happens to the user if we do this?" Both questions matter. But in a resource allocation meeting, only one of them moves money. That is not a flaw in the meeting. It is the meeting's job. The designers who hold influence are the ones who answer both questions in the same breath. "This onboarding redesign improves the user's first experience, and our data suggests that users who complete the full onboarding are retained at twice the rate of users who don't. That is worth measuring." That sentence is not a compromise. It is the same design thinking, translated. But it lands in rooms where the previous version did not. The resistance I hear from designers when this comes up is usually one of two things. The first is that reducing design to business metrics corrupts the work. That design is a humanist discipline and the moment you start valuing it in revenue terms you have already lost something. I have some sympathy for this. But it is also a position that only works if someone else is making the business case on your behalf. And in most organisations, that someone is a VP who is two steps removed from the design work and defending it with half the information. The second resistance is simpler: nobody taught me this. Design school did not cover CAC. My first job did not require me to understand margin. I have been hired to make things, not to run a P&L. This is entirely true. But it explains the situation without changing it. The gap does not close by waiting for someone to teach you. It closes when you start treating the business context as part of the design brief, not a constraint imposed on top of it. The senior designers I have mentored who made the largest leaps in influence did not learn business literacy from a course. They learned it by sitting in more rooms, asking more questions, and stopping themselves every time they were about to present work without also presenting the business question it answered. The muscle builds slowly. But it builds. The first time you walk into a design review and say "this reduces support escalations by an estimated 20%, which represents approximately 40 hours of support team time per month," and you watch the head of operations sit up slightly straighter, you understand something no portfolio can teach you. You understand that craft without context is a hobby. But design with a business case is a strategy. The meeting is still happening. The budget is still getting allocated. The only question is whether design is in the room in a language the room understands.

Product Design & Craft TopicsOctober 14, 2024

The always-on illusion: When availability became a productivity myth

The busiest product leader I have ever worked with was also the one producing the least important work. He answered every Slack message within four minutes, attended every meeting he was invited to, and kept his calendar so full that his lunch breaks were fifteen-minute windows labelled "bio break" so nobody would schedule over them. He was, by every visible measure, deeply committed. But he was also, by every outcome measure, falling behind. His decisions had a pattern: fast, confident, and wrong about forty per cent of the time. The correlation was not a coincidence. I have watched this pattern repeat for two decades across companies on three continents. The people who look the most available are often the ones doing the least thinking. Act I: The Setup Startup culture has always treated availability as a proxy for commitment. If you are online at eleven at night, you are serious. If you respond to messages within minutes, you care. If your calendar has gaps, the unspoken assumption is that you are either not important enough to be needed or not dedicated enough to fill the space. The always-on founder became the aspirational archetype. Sleep four hours, answer every ping, never let a question sit overnight. At my first startup, I was that person. I wore the exhaustion like a badge. My co-founder and I had a running joke about who had slept less, as though chronic fatigue were a competitive sport. One week I worked six consecutive eighteen-hour days building a feature integration while managing a client escalation. By day five, I was making decisions that I would not have accepted from a junior PM on day one. But I could not see it. Exhaustion does not announce itself as impairment. It disguises itself as determination. I shipped the integration on the seventh day. It had three critical bugs. A well-rested version of me would have caught at least two of them in review. Well-rested was not an option I believed I had. The setup was simple: we confused presence for productivity, hours for output, and availability for virtue. And most of the industry built its culture around that confusion. Act II: The Conflict The data arriving this year tells a story that the always-on culture does not want to hear. Research across multiple studies finds that past a threshold of roughly fifty hours per week, additional hours correlate negatively with decision quality. Not neutrally. Negatively. You are not just getting less return per hour. You are actively making worse choices. I call this the threshold inversion. Before the threshold, more time produces more output. After it, more time produces worse output. The relationship inverts. And the person experiencing it is usually the last to notice, because the subjective feeling of working hard is indistinguishable from the subjective feeling of working well. You feel busy. You feel engaged. You feel like things are happening. But the things happening are increasingly low-quality. At Freshworks, I watched a product director burn through a quarter this way. She was brilliant. Strategic mind, strong instincts, respected by her team. But she had fallen into the availability trap, the pattern where constant responsiveness leaves no uninterrupted time for the kind of slow, deliberate thinking that strategic work requires. Her days were a sequence of reactions. Slack message, meeting, Slack message, review, Slack message, decision. Every individual response was competent. But the decisions she made at four in the afternoon, after eight hours of continuous reactivity, were measurably different from the ones she made at nine in the morning. I know because I reviewed her roadmap decisions across a quarter. The morning decisions were thoughtful, connected to long-term strategy, and showed evidence of second-order thinking. But the afternoon decisions were narrow, focused on immediate problems, and optimised for resolution speed rather than outcome quality. Same person. Same intelligence. Different cognitive state. She was not lazy. She was depleted. And the culture she worked in read depletion as dedication. Act III: The Resolution The most effective product leader I have worked alongside did something that looked, to the always-on crowd, like professional negligence. He checked messages twice a day. He blocked four hours every morning as unavailable. He left meetings that ran past their scheduled time. His team initially found it frustrating. But within two quarters, something interesting happened. His decisions were consistently better than those of peers who worked longer hours. His roadmap had fewer reversals. His team shipped more, not because they worked more, but because they received clearer direction and wasted less time on rework from fatigued decisions. He told me once, "Availability is not a virtue. It is a design choice. And most people are designing it badly." That line has stayed with me because it reframes the entire conversation. We treat availability as a moral quality, evidence of commitment or character. But it is actually a resource allocation decision. Every hour spent being available for other people's questions is an hour not spent on problems that require uninterrupted concentration. The reframe matters because it moves the conversation from identity to design. You are not a bad founder if you check messages twice a day. You are a founder who has designed their availability for decision quality rather than response speed. But making that argument in most startup cultures still feels like confessing to a lack of seriousness. The deeply held belief that more hours equals more commitment is remarkably resistant to evidence. I spent a year making this transition myself. The hardest part was not the logistics. It was the guilt. Every time I did not respond to a message immediately, I felt a twitch of anxiety that I was letting someone down. That anxiety was not rational. It was conditioned. Years of startup culture had trained me to equate responsiveness with responsibility, and the training ran deeper than the data. But the results were undeniable. My error rate on product decisions dropped. My ability to spot strategic signals through operational noise improved. I started seeing patterns I had been too busy to notice when I was responding to everything in real time. The irony is thick: I became more useful to my team by being less available to them. What this actually means A body of founder essays circulating this year carries a common thread. The authors describe periods of overwork that they believed were productive, followed by a realisation that much of what they produced during those periods was mediocre, redundant, or actively counterproductive. The pattern is so consistent it reads less like anecdote and more like diagnosis. But nobody wants to say it plainly: we built an entire professional culture around a productivity model that, past a measurable threshold, produces the opposite of what it promises. I think about that first startup. The eighteen-hour days. The competitive sleep deprivation. The three critical bugs I shipped because I was too exhausted to review my own work. I thought I was being serious. But I was being self-destructive in a way that the culture could not distinguish from dedication. That is the always-on illusion: not that the hours are wasted, but that past a point, they are actively harmful, and the culture rewards them anyway. The question for any product leader is not how many hours you are willing to work. It is whether you have designed your availability for the quality of thinking your role requires. Most people have not asked that question, because the culture never gave them permission to ask it. But permission, like availability itself, is something you can design. And the people who design it well tend to produce work that outlasts the people who simply worked longer.

Productivity & Working MethodsOctober 2, 2024

Ownership without authority: Why product managers keep failing in the same way

In football, the manager picks the tactics. Formation. Style of play. Who starts and who sits on the bench. That is the theory. But in most clubs, the manager does not pick the team. Not really. The transfers are decided by a director of football in a different building, working from a different set of priorities, often with a different timeline. The manager gets the players they get. They build a system from whatever arrives. And then they are judged, entirely and publicly, on match results. When the results are poor, the manager gets sacked. The director of football stays. If you have spent any time in product management, you recognise this arrangement immediately. The accountability fiction Product managers are told they own the product. It is in the job description. It is in the interview. It is repeated in onboarding, in all-hands meetings, in blog posts written by executives at companies that have never actually given a PM real authority over anything consequential. Own the roadmap. Own the outcomes. Own the customer experience. But ownership implies control. And most PMs control almost nothing. They do not control engineering allocation. That is decided by an engineering lead or a VP of Engineering based on technical priorities, hiring constraints, and relationships with other parts of the organisation. They do not control design bandwidth. Designers report to a design lead who has their own roadmap, their own capacity problems, and their own opinion about what matters. They do not control sales behaviour. Sales teams sell what closes deals, including features that do not exist and timelines that no one in product has agreed to. The PM owns the outcome. The PM controls none of the inputs. I call this the authority gap. The distance between what a PM is accountable for and what a PM can actually decide. In most organisations, that gap is enormous. And it is the single most reliable predictor of PM burnout, PM failure, and PM attrition. At Adobe, I watched a product manager do everything right. Her PRDs were meticulous. Her user research was thorough. Her prioritisation was sharp and well-reasoned. She had identified a feature that users had been requesting for over a year, validated the business case, and built a clear plan for delivery. But the engineering lead had a different roadmap. His priorities were infrastructure and technical debt, both legitimate. He was measured on system reliability, not feature delivery. So her feature kept getting pushed. Quarter after quarter, it slipped. The stakeholders asked her why it had not shipped. She could not say "because engineering chose not to build it" without creating a political problem. So she absorbed the accountability. She smiled in the status meetings. She adjusted the timeline. She quit within a year. Not because she was bad at her job. Because her job, as it was structurally designed, was impossible to do well. The inputs you do not control The Adobe story is not unusual. It is the default. I have seen the same pattern at five different organisations, and the specific details change while the structure stays identical. At Freshworks, I watched a talented PM present a quarterly plan to leadership. It was a good plan. Thoughtful. Grounded in data. Clear on outcomes and success metrics. But I kept counting the dependencies. Engineering allocation: not his decision. Design bandwidth: not his decision. A commitment from sales to stop pre-selling features that did not exist: very much not his decision. His plan depended entirely on decisions made by people who were not in the room, who had not been consulted, and who had their own priorities. He owned the outcome. He controlled none of the inputs. And every person sitting in that meeting knew it, including him. Nobody said anything. That silence is the sound of the accountability fiction being maintained by mutual agreement. Everyone in the room understood that the plan was structurally dependent on cooperation that had not been secured. But naming it would have required someone to ask uncomfortable questions about how authority was actually distributed. And in most organisations, authority distribution is the conversation nobody wants to have. Ownership without authority is the most common lie organisations tell their product people. It is not always intentional. Sometimes it is org charts designed without thinking about decision rights. Sometimes it is inherited from a structure nobody updated. But the effect is the same. Someone is told they own something, works hard, plans carefully, and then discovers the plan depends on decisions they cannot make. Why talented PMs keep leaving The pattern is consistent enough that I have stopped being surprised by it. A PM joins with energy and capability. They are told they own the product. They build relationships, do the research, write the strategy. And then they hit the authority gap. Some PMs respond by becoming politicians. They spend more time influencing sideways and upward than they spend on the product. This works for a while. But it is exhausting, and it turns the role into something that is no longer about product work. It is about organisational manoeuvring. Some PMs respond by becoming order takers. They stop proposing their own roadmap and start asking leadership what they want built. This is safe. It is also the death of the product function, because an order-taking PM is just a project manager with a more expensive job title. And some PMs, the good ones, leave. They leave not because they cannot do the job but because the job, as designed, will not let them do what they were hired to do. The accountability fiction pushes out exactly the people organisations most need to keep. I have mentored enough junior PMs to see this cycle repeat. The ones with the most product instinct are the ones most frustrated by the authority gap, because they can see what needs to happen and they cannot make it happen. The ones who stay longest are often the ones who have learned to manage expectations down rather than push decisions up. They survive. But survival is not the same as impact. What honest organisations do differently The authority gap is not a management failure. It is a design flaw. It exists because organisations assign accountability without assigning the corresponding decision rights. The fix is not motivational. It is structural. The few teams I have seen get this right did something specific. They defined, in writing, what the PM could decide without approval, what required consultation, and what required escalation. Not as a philosophical statement about giving people permission (which usually means giving them nothing). As a practical document that everyone in the cross-functional team had read and agreed to. But most organisations will not do this. Because writing down decision rights forces you to confront who actually has power. And in most organisations, the gap between who is supposed to have power and who actually does is something everyone can feel but nobody wants to document. The football manager who cannot pick the team learns to work with what they have. Some become great at it. But the best managers eventually go to clubs where they have authority over the squad. They go where the structure matches the accountability. Product managers do the same thing. They leave for organisations where ownership means something. And the organisations they leave behind wonder why they cannot retain good PMs, without ever examining whether the role they designed was one a good PM could succeed in. The question is not whether your PMs are talented enough. It is whether you have built a structure that lets talent matter.

Product Teams & Org DynamicsSeptember 30, 2024

Usage-based pricing vs seat-based: the model shift

Every January, gyms fill up. By March, they're empty again. The business model depends on this. A gym that had to serve every member who paid for a membership, every day, would collapse under its own economics. The model works precisely because most people don't show up. Seat-based software pricing has operated on the same principle for years. Companies buy fifty licences. Twenty-three people log in regularly. The other twenty-seven are ghosts in the system, their seats gathering digital dust while the invoice keeps arriving. Nobody on the vendor side mentions this. The customer's finance team occasionally does, usually right before renewal season. But the model persists because it's simple, predictable, and extremely profitable for the seller. But that quiet arrangement is starting to break. The seat tax I saw this up close at Freshworks. We had enterprise customers paying for hundreds of seats. The dashboard told one story: X licences purchased. The usage data told a completely different one. Whole departments had access they never used. Some seats hadn't seen a login in six months. But we billed for them anyway, because that was the model. The awkward part wasn't the billing. It was the customer meeting where someone from procurement pulled up their own usage reports and asked, calmly, why they were paying for seats that nobody occupied. I remember sitting in one of those calls thinking: we don't have a good answer for this. We had a contractual answer. We had a "that's how SaaS licensing works" answer. But we didn't have a good one. I started calling it the seat tax. The price customers pay for access they don't use. And for a while, nobody questioned it because the alternative was messy. Usage-based pricing sounded elegant in theory. But in practice, it meant unpredictable revenue, harder forecasting, and a finance team that couldn't model next quarter with any confidence. But here's the thing. The seat tax only works when the buyer doesn't notice. Or doesn't care. And buyers have started caring. The alignment gap The deeper problem with seat-based pricing isn't that it's unfair. It's that it's misaligned. The product delivers value when someone uses it. The pricing charges whether they use it or not. Those are two different conversations happening at the same time, and neither one acknowledges the other. Pricing is the most honest conversation a product has with its users. When that conversation is dishonest, when you charge for presence rather than value, you create what I call the alignment gap. The distance between what the customer experiences and what the invoice claims they received. At Grab, this gap was visible from a different angle entirely. The Southeast Asian market operates on patterns that make seat-based licensing feel almost absurd. You have teams where usage is deeply seasonal. You have operations spanning multiple countries with wildly different engagement levels. You have field teams who use the product intensely for three weeks and then not at all for two months. Trying to fit that reality into a per-seat annual contract was like selling a gym membership to someone who only needs a treadmill during monsoon season (which, in Southeast Asia, is roughly half the year). The teams there didn't think about pricing as a finance problem. They thought about it as a product-fit problem. If the pricing model doesn't match how people actually use the thing, the product feels wrong even when the product works. The invoice becomes the user experience. And nobody in product was designing for it. When the model breaks The shift toward usage-based pricing isn't happening because it's trendy. It's happening because products are getting better at measuring what value actually looks like. But the transition is genuinely hard. I've watched teams try to move from seat-based to usage-based and run into three walls immediately. First, the revenue predictability wall. Finance teams built their entire forecasting apparatus around annual contracts with known seat counts. Usage-based revenue moves. It goes up and down with customer behaviour, seasonal cycles, and adoption curves. The CFO who signed off on a seat model can tell the board exactly what next quarter looks like. The CFO on a usage model has to explain probability distributions. That's a different meeting. Second, the product design wall. When you charge per seat, the product can be a Swiss army knife. Users pay for access to everything, and if they only use the screwdriver, that's their business. But when you charge per usage, every feature interaction has a cost the customer can see. Suddenly, product teams need to think about which actions are worth billing for and which ones should be free. That's a design conversation that most product teams have never had, because the pricing model never required it. Third, the customer psychology wall. Some customers genuinely prefer seats. A CFO who pays a flat rate per person sleeps well at night knowing the bill won't surprise them. Usage-based pricing introduces anxiety. What if the team uses more than expected? What if the bill spikes during a busy quarter? The simplicity of per-seat pricing isn't just a vendor convenience. For some buyers, it's a psychological comfort. The honest middle The reality forming right now isn't a clean victory for either model. The products making the smartest moves are the ones building hybrid approaches. A base platform fee (predictable, plannable, keeps the CFO calm) with usage-based components layered on top for the features where consumption actually varies. But even the hybrid model only works if the product team understands something most pricing discussions skip entirely. The unit of value. Not the unit of measurement. Not the unit that's easiest to meter. The unit that the customer would point to and say: yes, that's what I'm paying for. That's what I got. For some products, that unit is a resolved support ticket. For others, it's a report generated, a workflow completed, a prediction delivered. Getting that unit wrong is worse than staying on seats, because now you've built a usage model that charges for the wrong thing and the customer notices it every single month. Most pricing conversations happen between finance and sales. The product team gets consulted, if they're lucky, about what can be metered. But the question of what should be metered is a product question. It requires understanding not just what the software does, but what the customer believes they're buying. And those two things are almost never the same. The question underneath The real shift isn't from seats to usage. It's from pricing as an administrative decision to pricing as a product decision. The model you choose shapes the features you build, the metrics you track, the customers you attract, and the ones you lose. It determines whether your product and your revenue grow in the same direction or slowly pull apart until someone in a quarterly review asks why the numbers don't match the story. The gym figured this out decades ago. They know exactly who shows up and who doesn't. They built the entire business on the gap between access sold and access used. The question for every product team right now is simpler than it seems: do you want to be the gym, or do you want to be the class that's worth attending?

The Business of ProductsSeptember 21, 2024

Your written communication is your leadership presence now

The most effective leader on a distributed product team I worked with at Grab was not the most senior person. She was not the loudest. She did not have the most impressive title or the longest tenure. She was a principal engineer named Meera who had never once given a presentation that anyone would call inspiring. But her Slack updates were the clearest on the team. Her decision memos read like they had been edited three times, because they had been. Her written product reviews were so well structured that two other teams started using them as templates without being asked. And over the span of about six months, something quiet happened. The team started treating her written opinions as the ones that mattered most. Nobody promoted Meera. Nobody announced a leadership change. The medium changed, and a different kind of communicator rose to the top. Meanwhile, the product director who had been the most magnetic presence in any room he entered found himself struggling to translate that magnetism to the page. His Slack messages were fine. His memos were competent. But "fine" and "competent" are not what gets you followed. In a meeting, his charisma did the heavy lifting. On the page, the charisma had nowhere to land. Once Upon a Time, Leadership Was a Room For most of the history of product management, leadership was a performance art that required an audience. You led by showing up. You led by reading body language, adjusting your argument in real time, using tone and timing and the subtle social cues that only work when people share physical space. The best product leaders were not necessarily the deepest thinkers. But they were the best performers in the theatrical sense, capable of shaping a room's energy toward a decision. Every day, that worked. Then teams went async. Not partially. Not as a temporary arrangement. As the default operating mode for a growing number of product organisations. And because of that, something structural shifted. In an async-first organisation, nobody sees you read the room. Nobody watches you manage a tense conversation with a raised eyebrow and a well-timed pause. Nobody experiences the interpersonal gravity that made you effective in person. What they see is your writing. That is the only version of you that exists in the channel. The Presence Transfer I call this shift the presence transfer. The migration of leadership credibility from physical rooms to written artefacts. At Freshworks, I watched it play out across several product teams as the organisation moved toward a more distributed model. The leaders who had built their reputations through interpersonal influence found themselves on unfamiliar ground. Their Slack messages were serviceable. But serviceable writing in an async organisation is like a mumbled answer in a boardroom. Technically present. Functionally absent. In an async-first organisation, you are your writing. There is no second impression. The written signal is the concept that matters here. In async-first environments, your written output is the only signal the organisation receives about how you think, how you prioritise, and how clearly you understand the problem. Your Slack message is your leadership presence. Your product brief is your strategic vision. Your written feedback is your management style. There is no gap between the quality of your writing and the perception of your leadership. They are the same thing. The leaders who struggled with the presence transfer were not bad writers. But they were unintentional writers. They had spent years developing their ability to communicate in real time and almost no time developing their ability to communicate on the page. Their written voice was the voice they used when they were not trying particularly hard. In rooms, they performed. On the page, they drafted. That asymmetry of effort became visible to everyone who read what they wrote. What Good Looks Like on the Page The leaders who emerged strongest in async-first environments share a pattern I have observed at both Grab and Freshworks. Their writing is not literary. It is not beautiful prose. But it is relentlessly clear. They front-load the decision or recommendation. They state what they think before they explain why. They use short paragraphs and plain language. They anticipate the three questions the reader will have and answer them in sequence. They distinguish between facts, interpretations, and recommendations, and they label which is which. This is not a writing style. It is a leadership discipline. One senior PM at Freshworks told me something that stayed with me. She said she spends more time editing her weekly Slack updates than she ever spent preparing for the equivalent standing meeting. "In a meeting, I could course-correct if I saw confusion," she said. "On Slack, I get one shot. If the message is unclear, I do not get to see the confusion. I just get silence. And silence in async is worse than disagreement, because you cannot tell the difference between agreement and apathy." That observation captures the core challenge. In synchronous communication, you get feedback loops. You see nods, furrowed brows, raised hands. You can adjust. But in async communication, the feedback loop disappears. Your message lands once, in its final form, and the reader responds to what you wrote, not what you meant. The best async leaders write as though they will not be in the room when the message is read. Because they will not be. The Adjustment Nobody Talks About For product leaders who built their careers on interpersonal presence, the presence transfer is a genuine adjustment. But it is rarely discussed openly, because admitting that your writing is weaker than your speaking feels like admitting a professional deficiency. Nobody wants to say "I am less effective when I cannot be in the room." But a growing number of product leaders are discovering exactly that. This is not a generational divide. I have seen junior PMs who write with surgical clarity and senior directors whose Slack messages read like first drafts of a thought they have not finished having. Written communication skill was never evenly distributed across seniority levels. But it did not matter as much when the primary leadership medium was the room. Now the primary medium is the page. Every week, I watch product leaders spend hours preparing a presentation they will deliver once to thirty people. Then they spend three minutes writing a Slack update that two hundred people will read, discuss, and form opinions about. The ratio is backwards. The written artefact has more reach, more permanence, and more influence on how the organisation perceives your judgement. But almost nobody allocates their effort accordingly. The good news is that writing is a learnable skill. It responds to practise. It improves with feedback. It rewards the same kind of deliberate attention that product leaders already apply to roadmaps and user research. But the only shift required is treating writing as a leadership competency rather than an administrative task. The leaders who figure this out earliest tend to be the ones whose influence travels furthest. Not because they had the most presence in the room. Because they learned to put that same presence on the page, one carefully edited sentence at a time.

Communication & Storytelling September 19, 2024

Fear of failure drives more decisions than desire for gain

There is a ridge route on Aonach Eagach in the Scottish Highlands that experienced climbers consider one of the finest traverses in Britain. The views are extraordinary. The scrambling is varied and rewarding. But most guided groups do not take it. They take the tourist path on the opposite side of the glen instead. Not because it is better. Because it is known. Because every handhold has been tested a thousand times. Because on a mountain, the cost of choosing wrong is not measured in time or inconvenience. It is measured in whether everyone walks back down. That calculation, the one where familiar beats excellent because the penalty for getting it wrong is too high, is the same calculation your buyers are making every single quarter. And most product teams have no idea. The regret calculus I call this the regret calculus. It is the mental arithmetic buyers run before every significant purchase, and it has almost nothing to do with features, pricing, or competitive benchmarks. The regret calculus asks one question: if this goes wrong, what happens to me? Not what happens to the company. What happens to me. My reputation. My credibility. My standing in the room where the next budget decision gets made. Research keeps confirming what anyone who has sat on the buying side already knows. Roughly 80% of B2B buyers say that avoiding a bad decision matters more to them than getting the best possible deal. That number should terrify every product team that leads with innovation in their pitch deck. But it doesn't, because most product teams are still building for desire when the buyer is optimising for regret. But the regret calculus is not irrational. It is perfectly rational once you understand the asymmetry. A good purchase decision earns you a brief nod in a quarterly review. A bad purchase decision follows you for years. The upside of getting it right is modest and fleeting. The downside of getting it wrong is specific and memorable. Every buyer in a large organisation knows this, even if they never articulate it. The maths is simple. The safest product wins more deals than the best product. The Boeing lesson I spent time at Boeing working on products for aviation fleet management. Aviation procurement is a world where this psychology is not a subtle undercurrent. It is the entire operating principle. Every decision is made with the full weight of what could go wrong if you choose incorrectly. And what could go wrong, in aviation, is catastrophic. But here is what surprised me. The same psychology governed decisions that had nothing to do with physical safety. Software purchases. Tooling decisions. Workflow systems. The evaluation committees approached a new fleet management interface with the same instinct they used for a mechanical component. Proven beats innovative. Known beats novel. Reliable beats impressive. An engineer on one of those committees told me something I have never forgotten. He said: nobody gets fired for buying the existing system. But plenty of people get fired for buying the new one that fails. He was talking about a software platform, not an aircraft component. But the logic was identical. Choose the incumbent and nobody remembers. Choose the challenger and it stumbles, everyone remembers. Your name was on that decision. I watched two vendors present to the same committee in the same week. The first had a genuinely superior product. Better interface, faster workflows, more intelligent data handling. The second had a product that was, by any reasonable measure, less capable. But the second vendor's entire pitch was built around risk reduction. They talked about implementation guarantees, uptime records, rollback protocols, and a client list of similar organisations that had deployed without incident. They barely mentioned their features. The second vendor won. It was not close. The safety premium I call this the safety premium. It is the invisible price that buyers pay, willingly and often unconsciously, for the feeling that a product will not embarrass them. The safety premium explains why inferior products win enterprise deals with startling regularity, why incumbents survive long past the point where their product has been surpassed, and why "nobody ever got fired for buying IBM" became the most durable piece of procurement wisdom in technology. But the safety premium is not about the product being safe. It is about the buyer feeling safe. Those are different things. A product can be perfectly reliable and still feel risky if it comes from an unknown vendor or lacks recognisable clients. I learned this the hard way at my first startup. We were pitching to a mid-sized enterprise client. Our product was better than the competitor's. I knew it. Our team knew it. Honestly, I think the buyer knew it too. But we pitched aspiration. We talked about what their organisation could become with our platform. We painted a picture of the future. Transformation. Possibility. Growth. Our competitor pitched the opposite. They talked about what would not break. They talked about what had worked for organisations identical to the client's. They brought references from three companies the buyer had personally spoken to. Their presentation was, to my eyes, boring. Predictable. Conservative. They won the deal. I sat in a coffee shop afterwards, going through our pitch deck slide by slide, looking for the flaw. The flaw was not in the slides. It was in the assumption underneath them. We assumed the buyer wanted the best product. The buyer wanted the safest decision. We had optimised for the wrong one. That was an expensive tutorial in the regret calculus. Building for the buyer's fear Loss aversion does not announce itself. Buyers do not walk into a demo and say: I am primarily motivated by the fear of making a mistake that damages my career. They say: can you provide references from companies in our vertical? They say: what does your implementation timeline look like compared to the incumbent? But those questions are all the same question, dressed in different clothes. The real question is: if I choose you and it goes wrong, can I defend this decision? Product teams that understand this build differently. They do not lead with innovation. They lead with evidence. They do not demo the most impressive feature. They demo the most predictable workflow. They do not sell what the product can do. They sell what the product will not let happen. But most product teams cannot bring themselves to do this. Because it feels like a retreat. It feels like admitting that your product's brilliance matters less than the buyer's anxiety. And it does. That is the uncomfortable truth sitting underneath every enterprise sales cycle: the most relevant competitor is not the other vendor. It is the buyer's fear of making a decision they will have to explain later. The familiar route Product marketing teams spend months crafting messages about differentiation and competitive advantage. But best and safest live in different parts of the buyer's brain. The decision to buy is not a spreadsheet exercise, no matter how many evaluation matrices get passed around the committee. It is a risk exercise. And risk, in the context of a career, is deeply personal. The climber on Aonach Eagach does not take the tourist path because she lacks skill or ambition. She takes it because she has calculated, correctly, that the cost of being wrong on the ridge is a price she is not willing to pay. Not when the tourist path gets her to the same summit, with less to explain if the weather turns. Your buyers are standing at the same trailhead. The question is whether your product feels like the ridge or the path.

User & Buyer PsychologyAugust 16, 2024

The internal pitch is the most consequential product skill nobody practises deliberately

I once killed a perfectly good product idea with thirty-two slides and an unreasonable amount of confidence. It was at Adobe, during a design system overhaul proposal I had spent three weeks assembling. The existing system was fragile, inconsistent, and universally disliked by every designer on the team. I had user complaints documented by category. I had a prototype showing what the replacement could look like. I walked into the review room carrying the quiet certainty of someone who believed that being right was the same as being persuasive. It is not. It has never been. Twenty minutes in, the VP asked a question I had not anticipated: "What does this mean for our Q3 commitments?" I did not have an answer. Not because there was no answer, but because I had not considered the question worth asking. I had structured every slide around why the design system needed to change. But I had not structured a single slide around why anyone in that room should care enough to fund it this quarter. The meeting ended politely. My proposal died quietly. And I spent the next two months watching the same broken system produce the same problems I had documented. The idea was eventually built. Eighteen months later. By someone else. The Permission Gap If you have ever had a solid proposal rejected, deprioritised, or left to expire in someone's inbox, you are in the overwhelming majority. The pattern I have observed across every organisation I have worked with is consistent. Technically sound proposals fail not because the underlying logic is wrong but because the person presenting them cannot structure a clear case for an audience that cares about different things. I call this the permission gap. It is the distance between having an idea worth building and getting organisational permission to build it. The permission gap is not a technical problem. It is a communication problem. But because product teams are filled with people trained in logic and evidence-based reasoning, the assumption is that a well-reasoned argument will speak for itself. It will not. The best idea in the room loses to the best-pitched idea in the room. Every time. The permission gap explains why certain people inside organisations consistently ship important things while equally talented colleagues ship whatever they are assigned. The difference is rarely about the quality of their thinking. It is almost always about how they package that thinking for a specific room. Most product managers frame rejection as a judgement on their idea rather than feedback on their pitch. That framing keeps them stuck. The Hero Is Not You Here is where most internal pitches go wrong. The person pitching positions themselves as the hero. "I found this problem. I have the solution. Here is why my solution is brilliant." The implicit structure is: trust me, I have done the work. But the people you are pitching to do not need a hero. They need a reason to act. The question in every leadership meeting is never "Is this a good idea?" It is "Is this the best use of our limited resources right now, given everything else we are committed to?" That second question is the one most pitchers never answer. At Freshworks, I watched a product manager pitch the same feature twice across three months. The first time, he presented the technical rationale. The user research was thorough. The competitive analysis was sharp. Leadership listened, nodded in the way that senior people nod when they are being polite, and said they would think about it. That is corporate language for no. Three months later, he pitched it again. But this time, he opened with a customer story. A specific customer. An account worth a specific amount of annual revenue at risk of churning because of a specific gap in the product. He connected the feature to a retention metric leadership was already tracking. He showed the cost of inaction in terms they were already being measured on. Same feature. Same technical quality. Entirely different framing. It was approved in the meeting. Nothing about the feature had changed. But everything about the pitch had changed. The first pitch said "here is a good idea." The second said "here is a problem you already care about, and here is what it costs you every quarter you do not solve it." One required the audience to adopt new priorities. The other connected to priorities they already held. The Clarity Threshold There is a concept I use when mentoring product managers on internal communication. I call it the clarity threshold. It is the minimum level of contextual framing a proposal needs before the decision-maker can even evaluate it on its merits. Below the clarity threshold, the quality of your idea is invisible. Most rejected proposals are not actually rejected. They are deferred. They sit below the clarity threshold, and the response is not "no" but "not now," which is the organisational equivalent of putting something in a drawer and forgetting which drawer. The clarity threshold has three components. First, what is the cost of inaction, not to the product, but to the thing the audience is already being measured on? Second, what does this replace or displace? Every new initiative takes resources from something else, and if you do not name what, the audience will assume the cost is higher than it is. Third, what does success look like in terms the audience already uses? If your metric requires them to learn a new measurement vocabulary, you have added friction to the decision before the decision even begins. The PM at Freshworks cleared the clarity threshold the second time because he answered all three questions before anyone asked them. Same person. Same capability. But a completely different outcome. What Practise Looks Like The strange thing about internal pitching is that it is a skill, not a talent. It responds to deliberate repetition. But almost nobody treats it that way. Engineers practise coding challenges. Designers practise prototyping new patterns. Product managers practise writing documents that other product managers read. The actual skill that determines whether their work sees daylight is one they develop accidentally, if at all. I have sat through hundreds of pitches across Boeing, Adobe, Freshworks, and a handful of startups. The proposals that get funded are not always the best proposals. But they are always the clearest. The pitcher understood the room and structured the argument so the decision felt easy rather than brave. Your job is to make the right decision look obvious. When I mentor junior PMs, I tell them to pitch the same idea to three different people before taking it to a decision-maker. Not for feedback on the idea. For feedback on the pitch. Each conversation reveals an assumption you did not know you were making. By the third conversation, the pitch is structurally different from where it started. I did not do this at Adobe. I walked in with my thirty-two slides and my conviction that being right was sufficient. The solution I proposed was eventually built by someone else whose thinking was not as thorough as mine. But whose pitch was better. And in organisations, pitch quality is the filter that determines which ideas survive. Nobody teaches you this. The skill that determines which ideas ship is the one that lives entirely outside the curriculum, learned mostly through the accumulating evidence of things that should have been built but were not.

Communication & Storytelling August 16, 2024

Freemium economics: free users aren’t actually free

Every free user costs you money. Not metaphorically. Not in some abstract opportunity-cost sense. Actual money. Server costs, storage, bandwidth, support tickets, onboarding emails, and the engineering hours spent maintaining a tier that generates exactly zero revenue. Most product teams know this in theory. Almost none of them know the number. That gap between theory and number is where freemium models go to die quietly. The generosity nobody costed I call it the free user subsidy, and it works like this. A product team launches a free tier because the playbook says free drives adoption, adoption drives conversion, and conversion drives revenue. The logic is clean on a whiteboard. But the logic omits a line item that finance will eventually find: the cost of serving every user who never converts. At Freshworks, I watched this play out with painful clarity. The free tier was a growth engine. Thousands of signups per month. The product team celebrated the top-of-funnel numbers. Marketing used them in board presentations. But nobody had calculated what each free user actually cost to serve. Not the marginal cost. The fully loaded cost: infrastructure, storage, support, and the share of engineering time spent on bugs and feature requests that came exclusively from free accounts. Then finance did the maths. The meeting where that number first appeared on a slide was one of the quietest I have been in. The cost per free user was not trivial. Multiplied across the entire free base, it was a budget line larger than several paid feature investments the team had been fighting to fund. We had been subsidising a population of users who were, in aggregate, more expensive to serve than several of our paying customer segments. But nobody had asked the question before because the free tier was sacred. It was the growth story. And you do not question the growth story in a company that is growing. When every user is a cost centre The Freshworks experience taught me to look for the free user subsidy everywhere. But it was at Schneider Electric where I saw the most structurally uncomfortable version of the problem. We were working on a product where the infrastructure cost scaled directly with user count. Every additional user, whether paying or free, consumed resources that cost real money. This was not a marginal cost that rounded to zero at scale. It was a linear relationship: more users, more cost, regardless of revenue. The pricing model, which had been designed by people thinking about market share rather than unit economics, assumed that volume would eventually convert to revenue. But the conversion rate was low, and the per-user cost was not. We had built a product where success, measured by adoption, was financially indistinguishable from failure. That is the generosity trap. When the cost of being generous scales faster than the revenue from the users who convert, generosity is not a strategy. It is a subsidy from your paying customers to your free ones. And your paying customers, whether they know it or not, are funding an experiment that may never pay off. The maths nobody wants to do Here is the calculation most product teams avoid. Take the total cost of serving your free tier: infrastructure, a proportional share of engineering time, support tickets (even if you limit support for free users, they still generate load), and onboarding. Divide it by the number of free users. That is your cost per free user. Now multiply it by the percentage of free users who will never convert. For most products, that number is north of 90%. The result is the true cost of your freemium model. It is the price of the bet you are making that the 5-10% who do convert will generate enough lifetime value to cover the 90% who will not. But most teams never run this calculation. They run the optimistic version instead: “If we get our conversion rate from 3% to 5%, the model works.” Maybe. But the 97% who do not convert are not sitting in a spreadsheet waiting politely. They are consuming resources today, right now, at a cost that compounds every month. A free user is not a future customer. A free user is a current cost. Some of them will become customers. Most of them will not. And the product team’s job is to know the difference between an investment and a donation. Think of a restaurant that puts out a free appetiser bar to draw people in. The owner assumes the free food drives main course orders. But nobody has checked whether the people eating the free appetisers actually stay for dinner, or whether they fill up on bruschetta and leave. The appetiser bar costs real money every night. Whether it generates a return depends entirely on whether someone has bothered to measure. What the free tier is actually for The free tier is not a gift. It is a commercial instrument. And like any commercial instrument, it works when it is designed with its cost structure in mind and fails when it is designed on vibes and growth assumptions. But here is where most teams get it wrong. They design the free tier to be useful enough that people adopt it, without designing it to be limited enough that people graduate from it. The result is a free experience that is perfectly adequate for a large population of users who have no economic reason to ever pay. That is not a conversion funnel. That is a public service. The teams that run freemium well do something different. They design the free tier as a product decision, not a marketing decision. They know exactly what it costs. They know what behaviour predicts conversion. They know what features drive the moment where a free user hits a wall and decides the paid tier is worth it. And they track the ratio between the cost of serving free users and the revenue generated by those who convert with the same attention they give to any other financial metric. But that requires treating the free tier as a line item, not a slogan. Generosity is a strategy only when you can afford it. When you cannot, it is just a slow way to go broke. And the difference between the two is a spreadsheet that most product teams have never opened. The question behind the model The freemium conversation is usually framed as a growth question. How many free users do we need to hit our conversion targets? But the real question is a cost question. How many free users can we afford to carry, and for how long, before the economics demand that the bet pays off? Most product teams cannot answer that question. Not because the data is unavailable. But because asking it feels like questioning the model. And the model, once adopted, becomes identity. We are a freemium company. We believe in product-led growth. We trust the funnel. But trust without measurement is faith. And faith is a fine thing in most areas of life, but it is a poor foundation for a revenue model. There is something worth sitting with here. The best freemium products are not the most generous ones. They are the ones where generosity is precise, where the free experience is designed to reveal the value of the paid one, and where someone, somewhere in the organisation, knows exactly what the free tier costs and has decided, with open eyes, that the cost is worth it. That is not generosity. That is clarity. And clarity, in the long run, is the more honest form of care.

The Business of ProductsAugust 14, 2024

The platform layer began consolidating, and every point solution felt the ground shift

There was a shop in Kozhikode that sold the best chai in the neighbourhood. The owner had been there for twelve years, built a loyal following, and never missed a day. Then the building's landlord opened a tea stall in the lobby. Same building. Lower rent (he was paying it to himself). Better signage. The chai was worse, frankly. But the landlord had the foot traffic, the location, and the patience to wait. Within eighteen months, the original shop closed. Not because the tea was inferior. Because the landlord controlled the building. That story is playing out across the software industry right now, at a speed that should concern anyone who has built a product on top of someone else's platform. The Absorption Pattern If you are a product leader at a company that built its core value on a platform you do not own, this is the part where I tell you something you probably already suspect but have not said aloud in a leadership meeting. The platform is coming for your category. It may not be this quarter. It may not be next year. But the absorption pattern is as predictable as gravity, and it has been accelerating. Here is how it works. A platform creates an open surface, APIs, integrations, a marketplace. Third-party developers build tools that fill gaps the platform left. Users adopt those tools. The platform watches which tools get traction. Then, quietly, the platform begins building native versions of the most successful ones. Not all of them. Just the ones that proved there was demand. Best-of-breed is becoming the platform's unpaid R&D department. I watched this happen from the inside at Adobe. For years, Adobe's creative tools had a thriving plugin market. Designers installed third-party extensions for colour palette generation, stock photo integration, font management, prototyping workflows. These plugins were not trivial. Some of them were built by teams of ten or fifteen people who had invested years understanding design workflows better than Adobe's product teams did. But Adobe was watching. And one by one, the capabilities that those plugins had pioneered started appearing as native features. Stock photo integration became Adobe Stock. Colour tools became built-in. Prototyping capabilities evolved into Adobe XD. The plugin developers who had built real businesses on Adobe's platform had no structural defence. They had done the market validation. Adobe did the absorption. The plugin developers were not stupid. They were structurally exposed. There is a difference. The Platform Tax Every platform relationship involves what I call the platform tax. It is not the percentage cut on marketplace revenue, though that exists too. The platform tax is the ongoing cost of building on a foundation you do not control. It is the API change that breaks your integration overnight. It is the terms of service update that restricts your data access. It is the native feature announcement that makes your entire product roadmap irrelevant during a Tuesday keynote. The platform tax is not a line item on your P&L. It is a risk factor that compounds over time. At Freshworks, I lived inside this tension from the other side. We integrated deeply with Salesforce. Our products worked alongside their CRM, extending it, complementing it, making it more useful for specific customer segments. But we were also competing with Salesforce in adjacent categories. That dual position, partner and competitor simultaneously, shaped our product strategy in ways that most people outside the company never saw. Every integration decision was also a competitive calculation. Build deeper into the Salesforce surface and you reach more customers. But you also become more dependent on a company that could decide, any quarter, that your category is worth absorbing. Pull back from the integration and you lose distribution. Lean in and you lose independence. The platform is never neutral. It is patient. That patience is what makes platform competition different from ordinary market competition. A direct competitor tries to take your customers today. A platform competitor lets you build the market, validates the demand, and then uses its distribution advantage to offer a "good enough" native version that customers adopt because it is already in their workflow. The platform does not need to build a better product. It needs to build one that is close enough and already there. Why "Good Enough" Wins on Platforms This is the part that is hardest for product-minded founders to accept. You built the better tool. Your users agree. Your NPS is higher. Your feature set is deeper. Your support is more responsive. On every measure of product quality, you win. But product quality is not the variable that determines outcomes in platform competition. Distribution is. And the platform owns distribution the way a landlord owns the front door. I have seen founders spend months building feature comparison charts, convinced that if they could just show customers the objective superiority of their tool, the market would choose rationally. But markets do not choose rationally when one option is already embedded in the workflow. They choose conveniently. They choose the thing that does not require a separate login, a separate contract, a separate integration. They choose the thing that is already there, even when the thing that is already there is worse. This is not a failure of the market. It is how platform economics work. The absorption pattern is accelerating because AI has given platforms a new capability advantage. Microsoft is embedding Copilot across every surface. Salesforce is building Einstein into every workflow. Google is layering Gemini into Workspace. Each of these moves absorbs territory that third-party AI tools had staked out. The startups that built AI-powered extensions for these platforms are watching the platform replicate their core functionality as a native feature, bundled at no additional cost. What Defence Looks Like (and What It Does Not) If you are reading this and recognising your own situation, here is what I have observed from watching this pattern across multiple companies and platforms. There is no defence based on feature superiority alone. Features can be copied. But features that live on someone else's platform can be absorbed entirely. The only structural defences are the ones that create value the platform cannot replicate without fundamentally changing what it is. Depth in a vertical that the platform will never prioritise is one defence. Platforms are horizontal by nature. They serve the broad middle. If your product serves a narrow, specific segment with needs the platform will never address natively (because the segment is too small to justify the platform's engineering investment), you have a position that absorption does not threaten easily. Owning the customer relationship directly, rather than through the platform's marketplace, is another. But this is harder than it sounds, because the platform's distribution is often why you have customers. The hardest option, and the most durable, is building your own platform surface. Becoming the thing others build on, rather than the thing built on top. But that requires a different kind of company, a different kind of ambition, and a runway that most startups do not have. None of these options are easy. The structural reality is that building on a platform is a trade: distribution today for vulnerability tomorrow. Every point solution founder makes that trade knowingly or unknowingly. The chai shop in Kozhikode understood something that took the software industry decades to articulate. When you build your livelihood inside someone else's building, you are not just renting space. You are renting permission. And permission, by its nature, can be revoked. The question worth sitting with is not whether the platform will come for your market. It is what you will have built, independent of the platform, when it does.

Markets & Industry DynamicsAugust 13, 2024

Misaligned incentives make cross-functional teams structurally dysfunctional

Every team hit its target last quarter. The product still underperformed. If that sentence does not sound familiar, you have not been paying attention. Or you have been fortunate enough to work at organisations where the incentive architecture was designed by someone who understood systems rather than spreadsheets. Most of us have not been that fortunate. The conventional explanation for cross-functional dysfunction is communication. Teams do not talk enough. Teams do not share enough context. Teams do not align frequently enough. But I have spent twenty years watching product teams fail, and the communication explanation is almost never the real one. Teams communicate plenty. They share Slack channels, attend each other's standups, and sit through quarterly alignment presentations that nobody believes but everyone applauds. The real problem is simpler and harder to fix. The teams are measured on different things. And when teams are measured on different things, they optimise for different outcomes. Not because they are selfish. Because they are rational. The incentive structure is the strategy, whether anyone intended it to be or not. Act One: the illusion of performance At Freshworks, I watched a quarter unfold that taught me more about organisational design than any book ever has. Engineering shipped forty features. Forty. The engineering lead presented the number with earned pride. Deployment frequency was up. Release velocity had improved. The team was performing. But product was struggling to explain why none of those forty features had moved the commercial metrics. Activation was flat. Retention was flat. Expansion revenue had not budged. The features had shipped. They had not mattered. And then there was design. User satisfaction scores on the new features were strong. People who used the features liked them. But the features that scored highest on satisfaction were also the features with the lowest adoption. Design had optimised for delight on things almost nobody encountered. High satisfaction on features nobody used is a peculiar kind of success. I sat in the quarterly review watching three teams present three sets of metrics, all green. Every team had hit its number. The room felt good. But the product had not grown. Revenue had not moved. The user base was not healthier. Everyone succeeding was the clearest sign the system was broken. I call this the local success trap. It is the organisational condition where every function achieves its individual goals while the product, which exists at the intersection of all those functions, fails to improve. The problem is not that teams are underperforming. The problem is that performance is measured in dimensions that do not connect to outcomes that matter. Act Two: when the dashboards lie The local success trap is not a communication problem. It is a measurement problem. And measurement problems are incentive problems, because people do what they are measured on. Engineering is measured on deployment frequency, so engineering optimises for shipping. Design is measured on user satisfaction, so design optimises for the experience of the features that exist, regardless of whether those features are the right ones. Product is measured on feature delivery against the roadmap, so product optimises for checking boxes on a plan that may or may not be connected to business outcomes. Nobody is being irrational. Everyone is doing exactly what the system rewards them for doing. But the system rewards the wrong things. And because each team's metrics are green, nobody feels urgency to question whether the metrics themselves are the problem. But that is precisely the question that needs asking. At Boeing, I worked on an aviation fleet management product where this dynamic played out with consequences more serious than a flat quarter. Safety engineering, software engineering, and operations each operated with different success metrics. Safety cared about compliance scores. Software cared about uptime and release velocity. Operations cared about fleet utilisation rates. A software update went out that improved one metric visibly: the interface responded faster, release was smooth, uptime was unaffected. But the update had introduced a subtle change in how maintenance alerts were prioritised. Operations did not catch it because their utilisation numbers remained healthy. Safety did not catch it because compliance checks were still passing. Software certainly did not catch it, because by their measures the update was a clean win. Nobody discovered the problem until the client reported it. Their maintenance team had noticed that alerts for a specific category of inspection were appearing later than expected. Not dramatically later. Just enough to compress the response window in a way that made experienced operators uncomfortable. Every dashboard in our building showed green. The client's operations team, working with the actual aircraft, saw something different. That gap between what the metrics said and what the world showed is where the real damage happens. It is also where the local success trap is hardest to see, because the internal evidence says everything is fine. I call this second pattern the metric silo. It is what happens when each team's measurement system is designed to reflect that team's performance in isolation, without any mechanism to detect whether the combined output is coherent. Three runners on a relay team can each run a personal best and still lose the race. Not because they were slow. Because they were running in different directions. Act Three: redesigning what you measure The fix for the local success trap is not better communication. It is not more alignment meetings. It is not another quarterly review where every team presents its own metrics and everyone nods. The fix is redesigning the incentive architecture so that the metrics each team is held accountable for are connected to a shared outcome. But this is where it gets uncomfortable. Shared outcome metrics mean that engineering cannot celebrate deployment frequency if the features deployed did not move adoption. Design cannot celebrate satisfaction scores if the features scoring well are not the ones driving retention. Product cannot celebrate roadmap completion if the completed roadmap did not produce commercial results. Shared metrics create shared discomfort. And most organisations prefer distributed comfort to shared discomfort, which is why the local success trap persists even after everyone in the room has agreed it is a problem. The hardest conversation I have had in my career was not about a product decision. It was about telling a team lead that their team's metrics, the ones that showed strong performance, were not measuring anything that mattered. Not because the team was failing. Because the metrics had been chosen to be satisfiable. Green dashboards are not proof of health. They are proof that the metrics were chosen to be easy to satisfy. But here is what I have also learned. The teams that get this right, the ones that tie engineering, design, and product to a shared commercial or user outcome, are not just more effective. They are more honest. Because when everyone in the room is looking at the same number, there is nowhere to hide. No team can claim success while the product stagnates. No dashboard can be green while the user is struggling. But that honesty is expensive. It requires product leaders willing to be measured on outcomes they do not fully control. It requires engineering leaders who accept that shipping is not the finish line. It requires design leaders who care about whether the right thing was designed, not just whether the designed thing was liked. But most organisations will not do this. Not because they do not understand it, but because the local success trap is comfortable, and shared accountability is not. The product teams that build things worth using will always be the ones that chose the harder metric. Not the one that made the dashboard green. The one that told them the truth.

Product Teams & Org DynamicsJuly 20, 2024

Market timing re-emerged as the primary determinant of startup outcomes

The best product in a category rarely wins. This is one of those truths that everyone in the industry knows and almost nobody builds their strategy around. Founders talk about product quality the way athletes talk about training: as if it is the thing that determines the outcome. It is necessary. But it is not sufficient, and in many cases it is not even the primary variable. The variable that keeps showing up in every retrospective analysis of which AI-adjacent startups succeeded and which ones did not is timing. Not timing in the vague motivational sense. Not "strike while the iron is hot." Timing in the structural sense: where is the technology on its maturity curve, where is the infrastructure that supports adoption, and how wide is the window before the market consolidates? The market does not reward the best product. It rewards the right product at the right moment. The Early-Right Trap I know this because I lived it. My first startup was technically sound. We had identified a real problem, built a clean solution, and validated it with users who genuinely needed what we had made. The product worked. The engineering was solid. The design was, if I am honest, better than most things in our category at the time. We failed. Not because the product was wrong. Because the market was not ready. The infrastructure that would have made our product useful at scale did not exist yet. The behaviour patterns that would have driven adoption had not formed. The integrations that would have made us sticky were with platforms that had not yet reached the scale where our tool would matter. Three years later, a different company built a version of what we had built. Their product was, by most objective measures, worse than ours had been. Clunkier interface. Fewer features. Less technically elegant. But the market had shifted. Smartphone penetration had increased. The platforms we had tried to integrate with had matured. The user behaviour we had anticipated had finally arrived. They succeeded. We had already shut down. I call this the early-right trap. You were right about the problem. You were right about the solution. But you were wrong about when the market would care. And being right too early is structurally identical to being wrong. Your investors do not differentiate between the two. Your bank account does not differentiate. The company is gone, and someone else gets credit for the insight you had first. The early-right trap is particularly cruel because it punishes exactly the kind of founders the industry celebrates: the visionaries, the people who see around corners, who identify problems before anyone else does. Those founders are often too early. And too early, in market terms, means too dead. What Grab Taught Me About Infrastructure Timing At Grab, I saw the timing premium from the other direction. I watched features succeed not because they were brilliantly designed (some were, some were not) but because the infrastructure window had opened. Mobile payments in Southeast Asia followed a pattern that was invisible from the outside but obvious from within. The feature set we wanted to build was technically feasible years before it was practically adoptable. A mobile payment feature that would have failed in 2015, when smartphone penetration in parts of Indonesia and the Philippines was still low and trust in digital transactions was minimal, became the core of the product by 2018. The same feature. The same user need. But the infrastructure had caught up: cheaper smartphones, better mobile data, regulatory frameworks that permitted digital wallets, and a generation of users who had spent three years learning to trust their phones with money. The timing premium is the difference between a feature that works and a feature that gets adopted. Those are not the same thing. A feature can work perfectly in a demo and fail completely in a market where the preconditions for adoption do not yet exist. But the product leaders who understood this at Grab did not treat timing as luck. They treated it as a readable variable. They tracked infrastructure rollouts. They monitored smartphone sales data by region. They watched regulatory developments. They built features in advance and held them, waiting for the window to open rather than launching into a market that could not receive them yet. That discipline is one of the most undervalued capabilities in product strategy. Most founders cannot wait. The pressure to ship, to show progress, to demonstrate momentum to investors, makes patience feel like failure. But shipping into a market that is not ready is not momentum. It is waste. Why Product Quality Is a Losing Bet in Timing Markets Here is where the analysis gets uncomfortable for product-minded founders. In a stable market, product quality is the differentiating variable. Better design wins. Better performance wins. That is the world most product people were trained for. But AI-adjacent markets right now are not stable. They are moving through a technology maturity curve at a speed that makes product quality a secondary variable. The window between "too early" and "too late" is measured in months, not years. A startup that builds a superior AI-powered writing tool in January may find that by June the foundational model has been commoditised, the platform has built a native version, and three competitors have entered the category. Product quality did not save them. Timing did not favour them. The window closed. This is not an argument against building great products. It is an argument against believing product quality alone determines outcomes. In fast-moving markets, the timing premium overwhelms the quality premium. A good product at the right moment beats a great product at the wrong moment, every time. The founders succeeding in AI-adjacent categories right now share a common trait. It is not that they are better builders. It is that they read the window correctly. They shipped into readiness, not into ambition. The Readable Window Timing is not luck. That is the part most people get wrong. They treat market timing as something that happens to you, like weather. But timing is a readable variable if you know what to look at. Infrastructure maturity is the first signal. Is the underlying technology stable enough for mainstream adoption, or are you building on a surface that is still shifting weekly? Buyer behaviour is the second. Are potential customers already doing a manual version of what your product automates, or are you trying to create a behaviour that does not exist yet? Competitive density is the third. How many other companies have identified the same window? The early-right trap catches founders who read the first signal correctly (yes, this technology will matter) but ignore the second and third (buyers are not ready, and fifteen other companies saw the same opportunity). Reading one signal is insight. Reading all three is timing. But most founders do not read the window because they are in love with the product. The product is the thing they can control. The market is the thing that controls them. And most people would rather work on what they can control, even when it is not the variable that determines survival. I think about my first startup often. Not with regret, exactly. With the clarity that comes from watching someone else succeed with your idea at the right moment. The problem we identified was real. The solution we built was good. But the window was closed, and we did not know how to read it. The founders I respect most are not the ones with the best products. They are the ones who understood that the product is only one variable in an equation where timing carries the heavier coefficient.

Markets & Industry DynamicsJuly 17, 2024

PLG didn't fail you. You adopted someone else's conditions.

For most of the history of SaaS, the path to revenue ran through a human being. Someone had to run the demo. Someone had to handle the procurement conversation. Someone had to be on the other end of the phone when the enterprise buyer had a question at eleven in the morning on a Tuesday. Growth was a people problem. You hired your way to it. Every day, sales teams across the industry did the same thing. They qualified leads, managed pipelines, and personally guided buyers from interest to contract. It was expensive, it was slow, and it was the only model most companies knew. Until a handful of companies proved it didn't have to be. Slack. Dropbox. Figma. Notion. The list became a canon. Products that grew without a sales team. Users who signed up, found value, invited colleagues, and converted to paid without ever speaking to a human. The product did the growing. The numbers were real. The case studies were detailed and convincing. Because of that, product-led growth became the defining growth strategy of the early 2020s. Conference talks. Frameworks. Playbooks. Entire consultancies built around helping teams make the transition. The logic was simple: if it worked for them, it can work for us. The model was sound. The results were documented. Why would you keep paying sales reps when the product could do it better? Because of that, teams across the industry rewrote their growth strategy. Free tiers appeared on pricing pages that had never had them. Onboarding flows were redesigned for self-serve. Sales teams were reduced or repositioned. Product teams were handed growth metrics they'd never owned before and told to build toward them. Until finally, the results started coming in. And they weren't what the case studies had suggested. I've sat with four different product teams this year who adopted PLG between eighteen months and two years ago. All four are having the same conversation, just in different rooms. The numbers are moving, but not fast enough. The free tier is attracting users who aren't converting. The self-serve onboarding that looked clean in testing is producing a dropout rate nobody predicted. The viral loop that worked so visibly at Slack, where a user invites a colleague and the colleague invites a team, isn't firing. The teams are all asking the same question: what are we doing wrong. But that's not quite the right question. There's a version of franchising that works and a version that doesn't, and the difference is almost never about execution. The version that works starts with a restaurant that has something genuinely replicable at its core: a recipe, a process, a supply chain that can be reproduced across locations without losing what made the original worth copying. The franchise model scales the replicable parts. The original restaurant's specific chef, its neighbourhood regulars, the particular energy of a room that took five years to build: those don't franchise. They were never meant to. The version that doesn't work starts with a restaurant that was successful for reasons that are specific, local, and deeply tied to conditions that can't be transferred. The food is good. The model looks scalable from the outside. But what made it work was never in the recipe. PLG adoption followed the same logic at scale. Teams looked at Slack and saw a product that grew virally and concluded: viral growth is the output of PLG. Implement PLG, get viral growth. But viral growth wasn't the output of PLG at Slack. It was the output of a product where the core value was inherently collaborative, where using it alone was noticeably worse than using it with others, and where inviting a colleague was a natural step in getting value rather than a growth tactic bolted onto an existing workflow. That's a structural condition. Not a playbook. Dropbox grew because sharing a file was a built-in use case, and every shared file was an advertisement. Figma grew because design feedback required the reviewer to be inside the product. The viral loop wasn't engineered on top of these products. It was baked into the reason they existed. Most products don't have that. And most PLG playbooks don't mention it. The structural conditions that made PLG work at its canonical examples are specific enough that they're worth naming directly. The product has to be genuinely better with more people in it. Not marginally better. Noticeably, immediately better in a way the user feels in the first session. The free tier has to create real value, not a preview of value. A free tier that gives users enough to understand what they're missing is a trial. A free tier that gives users enough to solve a real problem is a growth engine. They behave completely differently. And the upgrade moment has to be a natural consequence of the user succeeding, not a gate placed in front of their progress. When a Notion user hits the block limit, they've already built something they don't want to lose. The conversion is a protection decision, not a purchase decision. Those are different psychological states and they produce different conversion rates. Most products asking users to upgrade are asking them to make a purchase decision before the user has a reason to care. And then wondering why the conversion rate looks the way it does. This isn't an argument against PLG. It's an argument for reading the case studies more carefully than the industry has been. The companies that proved PLG were not proving that any product can grow without a sales team. They were proving that products with specific structural characteristics, natural collaboration, inherent virality, and a free tier that solves rather than teases, can grow without a sales team. That's a narrower claim. And it's the claim that got lost somewhere between the conference talk and the roadmap rewrite. The teams I've worked with who are struggling with their PLG numbers are not failing at execution. They are succeeding at implementing a motion their product was never built to support. The honest question isn't what are we doing wrong. It's whether the conditions that made this work elsewhere were ever present here. And if they weren't, whether the product can be reshaped until they are, or whether a different growth model fits the actual structure of what was built. That question is harder to ask after eighteen months of investment in the wrong direction. But it's the right question. And the teams asking it now are already ahead of the ones who are still optimising the onboarding flow.

Product StrategyJuly 13, 2024

Building in public as a career infrastructure strategy, not just content marketing

The best product people I have met over twenty years have something in common, and it is not a prestigious company on their resume. It is that almost nobody outside their company has any idea how good they are. They spent two decades shipping products, leading teams, making the kinds of decisions that kept businesses alive, and they did it all inside buildings where the walls absorbed every ounce of that reputation. The work was real. The visibility was not. I know this because I was one of them. The visibility deficit I spent years building products at Boeing, Adobe, Nike, and Freshworks. At Boeing, I redesigned interfaces for aviation crews who wore gloves in cockpits. At Adobe, I worked on enterprise design problems that touched millions of users. At Nike, I was close to how consumer retail products were built at scale. At Freshworks, I watched a SaaS company grow from startup energy into enterprise ambition. All of it was meaningful work. All of it lived behind corporate walls. When I left that world and moved to Wayanad to work independently, I discovered something uncomfortable. Almost nobody outside those companies knew my name. I had two decades of credentials and zero public signal. My resume listed the logos, sure. But the market does not hire logos. It hires people it already trusts, people whose thinking it has encountered before, people whose perspective it has tested against its own judgment before the first conversation even happens. That gap between what you have done and what the market knows you have done is what I call the visibility deficit. It is the most expensive career problem that nobody talks about, because it only reveals itself at the worst possible moment: when you need the market to know you, and it does not. Your best work is invisible to the market unless you make it visible yourself. When the deficit comes due A senior PM I know, someone with fifteen years of exceptional work at well-known companies, was laid off last year. She had led product strategy for teams of forty. She had shipped features used by millions. Her internal performance reviews were outstanding every single cycle. None of that mattered the day her access badge stopped working. She spent three months applying for roles through the usual channels. Tailored resumes. Cover letters. Recruiter calls. The conversion rate was brutal. Not because she lacked the skills. Because the market had no independent evidence she possessed them. Her track record was locked inside companies that had already moved on. But then she tried something different. She started writing on LinkedIn. Not performative thought leadership with stock photos. Just clear, specific observations from her fifteen years of product work. How she had handled a pricing decision that went wrong. What she learned about stakeholder management when three VPs disagreed on a roadmap. The framework she used to prioritise when everything felt urgent. Within six months, she had more inbound opportunities than three months of applications had produced. People she had never met were reaching out with specific questions about her thinking. Hiring managers were citing her posts in initial conversations. She told me she felt like she had been professionally invisible for fifteen years and then suddenly became visible in six months. The visibility deficit had accumulated silently for her entire career. But writing in public paid it down faster than she had thought possible. A public body of work compounds in ways that a private track record cannot. Career infrastructure, not content There is a distinction I want to draw carefully here. Building in public is not content marketing. Content marketing serves a product or a business. Career infrastructure serves you. It is the accumulated body of evidence that tells the market who you are, how you think, and why your perspective is worth paying attention to, all before anyone opens your resume. I did not understand this when I started writing from Wayanad. I thought I was sharing ideas because I found the act of writing clarifying, which it was. But what I did not realise was that every article, every observation, every honest account of something I had got wrong was building a structure that would outlast any individual role or project. People I had never met started referencing my thinking in their own conversations. Consulting requests arrived from strangers who had read three or four pieces and decided they trusted my judgment. The career infrastructure was being assembled in public, one post at a time, without me having a strategy for it. But here is the part that surprises people: the writing itself made me better at the work. Explaining your product thinking to a public audience forces a precision that internal documents do not require. When you write for colleagues, you can rely on shared context. When you write for strangers, every assumption needs to earn its place. The act of building in public is not separate from the act of building your craft. They are the same activity viewed from different angles. Why product people resist it Most product professionals I talk to understand this argument intellectually. But they do not act on it. The reasons are predictable. Some believe the work should speak for itself. It should. But it cannot speak if nobody can hear it. Some worry about sharing ideas that their employer might consider proprietary. This is a legitimate concern, and the answer is simple. Do not write about your company's strategy. Write about your own thinking. There is a difference between revealing a roadmap and sharing a framework for how you prioritise. Some feel the whole exercise is narcissistic. I understand that instinct. But there is nothing narcissistic about making your professional thinking accessible to people who might benefit from it. The discomfort is a leftover from corporate cultures that treated visibility as vanity and silence as professionalism. But the most common reason is simpler than any of those. They are too busy doing the work to talk about the work. I was that person for twenty years. It cost me a decade of career infrastructure I can never get back. The compound curve Career infrastructure compounds. It does not grow linearly. The first ten posts feel like shouting into a void. The thirtieth post reaches someone who shares it with someone who hires you for a project you would never have found through applications. The fiftieth post becomes a reference point in a conversation at a company you have never heard of. The visibility deficit shrinks, and then it reverses. You stop searching for opportunities. Opportunities start searching for you. But the compound curve only works if you start. And starting feels pointless, because the early returns are almost invisible. This is exactly why so few product people do it. The payoff is delayed, and the discomfort is immediate. Writing a post about your thinking and watching it get twelve views feels like a waste of time. It is not. It is the first deposit into an account that will pay interest for the rest of your career. I spent twenty years building products inside companies where the work was real and the reputation was trapped. Starting to write publicly from a small town in Kerala changed the trajectory of my career more than any single role, promotion, or credential ever did. Not because the writing was brilliant. Because it was visible. The things you build inside a company belong to the company. The thinking you share in public belongs to you. That difference matters more the longer your career runs.

Product Leadership & CareerJuly 12, 2024

Real validation means money in the bank, not sign-ups on a waitlist

The founders with the most enthusiastic early feedback often have the weakest products. That sentence sounds wrong. It should be wrong. But I have watched it play out enough times that I no longer treat it as a paradox. I treat it as a pattern. Enthusiasm is cheap to give. It costs nothing to tell a founder their idea is brilliant. It costs nothing to fill in a survey saying you would pay for a product that does not exist yet. It costs nothing to type your email into a waitlist form. But that frictionless generosity is precisely what makes these signals worthless as predictors of actual demand. The validation theatre begins the moment a founder mistakes politeness for purchase intent. What my first startup taught me about false signals At my first startup, we built a project management tool for freelance designers. The idea came from my own frustration, which felt like a good sign. The early conversations were better than good. They were intoxicating. Every designer I spoke to nodded along. "I need this." "I would definitely pay for this." "When can I get access?" We built a waitlist. Within six weeks, we had four hundred names on it. We celebrated. We hired a second developer. We expanded the feature set beyond our original scope because, with this much apparent demand, we figured we should build something more complete. More complete meant more expensive, but the waitlist kept growing, and every new sign-up felt like a vote of confidence. Then we launched. We sent the email to all four hundred people on the waitlist with a monthly subscription price attached. Eleven converted. Not eleven percent. Eleven people. Out of four hundred who had said, in one form or another, "I would definitely use this." The gap between "I would definitely use this" and "here is my credit card number" turned out to be an ocean. And we had built an entire company on the assumption that it was a puddle. A waitlist is not validation. It is a list of people who were polite enough to give you their email address. We spent weeks trying to figure out what went wrong. But the answer was simpler and more uncomfortable than any diagnosis we considered. The product was fine. The validation was fake. We had validated against a question that cost nothing to answer, then acted as though the answer predicted whether people would spend real money on a recurring basis. The validation theatre I call this the validation theatre. It is the collection of activities that look like validation, feel like progress, and produce data that resembles evidence, but predict almost nothing about whether anyone will pay. Waitlists are the most visible form. But surveys run a close second. You ask a hundred potential users whether they would pay for a solution to a specific problem. Seventy say yes. The founder reads that as 70% demand. But the question "Would you pay for X?" and the act of actually paying for X occupy entirely different psychological spaces. In a survey, you are reacting to a hypothetical with zero consequences. When the payment screen appears, the consequences arrive. The psychology shifts completely. The validation theatre persists because it protects founders from the one thing they most need to experience: rejection. A waitlist cannot say no to your face. A survey respondent who ticks "yes, I would pay" has not rejected you. But a potential customer who looks at your price and walks away has given you something far more valuable than encouragement. They have given you information. The transaction test A founder I was mentoring earlier this year took the opposite approach, and it changed how I talk about validation entirely. She was building a scheduling tool for independent physiotherapists. Narrow market. Specific pain point. The temptation to build a waitlist was strong. Everyone she spoke to was enthusiastic. But she did something different. Instead of asking them to sign up for a waitlist, she asked them to pay. Before a single line of code was written, she contacted fifteen clinic owners and said: "I am building this tool. It will cost one hundred and fifty pounds a month. If you pay for the first three months now, I will build it to your specifications and you will shape what it becomes." Fifteen conversations. Fifteen chances for the validation theatre to collapse into reality. Eleven said no. That information was gold. Four said yes and transferred the money within two weeks. I call this the transaction test. The difference between "would you pay?" and "did you pay?" is the entire difference between the validation theatre and real validation. The transaction test does not ask people to predict their future behaviour. It asks them to demonstrate their current commitment. Those are different things. But here is what made the transaction test even more valuable than the money itself. Because those four clinic owners had paid in advance, they became genuinely invested in the outcome. They gave detailed, specific feedback. They tested early versions with a rigour that no free beta user ever matches. They told her what was missing, what was unnecessary, and what would make them stay past the initial three months. The payment was not just validation. It was a filter for the kind of customer who produces a good product through honest collaboration. The only feedback that matters is the kind that comes with a receipt. Why asking for money feels wrong (and is not) Most founders resist the transaction test because it feels presumptuous. You are asking someone to pay for a product that does not exist yet. It feels like you are exploiting trust. It feels pushy. But it is the opposite of pushy. It is respectful. You are respecting the customer's time by asking them to be honest about whether this problem is worth solving with their money, not just their words. And you are respecting your own time by refusing to spend months building something validated by nothing more than polite encouragement. But the discomfort is real. Asking for money requires you to believe that what you are building is worth paying for before you can prove it. That is a psychological leap most founders are not prepared for. At Boeing, at Adobe, at Freshworks, the product was always finished before anyone saw a price tag. Selling an unfinished thing felt like professional malpractice. It is not malpractice. It is the most honest conversation a founder can have with the market. My physiotherapy scheduling founder shipped her first version in eight weeks. It was not polished. It was not feature-complete. But it solved the exact problem her four paying customers had described, because they had described it with the specificity that only comes from having spent real money. She did not need to guess what they wanted. They told her, because they had a financial stake in the answer being useful. The founder who builds for four hundred curious email addresses builds a product shaped by assumptions. The founder who builds for four paying customers builds a product shaped by commitment. But the transaction test does not just produce better products. It produces better founders. The discipline of asking for money before you build teaches you to separate signal from noise in every conversation, every meeting, every piece of feedback you receive. You stop hearing what you want to hear. You start hearing what people are willing to pay for. That shift in listening is worth more than any accelerator programme or advisory board. One of those products still exists. The other one taught me everything I know about the distance between enthusiasm and commitment.

Building & FoundingJuly 11, 2024

The Scoreboard problem

Slot machines are one of the most carefully designed objects in the world. The button placement, the near-miss frequency, the sound design, the variable reward intervals: all of it is the product of decades of iterative research into human psychology. The people who build slot machines are not guessing. They are applying a precise understanding of how attention and reward interact to produce a specific behaviour: continued play. Nobody calls slot machine designers evil. The design is legal. The intentions behind it are transparent, at least internally. And the industry that produces them is regulated, studied, and widely understood to be engineered for compulsion. What is harder to explain is why that same logic, applied to a subscription cancellation flow or a cookie consent banner, gets discussed as if it were a craft problem rather than a choice. Dark patterns have been in the design conversation for years. The term has been around since 2010. But something shifted in the past twelve months. The UX community stopped treating deceptive design as a fringe concern and started naming it as a mainstream practice. The State of UX this year did not dance around it. Teams are building friction into cancellation flows, obscuring pricing tiers, and using pre-checked consent boxes not because they misunderstood good design, but because those choices move conversion metrics. That is the part of this conversation that most design discourse still avoids directly. Dark patterns are not a design failure. They are a measurement success. They work exactly as intended, on the metrics the team was optimising for. But the metrics were wrong, and the team either didn't know or didn't say so. That is the distinction most design discourse still avoids. I was part of a product review early in my career where a conversion optimisation team presented results from a redesigned checkout flow. The numbers were strong. Completion rate was up. Drop-off at the final step was down. The room responded the way rooms respond to good numbers: with approval and a discussion of what to test next. One designer on the team raised her hand and asked what had happened to refund requests. Nobody in the room had that number. It turned out refund requests had gone up sharply. Users were completing the purchase flow at a higher rate. But a significant portion of them felt they had been misled about what they were purchasing. They completed the transaction and then immediately tried to undo it. The conversion metric looked like a win. The refund rate told a different story. The checkout flow had been optimised for the wrong event. This is the scoreboard problem. Not that designers are malicious. But that they are designing toward the metrics they are given, and the metrics they are given are often proxies for value rather than value itself. Clicks are not engagement. Completion is not satisfaction. Conversion is not retention. When the scoreboard only shows the first number, that is what the team optimises for. And when a dark pattern moves the first number, it looks like good design work inside an organisation that is not looking at the second number. The design community's conversation about dark patterns tends to frame this as an ethics problem. Which it is. But framing it only as ethics puts the burden on individual designers to resist commercial pressure, which is both unfair and practically ineffective. Individual conscience is a poor substitute for a better scoreboard. The designers I have watched push back successfully on deceptive UX patterns did not do it by invoking ethics. They did it by expanding the measurement frame. They brought the second number into the room. They did it by expanding the measurement frame. They brought the second number into the room. Refund rates. Churn at 30 days. Support ticket volume. App store reviews mentioning confusion or frustration. When you put the second number next to the first one, the dark pattern stops looking like a win. It starts looking like a short-term conversion trade against long-term trust. And that is a business argument, not a values argument. Which means it can be heard by people who are not yet willing to be moved by the values argument. This is not cynicism. But it is strategy. You use the language that opens the door. The slot machine designers are not in the dark about what they are building. But they have a regulatory framework that sets limits on how far the compulsion can go. Product teams designing consumer software have no equivalent constraint, which puts the work of limit-setting inside the organisation itself. That is a structural problem. But until it gets solved structurally, the most useful thing a designer can do is make the second number visible. The scoreboard cannot be fixed from outside the room. But it can be changed by the people already in it.

Product Design & Craft TopicsJuly 1, 2024

The product team's responsibility for revenue

Most product teams have never read a P&L statement. They can tell you about activation rates, task completion times, NPS trends, and sprint velocity. But ask them what their product contributed to revenue last quarter, and you will get a pause. Then a redirect. Then something about how revenue is really a sales and marketing question. It has been a sales and marketing question for a long time. That is changing. The comfortable distance For years, product teams operated with implicit permission to stay upstream of money. Build the thing. Ship the thing. Measure whether people liked the thing. Then hand it to someone else to figure out whether the thing made money. Designers design. Engineers build. Product managers prioritise. Sales sells. Revenue belongs to the people whose bonus depends on it. But that arrangement only works when the company can afford the gap between what product builds and what the business needs commercially. Fewer companies can afford that gap now. I call this the accountability shift. The moment when product teams move from being measured on outputs (did you ship it?) and satisfaction (did users like it?) to being measured on outcomes (did it make money?). It sounds like a subtle change in language. It is a structural change in identity. At Adobe, I lived inside the comfortable distance for longer than I should have. The enterprise product team I was part of operated in a protected space. We had user research budgets, design sprints, and organisational respect. Our satisfaction scores were strong. But we had almost no visibility into how the product actually performed commercially. Revenue conversations happened in different rooms, with different people, using different language. Nobody walked into our sprint review and said: this feature you shipped last quarter, here is what it contributed to the bottom line. Then a reorg changed everything. Product leads were suddenly expected to sit in quarterly business reviews, to present not just what they shipped but what it earned. The first time I sat in one of those reviews and watched a product lead struggle to explain why a feature that scored brilliantly in usability testing had produced no measurable lift in expansion revenue, I understood something I had been avoiding. We had been building for users without understanding the business those users sat inside. That is the most expensive form of empathy a product team can practise. The chef who sees the bill Think of a chef who has spent fifteen years perfecting her craft. Sourcing the best ingredients, refining techniques, earning praise from critics and diners. But she has never once looked at the restaurant's finances. She does not know the margin on her signature dish. She does not know that the appetiser she considers beneath her accounts for forty percent of the profit, or that the tasting menu she spent six months developing costs more to prepare than customers will ever pay. Now imagine someone hands her the keys and says: run the restaurant. That is roughly what is happening to product teams across the industry right now. The GM model, where product leaders are expected to operate like general managers who own the full commercial picture, is moving from a concept people discuss at conferences to an expectation written into job descriptions. But most product leaders were trained as chefs. They know craft. They know users. They know quality. They were never trained to read the bill. The moment the question changed At Freshworks, I watched the question change in real time. For years, the metric that mattered after a release was adoption. Did users engage with the new feature? Did support tickets go down? Did the satisfaction score hold? These were reasonable questions. They were also insufficient ones. But the shift did not arrive as a grand strategic announcement. It arrived as a single question in a product review that nobody had asked before: did it move the number? Not the NPS number. Not the adoption number. The revenue number. The room handled it the way rooms always handle uncomfortable questions. People looked at their laptops. Someone offered a vague answer about indirect impact. The product lead talked about long-term value creation, which is what product people say when they do not have a short-term answer. But the question did not go away. It came back the next month, and the month after that. And slowly, the team started building differently. Not worse. Differently. Features started getting evaluated not just on whether users would adopt them, but on whether they sat in a part of the product that connected to expansion, retention, or conversion. The team started caring about packaging, about where features landed in the pricing tier, about whether a capability would pull a customer from a free plan to a paid one or from a mid-tier to an enterprise contract. I watched a designer on that team, someone whose instincts were impeccable, struggle with this for weeks. She kept saying: I did not get into product design to think about pricing tiers. And she was right. She didn't. But the product she was designing existed inside a business, and the business needed her to understand that the best feature in the world is worthless if it lives in a tier nobody pays for. Product teams that don't understand revenue don't understand their product. They understand the experience. They understand the user. But they don't understand the thing that determines whether the experience and the user continue to exist next year. The GM instinct The shift I am describing is not about turning product people into salespeople. It is about developing what I call the GM instinct: the ability to hold craft and commerce in your head at the same time. The GM instinct means knowing that the most important product metric is the one that appears on the P&L. Not because revenue is more important than user experience. But because revenue is the condition that allows user experience to continue. A product that delights users and loses money is a hobby. Most of us are building businesses, whether we talk about it that way or not. But this instinct does not come naturally to people trained in user-centred design, and it should not. The discomfort product people feel when asked to think about revenue is healthy. The danger is not caring about revenue. The danger is caring about revenue to the exclusion of everything else, which is what sales-led organisations already do. The product team is the only group in most organisations that can see both the user's problem and the business model simultaneously. Sales sees the deal. Marketing sees the funnel. Finance sees the spreadsheet. Product sees the moment where a person encounters a feature and decides whether it is worth paying for. That intersection is where revenue actually lives. Not in the contract. In the product. When the kitchen runs the restaurant The accountability shift is uncomfortable. It should be. Product people who resist revenue accountability are not wrong to feel uneasy. They are protecting something valuable: the instinct to build for the person using the product, not just the person paying for it. But the best product leaders I have worked with hold both. They care about the craft and they read the P&L. They build beautiful things that also keep the lights on. There is a version of the chef story that ends well. She takes the keys. She learns the numbers. She discovers that the appetiser she dismissed is the dish that funds the kitchen. She does not stop caring about the tasting menu. She just learns to care about the restaurant too. That is not a compromise. That is the whole job.

The Business of ProductsJune 29, 2024

The VC treadmill vs. the bootstrapped path: Founders recalibrating what winning looks like

Somewhere along the way, raising venture capital stopped being a funding decision and became an identity marker. The founder who had raised was serious. The founder who had not was still figuring things out. The raise was the starting line. Everything before it was preparation. That framing was always a distortion. But it took a long time for enough founders to say so out loud. The raise-or-fail assumption For most of the last decade, the default script for a new founder went something like this. Have an idea. Build a pitch deck. Find warm introductions. Get into a room with a partner at a fund. Convince them you are building something that will be worth ten times what they put in. Repeat until someone says yes. Capital is a tool. Most founders treat it as a trophy. I know this because I did it myself. At my first startup, I spent four months building pitch decks. Four months. Not four months building the product, not four months talking to users, not four months testing whether anyone would pay for what we were making. Four months crafting a narrative for investors who, in hindsight, were never the right audience for our energy at that stage. But the pitch deck work felt productive. It felt like progress. Every meeting with a potential investor felt like a step forward, even when the answer was no. The raise-or-fail assumption had lodged itself so deeply in my thinking that I could not distinguish between building a company and performing the act of building a company for an audience of venture capitalists. The distortion was subtle and total. Every product decision ran through a filter: will this make the next fundraising round easier? Not: will this make a customer's life better? Not: will this generate revenue? The filter was always the raise. And the raise was always six months away. What the maths actually looks like The standard venture model works beautifully for a small number of companies. For the rest, it is a treadmill that accelerates until someone falls off. Here is the arithmetic that most founders do not confront until it is too late. A typical seed round dilutes the founder by 15 to 25 percent. A Series A takes another 15 to 20 percent. By the time a founder has raised two rounds, they own somewhere between 55 and 70 percent of their company, often less. But the valuation expectations attached to those rounds mean the company now needs to grow at a pace that justifies the capital, not at a pace that makes sense for the product or the market. The treadmill starts here. Growth targets set by the fundraise, not by the business, begin dictating hiring, spending, and strategic choices. The founder is no longer building a company. The founder is servicing a capital structure. But there is a quieter story that rarely makes the tech press. The bootstrapped founder who builds a profitable company with a small team, owns 100 percent of it, and earns more over ten years than most venture-backed founders ever see from an exit. That story is boring. It does not produce splashy headlines or conference keynotes. But it produces something that venture-funded founders often cannot access: the ability to make decisions without asking permission. I call this the optionality premium. The value of being able to say no to things that venture-backed founders cannot refuse. Two founders, two paths A few years ago, I was advising a founder in India who was building a workflow tool for small accounting firms. Niche market. Specific problem. Four-person team, including himself. He reached profitability within fourteen months. Not massive profitability, but enough that the company sustained itself, paid reasonable salaries, and gave him the space to iterate on the product without external pressure. Around the same time, a VC-backed competitor entered the same market. Thirty people. A sleek website. A presence at three industry conferences. Aggressive pricing designed to capture market share before worrying about margins. Within eighteen months, the funded competitor had burned through its seed round and most of its Series A. The team had grown to a size where coordination consumed more energy than building. The product had been stretched to serve multiple segments because the growth targets demanded a larger addressable market than small accounting firms could provide. They pivoted twice, neither pivot informed by genuine customer need but by the requirement to show a growth trajectory that justified the next raise. They shut down. The bootstrapped founder is still running his company. Still four people. Still profitable. Still iterating on a product that his customers like because he has spent three years listening to them instead of three years preparing for board meetings. Nobody wrote a case study about him. But he is winning by every metric that actually matters to a founder: autonomy, sustainability, manageable stress, and the compounding value of a product that improves slowly and deliberately. The optionality premium in practice The optionality premium is not abstract. It shows up in specific, daily decisions. A bootstrapped founder can say no to a feature request from a large potential customer whose requirements would distort the product for everyone else. A venture-backed founder often cannot, because that customer represents the revenue growth the board expects. A bootstrapped founder can choose to stay small. A venture-backed founder has contractually agreed to pursue scale, whether or not scale serves the product. A bootstrapped founder can take a month to rethink the product direction after a significant insight. A venture-backed founder has a runway clock that makes that kind of pause feel irresponsible. But the optionality premium does not mean bootstrapping is always the right choice. Some products genuinely require significant upfront capital. Some markets have winner-take-most dynamics where speed matters more than profitability. Some founders are temperamentally suited to the intensity that venture capital creates. The point is not that one path is right. The point is that treating one path as the default and the other as the fallback has cost a generation of founders years of their lives. What winning actually looks like The question that has been shifting, quietly but persistently, is a simple one. What does winning actually mean for you? For some founders, winning is a billion-dollar exit and a name on a Forbes list. That is legitimate. But for many others, winning is something smaller and more personal. A profitable company that pays well, serves customers who are genuinely better off, and does not require the founder to sacrifice their health, their relationships, or their ability to think clearly. The raise-or-fail assumption made those founders feel like they were settling. It framed profitability without hypergrowth as a consolation prize. But a profitable company you own entirely is not a consolation prize. It is a different kind of success, and for many founders it is the better one. I wish I had understood that at my first startup. I wish someone had sat me down during those four months of pitch deck polishing and asked a simpler question: what if you just built the thing and charged people for it? The founders I know who are happiest, not the most celebrated but the most at peace with what they are building, are the ones who asked that question early. Some of them raised capital later, on their terms, from a position of strength. Some of them never raised at all. But all of them made the choice deliberately, which is the only version of that decision that does not leave you wondering, three years in, how you ended up on a treadmill you never consciously chose to step onto.

Building & FoundingJune 23, 2024

The narrative memo Is not a document format. It Is a thinking test.

In 1854, Florence Nightingale arrived at the British military hospital in Scutari and found conditions so terrible that more soldiers were dying from infection than from battlefield wounds. She collected the data. She understood the problem. But when she presented her findings to the War Office as written reports, nothing changed. The bureaucrats nodded and filed the papers. So Nightingale did something unusual for a nurse in the Victorian era. She invented a new kind of chart. The polar area diagram displayed mortality data in a visual format that made the crisis impossible to ignore. The format changed the outcome. Not because the data changed. Because the format forced the audience to actually see what the data was saying. Format shapes understanding. That principle is older than management science. But the product world keeps rediscovering it, usually the hard way. The Deck That Passed At Adobe, I sat through a product strategy review that should have been a warning. The deck was beautiful. Forty-two slides, clean typography, confident directional arrows connecting market opportunity to product capabilities to projected growth. The narrative, such as it was, flowed logically from one bullet point to the next. The SVP asked two questions, both answered with slides prepared in advance. The review passed. Three months later, the initiative was quietly restructured. Not because the market had changed or the technology failed. Because nobody had actually worked out how the product would reach the customers it was supposedly designed for. The go-to-market plan had been a single slide with three bullet points and an arrow labelled "distribution." It looked like an answer. It was not an answer. It was a placeholder dressed in a confident font. But here is what stayed with me. Nobody in that room had been dishonest. The deck format itself had hidden the gap. Bullet points with directional arrows create the appearance of logical connection without requiring the author to actually demonstrate one. You can place "Market Opportunity" on one slide and "Our Approach" on the next, draw an arrow between them, and the audience's brain fills in the causal logic. The deck performs clarity. But it does not produce it. I call this the clarity debt. It is the gap between what a team believes it has thought through and what it has actually thought through, and slide decks are the single most effective instrument for accumulating it without detection. The Memo That Broke The first time I encountered the narrative memo format, it was at Freshworks. A product lead had started requiring six-page written memos before any major product decision. No slides. No bullet points. No diagrams with confident arrows. Just prose. Structured, argued, written in complete sentences and paragraphs. The first round of memos was, to put it gently, revealing. Teams that had presented confident decks for months suddenly struggled to fill six pages of coherent argument. Not because they lacked data. Because they lacked clarity. A deck lets you gesture at a connection. A memo forces you to explain it. A deck lets you hide behind a phrase like "streamline the user journey." A memo requires you to describe what that actually means, step by step, in sentences that a reader can follow and challenge. One memo in particular stopped a project that was already three months into development. The product manager had written a solid deck that had passed two reviews. But when asked to write the same argument as a narrative, he could not connect the customer problem to the proposed solution in a way that survived six continuous pages of prose. The gap was not in his knowledge. He understood the domain deeply. The gap was in the logic underneath, and the deck format had allowed that gap to persist unchallenged. The team paused the project, reworked the strategy, and shipped something substantially different four months later. That something different actually worked. But the memo did not reveal a lazy team. It revealed a structural flaw in how the team communicated. The product manager told me afterwards that writing the memo was the hardest thing he had done in a year. Harder than the competitive analysis. Harder than the user research. Because the memo did not let him skip the parts he was uncertain about. The deck had. Every time. The Narrative Test The Amazon practice of replacing slide decks with six-page narrative memos has circulated widely enough that most product leaders have heard of it. But hearing about it and doing it are separated by a distance that few teams appreciate until they try. I call the practice the narrative test. Not because it tests writing ability. Because it tests thinking. Writing is thinking made visible, and a narrative memo is the most unforgiving mirror a product leader can hold up to their own reasoning. You cannot hide behind a transition slide. You cannot use a diagram to imply a connection you have not actually established. You have to write the sentence, make the claim, and then make the next claim follow from the first one. That is the insight most teams miss. The memo is not a better communication format. It is a better thinking format. The six pages are not the output. The six pages are the forcing function. If you cannot write it in prose, you do not yet understand it. But most organisations resist the narrative memo, and the resistance is instructive. Teams say it takes too long. They say it is inefficient. They say it slows down decision-making. But what they are actually saying, usually without realising it, is that they prefer the speed of decisions made on incomplete thinking. The deck is faster because it requires less rigour. That speed is not a feature. It is the source of the clarity debt that compounds until a project fails and everyone asks what went wrong. What went wrong was visible on slide seven. It just looked like an answer. Prose as Discipline I have started requiring narrative memos from founders I mentor. Not because I am an Amazon devotee. Because I have watched too many founders build pitch decks that obscure the questions they have not yet answered. A founder who can write six pages of clear prose explaining why their product should exist, who it is for, how it reaches them, and why now, has done the thinking. A founder who cannot has not, regardless of how polished the deck is. But I have also learned to be honest about the discomfort. Writing a narrative memo is genuinely difficult. It is slow. It is vulnerable. You cannot rehearse the transitions the way you rehearse a slide talk. The gaps in your reasoning sit exposed on the page, and there is no animation or confident voice to paper over them. That vulnerability is the point. The product leaders I have worked with who adopted narrative memos did not become better writers. But they became better thinkers. Because writing in prose, sentence after sentence, paragraph after paragraph, forces a kind of sequential honesty that no other format demands. Each sentence has to follow from the one before it. Each paragraph has to earn its place. The structure of prose is the structure of logic, and logic does not let you skip steps. Nightingale understood that the format of communication determines whether the truth inside it can be seen. The narrative memo is this generation's version of that insight, applied not to mortality data but to product strategy. The format is not the point. The thinking it forces is the point. And the teams willing to sit with that discomfort tend to be the ones whose strategies survive contact with the market.

Communication & Storytelling June 22, 2024

The saas growth model hit Its ceiling before AI agents arrived to finish it off

The company that defined SaaS growth for two decades just posted its worst trading day in twenty years. Salesforce dropped 20% after missing revenue expectations, and the commentary that followed was almost entirely about the wrong thing. Analysts pointed to AI competition. Pundits speculated about disruption. But the actual cause was quieter and more uncomfortable: the per-seat, land-and-expand model that powered the entire SaaS industry simply ran out of room. This is not a story about AI. Not yet. It is a story about what happens when a business model built on the assumption of infinite expansion encounters the reality that expansion has limits. The Expansion Illusion For twenty years, the SaaS growth formula was elegant and almost mechanical. Sell a small number of seats to a department. Prove value. Expand to adjacent teams. Grow the contract. Repeat across the organisation. The beauty of the model was that growth happened inside existing accounts, which meant acquisition costs dropped over time while revenue per customer climbed. Wall Street loved this. Investors loved this. Every SaaS company on earth modelled their financial projections around it. But the formula contained a hidden assumption that nobody examined too carefully. It assumed the expansion would never stop. More departments. More users. More seats. Always more. I call this the expansion illusion: the belief that because a model has been growing, it will continue to grow at the same rate. It is not a forecast. It is a wish dressed up as arithmetic. At Freshworks, I watched the expansion illusion play out in real time. The land-and-expand playbook worked brilliantly in the early years. We would sell to a customer service team, prove the value, then expand into sales, then marketing, then IT. Each expansion meant more seats, more revenue, more growth to report. The machine hummed. But then something started changing, and it was not dramatic enough to trigger alarms. Expansion within existing accounts slowed. Not collapsed. Slowed. The easy expansions had already happened. The departments that wanted the product already had it. Net revenue retention, the metric that Wall Street uses to judge whether a SaaS company is truly healthy, started declining. Not because customers were unhappy. But because there were simply fewer seats left to sell inside accounts we had already penetrated. The product was improving. Customer satisfaction was stable. But the growth engine was losing fuel, and no amount of product improvement could change the underlying maths. When every department that needs your product already has it, the question becomes: now what? The Seat Ceiling That "now what" is what Salesforce hit. Not in some future quarter. Not because of a competitor. Right now, because the per-seat model has a structural ceiling that twenty years of growth made invisible. The seat ceiling works like this. In a given enterprise category, there are a finite number of potential users. CRM, project management, design tools, communication platforms. Each category has a natural boundary defined by how many people in an organisation actually need the tool. Once a vendor has penetrated most of the addressable users within its existing accounts and captured a significant share of new accounts, the growth rate must slow. This is not failure. It is arithmetic. Salesforce's worst day was not a surprise. It was an arrival. The entire SaaS industry built its valuation framework on the assumption that growth rates from the expansion phase would persist indefinitely. When they did not, the market reacted as though something had broken. But nothing broke. The model simply reached its natural boundary. The growth was always going to slow. The only question was when. What AI Agents Actually Threaten Now here is where the AI story enters, and it is worse than most people realise. AI agents do not just compete with SaaS products for market share. They threaten the unit of pricing itself. The per-seat model charges for human access to software. But if an AI agent can perform the task that a human user previously performed inside the software, the seat disappears. Not because the customer switched to a competitor. Because the customer no longer needs a human doing that work at all. The seat is not lost to a rival product. It is lost to a category of work that no longer requires a person. This is not disruption in the classic sense. It is not one product replacing another. It is the evaporation of the unit that the entire pricing model depends on. But here is the critical point that the AI narrative obscures: the seat ceiling existed before AI agents arrived. The structural slowdown was already happening. AI agents are not causing the SaaS growth crisis. They are accelerating a decline that was already underway. They are arriving at a wall that was already built and knocking it over. A Different Model Was Already Visible At Grab, I saw a fundamentally different approach to pricing and growth. The model there was usage-based, scaling with actual value delivered rather than with the number of humans who had access. When activity increased, revenue increased. When it decreased, revenue decreased. The alignment between what the customer paid and what the customer received was direct and visible. The contrast with seat-based SaaS was stark and instructive. At Freshworks, we charged whether people logged in or not. At Grab, you only paid for what you used. One model rewarded the vendor for customer inertia. The other rewarded the vendor for customer activity. The incentive structures pointed in opposite directions. I spent years in both worlds, and the pattern was clear long before AI entered the conversation. The seat-based model was a brilliant vehicle for growth in an expanding market. But it was always going to become a constraint in a saturated one. The expansion illusion kept everyone focused on the upward trajectory without asking what happens when the curve flattens. The Ceiling Was Always There The SaaS growth model did not fail because something better arrived. It failed because the assumption underneath it, that there would always be more seats to sell, turned out to be finite. AI agents are making the ceiling more visible and more immediate. But the ceiling was there all along, built into the model's own logic, waiting for the market to mature enough to reveal it. Every business model has a lifecycle. The per-seat SaaS model had a spectacularly long and profitable one. But lifecycles end. Not with a dramatic disruption, usually. With a quiet deceleration that the numbers eventually make impossible to ignore. The companies that will matter in the next decade are not the ones defending the old model. They are the ones who noticed the ceiling forming before it became a headline. Most of them are already building something different.

Markets & Industry DynamicsJune 2, 2024

Barriers to entry collapsed across software categories, permanently raising the competitive intensity floor

The software companies that feel safest right now are, paradoxically, the most exposed. They built their competitive position on the assumption that what they had built was hard to replicate. Millions of lines of code. Years of accumulated integrations. Engineering teams numbering in the hundreds. The moat was complexity. Complexity just got cheaper. This is not a temporary disruption. It is a permanent change in the competitive floor beneath every software category. The Complexity Moat For most of the software industry's history, the barrier to entry was the cost of building. A competitive product required a large engineering team, months (often years) of development, significant infrastructure investment, and the institutional knowledge that accumulates slowly inside organisations that have shipped production software at scale. Small teams could prototype. But shipping a real product, one that handled edge cases, scaled under load, integrated with existing systems, and survived contact with actual enterprise buyers, required resources that most startups could not assemble. This was the complexity moat. Not a patent. Not a brand. Not a network effect. Just the sheer difficulty of building something that worked. And for a long time, it was enough. But "enough" had an expiry date that nobody checked. At Schneider Electric, I worked on an IoT thermostat product where the complexity moat was practically visible. The product required hardware design, firmware engineering, cloud infrastructure, a mobile application, and the integration layer that connected all four. Each component was challenging on its own. The combination was formidable. Small competitors would occasionally appear with a clever interface or a cheaper device. But they could not replicate the full stack. The integration complexity was the barrier, and it held for years. That barrier is dissolving now. AI coding tools and cloud platforms have made the integration work dramatically easier. What required a team of specialised firmware engineers, cloud architects, and mobile developers can increasingly be assembled by a smaller team using AI-assisted development in a fraction of the time. The complexity moat did not get breached by a smarter competitor. It got lowered by better tools available to everyone. The Eight-Week Competitor I advise a SaaS startup that demonstrated this shift in terms I found genuinely startling. Three founders. Eight weeks. A vertical CRM built to compete directly with an established player that had raised over forty million in funding and employed more than a hundred engineers. The product was not a toy. It handled the core workflows, integrated with the standard tools their target customers used, and looked polished enough that prospects in early demos did not ask whether it was "real." But the quality was not the surprising part. Two years ago, building the same product would have required a team of fifteen and at least six months. I know this because I have been in rooms where those resource estimates were made, and they were not inflated. The work genuinely took that long with conventional development approaches. The incumbent's response to learning about this new competitor was to cut prices. Which is always the last move before the moat drains entirely. Price cutting is what you do when you have no other differentiator. When your response to a new entrant is to make your product cheaper rather than better, you are announcing that the barrier was cost, not value. When the barrier to entry drops, the barrier to differentiation rises. The Competitive Floor Here is what most incumbents have not absorbed yet. The barrier collapse is not a one-time event. It is a permanent change in the structure of competition. The competitive floor, the minimum level of product quality and capability required to enter a category, has risen. But the competitive ceiling, what it takes to win, has risen even faster. I call this the competitive floor effect. Before the barrier collapse, the floor was low (anyone could build a prototype) and the distance between a prototype and a production product was enormous. That distance protected incumbents. But now the floor is much higher. A small team can build a production-quality product quickly. But the ceiling is also higher, because when everyone can build, building is no longer what differentiates you. The new differentiators are the things that AI tools cannot generate from a prompt. Domain expertise is one. Understanding the specific workflows, regulations, and pain points of a particular industry takes years of immersion. You cannot prompt your way to knowing that oil rig operators need buttons sized for gloved hands, or that hospital procurement cycles run on fiscal years that vary by state. I have spent twenty years across petroleum, aviation, SaaS, IoT, and consumer products, and the pattern is consistent: the teams that win are the ones that know something about their customers that cannot be found in a public dataset. Data is another. A startup can build a competitive product in eight weeks. But it cannot build eight years of customer usage data, behavioural patterns, and trained models in eight weeks. Proprietary data, accumulated through years of actual customer interactions, is a moat that gets stronger over time. But only if the company is actually using it. Plenty of incumbents are sitting on gold mines of data they have never properly analysed, which makes them vulnerable in an entirely different way. Distribution is the third. Building the product is now the easy part. Getting it in front of customers, earning their trust, integrating into their procurement processes, and building the relationships that enterprise sales require: none of that got easier because AI can write code faster. Distribution is still slow, expensive, and deeply human. But that is precisely what makes it defensible. The startup that builds in eight weeks still needs twelve months to build a sales pipeline. The Uncomfortable Implication The uncomfortable implication for every software company is this: if your competitive advantage was primarily the difficulty of building your product, that advantage is structurally weaker than it was twelve months ago. And it will be weaker still twelve months from now. This is not a reason to panic. It is a reason to be honest about what your actual moat is. At Schneider Electric, the real moat was never the firmware complexity. It was the relationships with HVAC distributors and the understanding of building management workflows that took years to develop. The complexity moat was the visible one. But the domain and distribution moat was the real one. The team spent most of its energy defending the complexity moat because it was easier to measure and easier to explain to executives. The companies that will maintain their competitive position are the ones that can answer a simple question: if a three-person team could replicate our product in eight weeks, what would they still not have? If the answer is "nothing," the competitive position is already gone. If the answer involves domain knowledge, proprietary data, distribution relationships, or customer trust, those are the assets worth investing in. The moat was complexity. Complexity just got cheaper. What remains is everything that was always harder to build than software. Some of it takes decades. That is the point.

Markets & Industry DynamicsMay 29, 2024

Peer validation over vendor narrative

The companies spending the most on marketing are often the ones whose marketing matters the least. That sounds like a provocation. It is an observation. Because the conversation that determines whether a buyer actually purchases your product is increasingly happening in rooms you are not invited to, on platforms you do not control, between people who have no obligation to say anything kind about you. Vendor websites still exist. They are polished. They are optimised. They say all the right things. But the buyer has already made up her mind before she visits yours. She made it on G2. She made it in a Slack community. She made it when a former colleague said: we use it, it works, the onboarding was painless. Or, more damagingly: we used it, it didn't, and the support team ghosted us. That second sentence does more commercial damage than a competitor's entire advertising budget. The narrative gap I call this the narrative gap. It is the distance between the story a company tells about its product and the story its users tell about it in public. Every product has one. The question is how wide yours is and whether you are honest enough to measure it. For most of the history of software sales, vendors controlled the narrative. You built a website. You published case studies. You hired analysts to write reports. You trained your salespeople to tell a specific story in a specific order. And buyers, lacking better options, relied on that narrative because it was the most available and most polished source of information. But that world is gone. Public review sites became the most consulted resource in software buying, overtaking vendor websites, analyst reports, and sales conversations. More than half of all buyers now consult existing product users before making a purchase decision. For enterprise deals, that number climbs to 71%. The people who use your product every day have become the most influential voices in your sales process, and you did not hire them, brief them, or approve their talking points. Your users are your most powerful marketing team. You cannot script them. The Freshworks lesson At Freshworks, I watched this shift happen with the specificity that only comes from sitting inside the numbers. For certain market segments, G2 and Capterra reviews were driving more qualified pipeline than the entire marketing budget combined. Not supplementing marketing. Outperforming it. The reviews were doing what millions of dollars of content, webinars, and event sponsorships could not: they were creating trust. But here is the part that most product teams do not want to hear. The reviews were not all positive. And the negative ones carried disproportionate weight. A single review from an enterprise customer describing a poor implementation experience cost the pipeline more than six months of carefully produced positive content. Six months of case studies, blog posts, webinar recordings, and sales enablement materials, all undermined by three paragraphs written by someone who had a bad week with the product. That was the moment I understood that marketing had become a downstream variable. The product experience was upstream. What happened between the user and the product on a Tuesday afternoon mattered more than what the brand said on a landing page on Wednesday morning. I call this the public courtroom. Every user interaction is a potential testimony. The courtroom is always in session. And the jury, your next buyer, is watching. You do not get to choose which testimonies they read. They find the ones that feel honest, and honest reviews tend to be the ones that include the problems alongside the praise. But the public courtroom is not hostile. It is fair. Products that genuinely work well accumulate genuine praise. The problem is that most product teams spend their energy managing the narrative instead of managing the experience. They respond to bad reviews with polished corporate language when they should be responding to bad experiences with actual product fixes. The courtroom does not care about your response to the review. It cares about whether the next user has the same experience. The Grab lesson This principle operates even more visibly outside Western markets. At Grab in Southeast Asia, I saw a market where formal marketing was almost irrelevant for two of the most critical acquisition channels: drivers and merchants. Drivers did not sign up because of an advertisement. They signed up because a cousin, a neighbour, a fellow driver at a coffee stall told them: I drive for Grab, the pay is reliable, the app works on my phone. That was the entire sales pitch. One human being telling another human being that it worked. But none of this showed up in the acquisition dashboards the way a paid campaign would. Merchant acquisition followed the same pattern. A stall owner in a hawker centre would see the neighbouring stall receiving Grab orders and ask how to join. No sales representative required. No marketing funnel. Just proximity, observation, and a question asked between two people who trusted each other. But here is what made it structurally interesting. When the product experience was strong, this word-of-mouth engine scaled faster than any paid channel could. When the experience faltered (a payment delay, an app crash during peak hours, a driver dispute handled poorly), the same network that distributed trust distributed distrust just as efficiently. The word-of-mouth channel had no off switch. It amplified whatever was true about the product, good or bad, without asking permission. Every product team that thinks it controls its own narrative should spend a week in a Southeast Asian market watching trust move through a community. It is humbling. And clarifying. What the vendor actually controls The honest answer is: less than you think. You do not control what users say on review sites. You do not control what buyers hear in private Slack channels or in conversations with former colleagues. You do not control the screenshot of a support interaction that gets shared in a procurement committee's email thread. But you do control the product. You control the experience a user has on a Wednesday afternoon when nothing is going wrong and nothing is going particularly right either. You control the moment when a customer contacts support and either feels heard or feels processed. You control the onboarding, the reliability, the small decisions that accumulate into a verdict your users will deliver publicly whether you are ready for it or not. The narrative gap does not close with better marketing. It closes with a better product. But a better product, in this context, does not mean more features or a shinier interface. It means an experience consistent enough that the story users tell each other matches the story you wish they would tell. But most teams are not structured to think this way. Marketing owns the narrative. Product owns the experience. And the gap between them is where trust goes to die. The teams that figure this out, the ones that treat every support ticket, every onboarding friction point, every broken workflow as a marketing problem, not just a product problem, are the ones whose reviews write themselves. Nobody in a procurement committee has ever said: I was convinced by the vendor's website. But people say, regularly and with conviction: I spoke to someone who uses it, and they said it was solid. That sentence, unscripted and uncontrolled, is worth more than every piece of content your marketing team will produce this quarter. The most valuable thing a product can build is not a feature. It is a reputation. And reputations are built in the space between what you promise and what your users experience. That space is public now. It has always been honest.

User & Buyer PsychologyMay 25, 2024

Collaboration drag: coordination costs more than the collaboration is worth

The most collaborative team I ever worked on was also the slowest. We had cross-functional representation from every discipline, a shared Slack channel, weekly syncs, bi-weekly reviews, and a quarterly alignment ritual that consumed an entire Thursday. On paper, we were the model. In practice, we shipped less than a two-person team working out of a Bangalore apartment with a whiteboard and a deadline. Nobody on that team was lazy. Nobody was incompetent. But the architecture of our collaboration had become the primary obstacle to our output. We were not working together. We were coordinating the appearance of working together. I call this collaboration drag. The cost of coordinating across functions exceeds the value the collaboration was meant to produce. Gartner reports 84% of leaders are experiencing it. Teams suffering from it are 37% less likely to hit revenue goals. That number should alarm people more than it does. The coordination tax There is a cost to every meeting, every alignment check, every status update, every shared document that requires six people to comment before anything moves. I call it the coordination tax. Like any tax, it is invisible until you calculate the total. At Adobe, I was part of an enterprise product team where every feature required sign-off from seven stakeholders spread across three time zones. The feature work itself was not complex. A senior designer and two engineers could have shipped it in two weeks. But the coordination required to align those seven stakeholders turned two weeks into three months. Not because the work was hard. Because getting everyone to agree on the work took longer than doing the work. We had coordination meetings to prepare for the coordination meetings. I am not exaggerating. There was a pre-alignment call before the alignment review, because the alignment review could not be productive unless everyone had already agreed on what would be discussed. The actual building happened in the cracks between these rituals. The product advanced in stolen hours, not scheduled ones. But here is the part that nobody in the room would say out loud. The seven stakeholders did not all need to be involved. Three of them had relevant expertise. The other four were included because the organisation's culture equated inclusion with respect. Excluding someone from a decision was read as a political signal, not an efficiency decision. So we included everyone and built nothing. The calendar was full. The product was empty. When consensus becomes the product At Freshworks, I sat through a sprint planning session that taught me something I have not forgotten. The team spent ninety minutes deciding what to build. Detailed discussion. Careful prioritisation. Thorough debate about scope and feasibility. By the time the session ended, everyone felt aligned. Everyone felt heard. But zero minutes had been spent building. The sprint had not started. The planning of the sprint had consumed the energy that was supposed to fuel it. I realised, sitting in that room, that the team was optimising for consensus, not progress. Consensus felt productive because it involved talking about the product, thinking about the product, and making decisions about the product. But consensus is not the product. The product is the product. And at some point, someone has to stop talking about what to build and actually build it. This is the trap most cross-functional teams fall into. The rituals of collaboration (the planning, the syncing, the aligning, the reviewing) become the work. The actual building becomes a secondary activity that happens after the collaboration requirements are met. But the collaboration requirements are never fully met, because every new decision creates a new coordination demand. Coordination is the work that disguises itself as collaboration. And it wears the disguise so well that most teams cannot tell the difference. The relay race problem Think of a relay race. Four runners. The goal is speed. But in most relay races, the baton handoff is where races are lost. Not because the runners are slow, but because the transition between runners introduces friction that running alone does not have. Now imagine a relay race where the baton handoff takes longer than the running. The runners stand around discussing who should receive the baton next, confirming the handoff protocol. By the time the baton moves, the other teams have finished. That is how most cross-functional product teams operate. The designers can design. The engineers can build. The product managers can prioritise. But the time spent coordinating between them dwarfs the time spent doing the actual work. The handoff has become the main event. But the handoff was never supposed to be the main event. It was supposed to be invisible. The best collaborations I have seen in twenty years of product work share one characteristic: you barely notice the coordination happening. It is lightweight, asynchronous, and trust-based. The moment coordination becomes heavy, synchronous, and consensus-driven, the team has crossed a line. Most teams do not notice because they are too busy in meetings to look up. What small looks like The smallest team I ever worked on shipped more in three months than the Adobe enterprise team shipped in a year. Not because the small team was better. Because there was nobody to coordinate with. Decisions happened in conversations, not committees. Alignment was implicit, because four people working in the same room on the same problem do not need a bi-weekly alignment review to stay aligned. They just stay aligned, the way a jazz trio stays in time without a conductor. But organisations do not trust small teams. Small teams feel risky. If the work is important, the logic goes, more people should be involved. More oversight. More review. More input. And every person added to the team adds coordination cost that grows not linearly but exponentially. A team of four has six communication pathways. A team of seven has twenty-one. A team of twelve has sixty-six. The maths is not subtle. But the org chart ignores it because headcount feels like commitment. I have watched this happen at four companies across three continents. The pattern does not change. The team starts small and fast. Leadership adds people because the project is important. The team slows down. Leadership assumes the problem is harder than expected and adds more people. The team slows down further. Nobody asks whether the team was faster when it was smaller, because that question implies that some of the people on the team should not be there. And that question is politically expensive in a way that adding another six weeks to the timeline is not. The honest question The question most product leaders need to ask, and most will not, is simple. How much of our collaboration is actually producing value, and how much is producing the feeling of value? If your team spends more time talking about the work than doing the work, that is not collaboration. That is theatre. Expensive, well-intentioned, calendar-filling theatre. But the answer is not to stop collaborating. The answer is to get honest about what collaboration actually requires, which is far less coordination than most organisations believe. The best collaboration I have ever experienced did not feel like collaboration at all. It felt like building. Two people, a shared understanding of the problem, a whiteboard, and the willingness to make a decision without asking permission from seven stakeholders in three time zones. No alignment meeting. No pre-alignment call. Just the work, and two people doing it. Somewhere between that moment and the enterprise coordination machine, most teams lose the thing they were trying to create. Not because they stopped caring about collaboration. Because they started caring too much about coordination. And they never noticed the difference.

Product Teams & Org DynamicsMay 23, 2024

The demand-supply gap for senior product leaders reached critical levels

In cricket, there is a concept called the genuine all-rounder. Not someone who bowls a bit and bats at number eight. A genuine all-rounder: someone who would make the team as a specialist in either discipline. Think Jacques Kallis or Ben Stokes. The cricket world produces perhaps three or four of them per generation. Thousands of professional cricketers play the game at any given time. But the ones who are genuinely elite at two fundamentally different skills can be counted on one hand. The product industry has an all-rounder problem of its own. And it is getting worse. The eleven-month search At Adobe, I watched a VP of Product search stretch across eleven months. Eleven months of recruiter calls, interview panels, case study presentations, and reference checks. The role was well-defined, the compensation was strong, and the company's reputation was not the issue. The issue was simpler and more stubborn than any of those things. The candidates with deep enterprise experience could run a product organisation. They knew how to manage stakeholders across business units, build roadmaps that satisfied twelve different internal constituencies, and operate within the gravitational pull of a large company's politics. But when the interview panel asked them to describe how they would approach a new product from scratch, their answers sounded like process documents. They would describe the infrastructure of building without ever describing the building itself. But the candidates with startup experience had the opposite problem. They could talk about building with an intensity that lit up the room. They had launched products from nothing, made decisions with incomplete data, and shipped on timelines that would give an enterprise PM a panic attack. But when the panel asked them how they would manage a product organisation of forty people across three time zones, their answers got vague. "I would hire great people and get out of their way" is a philosophy, not a plan. The gap between those two skill sets was the actual bottleneck. Not compensation. Not company brand. Not location. The market simply did not have enough people who had done both. They eventually filled the role. But the person they hired had to be convinced to leave a position they were happy in. The search cost, in recruiter fees, interview hours, and the eleven months the role sat empty, was staggering. The dual-context leader I have started calling this the dual-context leader: someone who has both zero-to-one experience and scale experience, and who can credibly operate in either mode. The dual-context leader is rare for structural reasons, not accidental ones. Think about how product careers actually develop. You either start at a startup or you start at a large company. If you start at a startup, you spend your formative years learning to build from nothing. You learn to make decisions with no data, ship with no process, and wear seven hats because there is nobody else to wear them. But if you start at a large company, you learn a completely different set of skills. You learn to build consensus across teams, manage dependencies, and influence without authority in organisations where authority is distributed across a dozen people who all think the product should go in a different direction. The problem is that each environment actively selects against the other skill set. Startups reward speed and autonomy. Large companies reward collaboration and process. The person who thrives in one environment often struggles in the other, not because they lack talent, but because their instincts are calibrated for a different game. Building from nothing and scaling within complexity are different sports played on different fields. The market wants someone who has won at both. The specialisation trap This creates what I think of as the specialisation trap. The longer you stay in one context, the more specialised your instincts become, and the less equipped you are to cross over. I have lived this tension in my own career. My early years were spent in startup environments, where building from zero was the only mode that existed. At my first startup, we did not have roadmaps. We had arguments at a whiteboard and a shared sense of urgency. The feedback loop was immediate: build something, ship it, watch users react, adjust. That speed became addictive. But then I moved into enterprise environments. At Boeing, the feedback loop was measured in months, sometimes years. The users were aircraft maintenance crews working in conditions I had never imagined until I visited a hangar. At Adobe, a single product decision could ripple across teams I had never met. The skills I needed were patience, political awareness, and the ability to build alignment across people who had fundamentally different incentives. I am not telling this story to suggest my career path was some kind of brilliant strategy. It was mostly accidental. But I recognise now that the combination of those experiences is genuinely uncommon. Most product people I know have deep expertise in one context and surface-level familiarity with the other. The ones who have real depth in both can fill a small room. The specialisation trap is self-reinforcing. Companies hire for the experience they need right now. A scaling company wants someone who has scaled. A startup wants someone who has built from nothing. Nobody posts a job listing that says "we need someone who has done both, and we are willing to wait a year to find them." But that is exactly what they end up doing. What $300,000 cannot buy Average compensation for VP of Product has crossed $300,000 in the US. That number is not the problem. Companies are willing to pay. The problem is that money cannot manufacture the career path that produces a dual-context leader. The most expensive hire a company will ever make is the senior leader they settle for because the right one does not exist yet. I have watched companies make that compromise. They hire the enterprise operator and hope she will develop the builder's instinct. Or they hire the startup founder and hope he will learn organisational complexity. Sometimes it works. More often, it creates a painful eighteen months where the leader struggles with half the job while the organisation absorbs the cost. But the alternative is worse. Leaving the role empty for a year means the product organisation drifts. Decisions get made by committee. The best ICs on the team start looking at other opportunities because nobody is fighting for their growth. There is no clean solution. The gap exists because the industry has not figured out how to systematically create the career path that produces a dual-context leader. The accidental path The few dual-context leaders I have met all have one thing in common: their career paths look messy on paper. They jumped between startups and large companies. They took roles that seemed like lateral moves at the time. But those messy paths are what produced the range. You cannot develop zero-to-one instincts inside a large company. You cannot develop organisational complexity instincts inside a startup. The only way to get both is to cross between the two worlds, and that crossing always looks inefficient from the outside. The industry talks about this gap as a hiring problem. It is not a hiring problem. It is a career design problem. And until we build product career paths that intentionally create movement between building and scaling environments, the gap will keep widening. The people who close it will not be the ones who optimised for a clean resume. They will be the ones whose careers look like a series of bets that only make sense in retrospect.

Product Leadership & CareerMay 22, 2024

The founder's distribution blindspot: most products fail after shipping, not before

I once spent five months building a product that seventeen people used. Not seventeen thousand. Seventeen. And three of them were my co-founder, my mother, and a university friend who I suspect was just being polite. The product worked. It did exactly what we designed it to do. We had solved the technical problems, polished the interface, written the onboarding copy. On launch day we opened the doors and stood there like restaurant owners who had cooked a beautiful meal, set every table, dimmed the lights to precisely the right level, and then realised we had forgotten to put a sign on the building. Nobody came. Not because the food was bad. Because nobody knew we existed. The build-first fallacy This is the story of almost every technically skilled founder I have ever met, including myself. We treat building as the hard part and distribution as something we will sort out later. We tell ourselves that if the product is good enough, people will find it. Word will spread. The work will speak for itself. But the work does not speak for itself. The work sits there in silence until someone with a distribution strategy comes along and eats your market with an inferior product and a superior understanding of how to reach people. Most products do not fail because they are bad. They fail because nobody knows they exist. I call this the build-first fallacy. It is the belief that the sequence is build, then distribute. That the product comes first and the audience comes second. But that sequence is backwards, and by the time most founders realise it, they have already spent their runway on the wrong problem. The build-first fallacy is particularly lethal for founders who are engineers or designers, because those founders experience the building phase as progress. Every feature completed feels like a step forward. Every bug fixed feels like momentum. But progress toward a finished product is not progress toward customers. Those are two separate distances, and only one of them determines whether the company survives. The week-of-launch conversation A founder I was mentoring earlier this year, let us call him Karthik, was one of the most talented engineers I have worked with. He had spent seven months building a project management tool for architecture firms. The product was genuinely impressive. Clean interface, thoughtful workflows, a set of integrations that showed he understood how small architecture practices actually operate. He had done the research. He had talked to architects. He had built something they needed. One week before launch, we had a call. I asked him about his distribution plan. There was a long pause. "We need to figure out marketing," he said. That sentence, spoken seven days before a product launch, is the distribution blindspot in its purest form. Karthik had spent seven months perfecting the product and zero months building an audience, establishing a presence in the communities where architects gather, or creating any mechanism for the right people to discover what he had made. But here is what makes the distribution blindspot so painful. Karthik's product was not the problem. The product was excellent. If you put it in front of the right architect at the right moment, they would have seen its value immediately. But products do not put themselves in front of people. Founders do. And Karthik had invested nothing in that capability. He launched. The landing page went live. He posted on LinkedIn, where he had about two hundred connections, most of them fellow engineers. He sent emails to twelve architects he had interviewed during the research phase. And then he waited. First week: ninety-one visitors. Four sign-ups. Zero paid conversions. The product did not fail. The distribution did. Karthik's company shut down four months later. Not because the product was wrong. But because by the time he started thinking about distribution, he had no runway left to learn it. The build-first fallacy had consumed all his time and money on the part of the problem he was already good at, leaving nothing for the part he had never considered. Distribution is not a department When I think back to my own first startup, the one with seventeen users, the mistake is so clear in hindsight that it is almost funny. Almost. We were three people who were good at making things. None of us had ever thought seriously about how things get found. We treated distribution as a category of work that other people do. Marketing people. Sales people. Growth people. We would hire them later, we told ourselves. After the product was ready. But distribution is not a department you staff later. It is a set of decisions you make from day one. It is choosing which communities to participate in before you have anything to sell. It is writing about the problem you are solving while you are still solving it. It is building relationships with the twenty people who might become your first customers long before the product exists. Distribution is not what happens after you ship. It is what makes shipping matter. The founders who get this right do not treat building and distributing as separate phases. They treat them as parallel activities. While the product is being coded, the founder is writing about the problem space. While the interface is being designed, the founder is having conversations in the forums and Slack channels where potential customers spend time. While the onboarding flow is being polished, the founder has already identified fifty people who will try the product on launch day, not because of a landing page, but because of a relationship built over months. But most technically skilled founders do not do this. They spend their energy on the part they are comfortable with and defer the part that makes them uncomfortable. Building feels productive. Distribution feels like asking for attention. And so the building gets all the hours and the distribution gets none, until launch day arrives and the founder discovers that a finished product with no audience is not a business. It is a portfolio piece. The uncomfortable truth about who survives Here is what I wish someone had told me before my first startup. The founders who survive are not always the ones with the best product. They are the ones who figured out distribution early enough to still have runway when the product was ready. The product is necessary. But the product alone is not sufficient. You need both the meal and the sign on the building. You need both the thing and the mechanism by which people discover the thing. But this is not bad news. Distribution is a learnable skill. It is not a personality trait. You do not have to be extroverted. You do not have to be a natural salesperson. You have to be willing to start building your audience before your product is finished, which feels premature but is actually just correct timing. The distribution blindspot does not discriminate. It takes down founders who build excellent products with the same efficiency as founders who build mediocre ones. But the difference is that the excellent-product founders feel more confused about why they failed. They know the product was good. They do not understand why nobody came. The answer is almost always the same. Nobody came because nobody knew. The best time to start building distribution was before you started building the product. The second best time is now, while there is still something left to build toward.

Building & FoundingMay 7, 2024

Build in public: the distribution strategy hiding in plain sight

There is a documentary filmmaker I follow who does something most directors would consider reckless. She posts her dailies online. Raw footage. Ungraded colour. Scenes with temporary audio and visible boom mics. Her audience watches the film being assembled week by week, and by the time the finished version screens at a festival, hundreds of people already feel like it is partly theirs. They show up because they watched it being made. They share it because they feel invested in its success. She did not market the film. She made the making visible. I have been thinking about that filmmaker, because what she figured out about distribution is exactly what the smartest founders are figuring out right now. But it is the opposite of what most of us were trained to do. The stealth tax For years, I operated inside organisations where secrecy was the default posture. At Boeing, we could not discuss what we were working on outside the building. At Adobe, product roadmaps were guarded with the seriousness of state secrets. Confidentiality was not just policy. It was culture. You did not share half-finished work. You did not discuss problems publicly. You polished, you packaged, you revealed, and you hoped the market noticed. When I left that world and moved to Wayanad, I carried that instinct with me like luggage I did not know I was holding. My first months of working independently were spent building quietly. Writing ideas in private notebooks. Sketching frameworks nobody saw. I was paying the stealth tax without realising it had a name. The stealth tax is the compound cost of building in private. Every month you spend in silence is a month where nobody learns your name, nobody associates you with the problem you are solving, nobody develops the kind of trust that turns a stranger into a customer. But the tax is invisible because you never see the opportunities that did not arrive. You only see the silence after you launch. But here is what changed things for me. I started writing on LinkedIn. Not polished thought leadership with stock photos and motivational closing lines. Just honest observations about product thinking, design decisions, the things I was getting wrong, the things I was reconsidering. The early posts were rough. Some were probably embarrassing. I kept going. Within a few months, something shifted. People I had never met started reaching out with specific questions. Not generic compliments, which is what social media usually produces. Specific questions about product strategy, team structure, design tradeoffs. A few wanted to hire me for consulting. Others wanted introductions. The best time to build your audience is before you have anything to sell them. I did not have a product. I did not have a service page. But I had built something more valuable than either: a group of people who already trusted my thinking. Eight months of silence, then nothing A founder I was mentoring last year learned this lesson the expensive way. He spent eight months building a SaaS tool for independent insurance brokers. The product was genuinely good. Clean interface, thoughtful workflow, a pricing model that made sense for small firms. He wanted to get it right before showing it to anyone. He wanted the launch to speak for itself. He launched in February. Put up a landing page. Wrote one LinkedIn post. Sent a dozen emails to contacts. Thirty-seven visitors in the first week. One sign-up. Zero paying customers. Not slow traction. Silence. The internet responded with its most brutal verdict: indifference. Stealth mode is not a strategy. It is a comfort zone with a business plan attached. But here is where the story gets interesting. Instead of giving up, he tried something different with version two. He started posting about the rebuild on X. Weekly updates. Screenshots of the new dashboard. Honest posts about what went wrong with v1 and what he was changing. He shared a thread about a customer conversation that completely altered his pricing model. He posted a video of himself staring at a Figma file at midnight, trying to solve a particularly stubborn onboarding problem. By the time v2 was ready to launch, four months later, he had eleven hundred followers who had watched the entire journey. The launch post got shared by people he had never spoken to. His first fifty paying customers came from that audience. Same founder. Same market. Same category of product. But this time, the audience existed before the product did. The audience-first advantage turned a silent launch into a noisy one without spending a single rupee on advertising. Why this works (and why it feels wrong) The audience-first advantage works because it reverses the sequence most founders assume is fixed. The default sequence is: build the product, then find customers, then earn trust. The reversed sequence is: earn trust, then build the product, then convert people who already trust you into customers. The second sequence is faster, cheaper, and structurally more reliable. But it requires something that corporate culture trains out of people. It requires sharing before you are ready. Posting the screenshot with the misaligned padding. Describing the feature you cut and why. Admitting publicly that your first assumption was wrong. Every instinct from a decade of working inside large organisations told me this was unprofessional. It turns out it is the most professional thing a founder can do, because it treats the audience as collaborators rather than targets. But the stealth tax is not just about missing distribution. It is about missing feedback. When you build in silence, every assumption remains untested until launch day. When you build in public, your assumptions get challenged weekly by the people who will eventually decide whether to pay for what you are making. The founders who share their process are not being generous with information. They are being efficient with risk. But I want to be precise about what building in public is not. It is not performing confidence you do not feel. It is not manufacturing excitement about features nobody has asked for. It is not a content calendar with motivational quotes on branded templates. It is the disciplined practice of making the work visible to the people who might care about the outcome. Nothing more. Nothing less. The visibility compound There is a compounding dynamic here that most founders underestimate. Every post, every update, every honest reflection creates a layer of credibility that cannot be replicated retroactively. You cannot fake six months of consistent sharing. You cannot backdate the trust that accumulates when an audience watches you struggle with a problem and then solve it. The compound interest of visibility is real, and it only accrues to founders who start early. But starting is the hard part. Not because the tactics are complicated. They are not. The hard part is overcoming the instinct that sharing unfinished work is a sign of weakness. That instinct is a leftover from a corporate world where polish was professionalism and rough edges meant you were not ready. The documentary filmmaker I mentioned at the beginning does not hide in the edit suite until the film is perfect. She shares the dailies. The footage is rough. The colour is wrong. But her audience does not care about polish. They care about the process. They care about watching something come into being. And by the time the final cut is ready, they have already decided to show up. The founders who understand this are not louder than everyone else. They are simply visible earlier. But visibility is not about volume. It is about consistency. And consistency, compounded over months, is the quietest distribution strategy most founders will ever find.

Building & FoundingMay 4, 2024

The collapse of trust in salespeople

The number is 32%. That is the percentage of B2B buyers who consider sales representatives a valuable part of their purchase process. Not a majority. Not even close to a majority. A third. And that third is being generous, because it includes buyers who found the rep useful for logistics and contracting, not for the actual decision. But the real number is the one underneath it. Eighty percent of the buying journey now happens without any direct contact with a vendor. The buyer reads. The buyer asks peers. The buyer runs a trial. The buyer forms an opinion. And then, only then, does the buyer talk to sales. Not to be persuaded. To be processed. This is not a blip. It is a structural collapse. Act one: when sales was the product There was a time when a good salesperson was genuinely the most useful thing a buyer could encounter. The product was complex. Information was scarce. A skilled rep who understood the problem, knew the product deeply, and could map the two together was not just helpful. They were necessary. But that necessity depended on information asymmetry. The salesperson knew things the buyer did not. And as long as that gap existed, the relationship had value. The internet closed that gap. Product documentation went public. Review sites appeared. Peer communities formed. Buyers could do in an afternoon what used to take weeks of vendor meetings. But the sales playbook did not update. The structure of enterprise sales, the outbound cadences, the qualification frameworks, the demo scripts, continued to operate as though the buyer still needed the salesperson to understand the product. The buyer did not. The buyer needed the salesperson to confirm what they had already learned on their own. I call this the confirmation call. The moment the sales conversation stopped being about discovery and started being about validation. The buyer already knows what your product does. They already know your pricing, roughly. They already know your competitors. They are not calling to learn. They are calling to check. Act two: the trust deficit At Freshworks, we had data that nobody in the sales organisation wanted to discuss. The accounts that converted fastest, retained longest, and expanded most reliably were the ones that had never spoken to a salesperson before signing up. Self-serve. Product-led. No human intermediary. The pattern was clear and uncomfortable. But nobody wanted to say the obvious thing out loud. The absence of a sales conversation correlated with better outcomes. I brought this data to a meeting once (a decision I would not describe as career-enhancing). The response was predictable. The sales leadership argued that self-serve accounts were smaller, simpler, easier to close. They were not wrong about size. But they were wrong about the implication. The reason those accounts performed better was not that they were simpler. It was that the buyer's experience of the product was unmediated. Nobody had oversold it. Nobody had set expectations the product could not meet. The product spoke for itself, and what it said was accurate. Trust did not leave the building in one dramatic exit. It leaked out slowly, deal by deal, over a decade of overselling. Every time a sales rep promised a feature that was "on the roadmap" and it never arrived. Every time a demo showed the happy path while hiding the broken edges. Every time the post-sale experience felt nothing like the pre-sale pitch. Each of those moments was a small withdrawal from a trust account that had no deposits coming in. But the buyer learned. Slowly, collectively, and irreversibly. Think of a doctor whose patients arrive having already diagnosed themselves on the internet. The patient has Googled their symptoms, read three medical journals (or at least the abstracts), and formed a firm opinion about what is wrong. The doctor walks in with a stethoscope and fifteen years of training, and the patient says, "I think it's this. Can you confirm?" The good doctors adapt. They meet the patient where they are and add value through expertise that a search engine cannot replicate. The bad doctors get offended that their authority is being questioned. The sales profession, broadly, has responded like the bad doctors. Act three: the product as the conversation At Adobe, I saw the other side of this problem. Enterprise sales cycles where the product demo had to do all the heavy lifting because the buyer had already decided they did not trust the rep. The rep could be articulate, prepared, and genuinely knowledgeable. It did not matter. The buyer's default position was scepticism. Not because the rep had done anything wrong. Because every rep who came before had eroded the baseline. But the product demo became the only moment in the sales cycle where trust was possible. Because the product could not lie. It either did the thing or it did not. The feature either worked or it did not. The experience either felt right or it did not. The product was the last honest salesperson in the building. But most products are not built to carry that weight. They are built for users, not for buyers performing an evaluation under time pressure with a sceptical procurement team watching. The gap between what a product can do and what a product can demonstrate in thirty minutes to a room of people who do not trust the person presenting it is enormous. And most product teams have never thought about it. But this is the trust deficit in action. Buyers have learned that human intermediaries are unreliable narrators. So they look for the one narrator they believe cannot fabricate: the product itself. The teams that understand this build differently. They make the first five minutes of a free trial do the work that a sales deck used to do. They build onboarding that does not require a human to guide it, because the buyer does not want a human guiding it. They treat the product experience as the sales conversation, because for 80% of the journey, it is. What this means for product people The implication is not that sales teams are unnecessary. Contracting, negotiation, relationship management at scale, those remain human work. But the persuasion work, the part where someone decides this product is the right one, that has moved. It lives inside the product now. But here is the part that product teams miss. Building a product that sells itself is not the same as building a product that works well. A product can be excellent for its daily users and terrible at communicating its value to a buyer encountering it for the first time. The empathy required is different. The user already trusts you. They chose you. The buyer does not trust you yet. They are deciding whether to. But every loading screen, every confusing empty state, every feature that requires context the buyer does not have, those are not usability problems. They are trust problems. And in a world where the buyer's default setting is scepticism, every friction point confirms the suspicion that the sales pitch was too good to be true. The product teams that win this era are the ones building for the sceptic, not the convert. They are the ones who treat a buyer's first unguided experience as the most important sales meeting that no salesperson will ever attend. There is something honest about a product that earns trust without anyone in the room arguing for it. No pitch. No deck. No carefully rehearsed objection handling. Just a person, alone with the product, deciding quietly that it does what it claims to do. That is what trust looks like now. Quiet, private, and completely outside your control.

User & Buyer PsychologyApril 25, 2024

The Sales Rep Didn't Leave. You Just Stopped Paying Them.

When a company moves to self-serve, the announcement is usually framed as an efficiency story. Fewer sales reps. Lower CAC. Users who can get from signup to value without a human in the loop. The deck makes it look clean. What the deck doesn't say is that someone still has to do the sales rep's job. The objections still need handling. The value still needs demonstrating. The moment when a user is on the edge of committing, half-convinced and looking for a reason to stop, still needs to be managed. The sales rep didn't leave. Their job got quietly handed to the product. And most products weren't built to do it. About a year ago I was brought in to look at the onboarding flow for a self-serve SaaS product. The team had invested seriously in it. Multiple rounds of user testing, a clean visual design, a step-by-step setup experience that any designer would be proud to put in a portfolio. But users were dropping off at the same point every time. Not early, not late. A specific moment, about two thirds of the way through setup, where they were asked to connect their existing data source and configure their first workflow. The team had tried everything. Simplified the copy. Added tooltips. Reduced the number of steps. The drop-off moved slightly but never resolved. They were treating it as a UX problem. It wasn't a UX problem. I asked whether they'd kept any recordings of their old sales calls from the period before they went self-serve. They had. We spent an afternoon going through them. The pattern was obvious within the first three calls. Every single sales rep, without exception, handled a specific objection at exactly that moment in the demo: "This looks like it's going to take a long time to set up properly." The rep's response varied in wording but not in substance. They acknowledged the concern, showed a shortcut, told a story about another customer who'd felt the same way, and moved on. The product had no answer for that objection. It just waited. And users, with no sales rep in the room and no reason to push through, left. The mistake wasn't going self-serve. The mistake was treating self-serve as a distribution decision rather than a product design decision. Distribution decisions change the channel. Product design decisions change what the product has to do inside that channel. When you remove the sales rep, you don't just change the channel. You remove a layer of the product experience that was running in parallel all along, one that your team never built because it was being handled by a different team entirely. Sales reps do things that most product designers have never been asked to think about. They read hesitation. They sequence information based on where the buyer's head is, not where the product flow assumes it should be. They handle the moment when a user is technically on track but emotionally uncertain. They know that a buying decision isn't made when the logic is complete. It's made when the doubt is resolved. A product can do all of those things. But only if someone on the product team was in the room when the sales team was doing them. Most weren't. We fixed the onboarding flow by doing something that felt almost too simple. We added a single screen at exactly that point in the setup, before the data connection step, that did three things. It named the concern directly: "This next step is the most common place people pause." It showed how long setup actually takes for a typical user. And it showed a single example of a completed workflow so the user could see what they were building toward. No redesign. No new architecture. A screen that did what the sales rep used to do at that moment. Completion rates at that step went from fifty-one percent to seventy-eight percent in six weeks. The product wasn't broken. It was just missing the conversation. This is the thing most product teams haven't fully reckoned with yet. Self-serve sounds like simplification. In one sense it is. But in another sense, it hands the product team a responsibility they were never trained for and rarely warned about. A sales rep loses a deal and gets feedback. Their manager asks what happened. The objection gets logged, iterated on, handled better next time. There is a learning loop. A self-serve product loses a user and, if the team isn't looking in the right place, gets nothing. The user just doesn't come back. The product doesn't know what objection it failed to answer. It doesn't know what doubt was present at the moment of exit. It knows a drop-off happened and it knows where. That's not a learning loop. That's a leakage report. But product teams treat it like the same thing, because the data looks similar. Both tell you where users stopped. Only one tells you why. The teams doing this well aren't the ones with the most sophisticated onboarding flows. They're the ones where a product designer has sat through enough sales calls to understand what a buying conversation actually sounds like from the inside. Not to copy the pitch. To understand the doubt. Because the doubt doesn't go away when the sales rep does. It shows up in your drop-off data instead. And the product that learns to answer it will outperform the product that keeps optimising the wrong thing. Self-serve was never going to be simpler. It was always going to be different. The teams that understood that distinction early will have the retention numbers to show for it. The ones who thought they were just changing the channel are still wondering why their onboarding flow isn't converting.

Product StrategyApril 10, 2024

Output was never the job

The layoffs that swept through tech design teams over the past year were not random. They followed a pattern, and the pattern says something uncomfortable about how design positioned itself during the expansion years. Design headcount grew fast between 2019 and 2022. Ratios that had been one designer for every fifteen engineers moved toward one for every eight, sometimes one for every five. Companies were hiring designers the way they were hiring everyone else: because capital was cheap, growth was the mandate, and adding people felt like adding capacity. But adding designers is not the same as adding design impact. And when the reckoning came, a lot of organisations looked at their design teams and could not clearly articulate what the return had been. That is not entirely the designers' fault. But it is partly their problem. The case I keep coming back to happened at a product company I worked with closely. When headcount pressure arrived, the design team braced for cuts. What they expected was a conversation about which designers to keep. What they got was a more uncomfortable question: what has this team actually changed? Not what have they shipped. What have they changed. In the product. In the metrics. In the decisions that leadership made because design was in the room. The team had produced good work. The screens were clean. The components were consistent. The user flows had been properly researched and tested. But when leadership looked for the thread between design activity and business outcomes, it was thin and hard to follow. Not because design hadn't contributed, but because design had never made the case for its own contribution in terms that the rest of the organisation was tracking. Portfolios full of beautiful screens and no sentence about what changed because of them. This is the credibility gap that has been building in the design profession for years. But the layoff wave has made it visible in a way that cannot be unseen. Design earned its seat at the table during a period when "user-centred" was a differentiator. When companies could point to a beautifully designed product as proof of quality, and when quality correlated visibly with growth. In that environment, design's contribution was legible even without a business case. The product looked better. Users preferred it. Sales went up. The chain was loose but it held. But that chain has been getting harder to see. As design standards rose across the industry, good UX became table stakes rather than competitive advantage. The companies that hadn't invested in design started catching up. The ones that had found themselves with large teams producing incremental improvements to products that were already well-designed. The value of the work did not disappear. But the visibility of it did. The designers who kept their seats, and kept their influence, were the ones who had already crossed a line that most of their colleagues hadn't crossed yet. They could translate design decisions into business outcomes. Not by learning to speak corporate. But by understanding what questions the business was actually asking, and answering those questions with design reasoning. Not "we improved the onboarding flow." But "we reduced drop-off at step three by redesigning the permission request, which contributed to a 12-point lift in week-one retention." Not "we simplified the dashboard." But "we reduced support tickets related to data interpretation by 30%, which freed up two support agents for higher-complexity issues." The difference between those two statements is not the design work. It is the designer's decision about what the work is for. Here is the uncomfortable part. The design profession has sometimes resisted this framing as a corruption of the craft. There is a version of the argument that says reducing design to business metrics misses the point of design: that good design serves people, not spreadsheets, and that the moment you start measuring design in revenue terms you have already lost something important. I understand that argument. I have made a version of it myself. But I no longer believe it holds as a complete position. Because the designers who frame their work only in craft terms are, in practice, dependent on someone else to make the business case for them. And that someone else is a leadership team that has competing priorities, incomplete information, and a budget to cut. The designers who survive are not the ones who abandoned craft. They are the ones who understood that craft without legibility is a gift nobody can unwrap. The layoffs were a correction. Not to design's importance. But to design's relationship with accountability. The teams that come out of this period with more influence than they went in with will be the ones who made the translation. Who understood that sitting in the strategy room requires speaking the strategy room's language, not just showing up with better screens than anyone else. Better screens are necessary. They are not sufficient. They never were.

Product Design & Craft TopicsApril 6, 2024

The personal operating system

A professional chef does not walk into the kitchen and decide what to cook based on whatever ingredient catches their eye first. Before service begins, everything is in place. The mise en place. Knives sharpened, aromatics diced, sauces reduced, stations organised so that when the pressure hits, the chef responds from structure, not from improvisation. Nobody watches a great chef and says, "What incredible reflexes." They see the result of a system so well designed that execution looks effortless. Product people, meanwhile, tend to start their day by opening their inbox and letting whatever landed overnight set the agenda. I did this for years. It felt like working. It was just reacting. The reactive default Once upon a time, I managed my work the way most product managers do: by responding to whatever felt most urgent. Every day, the inbox dictated the morning. Slack notifications dictated the afternoon. The roadmap review I was supposed to prepare got squeezed into the last forty minutes of Friday, when my brain had the structural integrity of wet cardboard. I told myself I was being responsive. Adaptive. Close to the customer and close to the team. But what I was actually doing was letting other people's priorities fill every gap in my day, and then wondering why my own thinking never seemed to advance. The strangest part was that I could not point to a single wasted hour. Every hour was "productive" in the narrow sense. Emails answered. Meetings attended. Questions responded to. But there was no accumulation. No compounding. Each week felt like a reset, not a continuation. I was running hard and staying still. Until one day at Adobe, I noticed something about a colleague named Priya. She was a senior product manager on a different team, and she seemed to operate in a different temporal dimension. While the rest of us were constantly reacting, she always appeared to be working from a plan that existed before the week started. When an urgent request came in, she did not ignore it. But she placed it inside a structure that had room for urgency without being defined by it. Her output compounded visibly. Quarter over quarter, her decisions got sharper and her strategic clarity grew in a way that the rest of us, working just as many hours, could not match. I asked her about it once, expecting some revelatory productivity tool or secret morning routine. "I just have a system," she said. "It is not complicated. But I designed it on purpose." What a personal operating system actually is The term "personal operating system" has gained currency this year, but the concept has always existed informally among the most effective knowledge workers. It is the intentional set of choices a person makes about how they capture ideas, triage incoming demands, structure their days, and protect the conditions under which their best thinking happens. The key word is intentional. Most product people have habits. But habits are not a system. A habit is brushing your teeth before bed. A system is a dentist's practice: scheduled, reviewed, adjusted based on outcomes, and designed to compound results over time. What I eventually built for myself, borrowing from Priya and refining the approach at Freshworks, is what I think of as The Compound Ritual Stack. It is not a single habit. It is a layered set of recurring practices, each operating at a different time horizon, that collectively ensure the most important work gets attention before the urgent work consumes all available space. The daily layer is simple: thirty minutes every morning before opening any communication channel, spent reviewing what matters most this week and choosing the one thing that will receive my best thinking today. Not three things. One thing. The weekly layer is what I call The Weekly Calibration Loop: a Friday review where I look at what I intended to accomplish, what I actually accomplished, and where the gap came from. Was the gap a planning failure or an intentional reprioritisation? If I chose to redirect my week, that is adaptive. If my week was redirected by whoever sent the loudest message, that is reactive. The loop makes the difference visible. The monthly layer is a reflection on whether the system itself needs adjustment. Are the rituals still serving me, or have they become performative? The system is not sacred. It is a tool. But like any tool, it needs maintenance. The compounding effect Because of that system, something started to change at Freshworks. My output did not increase in volume. But it increased in coherence. The decisions I made in month three connected to the thinking from month one, because the system preserved continuity. Without the system, that earlier thinking would have been overwritten by daily churn. With it, each week built on the previous week's foundations. This is the part that most productivity advice misses entirely. The advantage of a personal operating system is not efficiency. It is accumulation. The system is not the work. The system is what makes the work compound. I saw the same pattern when mentoring interns. The ones who built a personal capture system early, even something as simple as a running document where they logged questions, observations, and decisions, learned faster than interns who relied on memory and reaction. Not because the system made them smarter. But because it gave their intelligence something to accumulate in. The difference between a reactive product manager and a systematic one is invisible in any given week. Both attend the same meetings, write the same documents, ship the same features. But over a year, the systematic one has built a body of thinking that the reactive one has not. They simply did not compound. Effort without architecture is just motion. Designing your own The specific practices matter less than the design principles. I know product leaders who use Notion databases with elaborate tagging. I know others who use a single A5 notebook and a pen. What matters is whether the system includes four elements. First, a capture mechanism that removes ideas from your head and puts them somewhere you will actually revisit. The brain is for generating thoughts, not storing them. If Tuesday's product insight lives only in your memory, it will be gone by Thursday. Second, a triage ritual that distinguishes between what is urgent and what is important. Not in theory. In practice, every day. Urgency is loud. Importance is quiet. Third, a review cycle that forces you to look at your own patterns. Without reflection, you cannot improve the system. Without improving the system, you cannot compound. The loop must close. Fourth, a protection mechanism for your best thinking time. The system defends the conditions under which your best work happens, treating them as infrastructure, not as luxury. When I moved from Bangalore to Wayanad, my system had to adapt completely. The rhythms of the day changed. But because I had a system to adapt, rather than a collection of habits to reconstruct, the transition took weeks instead of months. The system was portable even when the specific practices were not. That portability is the real test. A personal operating system that only works in one context is not a system. It is a routine. Routines break when context shifts. Systems bend. The question that separates product people who compound over time from those who stay reactive is not "how hard do you work?" It is quieter than that, and more consequential: how well is your system designed? Most people never ask it. The ones who do tend to find that the answer changes everything, not all at once, but gradually, in the way that compound interest changes a bank balance. Slowly, then unmistakably.

Productivity & Working MethodsApril 6, 2024

Burnout is not a badge of honour

In my first startup, I once fell asleep during a product demo. Not a casual nodding off. A full, chin-on-chest, pen-rolling-off-the-table surrender to gravity. The client was mid-sentence. My co-founder kicked me under the table, which I barely registered. Afterwards, he did not ask if I was okay. He said, "That was embarrassing, but at least it shows we are working hard." I accepted that framing completely. I was twenty-seven and running on four hours of sleep a night, and I wore the exhaustion like a medal. It took me years to understand that what I was wearing was actually a symptom. Act One: The Gospel of the Grind Startup culture has, for at least two decades, operated on a foundational belief: more hours equals more commitment, and more commitment equals better outcomes. The mythology is relentless. Founders sleeping under their desks. Engineers pulling seventy-hour weeks and tweeting about it. Product leaders answering Slack messages at midnight and calling it "being responsive." The message, absorbed through a thousand conference talks and founder interviews, is clear. If you are not grinding, you are not serious. I believed this deeply. At Freshworks, during a particularly intense product launch cycle, I tracked my own working hours for a month. The average was sixty-three hours a week. I was proud of that number. But what I did not track, and what nobody around me was tracking, was the quality of the output those hours produced. The decisions I made in week three of that sprint were measurably worse than the ones I made in week one. I approved features I would have questioned. I let timelines slide that I would have challenged. I signed off on copy that, three weeks later, I could not believe I had agreed to. But the hours looked right. So nobody questioned it. This is what I have come to call The Grinding Fallacy: the belief that effort and output are linearly related, that doubling the hours doubles the results. A comforting belief. But it is wrong in exactly the way that matters most for people making consequential decisions under sustained pressure. Act Two: The Data Arrives A 2024 survey of 156 founders found that 53% had experienced burnout within the past year. More than half. That number alone should prompt reflection. But what makes it more pointed is the secondary finding: burnout was not merely a personal wellbeing issue. It was correlating with measurably worse business outcomes. Balderton Capital and several other institutional investors have begun reframing burnout as a business performance variable. Not a lifestyle concern. Not a wellness perk to be addressed with meditation apps and ping-pong tables. A variable that directly affects the quality of the decisions a founder makes, the signals they catch or miss, and the people they retain or lose. The logic is straightforward. Exhausted founders make worse decisions. They miss market signals. They retain fewer people because burned-out leaders create burned-out teams. And they produce worse products, because product quality is downstream of decision quality, which is downstream of cognitive capacity, which is downstream of recovery. Every link in that chain is obvious. But somehow, the startup world spent two decades pretending the chain did not exist. I saw this firsthand at a petroleum company I consulted for. The head of digital products was a brilliant strategist who, over the course of six months, transformed from someone who asked sharp questions in every meeting to someone who rubber-stamped whatever was put in front of him. The change was gradual enough that most people did not notice. But I had worked with him early in the engagement, and the contrast was stark. His decision quality had not declined because the problems got harder. It declined because he had been running at full intensity for so long that he had nothing left to bring to the table. Nobody used the word burnout. They said he was "having a rough patch." He left four months later. The product direction he had rubber-stamped took nearly a year to correct. The Cost Nobody Budgets For Burnout is not a badge of honour. It is a performance bug that nobody files a ticket for. What makes this particularly insidious in product roles is that the symptoms look, from the outside, like competence. The burned-out PM still attends every meeting. They still reply to every message. They still hit their deliverables. But the nature of their contributions shifts. They stop challenging assumptions. They stop asking the second question. They start optimising for speed of resolution rather than quality of outcome. I have mentored interns who, three months into their first product role, were already showing early signs. Not because the work was too hard. But because they had absorbed the culture's message that working long hours was the price of being taken seriously. One of them told me she felt guilty leaving the office before 8pm. She had been in the role for eleven weeks. The culture was not teaching her to build great products. It was teaching her to perform suffering. And she could not see that, because everyone around her was performing the same thing. Act Three: The Athlete Model The counter-frame that has gained the most traction in 2024 is what practitioners are calling The Athlete Model. The insight is borrowed from elite sports: the best performers in the world do not train by maximising hours. They train by optimising the balance between exertion and recovery. A sprinter who trains at maximum intensity every day does not get faster. They get injured. The same principle applies to cognitive work. But the startup world has been remarkably slow to accept it. An athlete who never rests is not dedicated. They are poorly coached. But a founder who never rests is still, in many circles, celebrated. The Athlete Model asks a different question. Not "how many hours can I sustain?" Instead: "what is the sustainable intensity that produces my best thinking over months and years, not just this week?" It is the difference between a sprint pace and a marathon pace. And most founders, by the time they recognise the distinction, have already been sprinting for too long. When I moved from Bangalore to Wayanad, part of what I was doing, though I would not have articulated it this way at the time, was redesigning my own operating rhythm. Fewer hours of deep work, yet higher quality. More recovery built into the week, not as indulgence, as infrastructure. The output did not decline. If anything, it improved. But the shift required accepting something that the startup gospel had spent years telling me was weakness: that rest is not the absence of work. It is part of the work. That distinction still makes people uncomfortable. What Gets Better When founders begin treating recovery as a performance variable rather than a reward, three things tend to improve. Decision quality goes up, because the cognitive resources that decisions draw on are being replenished rather than perpetually depleted. Team retention improves, because sustainable leadership creates sustainable teams. And product quality improves, because the people making the calls about what to build and why are doing so from a position of clarity rather than exhaustion. But this requires a cultural shift that goes beyond individual behaviour. Investors who celebrate the sixty-hour-week founder are subsidising burnout. Boards that reward velocity over sustainability are creating the conditions for the very decline they fear. The Athlete Model only works if the people around the founder accept its premise. That means roughly half the products being built right now are being shaped by people whose cognitive resources are depleted. Not occasionally. Structurally. The best work does not come from the person who stayed latest. It comes from the person who still had something left to give when the decision that mattered most arrived quietly, on a Tuesday afternoon, disguised as a routine call.

Productivity & Working MethodsMarch 31, 2024

Agile as ritual: the gap between ceremony and actual agility

At my first startup in Bangalore, I was the person who bought the Agile textbook. I am not proud of this. I read it cover to cover, highlighted passages, and then introduced every ceremony I could find to a team of seven people who had been shipping perfectly well without any of them. We had stand-ups. They lasted forty-five minutes. People leaned against walls, shifted their weight, checked their phones while someone explained a database migration in the kind of detail that belongs in a document, not a morning ritual. We had sprint planning. It took an entire afternoon. We had retrospectives every two weeks where we identified the same three problems (unclear requirements, too much scope, not enough testing) six sprints in a row. We wrote them on sticky notes, put them on a board, and then ignored them until the next retro, when we wrote the same problems on fresh sticky notes. The process felt agile. The output was waterfall with post-it notes. I thought we were doing it wrong. So I added more structure. More templates. More tracking. But nothing about how we actually built the product changed. We still waited for one person to approve every decision. We still committed to scopes that nobody believed in. We still treated the sprint as a container for work that had already been decided, not a framework for adapting to what we learned. That was my first encounter with what I now call the ceremony trap. The ceremony trap The ceremony trap is not that teams do the wrong rituals. It is that the rituals become the product. You start measuring whether the stand-up happened, not whether the stand-up changed anything. You track sprint velocity, not whether the sprint delivered value. You run retrospectives on schedule, not because anyone expects the outcome to be different from last time. And the trap is seductive because it feels responsible. You are doing the meetings. You have a board with columns and cards moving left to right. From the outside, it looks like a functioning Agile team. From the inside, everyone knows better. But nobody says so, because the ceremonies provide cover. GitLab's DevSecOps survey found that 67% of teams admitted to sacrificing quality for speed. But I would frame that differently. They were not sacrificing quality for speed. They were sacrificing quality for the appearance of speed. The sprints created urgency. The ceremonies created the illusion of responsiveness. But the underlying decision-making structure, the hierarchy of who decides what gets built and when, had not changed at all. This is what I call Agile theatre. The performance of agility without the substance of it. The kitchen did not change Imagine a restaurant that renovates the dining room. New furniture. New lighting. New plates, the kind with the wide rim and the small portion artfully placed in the centre. The menu has a new typeface. But the kitchen is the same. The same chef, the same suppliers, the same recipes, the same workflow where everything bottlenecks through one person who insists on tasting every dish before it goes out. The plates look modern. The food has not changed. That is what most Agile adoptions look like. The ceremonies are the dining room renovation. The org chart, the approval chains, the power dynamics, the way decisions actually get made: that is the kitchen. But most organisations renovated the dining room without touching the kitchen. I saw a more sophisticated version of this at Freshworks. A product team running clean two-week sprints. Ceremonies on schedule. Velocity tracked. Burn-down charts on a screen in the team area. From the outside, textbook Agile. But the PM pre-decided every item before sprint planning. The "planning" session was a presentation. The PM walked through what they had already committed to stakeholders, and the team listened, nodded, and assigned story points to work that had been scoped without their input. Sprint planning was not planning. It was an announcement wearing the costume of collaboration. I asked in a retro once why nobody ever pushed back on scope during planning. The room went silent. Not the productive silence that follows a good question. The silence that means everyone knows the answer and nobody wants to say it. The answer, which someone finally offered after I let the silence sit for an uncomfortable twenty seconds, was simple: pushing back did not change anything. The PM had already committed upward. The stakeholders had already been told. The scope was fixed before the ceremony began. The ceremony existed to make a top-down decision look like a team decision. That team was agile in vocabulary. It was waterfall in every way that mattered. Where agility actually lives Agility lives in decisions, not ceremonies. A team is agile when it can change direction based on what it learns. When a sprint reveals that the initial assumption was wrong, an agile team adjusts scope for the next sprint. A ceremonially agile team keeps building what was originally planned because the PM already told the VP it would ship. The real test is not whether you have stand-ups. It is what happens when someone says, mid-sprint, that the thing you are building is the wrong thing. In a genuinely agile team, that observation changes the plan. In an Agile theatre team, that observation gets noted, possibly acknowledged, and then shelved because the commitment has already been made. But here is the uncomfortable part. Genuine agility requires something most organisations are not willing to give: distributed authority. If the team cannot make real decisions about scope, priority, and direction without escalating to someone outside the team, it does not matter how many ceremonies they run. The agility is cosmetic. The power structure is the process. Everything else is set dressing. I have worked across nine different organisational contexts, from three-person startups to global enterprises. The pattern is consistent. The teams that were genuinely agile were not the ones with the best ceremony discipline. They were the ones where the team had real authority to change course. Not permission to suggest changes. Authority to make them. That distinction sounds small. It is enormous. The retro that never changes anything The retrospective is the most revealing ceremony. It is where the gap between Agile theatre and genuine agility becomes impossible to hide. A retro is supposed to produce change. The entire point is that the next sprint is different from the last one. But in most teams I have observed (and a few I have led, including that first startup), the retro produces a list. The list goes on a board. The board gets photographed. And the next sprint begins exactly as the previous one ended. The retro becomes a confession ritual. You name the sins. You feel briefly lighter. Nothing changes. You come back in two weeks and confess the same sins again. It is performance without consequence. The teams where retros actually work are the ones where someone in the room has the authority to act on what the retro reveals. Not escalate a suggestion. Change the practice. That week. But most organisations treat the retro as feedback, not as a decision-making moment. And feedback without authority is just venting with structure. The ceremony trap is comfortable. It provides the language of progress without the friction of actual change. It lets organisations tell themselves they are agile while preserving every hierarchy, every approval chain, every political dynamic that existed before anyone had heard the word sprint. Agility was never a set of meetings. It was a willingness to be wrong in public and adjust in real time. Most organisations adopted the meetings. The willingness was never part of the package.

Product Teams & Org DynamicsMarch 22, 2024

Churn at an all-time high: the retention reckoning

The fastest-growing product I ever worked on was also the one closest to collapse. We just didn’t know it yet. The acquisition numbers were beautiful. New logos every week, pipeline charts climbing in the right direction, and a sales team that had started walking into Monday standups with visible swagger. But underneath those numbers, something was rotting. And nobody wanted to look. I call this the acquisition illusion. The belief that if the top of the funnel keeps filling, the business must be healthy. It is the most expensive lie in SaaS. And right now, as retention data starts catching up to the growth narrative, more teams are discovering it than at any point in the last decade. The numbers don’t lie, but they do hide ProfitWell’s data tells a story that should make every product leader uncomfortable. Churn’s revenue impact is roughly 30% higher than its previous peak during the pandemic boom. But most teams will not feel it yet. They will feel it in six months, when the cohort curves flatten and the board starts asking questions that the acquisition dashboard cannot answer. Here is what I have learned across twenty years of building products: growth is a narcotic. It feels like progress right up until the withdrawal starts. And the withdrawal, when it comes to churn, does not arrive as a crisis. It arrives as a slow, persistent drag that makes every other number slightly worse, every quarter, until someone finally asks what happened. But nobody asks what happened when things are going up. At Freshworks, I watched this pattern play out with the precision of a recurring bad dream. We had strong acquisition. Marketing was performing. Sales was closing. But when someone (finally, reluctantly) pulled the cohort retention data and laid it alongside the acquisition curve, the room went quiet. Accounts that had signed twelve months earlier were disappearing at a rate that made the growth curve meaningless. We were not building a bigger business. We were building a faster treadmill. The specific moment I remember is a Thursday afternoon meeting where a product lead put two charts on the screen. The first showed monthly new accounts. Beautiful. The second showed net revenue retention by cohort. Devastating. The gap between those two charts was the entire future of the product, and we had been staring at only one of them. The leaky bucket tax There is a cost to churn that goes beyond the lost revenue. I call it the leaky bucket tax, and it compounds in ways most product teams never account for. Every churned customer cost you money to acquire. That is the obvious part. But every churned customer also consumed support resources, onboarding time, engineering bandwidth for feature requests that were specific to their use case, and product roadmap attention that pulled the team away from the customers who were actually going to stay. You paid to bring them in. You paid to serve them. And then you paid for the distortion they introduced into your product decisions on the way out. But here is the part that really stings. The customers who leave rarely tell you why. They just go quiet. Usage drops. Logins thin out. And then one day someone in finance notices the invoice was not renewed and sends an email that bounces. I learned this at my first startup. We celebrated every new signup like it was a small victory. We had a Slack channel for it (of course we did). But we had no channel for the users who stopped logging in. No alert, no ritual, no visible signal. The product was haemorrhaging value, and we were too busy watching the front door to notice the back door was wide open. That startup grew its user count every single month for nine months straight. It also failed. Those two facts are not contradictory. They are causally linked. Why teams look away The reason product teams tolerate churn is not ignorance. It is comfort. Acquisition metrics are clean, immediate, and controllable. You can run a campaign, change a price, adjust a landing page, and watch the number move. It feels like agency. But retention is slow, messy, and humbling. Fixing retention means admitting that the product, the thing you built, is not good enough to keep people. That is a harder conversation than most teams are willing to have. It is certainly a harder presentation to give to a board that has been conditioned to celebrate growth. Think of a restaurant that fills every table every night. The owner sees the queue out the door and assumes the business is thriving. But if nobody comes back for a second meal, the restaurant is not a restaurant. It is a novelty. And novelty has a half-life. The most dangerous number in product is the one that only goes up. Because it trains the entire organisation to optimise for more, when the real question is whether enough of the existing base finds enough value to stay. But teams do not build dashboards for enough. They build dashboards for more. What retention actually requires Retention is not a feature. It is not an onboarding flow improvement or a customer success hire (though those things can help). Retention is the product earning the right to be used again tomorrow. And that right is earned in the first fourteen days, reinforced in the first ninety, and lost in the silence between month three and month six when nobody on the product team is watching. But here is the uncomfortable truth. Most product teams do not own retention. Marketing owns acquisition. Sales owns conversion. Customer success owns expansion. Retention sits in the gap between all three, which means it sits nowhere. And the things that sit nowhere in an organisation are the things that only get fixed after they become emergencies. I have seen this at three different companies across two continents. The pattern does not change. The org chart determines what gets measured. What gets measured determines what gets fixed. And retention, because it belongs to everyone, belongs to no one. But the product is the retention mechanism. The experience is the retention mechanism. Every interaction, every loading time, every confusing flow, every moment where a user wonders whether this tool is worth the trouble of opening again tomorrow. That is retention. And that is product work. The reckoning is not coming. It is here. The era of growth-at-all-costs produced a generation of products that are excellent at getting people through the door and mediocre at giving them a reason to stay. The data is now catching up. Churn is at levels that make the maths of customer acquisition brutally simple: if you cannot keep them, you cannot afford to get them. But the teams that figure this out will not be the ones with the best retention dashboards. They will be the ones willing to sit with the uncomfortable question: why are people leaving? And then willing to act on answers that might mean rebuilding the parts of the product that everyone thought were finished. There is something quietly honest about a product that people come back to without being reminded. No re-engagement email. No discount offer. No push notification dressed up as helpfulness. Just a person opening your product because yesterday it did something worth repeating. That is the only metric that matters. Everything else is noise wearing a growth costume.

The Business of ProductsMarch 20, 2024

Entry-level product positions collapsed, creating a broken leadership pipeline

There is an old principle in forestry management that my grandfather, who grew coffee in Wayanad, would have recognised instantly. You never stop planting seedlings just because you have enough mature trees to harvest this season. The moment you do, you have set a clock. In five years, maybe eight, your canopy thins. In ten, your forest is gone. You cannot rush-order a mature tree. The product industry is running this exact experiment right now, and it is running it on people. The Seedling Problem Junior and associate product manager roles have collapsed. In India, startups have recorded a 58% decline in junior product positions. In the US and Europe, the pattern is nearly identical. Companies that once hired cohorts of associate PMs and built structured rotational programmes have quietly dismantled them. The mentorship programmes wound down. The internship pipelines went dry. The stated logic is the same: "We need to stay lean." "We need people who can hit the ground running." But here is what that logic actually says, translated from corporate euphemism into plain English: "We would rather pay more later than invest less now." This is the seedling problem. It feels rational in the moment. But it looks catastrophic in retrospect. When I was at Freshworks, I mentored three junior PMs over the course of about eighteen months. The time investment was modest. Roughly an hour a week per person, sometimes less. We would review their PRDs together. I would sit in on their stakeholder meetings and give notes afterward. Occasionally I would let them lead a customer call and then debrief on what they missed and what they caught that I had not. Within two years, all three had become the strongest mid-level product people in the organisation. They understood the product deeply because they had grown up inside it. They knew the engineering team's quirks, the sales team's pressure points, the support team's recurring pain. But the real advantage was organisational context that no external hire could replicate. That context is not something you learn from an onboarding document. It accumulates like sediment. I ran the numbers once. The fully loaded cost of mentoring those three juniors was a fraction of what it would have cost to hire three mid-level PMs externally. Not in the same postcode. And the external hires would have taken six months to reach the baseline understanding that the juniors had absorbed through osmosis. The cheapest senior hire you will ever make is the junior you invested in three years ago. The Expensive Fragility of Senior-Only Teams But the cost argument, while compelling, is not even the most important one. A startup founder I advise stopped hiring juniors about two years ago. His reasoning was sound on paper. He had limited runway. He needed velocity. So he built a team of exclusively senior product people: experienced, autonomous, expensive. The team is excellent. Right now. But nobody on that team is developing the next generation of leaders. Nobody is mentoring. Nobody is teaching someone how to write their first product requirement document, how to handle their first angry stakeholder, how to sit in a room where engineering and sales are shouting past each other and find the actual question underneath the noise. He has a team of mature trees and no seedlings in the ground. I asked him last month who would backfill his senior PM if she left. He paused. "I would have to hire externally," he said. "Probably three months to find someone, another three to get them up to speed." Six months of degraded product leadership because there was nobody on the bench. That is not lean. That is structurally fragile. The pipeline gap is not a staffing problem. It is a leadership continuity problem disguised as a staffing problem. What Juniors Actually Learn (and Why It Cannot Be Skipped) There is a popular argument that junior PMs do not contribute enough to justify their cost. That the role is essentially training someone on the company's dime. That it is more efficient to hire people who have already been trained somewhere else. But this argument has a fatal flaw. It assumes that product management skills are portable and context-free. They are not. A junior PM at your company learns your customers, your technical architecture, your organisational politics. They learn which VP reads the strategy documents and which one asks for a summary in the corridor. They learn that your engineering team in Bangalore delivers faster when you write specs with more visual wireframes and fewer bullet points. But none of that knowledge transfers from a previous job. It is indigenous knowledge, and it only grows locally. You cannot harvest senior leaders from a field where you stopped planting juniors five years ago. The harvest does not exist. But companies keep trying. They post senior PM roles with requirements that read like wish lists from a fantasy novel. Eight years of experience. Strategic thinking. Technical depth. The ability to influence without authority, which is corporate code for "we want you to be a magician." Then they wonder why the roles take four months to fill. The answer is written in the job description. They are looking for a mature tree because they forgot to plant the seedling. The Mentorship Multiplier The saddest part of the pipeline gap is what it does to the seniors who remain. Product leaders who once spent part of their week developing junior talent now spend all of their time in execution mode. They are not growing anyone. They are just producing. But production without reproduction is a dead end. Any biologist will tell you that. When I think about the time I spent mentoring those juniors at Freshworks, I do not remember it as a cost. Not because I am generous, though my wife might debate even that characterisation. But because mentoring forced me to articulate my own instincts. When a junior PM asked me why I pushed back on a feature request, I had to explain the reasoning, not just act on it. That made me sharper. Mentoring is not charity. It is a compression algorithm for your own thinking. But that loop is broken now. Seniors are not mentoring because there are no juniors to mentor. Their own skills are calcifying because they are never forced to explain them. The organisation loses twice: once in the missing pipeline, once in the stagnating seniors. The Clock Is Already Running Companies that cut junior roles over the past two years are beginning to feel the consequences. The mid-level PM bench is thinner than it should be. Internal promotions are stalling because there is nobody ready to step up. But external hiring is getting more expensive because everyone is fishing from the same shrinking pool of experienced product people. The seedling problem is not theoretical. It is here. But I do not think this is permanent. Cycles correct. The companies that maintained their junior programmes through the downturn will have an extraordinary advantage: a bench of mid-level product people with deep organisational context, ready to step into senior roles just as their competitors scramble to hire externally at premium rates. The companies that cut their seedlings will pay the price in three to five years. Some are paying it already. But perhaps the deepest irony is an industry that talks constantly about long-term thinking and user-centred design, then makes its most consequential people decisions based on next quarter's headcount budget. The best product organisations I have seen treat talent development the way good farmers treat soil. You do not stop tending it because this season's crop looks fine. The harvest you skip planting for is the one you will miss most.

Product Leadership & CareerMarch 18, 2024

Everyone Says Outcomes. Nobody Measures Them.

The Product Plan State of Product report landed a few weeks ago and the number everyone is quoting is this one: outcomes over outputs is now the #1 strategic priority for product teams in 2024. Which is good news. Except for one thing. I've spent the last several months sitting in roadmap reviews, sprint retrospectives, and quarterly planning sessions with product teams across three different companies. Every single one of them will tell you, with complete sincerity, that they are focused on outcomes. And every single one of them, when you look at what they're actually measuring, is counting features. The language changed. The behaviour didn't. And in some ways, that's worse than before. About eight months ago I worked with a product team that decided to take the outcomes shift seriously. Genuinely. The head of product had read the right books, attended the right conference talks, and came back with conviction. They were going to rewrite the roadmap. Not in feature language. In behaviour language. Real outcomes, defined upfront, tied to real user actions. It took three weeks. It was painful in the right ways. Arguments about what "engagement" actually meant. Debates about whether a metric was measuring the behaviour they cared about or a proxy for it. Good arguments. The kind that make a team sharper. They shipped the new roadmap to leadership. Everyone approved it. The team exhaled. Then Q4 arrived. The quarterly review was the moment I watched the whole thing unravel. Not dramatically. Quietly. Someone put up the metrics slide and the room went still for a moment. The numbers were ambiguous. Not bad, not good. The kind of result that requires interpretation. And that's when it became clear that nobody in that room had agreed, before the quarter started, on what the outcome actually looked like when it arrived. They had written outcome statements. They had not written success criteria. The difference is everything. An outcome statement says: we want users to complete the onboarding flow and reach their first meaningful action within seven days. A success criterion says: if fewer than forty percent of new users reach that milestone by day seven, we have not solved the problem and we do not move to the next phase. The first one sounds strategic. The second one is. Because the second one requires you to make a decision before you start building about what failure looks like. And making that decision in advance is the thing most teams cannot bring themselves to do. Here is why. Defining failure upfront means that someone in the room might be wrong. The PM who championed the feature. The designer who spent six weeks on the flow. The engineer who built the component everyone is proud of. Pre-defining failure makes accountability specific. And specific accountability, in most product organisations, is the thing nobody actually wants despite everyone saying they do. So teams write outcome language on their roadmaps and leave the success criteria vague enough to be interpreted generously at the end. Which means they've done all the work of outcomes thinking and retained all the escape routes of output thinking. That's not a shift. That's a rebrand. The team I was working with did what most teams do in that quarterly review. They found a number that was moving in the right direction and built the narrative around it. Not dishonestly. Nobody lied. But the outcome they had written at the start of the quarter had three components, and the one they were reporting on was the easiest one to hit. I asked the head of product afterward whether they'd achieved the outcome. She paused for a long time. "We made progress," she said. That pause was the whole problem. Progress toward an outcome and achieving an outcome are different things. But in the absence of a pre-agreed definition of success, progress is the story you tell when the result is inconclusive. And the result is almost always inconclusive when nobody agreed on what conclusive looks like. There is a simple test for whether your team is doing outcomes thinking or outcome language. Write down the outcome you're building toward. Then write down, in one sentence, what you will observe in user behaviour that will tell you the outcome was achieved. Not a metric range. Not "an increase in." A specific threshold that, if crossed, means yes, and if not crossed, means no. If you can't write that sentence before the sprint starts, you are not doing outcomes thinking. You are doing output thinking with better vocabulary. Most teams, when they try this, discover that they genuinely don't know what success looks like until they see the result. Which means they've been retrofitting the definition all along. Which means the shift they announced at the start of the year hasn't happened yet. It can. But not by rewriting the roadmap. The roadmap is the easy part. The harder part is sitting in a planning session and agreeing, out loud, on the number that means it didn't work. Most teams have never done that. And until they do, outcomes over outputs will remain the most widely cited, most narrowly practised idea in product strategy. The report is right. The priority is right. But a priority without a method is just a preference. And preferences don't show up in user behaviour.

Product StrategyMarch 5, 2024

The system nobody follows

Walk into IKEA and pick up any flat-pack furniture box. Inside, you will find an instruction sheet with no words. Just diagrams. Numbered steps. A small cartoon person holding the right tool at the right moment. The instructions look complete. They are not. What they assume is vast: that you know how to read a hex bolt diagram, that you understand which direction "clockwise" goes when you are upside down under a shelf, that you have a partner to hold the third panel while you align the fourth. The document is perfect on paper. It fails in the specific conditions of your Sunday afternoon. I think about IKEA instructions every time I hear a team say they have a design system. The promise of design systems was genuine. A shared visual language across a product reduces inconsistency, speeds up the design process, and gives engineering a stable contract to build from. The teams that articulated this vision were not wrong. Consistency is real. Efficiency is real. The Figma libraries, the component documentation, the token definitions, the contribution guidelines: all of it exists for good reasons. But a system is only as good as the conditions it was built for. But somewhere between the promise and the implementation, something reliably breaks down. Not in the components. In the conditions. I have now been in this conversation at three different companies, and the shape of it is always the same. A design system gets built. It gets celebrated. It gets presented to leadership with a slide that says "single source of truth." And then, about six months later, someone notices that half the product team isn't using it. Not because they are rebellious. But because the system was built for the product as it was, not the product as it needed to become. The specific failure I remember most clearly happened at a mid-sized SaaS company. We had spent the better part of a year building out a component library that any designer on the team would have been proud of. Documented, versioned, accessible-compliant, with a Figma file that was genuinely beautiful to look at. Three months after we shipped it, I sat down with one of the product designers who had been a vocal advocate for the system during its development. She was working on a new feature flow. I noticed she was building everything from scratch. "Why aren't you using the library?" I asked. She paused, which told me everything. "The components don't account for our new data structure," she said. "I tried to adapt them but they break in edge cases. It's faster to start fresh." She was not wrong about the faster part. But the faster part was destroying the thing the system was supposed to protect. And nobody had noticed because the metrics we tracked were component adoption, not product consistency. Here is what most teams miss when they build a design system: a system is not documentation. It is a set of decisions that have already been made so that future designers don't have to make them again. But those decisions have an expiry date. The product at the time the system was built is not the product six months later. New features arrive. New user research surfaces edge cases nobody anticipated. The data model changes. The system that solved last year's consistency problem is now a ceiling on next year's design thinking. This is not a failure of the system. It is the nature of systems. They encode what was true. They cannot anticipate what will be needed. But most teams treat the system as permanent. The component library becomes the constraint, not the starting point. And the designers who most need the system's consistency end up working around it, which is precisely the outcome everyone was trying to prevent. The teams I have seen get this right do one thing differently: they treat the system as a living product, with its own roadmap, its own feedback loops, and its own definition of done. Not a document. Not a library. A product. That means someone owns it the way a PM owns a product: with accountability for outcomes, not just outputs. The question isn't "is the system complete?" The question is "is the team using it, and when they aren't, do we understand why?" The gap between those two questions is where most design system efforts go quiet. The first question is answerable with a Notion page. But the second requires conversations nobody wants to have, because the answer is usually that the system solved the problem the team used to have, not the one they have now. And the team has moved on. But the system hasn't. The IKEA instructions are not broken. They are specific to a set of conditions. When the conditions change, the instructions fail silently. Nobody updates the diagram. You just end up with a shelf that wobbles. A design system that nobody follows is not a failed system. It is a system that succeeded at the wrong moment. But it is also a leadership failure, because someone decided that shipping the system was the finish line. The only question worth asking is whether you know the difference.

Product Design & Craft TopicsMarch 2, 2024

Everyone writes better now. That is the problem.

Generative AI has made everyone a competent writer. Grammar is cleaner. Sentences are smoother. Vocabulary is broader. And none of it matters, because when everyone sounds the same, sounding good is no longer a differentiator. It is camouflage. The paradox is almost too clean to believe. The tools designed to improve professional writing have, in aggregate, made most professional writing worse. Not grammatically worse. Structurally identical. The sentence rhythms match. The hedging patterns match. A generation of professionals now writes with the fluency of a competent copywriter and the distinctiveness of a hotel welcome card. That is not an improvement. That is a new kind of noise. The Batch That Broke I noticed it first during a product brief review at a company where I was advising. Three product managers had submitted briefs for three different initiatives. Different markets, different user segments, different strategic priorities. But the briefs read like they had been written by the same person. The same sentence structures. The same way of introducing a problem statement. The same careful, polished, entirely unremarkable prose. I asked one of the PMs whether she had used a writing tool. She had. She said it made her briefs "more professional." She was right. The prose was professional. But it was also indistinguishable from the other two. The professionalism had come at the cost of the one thing a product brief needs to do: convey a specific person's understanding of a specific problem. Her thinking was somewhere inside that document. But it had been smoothed into something no one would argue with, which meant no one would remember it. I started watching for the pattern, and once I saw it, I could not stop seeing it. LinkedIn posts from product leaders began reading like they were generated from the same prompt. Slack updates across teams I worked with developed an eerie uniformity. Investor updates from founders I mentor started arriving in prose so clean and measured that I could not tell whether the founder was excited, worried, or merely complying with a quarterly obligation. The voice had been polished away. What remained was text. The Sameness Tax I call this the sameness tax. It is the price you pay when your communication is technically correct but personally absent. The sameness tax is not measured in errors. It is measured in attention. When every product brief, stakeholder update, and internal memo reads like every other one, readers stop reading for meaning and start scanning for compliance. They skim. They check boxes. They move on. The writing has become furniture. Present, functional, and entirely invisible. But the sameness tax compounds. When your writing sounds like everyone else's, you lose the ability to signal what you actually think, as distinct from what a competent professional might think. A product leader's job is not to produce correct prose. It is to produce clear thinking in a voice others can trust, challenge, and respond to. When the voice disappears, so does the trust signal. You are not communicating. You are filing documents. The thing nobody warned us about AI-assisted writing is that it optimises for the average. It makes your worst writing better and your best writing blander. It lifts the floor and lowers the ceiling simultaneously. But most professionals only notice the floor lifting and mistake that for progress. What Voice Actually Is Voice is not style. It is not vocabulary choices or sentence length preferences. Voice is the residue of a specific mind thinking through a specific problem, and it shows up in the patterns that no tool would generate because they are too personal, too shaped by individual experience to be predicted by a model trained on the aggregate. At Freshworks, there was a product director who wrote the most distinctive stakeholder updates I have ever read. They were not literary. They were not polished in the way that AI prose is polished. But they were unmistakably hers. She had a habit of starting updates with the single most uncomfortable number from the previous quarter, no context, no framing, just the number. Then she would spend two paragraphs explaining why that number was the one that mattered. Her updates were the only ones that senior leadership actually discussed in meetings rather than acknowledged and moved past. Her voice was not a personality trait. It was a strategic asset. But here is what has changed. Before generative AI, distinctive voice was nice to have. Now it is the primary signal that separates human thought from generated text. When a founder sends me an investor update that reads like every other update I have seen that month, I do not think "this person writes well." I think "this person used a tool and did not edit for voice." The polish itself has become the tell. Voice as signal is the concept that matters now. Your distinctive way of communicating is no longer a stylistic preference. It is the primary evidence that a human being with specific knowledge and specific judgement produced this text. Without it, your writing joins the growing pile of competent, indistinguishable prose that nobody reads twice. The Intern Problem I ran into this most starkly while mentoring interns. I had asked three of them to write up findings from a user research sprint. Different products, different user segments, different insights. The write-ups arrived within an hour of each other. They were identical in everything but the specifics. Same sentence structure. Same transitional phrases. Same way of hedging uncertainty. Same slightly formal register that no twenty-two-year-old actually speaks in. I asked them directly. All three had used AI tools to "clean up" their drafts. The cleaning had removed every trace of the original thinking. One of them had written a rough first draft that was messy, specific, and full of observations that surprised me. The AI-polished version was correct and forgettable. She had taken something interesting and made it professionally invisible. But I could not blame them. Every signal in the professional world tells junior people that polished equals competent. Nobody had told them that polished and indistinguishable equals ignored. The most valuable writing skill in a world of AI is the one AI cannot replicate: a point of view. The Premium on Being Recognisable At Schneider Electric, I worked on building automation products, thermostats and energy management systems for facility managers who were not technical users. One of the hardest design challenges was making our interface distinct from competitors using the same component libraries and the same interaction patterns. Everything looked competent. But nothing looked specific. Professional communication is approaching the same problem. When every tool draws from the same training data and produces prose in the same register, the result is communication where nothing is wrong and nothing stands out. But standing out is not vanity. It is function. A product brief that sounds like every other product brief will be processed like every other product brief. A brief that sounds like a specific person thought hard about a specific problem will be read, argued with, and remembered. The premium is not on writing well. The premium is on being recognisable. But recognisability requires risk. It requires leaving in the rough edges that a tool would smooth away. It requires writing a sentence that is slightly too direct, slightly too shaped by your own experience to be mistaken for generated text. It requires trusting that the reader will value your thinking over your grammar. The tools will keep getting better at producing competent text. But competent text is not what leadership communication requires. It requires conviction, specificity, and the willingness to sound like exactly one person in a world that is rapidly learning to sound like everyone.

Communication & Storytelling February 20, 2024

Your AI Feature Has a Problem. Nobody Is Using It.

Every January, gyms make a bet. They buy extra equipment, hire extra staff, extend their hours. They spend money they haven't earned yet on a surge they know is coming. The surge always arrives. Two weeks of packed classes, waitlists for the squat racks, strangers asking if you're using that bench. The gym hasn't felt this alive in eleven months. But by the third week of February, the gym looks exactly like it did in December. Same regulars. Same empty treadmills in the corner. Same staff wondering what happened to all those members who swore this year was different. The memberships were real. The commitment was performance. Spend ten minutes with a product changelog from any technology company in 2023 and you'll find the same pattern. AI features announced with confidence, shipped on schedule, measured with the kind of silence that product teams learn to explain away as an early adoption curve. It's not an adoption curve. But teams keep treating it like one, which is a more comfortable position than the alternative. I worked with a team at a mid-sized SaaS company last year who shipped four AI features in eight months. The brief for each one started the same way: "We need an AI play for this part of the product." Not "users are struggling with this specific workflow." Not "we've identified a problem that AI solves better than anything else we've tried." The brief was the technology, looking for a problem to justify it. The fourth feature had a name, a launch announcement, and a product walkthrough video that did reasonably well on LinkedIn. Three months later, fewer than six percent of active users had touched it. The team lead delivered the number like a weather report. Unfortunate. Not their fault. But it was exactly their fault. Just not in the way they thought. The mistake wasn't building AI features. The mistake was treating "AI" as a brief instead of as an answer to a brief. Nobody walks into a roadmap session and says "we need a dropdown play for the onboarding flow." Dropdowns are tools. You reach for them when they solve the problem. But in 2023, AI stopped being a tool and became a category of ambition. And ambition, it turns out, is very bad at asking whether the user actually has the problem you're solving for. Every product team I spoke with last year was running the same internal conversation. Someone senior had returned from a conference, or finished a long read on a Sunday afternoon, and the message coming down was clear: we need to be doing more with this. Teams heard that correctly. But they translated it into "what should we build with AI" when the actual question was "what are our users struggling with, and is AI the right answer." Those are different questions. The gap between them is where most of 2023's AI features currently live. Here is what makes this hard to diagnose from inside a team. The pressure to ship AI features wasn't irrational. The competitive environment was genuinely moving fast. A team that spent Q1 2023 asking whether AI was right for their product looked, from the outside, exactly like a team that was paralysed. There is no visible difference between disciplined validation and being slow. Both look like not shipping. But there is an internal difference. One has a clear answer to the question: what problem does this solve for the person using it? The other has a launch date and a LinkedIn announcement ready to go. I ran a workshop with a product team in the second half of last year. Genuinely sharp people who cared about their users. But they'd shipped an AI summarisation feature that nobody was using and they couldn't understand why. Morale was odd. The feature was beautiful. The metrics were not. We spent forty minutes mapping the actual workflow. Not the one they'd designed for. The one users were actually running day to day. About halfway through, someone said it, quietly: "they don't actually read these documents anyway." The AI feature summarised documents users weren't reading. Faster access to something nobody wanted was still something nobody wanted. The feature wasn't wrong. The problem statement was. This is the reckoning that 2024 is starting to force. Not whether AI belongs in products. It does, and it will, in ways that will be genuinely valuable. But whether the discipline that applies to every other product decision applies equally when the technology is exciting enough to make teams forget to ask the basic questions. It should. But in 2023, for a lot of teams, it didn't. The gym analogy holds further than it first appears. The gyms that retain members past February are not the ones with the best equipment. They're the ones that figured out what people actually struggle with in January. Not the gear they think they need. But the accountability, the structure, the small social contract that makes staying home feel like a decision rather than a default. Those gyms were thinking about the problem. The others were thinking about the surge. Product teams that start with what users genuinely struggle with, and then ask whether AI is the right answer, will build things people use. But the teams still asking "what's our AI play" will have excellent changelogs and very quiet dashboards. The infrastructure will be real. The commitment, from the user, won't be.

Product StrategyFebruary 15, 2024

The unit economics reckoning

The most celebrated startups of the cheap-capital era had something in common. Extraordinary growth rates. Enormous user bases. And, in a remarkable number of cases, no coherent explanation for how they would ever make more money than they spent acquiring each customer. That was the paradox. Growth was the proof of value. Growth was also the mechanism by which value was destroyed. Nobody talked about this when the money was flowing. Venture capital was cheap, rounds were large, and the implicit contract was simple: grow now, figure out the economics later. Later turned out to be a specific moment. The moment when interest rates went up, funding tightened, and finance teams started asking questions that product teams had never needed to answer. Why this matters to product people There's a common assumption in product teams that unit economics belong to finance. That CAC, LTV, payback periods, and margin calculations are someone else's spreadsheet. Product people build the thing. Finance people figure out whether the thing makes money. But this is a structural misunderstanding of how products actually work. Every product decision is a unit economics decision. The onboarding flow that takes four days instead of one is a CAC decision (it costs more to convert a user who takes four days to understand the product). The feature that increases daily active usage but doesn't connect to any monetisation event is an LTV decision (engagement without revenue is just server cost with better optics). The pricing tier that's too cheap to justify sales involvement but too expensive for self-serve is a margin decision hiding inside a pricing page. Product teams that don't understand this aren't just leaving money to someone else. They're making commercial decisions without knowing it. Which is worse. The denominator problem At my first startup, we had a dashboard that everyone loved. Users acquired this week. Users acquired this month. The graph went up and to the right. It was the kind of chart you put in an investor update. It felt like progress. But nobody had built the other dashboard. The one that showed what each of those users cost to acquire. The one that showed what each of them was worth over time. The one that divided revenue by the number that mattered, not the number that felt good. I call this the denominator problem. Every product team has a numerator they celebrate. Users. Downloads. Sign-ups. Active sessions. But the denominator, the cost of acquiring each one and the revenue each one generates, is invisible until someone forces it onto the screen. We didn't force it onto the screen until month fourteen. By then we'd burned through most of our runway celebrating a numerator that was growing while the denominator was eating us alive. We had ten thousand users. Our cost to acquire each one was roughly four times what they'd ever pay us. Growth without unit economics is a story you tell yourself until the money runs out. Ours ran out on a Tuesday. The bank balance was the punchline nobody laughed at. A farmer who measures crop yield by the number of seeds planted, not by the harvest, would be bankrupt in two seasons. We were that farmer. We just had better graphs. The growth mirage The first startup taught me what happens when you don't know your economics. Adobe taught me what happens when an organisation treats them as sacred. At Adobe, every feature had a commercial case attached to it before it entered the roadmap. Not a vague "this will improve retention" claim. A specific argument: this feature will reduce churn by X percent in this segment, which translates to Y dollars retained over Z months. If the math didn't hold, the feature didn't get built. Full stop. I found it frustrating at first. It felt like the finance team was standing between design and the user. But over time, I saw what it actually produced. Discipline. Not every feature needed a direct revenue line. But every feature needed someone who could articulate why it was worth the cost of building and maintaining it. That's a different question from "is this a good idea," and it's a harder question. It's also the right one. The growth mirage is what happens when teams answer the easy question and skip the hard one. Is this a good feature? Yes. Will users like it? Probably. Does it move a commercial metric that matters to the survival of this business? Silence. I've sat in roadmap reviews at three different companies where nobody in the room could connect a single planned feature to a specific revenue outcome. Not because the features were bad. But because the habit of asking had never been built. The culture rewarded shipping. Nobody had thought to reward shipping things that made the business work. The how: three numbers every product person should know You don't need a finance degree. But you need to know three numbers for your product. The first is your acquisition cost. Not the marketing budget divided by sign-ups. The fully loaded cost: marketing, sales, onboarding support, the engineering hours spent on the acquisition funnel, the time your PM spent writing copy for the landing page at midnight. All of it. Most product teams undercount this by 40 to 60 percent because they only count what marketing spends. The second is your customer lifetime value. Not a projection based on the assumption that every user stays for three years. The actual, observed value of a customer over the time they've actually been a customer. Early-stage companies often don't have this number because they haven't existed long enough. But the honest estimate, with assumptions stated clearly, is better than the fiction of "we assume 36-month retention" when the product has been live for nine. The third is the ratio between them. If it costs you more to acquire a customer than that customer will ever pay you, you do not have a business. You have a mechanism for converting investor money into user growth. Those are different things, and the difference matters when the investor money stops. What changes when you know Knowing your unit economics doesn't constrain creativity. It redirects it. The product team that knows acquisition cost is too high starts thinking about viral loops, referral mechanics, and onboarding that converts faster. The team that knows LTV is too low starts thinking about expansion revenue, usage depth, and the features that make someone stay for month thirteen instead of leaving at month six. But the team that doesn't know either number builds whatever feels right and hopes the spreadsheet works itself out. Hope is a fine personal quality. It is a terrible commercial strategy. The reckoning that arrived when capital tightened wasn't a surprise to anyone who understood their own numbers. It was only a surprise to teams that had never looked at them. And the uncomfortable truth is that many product teams, filled with genuinely talented people, had simply never been asked to. That's the part I keep coming back to. Not that product people failed at unit economics. But that nobody thought to teach them. The finance team assumed product understood. Product assumed finance had it covered. And in the gap between those two assumptions, entire companies burned through their runway building things that users loved and the business couldn't afford. If you're early in your career and none of this was part of your training, that's not your fault. But it's your problem now. The good news is that the math isn't hard. The discipline is. And discipline, unlike capital, is something you can build for yourself.

The Business of ProductsFebruary 14, 2024

The production trap

A junior designer I was mentoring last year sent me a message at 11pm on a Tuesday. She had been working at a product studio for eight months, she was good, her manager liked her work, and she had just watched a colleague generate a complete set of UI screens from a text prompt in about twenty minutes. "I spent three days on something that just took him twenty minutes," she wrote. "What am I even doing here?" I did not have a quick answer. Which is how I knew it was the right question. The debate running through design communities right now is framed as tool versus threat. AI is either a productivity multiplier that frees designers to do higher-order thinking, or it is an accelerant compressing the bottom of the profession until entry-level roles stop existing. Both camps are loud. Both have evidence. Both are, in a specific and important way, missing the point. But the question was never tool or threat. The question is: what do you think design actually is? The question is: what do you think design actually is? If your answer is production, the threat is real and it is already here. But if your answer is judgment, the tools change the shape of the work without threatening the value of doing it well. The distinction matters more than anything else being said in this debate right now. I fell into the production trap myself, early in my career. I was at a large enterprise, designing complex B2B software, and I was proud of how quickly I could turn around polished deliverables. High-fidelity screens, annotated specs, detailed component documentation. Stakeholders complimented the quality. My manager mentioned it in reviews. I thought that was the job. But it took a senior product leader pulling me aside after a presentation to say something I have not forgotten: "Your screens are beautiful. But you're solving the wrong problem." She was not being unkind. She was being accurate. I had been so focused on producing good work that I had stopped asking whether the work I was producing was good to produce. That is the production trap in full: you get so fast at making things that making things becomes the goal. Here is what the AI anxiety in design is actually surfacing, if you look at it without flinching. A generation of designers were trained, implicitly, to believe their value lived inside the artifact. The screen. The system. The prototype. The thing you could put in a portfolio, show in a case study, and hand off to engineering with a Figma link. But that was never the full job. It was the visible part of the job. And visibility got confused with value so completely that most designers never separated the two. The designers who are genuinely at risk right now are not necessarily the ones with weaker skills. They are the ones whose entire professional identity sits inside production, because the thing they have optimised for is the thing being automated fastest. And they never built the second layer. But the second layer was always the real job. The second layer is everything that happens before the screens exist. The framing of the problem. The pushback on the brief when the brief is wrong. The ability to walk into a room full of stakeholders who all want different things and leave with a shared definition of what success looks like. The judgment to know when a user research finding should change the product direction and when it is noise. You cannot prompt your way to that. Not because AI isn't capable of surprising things, but because judgment requires stakes. It requires having been wrong before in ways that cost something. It requires scar tissue from decisions that looked right on the surface and failed in practice. AI tools do not have scar tissue. But more importantly, the people who hired you don't need your scar tissue replaced. They need it applied. When I think about what to tell junior designers right now, I resist the instinct to offer false comfort. The profession is changing. Some of what took days will get faster. Some of what took weeks will get automated. That is not a rumour. But the change is also revealing something true that the profession has been obscuring for years: design was never primarily about making things. It was about deciding things. The making was how you proved you decided correctly. The designers I have watched stay relevant through disruption, across every industry I have worked in, had one thing in common. They were never just the person who made the screens. They were the person who understood why those screens existed, what problem they were actually solving, and what would happen to real people if the team got it wrong. No tool replaces that. Not because it isn't possible in principle. But because the organisations that need design are full of competing incentives and partial information and people who have not yet fully understood their own problem. Getting through all of that requires presence. It requires being in the room. The junior designer who messaged me at 11pm replied to my response with: "So I need to stop thinking of myself as someone who makes things?" Close, I told her. Think of yourself as someone who decides things. The making is just how you prove you decided correctly. She still makes things. She has just stopped believing that is why she matters.

Product Design & Craft TopicsFebruary 9, 2024

The IC-to-leadership transition is the hardest career move in product, and most people fail it for the same reason

Three weeks into my first leadership role at Adobe, I stayed up until 2 a.m. redesigning a navigation flow that one of my junior designers had submitted. It was not bad work. It was good work, honestly. But I could see a better version in my head, and my fingers were already on the keyboard, and some part of my brain whispered "you can fix this in forty minutes." So I did. I fixed it. I also fixed two other screens she had been working on. Then I presented the revised designs in our Monday review as if the team had produced them together. Nobody said anything. But something had shifted. Two weeks later, that junior designer walked into a one-on-one meeting and said, very quietly, "I do not know what my job is if you keep redoing my work." I have been thinking about that sentence for years now. It was the most important piece of feedback I have ever received in my career. The maker's trap There is a pattern I see repeated so consistently in IC-to-leadership transitions that I have started calling it the maker's trap. Someone spends years becoming exceptionally good at the craft of product work. They write better PRDs than anyone on the team. They spot edge cases that nobody else catches. Their personal output gets them promoted. Then the promotion arrives. And they carry every one of those instincts into a role where those instincts are poison. The maker's trap is not about ego, though ego plays a part. It is about identity. When you have spent a decade defining yourself by the quality of your direct output, stepping back from that output feels like losing a limb. But leadership does not reward your personal output. It rewards the collective output of a team you have enabled. Those are not the same thing. I remember sitting in a skip-level meeting at Adobe where my director asked me what my team had shipped that quarter. I instinctively started listing the things I had personally contributed to. He stopped me and said, "I asked what your team shipped. Not what you shipped." That correction stung. It also clarified something I had been avoiding. The Freshworks PRD machine I watched this play out again at Freshworks. A senior PM, one of the sharpest product thinkers I have worked with, got promoted to lead a team of four PMs. His PRDs were a masterclass in clarity. Everyone agreed he was ready. But six months into the role, he was still writing every PRD himself. All four of them. His team would draft something, and he would rewrite it top to bottom before it went to engineering. When I asked him why, he said, "It is just faster if I do it myself." He was right, in the short term. His PRDs were better than what his team would have produced. But his team was not learning. They were not developing judgment, because he never gave them the space to exercise judgment. They were not making mistakes, because he caught every mistake before it left the room. And people who do not make mistakes do not grow. Two of the four PMs left within a year. One of them told me during an exit conversation that he felt "decorative." That word has stayed with me. The maker's trap does not just hurt the leader. It hollows out the team. The letting-go tax The hardest part of becoming a leader is not learning new skills. It is unlearning the ones that got you promoted. I call the cost of this unlearning the letting-go tax. It is the period where you watch work go out the door that is not as good as what you would have produced yourself, and you have to accept that. You have to tolerate a temporary dip in quality because the alternative, doing everything yourself, is a guaranteed ceiling on what the team can accomplish. Nobody tells you about the letting-go tax. Nobody warns you that for six months, maybe longer, things will feel worse before they feel better. You will sit in a review and see a decision your PM made that you would have made differently, and you will have to let it stand because overriding it sends a signal more damaging than the imperfect decision itself. But that tax is the price of scale. An IC's output is bounded by the hours in their day. A leader's output is bounded by the capability of their team. If you never pay the letting-go tax, you never expand beyond your own capacity. You become a very expensive individual contributor with a leadership title. At Boeing, I saw the same pattern with engineering leads. The ones who kept solving every technical problem themselves had teams that could not function without them. The ones who tolerated imperfect solutions early on had teams that eventually surpassed what any single engineer could produce. The identity shift The real transition is not from IC to leader. It is from "I am the person who does the best work" to "I am the person who makes other people do their best work." That sounds simple on paper. It is agonising in practice. Leadership is not doing the work better than everyone else. It is making sure the work gets done without you. But here is what nobody tells you about the other side of the maker's trap: there is a different kind of satisfaction waiting there. Not the satisfaction of craft. The satisfaction of watching someone you mentored make a decision you would not have thought of yourself. I think about my junior designer at Adobe, the one who told me she did not know what her job was. A year after that conversation, after I had learned to sit on my hands, she redesigned our entire onboarding flow. It was better than anything I would have produced. Not marginally better. Genuinely better. She had spent months close to users in a way I never had time for because I was too busy being the person who "fixed" things. But that outcome was only possible because I stopped. Because I paid the letting-go tax, tolerated the discomfort, and gave her room to become better than me. The Freshworks PM I mentioned, he eventually figured it out too. But it took losing two team members for the lesson to land. The maker's trap has a tuition, and the tuition is always paid in people. Not everyone survives the transition. Some people are genuinely happier and more effective as senior ICs, and there is no shame in that. What the silence teaches The strangest part of leadership is how quiet the wins are. When you are an IC, the wins are visible. You shipped the feature. You wrote the spec. Your name is on the work. But when you are a leader, the best days are the ones where nothing requires your involvement. The team made the call. The designer nailed the flow. Nobody needed you. That absence of need is the win. It is not a promotion. It is a profession change wearing the same job title. The crossing requires leaving the old self behind, standing in the uncomfortable middle ground where you are no longer the best maker in the room, and trusting that what you are becoming is worth what you are giving up.

Product Leadership & CareerFebruary 4, 2024

Deep work under siege

We have more tools for concentration than any generation of knowledge workers before us. Noise-cancelling headphones. Focus-mode toggles on every device. Apps that block other apps. Pomodoro timers shaped like tomatoes, because apparently the fruit was the missing variable. And yet the average knowledge worker in 2024 is interrupted roughly thirty-one times per day and spends seventy per cent more time in meetings than they did in 2020. We built an arsenal of focus tools and then used them to decorate the margins of a calendar that belongs to everyone else. The paradox is worth sitting with. The era that gave us the most sophisticated attention-protection technology also produced the most fractured attention in the history of office work. Something went structurally wrong, and it was not a failure of willpower. The meeting creep nobody voted for Remote work was supposed to liberate us from conference-room culture. And for about six months in 2020, it did. Calendars opened up. People reported thinking more clearly, working in longer unbroken stretches, rediscovering what it felt like to hold a problem in their head for ninety continuous minutes. But then something predictable happened. Organisations, nervous about losing visibility into what people were doing, replaced physical presence with digital presence. The stand-up became a video call. The hallway check-in became a scheduled slot. The informal whiteboard session became a recurring ceremony with a calendar invite, a Zoom link, and an implied obligation to keep your camera on. But the real damage was not any single meeting. It was the cumulative architecture. When your calendar has six meetings scattered across the day, you do not have six meetings and several hours of free time. You have six meetings and several fragments of time too short to hold a real thought. Deep work does not happen in the gaps between meetings. The gaps are where it goes to die. I watched this unfold at Grab in real time. We were building products for markets across Southeast Asia, and the coordination overhead was genuine. Different time zones, different regulatory environments, different user behaviours by country. But the response to that complexity was more synchronous meetings, not fewer. By the time I mapped a typical product manager's week, the picture was grim: twenty-three hours of scheduled meetings. That left seventeen hours in a standard forty-hour week. But those seventeen hours were not contiguous blocks. They were confetti. Fifteen minutes here, twenty-two minutes there, a luxurious forty-five-minute stretch on Thursday afternoon that inevitably got claimed by a "quick sync." The most important product thinking of the quarter was supposed to happen inside that confetti. Why willpower fails and architecture works The common advice is to "protect your focus time." It sounds reasonable. But it frames the problem as an individual discipline challenge, which is a bit like telling someone to protect their lungs while the building fills with smoke. I learned this the hard way at Freshworks. I had adopted the habit of blocking two-hour focus windows on my calendar every morning. Colour-coded them red. Labelled them "Deep Work, Do Not Book." For the first two weeks, it worked beautifully. But by week three, the blocks started getting overridden. A stakeholder would message: "I see you have something from 9 to 11, but this is urgent." And because it was on a screen, not behind a closed door with a physical lock, the social cost of declining felt higher than the cost of surrendering the block. This is the pattern I call The Focus Fortress problem. You can build the walls. But if the culture treats every wall as negotiable, you have built a suggestion, not a structure. The fortress has to be embedded in something the organisation recognises as legitimate, or it will be breached every time someone has a "quick question." What finally worked was not individual calendar blocking. It was team-level agreements. When a product trio agrees that mornings before 11 a.m. are synchronous-meeting-free, and when engineering leadership reinforces that norm, the fortress becomes structural. One person's red block is a request. A team's shared norm is architecture. Nobody argues with architecture. Calendar Negative Space The concept I keep returning to is what I think of as Calendar Negative Space. In photography and design, negative space is not emptiness. It is the deliberate absence that gives the positive elements room to breathe, room to mean something. A calendar works the same way. The unscheduled time is not leftover time. It is the most valuable time on the calendar, the time where the actual product thinking happens. But most organisations treat calendar negative space as inventory to be consumed. If a slot is open, it is available. If it is available, someone will claim it. The calendar operates like a gas, expanding to fill every container. I once asked a product director at a large petroleum company how many hours per week she spent in genuinely generative thinking. The kind where she was holding a user problem in her mind, turning it over, connecting it to business constraints, sketching possible solutions. She paused for a long time. "Maybe two," she said. "On a good week." But she was working fifty-hour weeks. Ninety-six per cent of her time was the mechanics of product work. Four per cent was the thinking that product work actually is. That ratio is not unusual. It is the norm. The calendar had become the product, and the product had become an afterthought. So what does an architectural defence look like in practice? Three things I have seen work consistently. First, time-box the shallow work instead of the deep work. Schedule your meetings into a defined afternoon window and let the morning be unstructured by default. Now the burden of proof shifts: someone who wants your morning has to justify pulling you out of deep work, rather than you having to justify staying in it. Second, make the cost of interruptions visible. At Grab, I started logging every interruption for two weeks. Not to shame anyone, but to create data. My most productive ninety-minute stretch had produced more measurable output than three full days of fragmented work combined. Data does not fix culture by itself. But it gives reformers something concrete to point at. Third, negotiate at the team level. A single person blocking focus time is making a personal lifestyle choice, easy to override. But a team agreeing that certain hours are sacred is establishing a working norm. Norms are much harder to breach than preferences. The maths over time is stark. A product manager who gets three hours of uninterrupted thinking per day will, over a quarter, accumulate roughly sixty hours of deep work. A product manager whose focus is sliced into fifteen-minute fragments will accumulate close to zero usable hours, because cognitive switching cost eats most of each fragment before real thinking begins. But both will appear equally "busy" in any utilisation report. You cannot think your way to a better product in eleven-minute increments between stand-ups. If you are recognising this pattern in your own calendar, the intervention is not another productivity hack. It is a conversation with your team about what you are collectively willing to protect. The tools already exist. The headphones are on your desk. But the architecture of your day has to make room for the thinking your role actually requires, or no tool will save you. That is not a discipline problem. It is a design problem. And product people, of all people, should know the difference.

Productivity & Working MethodsFebruary 1, 2024

The best decision makers make their worst decisions at 4pm

Here is a paradox that product leaders rarely examine. The people who are best at making decisions are also the people making the worst ones, and the only variable separating their best calls from their worst is the time of day. Not complexity. Not information quality. Not stakeholder pressure. The clock. And that should unsettle every senior product person reading this. Product leaders make dozens of decisions daily. Most feel manageable. You approve a design direction before lunch. You settle a prioritisation dispute between two squads after your second coffee. You sign off on an experiment's success criteria during a stand-up. Each one, on its own, feels like a small exertion. And because the individual cost feels low, you treat them as free. But the cognitive resource that decision-making draws on is finite, and it depletes through the day in ways you cannot feel happening. By mid-afternoon, the account is overdrawn. But the invoices keep arriving. This is decision fatigue, and in early 2024 it has become the hidden tax on product leadership that almost nobody is managing deliberately. The Invisible Account I want to introduce a concept I have started calling The Depletion Ledger. Every decision you make, regardless of its apparent stakes, withdraws from the same cognitive account. But there is no balance notification. No red warning banner. No overdraft alert. You simply start making worse calls, and the dangerous part is that you feel exactly as confident making them. Decision fatigue is not tiredness. It is the quiet depletion of the resource you need most and notice least. I learned this the expensive way at Adobe. We were deep in a product integration cycle, and I had spent the morning in back-to-back syncs, approving copy changes, resolving a minor API versioning disagreement, and reviewing three separate A/B test proposals. None of it felt taxing. But by 4pm, when the actual consequential meeting arrived, a session to decide whether we should pivot our onboarding strategy for a segment that represented roughly 30% of new revenue, I was already spent. I did not know I was spent. I sat in that room, listened to two well-argued positions, and picked the one that required fewer follow-up decisions. Not the better strategy. The easier one. The one that let me stop deciding. It took three weeks to realise the mistake. Three weeks and a set of onboarding metrics that told a story I should have predicted. But the truly unsettling part was this: at the moment I made the call, it felt perfectly sound. The decision was not hard. I had simply arrived at it empty. Why the Day Runs Backwards Most product leaders structure their days in a way that is precisely inverted from what the research supports. They frontload mornings with low-stakes calls and synchronous check-ins. Stand-ups at 9. One-on-ones at 10. Design reviews at 11. By the time the genuinely consequential work arrives, the strategic decisions about roadmap bets, partnership terms, or pricing model changes, the cognitive budget is already gone. But here is what makes this worse. The low-stakes decisions feel productive. You clear your inbox. You unblock three people. You resolve a Slack thread. But each micro-decision nibbles at the same finite resource. And the high-stakes decisions that arrive later do not get a fresh budget. They get the scraps. I have watched this pattern repeat across every organisation I have worked in. At Freshworks, I noticed it most clearly because the product team was spread across time zones, which meant the consequential calls often landed in the late afternoon for the India-based leaders. But the pattern was not about geography. It was about sequence. The leaders who scheduled their thinking work first consistently made better strategic calls. The ones who "got the small stuff out of the way" first consistently made worse ones. The correlation was stark enough to be embarrassing. The Two-Hour Vault The specific practice that has been circulating among senior product people in early 2024 is deceptively simple: reserve the first two hours of each working day strictly for the highest-stakes thinking. No Slack. No stand-ups. No "quick syncs." No email triage. Just the decisions that carry the most weight. I call this The Two-Hour Vault, and it sounds almost comically easy until you try to implement it. The resistance is immediate. Your team wants morning alignment. Your manager wants a 9:30 check-in. Your calendar is a Tetris board someone else assembled. But the maths is unforgiving. If your best cognitive resources exist between 8 and 10am, and you spend them on decisions that a junior PM could make, you have traded your most valuable asset for your least valuable work. When I moved from Bangalore to Wayanad, one of the unexpected gifts was that the slower mornings made it easier to protect that window. No commute eating into the first hour. No office small talk burning fifteen minutes of prime cognition. But I also learned something subtler. The vault is not just about blocking time. It is about what you do not allow into the first two hours. Every "quick question" you answer is a withdrawal. Every notification you glance at is a withdrawal. The vault only works if the walls are real. A product leader who protects their first two hours is not being precious. They are being strategic about a resource that does not regenerate on demand. The Decisions That Get Worse At Boeing, early in my career, I watched a senior engineering manager who seemed to make effortlessly good calls. I assumed it was experience. But when I paid closer attention, I realised his calendar told a different story. He simply refused meetings before 10am. Not because he was lazy. Because he had learned, probably through failures he never discussed, that his first two hours were worth more than any meeting. I thought he was eccentric at the time. I now think he was one of the few people who understood the ledger. Not all decisions degrade equally under fatigue. The ones that suffer most are the ones requiring you to resist the default, to say no when yes is easier, to ask for more data when the room wants to move forward. Fatigued decision-makers default to the path of least resistance. They approve instead of questioning. They agree instead of pushing back. But they rarely notice the drift until the consequences arrive weeks later. But this is precisely the type of decision that product leaders are paid to make well. The job is not to approve things. The job is to make the calls that shape what the product becomes. The tragedy is not that product leaders make bad decisions. It is that they make bad decisions with their best thinking already spent on decisions that did not matter. The calendar is not a schedule. It is a resource allocation plan for your cognition. And right now, most of those plans are badly misallocated. Protect the mornings. Not because the afternoons do not matter, but because the decisions you make at 4pm are only as good as what you did not spend at 9am.

Productivity & Working MethodsJanuary 30, 2024

Buyers arrive with their minds already made up

The most successful demo I ever sat through had nothing to do with the product. The prospect had already decided. I could see it in the way they nodded, the way they asked questions designed to confirm rather than interrogate, the way they steered the conversation toward implementation timelines before we had finished the second slide. The demo was not a test. It was a ceremony. And we performed it beautifully. Because that is what you do when the room has already chosen you. You give them the evidence they need to tell their procurement team, their CFO, their board that they did their due diligence. But here is the thing most product teams never confront: that demo was not where the deal was won. It was won weeks earlier, in conversations we were never part of, in peer recommendations we never saw, in a decision made quietly before anyone on our side picked up the phone. The post-rationalisation window TrustRadius data paints a picture that should unsettle every product and go-to-market team in B2B. Shortlists have shrunk. Not from ten products to five. From four or five down to one to three. And 71% of buyers go with their first-choice product after creating that shortlist. The research phase, the part where teams assume persuasion happens, is not where the decision lives. It is where the decision gets dressed up. I call this the post-rationalisation window. The period between a buyer deciding and a buyer appearing to decide. It looks like evaluation. It feels like evaluation. Your analytics might even track it as evaluation. But the buyer is not weighing options. They are collecting evidence to support a conclusion they have already reached. This is not cynicism. It is human psychology. People decide with instinct, pattern recognition, and social proof. Then they build a rational case after the fact. Buying a B2B product is no different from buying a house or choosing a restaurant. The gut moves first. The spreadsheet follows. But most product teams build their entire go-to-market around that spreadsheet. At Freshworks, I watched this play out in enterprise deal after enterprise deal. The prospects who were genuinely undecided looked different from the ones who had already made up their minds. The undecided ones interrogated. They pushed back on claims. They asked uncomfortable questions about edge cases and integrations. The decided ones asked easy questions. They smiled. They wanted to know about onboarding. The demo, for the decided buyer, was a performance for the procurement team. Not a genuine evaluation. The sales team knew this instinctively but never said it out loud, because saying it would raise an awkward question: if the decision is already made before the demo, what exactly is the demo for? The phantom evaluation I have a name for what happens when a product team invests heavily in a stage the buyer has already passed through. I call it the phantom evaluation. Your team prepares for weeks. You rehearse the demo. You build custom slides. You assemble your best people in a conference room. And the buyer sits through it politely, because they need to demonstrate process compliance to their internal stakeholders. The demo is theatre for an audience that has already chosen the ending. But the phantom evaluation is not harmless. It consumes enormous resources. Product teams build features to win evaluations that were never genuine competitions. Sales engineers spend days on proof-of-concept environments that exist to satisfy a checkbox, not to change a mind. Marketing produces comparison content for a decision that was made over coffee two weeks earlier, when a buyer's former colleague mentioned your competitor's name. The waste is invisible because it looks like work. It looks like rigour. But it is rigour applied to a process that has already concluded. I saw the mirror image of this at Nike, in a completely different context. Retail. Consumer. Physical stores. But the pattern was identical. Consumers were arriving at the store having already decided what they wanted to buy. They had seen it on a friend. They had read about it. They had scrolled past it fourteen times on their phone. The in-store experience was not conversion. It was confirmation. The store associates who understood this were brilliant. They did not try to sell. They reinforced the choice the customer had already made. "Great choice, that colourway has been moving fast." The associates who tried to redirect, who pitched alternatives, who treated the interaction as a fresh sales opportunity, consistently underperformed. They were trying to influence a decision that had already been made by the time the customer walked through the door. Which is exactly the same mistake most B2B product teams make with their demos. Where influence actually lives If the decision is made before the formal evaluation, the question product teams need to ask is not how to win the demo. It is how to win the conversation that happens before the demo is ever scheduled. But this is harder. Because that conversation is invisible. It happens in Slack channels you are not in. It happens when a VP asks a peer at another company what they use. It happens when a product manager reads a thread on LinkedIn where someone recommends a tool for a problem they recognise. It happens in the dark, outside your funnel, beyond your analytics, in spaces your marketing team does not control. The implication is uncomfortable. You are not selling. You are helping the buyer justify what they have already decided. And if that is true, then the real product work is not building a better demo. It is building a product that people talk about before the buying process starts. Peer influence. Word of mouth. The quality of the experience your existing users have. The things those users say about you when nobody from your company is in the room. That is your real sales motion. Everything else is post-production. But most go-to-market strategies still treat the formal evaluation as the main event. They invest in demo environments, sales decks, competitive battle cards, and objection-handling playbooks. All of which matter. But all of which arrive after the verdict. Think of a jury that has decided the case before the closing arguments begin. The lawyers still argue. The judge still instructs. The process still runs. But the outcome was settled in the jury room hours ago, based on evidence presented days earlier. The closing arguments exist for the record, not for the decision. Building for the moment before the moment The product teams that understand this do not stop investing in demos and evaluations. But they invest differently. They put more into what the product feels like in the first five minutes of a free trial, because that is where the real evaluation happens, alone, without a sales engineer narrating the experience. They put more into making existing customers successful, because those customers are the ones generating the recommendations that create the shortlist. They put more into public product quality, the kind a buyer encounters before anyone from the company knows they exist. But this requires a kind of humility that most product organisations struggle with. It requires accepting that the moment of maximum influence is not the moment you control. It is the moment you never see. The best product work happens long before the buyer raises their hand. It happens in the experience you built for someone else, someone who liked it enough to mention your name when a colleague asked what they should use. That quiet recommendation carries more weight than any demo you will ever build. And you will never see it happen.

User & Buyer PsychologyJanuary 5, 2024

The Budget Didn't Give You Focus. It Was Just Hiding the Absence of It.

There is a restaurant in the city I used to live in that has been open for eleven years. It survived a flooded kitchen, two ownership changes, and a period where the head chef left without warning in the middle of a Saturday service. What it did not survive, at least not gracefully, was success. In its fifth year, it expanded. New premises, bigger kitchen, twice the staff. The menu went from fourteen dishes to forty-two. The logic was sound: more covers, more options, more revenue. For about eighteen months it worked. Then it didn't. Reviews started noting that the food was inconsistent. The kitchen was doing too many things at once. The dishes that had made the restaurant worth going to in the first place were still on the menu but they weren't the same. The chef was spread across forty-two problems instead of focused on fourteen solutions. The restaurant didn't have a menu problem. It had a belief problem. It had stopped knowing what it was actually for. I've been thinking about that restaurant a lot this January. The conversation in most product teams right now is about cutting. Headcount is down. Budgets are tighter than they've been in three years. Every roadmap review I've sat in since October has had the same energy: we need to do less, we need to focus, we need to make sharper bets. All of which is correct. But most teams are approaching it the wrong way. They're starting with the list. They pull up the roadmap, look at what's on it, and start removing the items that are hardest to defend. The newest additions go first. The speculative bets get cut. The things that haven't started yet are the easiest to kill. And three weeks later the team has a shorter roadmap that feels more manageable but is structurally identical to the original one. Same thinking. Fewer items. That's not focus. That's a smaller version of the same unfocused strategy. The restaurant that cuts twenty-eight dishes by removing the least popular ones still has a kitchen trying to do too many things. The restaurant that cuts twenty-eight dishes by asking "what are we actually brilliant at and willing to commit to" ends up with something different. Not just shorter. Sharper. The question that produces focus is not "what can we remove." It's "what do we believe in enough to protect when everything else is being challenged." Most product teams, when the pressure arrived, discovered they didn't have a clear answer. I worked with a team last year that went through exactly this. Good people, genuinely strong product instincts, but they'd spent two years in a well-funded environment where being wrong about a bet didn't cost much. There was always another quarter, always another hire, always another feature to try next. Abundance is a very effective way of making strategic clarity feel optional. Then the funding environment changed and leadership asked for a focused roadmap. The team produced one in two weeks. I looked at it and felt something was off but couldn't immediately place it. It took another month to see it clearly. The roadmap was focused in appearance and scattered in logic. They'd removed items based on effort and recency, not based on belief. The things they'd kept were the things that had been on the roadmap longest, which meant they'd been kept out of inertia as much as conviction. When I asked the head of product which item on the roadmap she would fight hardest to protect if she had to cut one more thing, she paused for a long time. She named something that wasn't on the roadmap at all. That was the real roadmap. One item. Everything else was furniture. This is the thing that constraint reveals, and why the teams that come out of this period sharper are not the ones who cut the most aggressively. They're the ones who used the pressure to ask a question that abundance had let them avoid: what do we actually believe this product is for? Not the mission statement version. Not the investor deck version. The version that would hold up in a room where someone was cutting the budget in half and asking you to defend every remaining item with your own money on the line. Most product strategies, examined that way, turn out to contain a lot of things the team built because they could, a few things they built because users asked, and one or two things they built because they genuinely believed the product needed them. The first two categories are the forty-two menu items. The third category is what the restaurant was actually for. Funding allowed teams to carry all three categories simultaneously and call it a strategy. Constraint is forcing the question of which category the team actually believes in. The teams I'm seeing struggle most right now are not the ones with the tightest budgets. They're the ones trying to maintain a wide surface area with fewer resources, defending every item on the roadmap with equal energy because they haven't decided which ones actually matter. Spreading a smaller team across the same strategic perimeter doesn't produce a leaner strategy. It produces the same strategy, executed worse. But the teams treating this moment as a forcing function rather than a crisis are asking a different question. Not "what can we afford to build" but "what do we believe enough to build when we can only build one thing." That question is harder. It requires conviction rather than consensus. It requires someone in the room to say: this is what we are, these are the things we are brilliant at, and the rest is noise. Fewer product leaders are willing to say that out loud than you'd expect. The ones who are, though, will have roadmaps worth reading by the end of the year. And kitchens that know what they're cooking.

Product StrategyJanuary 5, 2024

The PM role identity crisis: Senior leaders publicly questioning whether the job should exist

The people most passionately defending the product manager role right now are, ironically, the ones who struggle most to explain what it actually does. Scroll through LinkedIn on any given Tuesday and you will find a dozen PMs writing impassioned posts about why their role matters, citing collaboration, strategy, and customer empathy. But ask them to name a single decision their team would have gotten wrong without them, and you get silence. Or worse, you get a vague gesture toward "alignment." That silence is the problem. Tobi Said the Quiet Part Out Loud When Tobi Lutke posted that Shopify would default to not hiring product managers, the product community treated it like a five-alarm fire. Twitter erupted. LinkedIn turned into a support group. But Lutke did not say anything that engineering leaders had not been muttering in private for years. He just said it publicly, with a CEO's authority behind it. The uncomfortable truth is that plenty of product managers have been operating as high-paid project coordinators for a long time. They schedule meetings. They write tickets. They move cards across Kanban boards. They run stand-ups. None of these activities require product judgment. Any organised person with a Jira login can do them. I call this the articulation gap: the distance between what a PM's title promises and what their daily work actually delivers. The wider the gap, the more vulnerable the role. When I was at Freshworks, I watched this play out in real time. We had product managers who spent their entire week in the mechanics of delivery. Writing user stories. Updating sprint boards. Chasing engineers for status updates. They were busy, certainly. But they were not making product decisions. They were administering a process. When the organisation restructured, those PMs were the first roles eliminated. Here is what should make every product manager uncomfortable: nobody noticed. The engineers kept building. The designers kept designing. The standups kept happening. The work flowed exactly as it had before, because the work those PMs were doing was not uniquely theirs. It belonged to the process, not to the person. The Decision Residue But not all PMs are interchangeable process administrators. Some leave behind what I think of as decision residue: the invisible trace of good product judgment that only becomes visible when it disappears. At Adobe, I worked alongside a PM who operated nothing like the Freshworks coordinators. She sat at the intersection of engineering constraints and commercial priorities, two worlds that spoke entirely different languages. Engineering would propose a technically elegant solution that served 3% of the user base. The business team would demand a feature that required rebuilding half the platform. She was the person who found the third option, the one that satisfied enough of both constraints to actually ship something valuable. When she left the company, the team shipped two features in the following quarter that made zero commercial sense. Technically impressive. Commercially pointless. The engineering team had optimised for what they found interesting. The business team had not pushed back because nobody was translating their concerns into technical trade-offs. The decision residue was gone, and the team did not even realise it until the revenue numbers came in. That is the difference between a PM who holds a title and a PM who holds a role. The title is a line on an org chart. The role is a function that, when removed, changes outcomes. The Articulation Gap Is a Skills Problem, Not a Narrative Problem Here is where the PM community keeps getting the response wrong. Every time someone questions the role, product managers rush to write thought pieces about why PMs matter. They build frameworks. They create Venn diagrams showing the PM at the intersection of business, technology, and user experience. They quote Marty Cagan. But the problem is not that PMs lack a compelling narrative about their value. The problem is that too many PMs lack the actual skills that would make the narrative true. If you cannot point to a decision that would have been made differently without you in the room, you do not have a role. You have a title. This is not comfortable to hear. But comfort is not the point. The PM identity crisis is not about whether the role matters. It is about whether the person in it does. And that distinction is everything. Lutke was not arguing that product thinking is unnecessary. He was arguing that product thinking does not require a dedicated product manager, at least not the kind who functions primarily as a coordination layer. He is half right. Product thinking does not require someone whose main contribution is scheduling and status tracking. But it does require someone who can hold multiple competing constraints in their head simultaneously and find a path through them. The question every PM needs to answer is: which one am I? The Survival Test There is a simple test I have started recommending to product managers who feel anxious about this reckoning. Sit down and write a list of the last ten decisions your product team made. Not features shipped. Decisions made. Trade-offs resolved. Directions chosen over alternatives. Now circle the ones that would have gone differently if you had not been in the room. If you can circle five or more, you have a role. You are the person who shapes outcomes, not the person who tracks them. But if you are staring at a list of ten decisions and struggling to circle even two, the identity crisis is not abstract. It is yours. The good news is that the articulation gap is closeable. It requires shifting from process work to judgment work. From asking "what is the status?" to asking "what are we trading off?" From running the meeting to changing the meeting's conclusion. But it requires honesty first. The kind of honesty that most professional communities are not great at, because it means admitting that some of your peers (and possibly you) have been coasting on a title that the industry granted generously during the growth years and is now auditing more carefully. I have seen PMs close the articulation gap in six months. It is not a years-long transformation. It is a focus shift. But it starts with accepting that the question "should PMs exist?" is not an attack on the profession. It is a performance review that the profession has been avoiding. What the Critics Miss But Lutke and his fellow travellers miss something important too. They see the worst version of the PM role and conclude that the role itself is the problem. That is like watching a bad surgeon and concluding that surgery is unnecessary. The PMs who generate decision residue are not performing a function that engineers or designers can absorb. Engineers optimise for technical excellence. Designers optimise for user experience. Business leaders optimise for revenue. But someone has to make the call about which optimisation wins in this specific context, for this specific customer, at this specific moment. That is product judgment. It is genuinely hard to do well. The role does not need to be abolished. It needs to be earned, every quarter, by every person who holds the title. But the earning is a reckoning with individual performance, not with the concept of product management itself. The best PMs I have worked with never worried about whether their role would be eliminated. They were too busy making decisions that nobody else in the room could make. That quiet confidence is worth more than any LinkedIn post defending the profession. If you are a PM reading this and feeling defensive, that feeling is data. Sit with it.

Product Leadership & CareerJanuary 2, 2024