ProductNatives — Build Products People Actually Need

About Arun Jacob

20 years of building products.
Every mistake you can skip.

Arun Jacob's career never stayed in one world. Retail, SaaS, fintech, fitness wearables, petroleum, aviation, industrial IoT. Every switch felt like starting over. Every switch also taught him something the previous world never could. That cross-industry perspective is exactly what you'll find here.

AdobeBoeingNikeParamountFreshworksMicrosoftMotorolaSchneider ElectricLevi’sYahoo

Read the full story →

The Book

MisAligned

Finding the Missing Link Between Smart Teams and Successful Products

The gap between a great team and a great product isn't talent. It's alignment. This book is about what that gap looks like in the real world and how to close it, whatever your role.

Get the Book Read Free Chapters

From the Blog

Featured articles

View all →

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.

Product Teams & Org DynamicsMay 22, 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.

Product Teams & Org DynamicsMay 8, 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.

Product Teams & Org DynamicsMay 1, 2026

One lesson, every week.

Practical insights to help you build better products. No spam. No fluff.

Great products come from teams who think beyond their role

20 years of building products.Every mistake you can skip.