<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:googleplay="http://www.google.com/schemas/play-podcasts/1.0"><channel><title><![CDATA[The Product Man]]></title><description><![CDATA[CPO writing about product and the systems, incentives, and behaviours that shape our lives.]]></description><link>https://www.theproductman.com</link><image><url>https://substackcdn.com/image/fetch/$s_!1Vpx!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F9e7fc53c-1600-4bff-a6b4-63ec5c9c2834_1024x1024.png</url><title>The Product Man</title><link>https://www.theproductman.com</link></image><generator>Substack</generator><lastBuildDate>Wed, 15 Apr 2026 21:40:12 GMT</lastBuildDate><atom:link href="https://www.theproductman.com/feed" rel="self" type="application/rss+xml"/><copyright><![CDATA[The Product Man]]></copyright><language><![CDATA[en]]></language><webMaster><![CDATA[theproductman@substack.com]]></webMaster><itunes:owner><itunes:email><![CDATA[theproductman@substack.com]]></itunes:email><itunes:name><![CDATA[The Product Man]]></itunes:name></itunes:owner><itunes:author><![CDATA[The Product Man]]></itunes:author><googleplay:owner><![CDATA[theproductman@substack.com]]></googleplay:owner><googleplay:email><![CDATA[theproductman@substack.com]]></googleplay:email><googleplay:author><![CDATA[The Product Man]]></googleplay:author><itunes:block><![CDATA[Yes]]></itunes:block><item><title><![CDATA[The Mental Load of Being Reachable]]></title><description><![CDATA[When did we normalise permanent availability?]]></description><link>https://www.theproductman.com/p/the-mental-load-of-being-reachable</link><guid isPermaLink="false">https://www.theproductman.com/p/the-mental-load-of-being-reachable</guid><dc:creator><![CDATA[The Product Man]]></dc:creator><pubDate>Mon, 01 Dec 2025 15:04:17 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!913q!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fec533828-a405-424e-99df-6c0e5f474588_700x467.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<div class="captioned-image-container"><figure><a class="image-link image2 is-viewable-img" target="_blank" href="https://substackcdn.com/image/fetch/$s_!913q!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fec533828-a405-424e-99df-6c0e5f474588_700x467.png" data-component-name="Image2ToDOM"><div class="image2-inset"><picture><source type="image/webp" srcset="https://substackcdn.com/image/fetch/$s_!913q!,w_424,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fec533828-a405-424e-99df-6c0e5f474588_700x467.png 424w, https://substackcdn.com/image/fetch/$s_!913q!,w_848,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fec533828-a405-424e-99df-6c0e5f474588_700x467.png 848w, https://substackcdn.com/image/fetch/$s_!913q!,w_1272,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fec533828-a405-424e-99df-6c0e5f474588_700x467.png 1272w, https://substackcdn.com/image/fetch/$s_!913q!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fec533828-a405-424e-99df-6c0e5f474588_700x467.png 1456w" sizes="100vw"><img src="https://substackcdn.com/image/fetch/$s_!913q!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fec533828-a405-424e-99df-6c0e5f474588_700x467.png" width="700" height="467" data-attrs="{&quot;src&quot;:&quot;https://substack-post-media.s3.amazonaws.com/public/images/ec533828-a405-424e-99df-6c0e5f474588_700x467.png&quot;,&quot;srcNoWatermark&quot;:null,&quot;fullscreen&quot;:null,&quot;imageSize&quot;:null,&quot;height&quot;:467,&quot;width&quot;:700,&quot;resizeWidth&quot;:null,&quot;bytes&quot;:null,&quot;alt&quot;:null,&quot;title&quot;:null,&quot;type&quot;:null,&quot;href&quot;:null,&quot;belowTheFold&quot;:false,&quot;topImage&quot;:true,&quot;internalRedirect&quot;:null,&quot;isProcessing&quot;:false,&quot;align&quot;:null,&quot;offset&quot;:false}" class="sizing-normal" alt="" srcset="https://substackcdn.com/image/fetch/$s_!913q!,w_424,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fec533828-a405-424e-99df-6c0e5f474588_700x467.png 424w, https://substackcdn.com/image/fetch/$s_!913q!,w_848,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fec533828-a405-424e-99df-6c0e5f474588_700x467.png 848w, https://substackcdn.com/image/fetch/$s_!913q!,w_1272,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fec533828-a405-424e-99df-6c0e5f474588_700x467.png 1272w, https://substackcdn.com/image/fetch/$s_!913q!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fec533828-a405-424e-99df-6c0e5f474588_700x467.png 1456w" sizes="100vw" fetchpriority="high"></picture><div class="image-link-expand"><div class="pencraft pc-display-flex pc-gap-8 pc-reset"><button tabindex="0" type="button" class="pencraft pc-reset pencraft icon-container restack-image"><svg role="img" width="20" height="20" viewBox="0 0 20 20" fill="none" stroke-width="1.5" stroke="var(--color-fg-primary)" stroke-linecap="round" stroke-linejoin="round" xmlns="http://www.w3.org/2000/svg"><g><title></title><path d="M2.53001 7.81595C3.49179 4.73911 6.43281 2.5 9.91173 2.5C13.1684 2.5 15.9537 4.46214 17.0852 7.23684L17.6179 8.67647M17.6179 8.67647L18.5002 4.26471M17.6179 8.67647L13.6473 6.91176M17.4995 12.1841C16.5378 15.2609 13.5967 17.5 10.1178 17.5C6.86118 17.5 4.07589 15.5379 2.94432 12.7632L2.41165 11.3235M2.41165 11.3235L1.5293 15.7353M2.41165 11.3235L6.38224 13.0882"></path></g></svg></button><button tabindex="0" type="button" class="pencraft pc-reset pencraft icon-container view-image"><svg xmlns="http://www.w3.org/2000/svg" width="20" height="20" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="lucide lucide-maximize2 lucide-maximize-2"><polyline points="15 3 21 3 21 9"></polyline><polyline points="9 21 3 21 3 15"></polyline><line x1="21" x2="14" y1="3" y2="10"></line><line x1="3" x2="10" y1="21" y2="14"></line></svg></button></div></div></div></a></figure></div><p>My phone has already buzzed thirty-three times today, and it is not yet noon.</p><p>I am not complaining about the volume. I chose this. I run a company, I have a family, I maintain friendships across time zones. The messages are not unwelcome. What I am trying to name is something else: the particular weight of knowing that at any moment, another one could arrive.</p><p>This feeling is not new to me. It has been there for years, a low hum running beneath everything else. What changed recently is that I stopped dismissing it as a personal failing, some deficiency of focus or discipline, and started recognising it for what it is: a predictable psychological response to the way our communication tools are designed.</p><p>I work in product. I build software. And in product, we like to tell ourselves that we&#8217;re building tools as proxies for things people already do. More often than not, we&#8217;re not. We&#8217;re building entirely new behaviours, and then acting surprised when people adapt to them.</p><p>This is especially true for communication. Always-on communication wasn&#8217;t inevitable. It was a product decision. And like all product decisions, it came with trade-offs. Some of those trade-offs we measured. Others we exported quietly onto users and never looked at again.</p><p>What follows is my attempt to explain why this weight exists, where it came from, and why the usual advice to &#8220;just set boundaries&#8221; misses the point entirely. This is not a wellness piece. It is not about digital detox or screen time. It is about a structural problem that we have individualised into a personal one, and what it might mean to see it clearly.</p><blockquote><p>&#8220;The anxiety isn&#8217;t caused by how many messages we receive. It&#8217;s caused by knowing that someone can reach us at any time.&#8221;</p></blockquote><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://www.theproductman.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">If you&#8217;re enjoying this, consider subscribing.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div><p>I find myself thinking about MSN Messenger more often than I expect to. Not because I miss the interface, or the sounds, or even the people I spoke to on it, but because of how it felt to communicate then. You could see who was online. If someone wasn&#8217;t there, you couldn&#8217;t message them. There was no composing into the void, no quiet expectation sitting with them until they returned. Conversations began when both people arrived and ended when one of them left. When it was over, it was over. Nothing lingered.</p><p>That constraint sounds trivial now. It wasn&#8217;t. It did important psychological work. It meant obligation only existed while presence was shared. Absence wasn&#8217;t silent judgement. It was just absence.</p><p>The shift happened gradually, then completely.</p><p>When communication is presence-based, obligation exists only while both people are present. When communication is persistent, obligation begins the moment a message is delivered, regardless of whether the receiver is available.</p><p>That distinction sounds small. It is not.</p><p>Modern messaging is defined by persistence. Messages can be sent at any time, to anyone, regardless of availability. The message waits. It sits in a queue that the recipient never asked for, creating an obligation on a timeline they do not control.</p><p>The anxiety isn&#8217;t caused by how many messages we receive. It&#8217;s caused by knowing that someone can reach us at any time.</p><p>This is what I call latent obligation: the continuous background awareness that you might owe someone a response, even when no specific message is waiting. Every unread message is a suspended task. Until it&#8217;s resolved, it takes up space in your head.</p><blockquote><p>&#8220;Every unread message is a suspended task.<br>Until it&#8217;s resolved, it takes up space in your head.&#8221;</p></blockquote><p>I notice it most when I sit down to do focused work. No notification has fired. Nothing is urgent. And yet, within minutes, I&#8217;ve opened Slack anyway, just to check. Just in case. The channel was quiet. I learned nothing. But I couldn&#8217;t not look.</p><p>The symptoms are predictable. You check your phone not because you heard a notification but because you feel like you should. You think about a conversation you have not yet had. You remember, hours later, that you forgot to reply, and the forgetting itself becomes a secondary failure requiring its own repair. You feel a faint guilt when you deliberately go offline, even when you have every right to.</p><p>These are not personality quirks. They are not signs of poor boundaries or weak character. They are the ordinary psychological responses to a communication architecture that assumes permanent availability as its baseline.</p><blockquote><p>&#8220;Silence didn&#8217;t used to require explanation.<br>Now it often does.&#8221;</p></blockquote><p>Something else shifted alongside the technology, and it is harder to see because it happened socially rather than structurally.</p><p>Responsiveness became moral.</p><p>Silence didn&#8217;t used to require explanation. Now it often does.</p><p>At some point, the speed of your reply became a proxy for how much you care. A delayed response is no longer neutral. It is interpreted. They saw the message and chose not to reply. They are busy, which means I am not a priority. They must be upset with me.</p><p>In Slack, the green dot becomes a subtle accusation. You can see that someone is active. You can see that they have read channels but not replied to yours. In Teams, presence indicators carry the same weight. &#8220;Last seen 3 minutes ago&#8221; is not a neutral timestamp. It is social information, available to anyone who chooses to read it.</p><p>We do this to others, and we do it to ourselves. We&#8217;ve quietly moralised responsiveness. Being late isn&#8217;t just inconvenient anymore. It&#8217;s interpreted as thoughtless, unreliable, or uncaring.</p><p>Last week, I noticed myself feeling a flicker of irritation when a colleague didn&#8217;t reply to a message for several hours. It was not urgent. There was no deadline. And yet I caught myself thinking: they&#8217;ve been online, I can see it, why haven&#8217;t they responded? I was doing exactly what I am critiquing. The tools had trained me without my noticing.</p><p>This is new. A missed phone call, before voicemail became ubiquitous, carried no such weight. The person was not home. You would try again later. There was no observable gap between message sent and message read, no timestamp marking exactly when the other person became aware and chose not to respond.</p><p>Now there is. And that visibility has quietly rewritten the social contract around communication.</p><p>From a product perspective, this outcome is predictable. That is precisely what makes it uncomfortable.</p><p>When building communication tools, teams optimise for reach, speed, engagement, and convenience. These are measurable. They show up in dashboards. They correlate with growth. A product that delivers messages instantly, to anyone, regardless of availability, will outcompete one that requires both parties to be present. The efficiency gains are obvious.</p><p>What does not show up in dashboards is psychological cost.</p><p>No product roadmap ever includes a line item for &#8220;creates low-grade, persistent guilt.&#8221; But that doesn&#8217;t mean the cost doesn&#8217;t exist. It just means it&#8217;s carried privately. The anxiety of being interruptible at any moment is diffuse and normalised. It does not feel like a bug. It feels like life.</p><p>This is the structure of an externality. The system captures the efficiency gains. Users carry the costs in private. And because those costs are distributed across millions of individuals, each experiencing them in isolation, they never aggregate into a problem that demands a solution. They are just the way things are.</p><p>I want to be direct about something, because I think clarity here matters.</p><p>Product teams are incentivised to increase usage. We optimise obsessively for monthly active users, daily engagement, stickiness, reduced churn. We run experiments designed to change behaviour: increase frequency, reduce friction, pull users back more often. This is not unusual. It is the ordinary practice of building products that succeed.</p><p>Whether we admit it or not, a lot of product work involves shaping user psychology so that people choose us more often than something else.</p><p>I am not saying this is sinister. I am saying it is real, and that it creates questions we do not always stop to ask.</p><p>I&#8217;ll go further. I use email open tracking in my own outbound campaigns. I know exactly when someone opens a message. I know if they opened it three times. I know if they forwarded it. This information is useful to me. It helps me time follow-ups, gauge interest, prioritise effort. And I am also aware that every time I send a tracked email, I am creating for someone else the exact pressure I have spent this essay describing. They do not know I can see them. But I can. And that visibility is not neutral.</p><p>I do not have a clean resolution to this. I use the tools. I also know what they cost.</p><p>What is the psychological cost of designing for maximum reachability? What happens when increasing engagement quietly increases obligation? Are we blind to the long-term effects because they do not show up in metrics? Is this simply the cost of progress, or is that framing an excuse we use to avoid looking?</p><p>We&#8217;re very good at measuring the upside of engagement. We&#8217;re much worse at noticing the long-term psychological costs, because they don&#8217;t aggregate cleanly.</p><p>Always-on reachability was not a law of nature. Infinite persistence was not technically mandatory. We chose convenience and growth, often without fully pricing the consequences. It is not that we intended these outcomes. It is that our tools for measuring success do not incentivise us to see them.</p><p>I do not think this makes product leaders villains. But I do think it means we cannot pretend ignorance indefinitely. If we build tools that compete for attention by extending psychological reach, then we cannot pretend surprise when that reach becomes a burden.</p><blockquote><p>&#8220;We&#8217;re very good at measuring the upside of engagement.<br>We&#8217;re much worse at noticing the long-term psychological costs.&#8221;</p></blockquote><p>The instinct, at this point, is to reach for individual solutions. Mute notifications. Schedule focus time. Be more intentional.</p><p>I have tried this. I have turned off badges, scheduled Do Not Disturb windows, built systems to batch my communications into discrete blocks. It works, in the sense that I am interrupted less often. It does not work in the sense that matters: the background hum remains. The awareness that messages are accumulating, that someone might be waiting, that silence is being observed and interpreted. The tools are quieter. The weight is the same.</p><p>These strategies are not wrong, exactly. They are just incomplete.</p><p>When millions of people independently experience the same pattern of low-grade anxiety, the cause is not a million individual failures of discipline. It is architectural. The tools are built to assume you are always available. The social norms that grew up around those tools encode the same assumption. The psychological cost is the predictable output of that design, distributed across a population that never asked for it and has no collective means to refuse it.</p><p>Personal strategies can help at the margins. But they cannot change the underlying structure. They are accommodations to a system, not alternatives to it.</p><p>This pattern is not unique to messaging.</p><p>The same dynamic appears wherever friction is removed without replacement. Friction, it turns out, often serves a purpose. It creates separation. It marks transitions. It signals that one mode of interaction has ended and another has not yet begun.</p><p>When communication required presence, presence was the friction. You had to be there, and so did the other person, and that mutual requirement created natural boundaries. When that friction disappeared, nothing replaced it. The boundary simply collapsed. And the cognitive work that the boundary used to perform migrated somewhere else.</p><p>It migrated into the mind.</p><p>I am not arguing that we should return to an earlier model. The convenience of asynchronous communication is real, and for many purposes, essential. The ability to send a message whenever it occurs to you, knowing it will be there when the other person is ready, is genuinely useful.</p><p>But convenience has costs that do not appear on the balance sheet. The question is not whether asynchronous messaging is good or bad. It is whether we have accurately accounted for what it asks of us, and whether we have been honest about who bears that cost.</p><p>The tools we build are not neutral. Every default teaches users how to behave. Every architectural decision encodes an assumption about what is normal, what is expected, what silence means. When we built tools that assume permanent availability, we also built the expectation that permanent availability is reasonable. That expectation now feels like common sense. It is not. It is a design choice that became a social norm.</p><p>If the tools we build normalise permanent availability, then the anxiety required to sustain that availability is also something we&#8217;ve designed. The one follows from the other, whether or not anyone meant it to.</p><p>Communication tools made this visible because the effects are immediate and ubiquitous. Most of us feel them daily. But the underlying pattern is not limited to messaging.</p><p>It appears wherever friction is removed without asking what that friction was protecting. Wherever engagement is optimised without measuring what engagement costs. Wherever behaviour is nudged, defaults are set, and users adapt to systems that were never designed with their long-term psychology in mind.</p><p>Feeds that reward compulsive checking. Workflows that blur the boundary between available and unavailable. Recommendation systems that learn what captures attention without asking whether attention was freely given. The mechanisms differ. The structure is the same: optimise for one metric, export the psychological cost elsewhere, and never revisit the trade-off once the numbers look good.</p><p>I do not think most product leaders set out to create anxiety. I do think we have developed a remarkable capacity for not seeing it. Our tools for measuring success are precise. Our tools for measuring cost are almost nonexistent. And so we optimise toward what we can see, and assume that what we cannot see is not our problem.</p><p>Communication is just one place where the cost finally became legible. It will not be the last.</p><p>Is permanent availability inevitable, or just profitable? And what else are we shaping without noticing?</p><p>What we choose not to measure still shapes people. That, in itself, is a design decision.</p><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://www.theproductman.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">Thanks for reading! Subscribe for free to receive new posts and support my work.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div>]]></content:encoded></item><item><title><![CDATA[What Does a Product Manager Actually Do?]]></title><description><![CDATA[The PM is responsible for determining what to build and why. This definition is clear, widely accepted, and almost entirely useless.]]></description><link>https://www.theproductman.com/p/what-does-a-product-manager-actually</link><guid isPermaLink="false">https://www.theproductman.com/p/what-does-a-product-manager-actually</guid><dc:creator><![CDATA[The Product Man]]></dc:creator><pubDate>Fri, 28 Nov 2025 14:37:38 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!VLmW!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb7b3626f-f810-4dc9-b0c7-d5ecec4515b0_524x386.jpeg" length="0" type="image/jpeg"/><content:encoded><![CDATA[<div class="captioned-image-container"><figure><a class="image-link image2 is-viewable-img" target="_blank" href="https://substackcdn.com/image/fetch/$s_!VLmW!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb7b3626f-f810-4dc9-b0c7-d5ecec4515b0_524x386.jpeg" data-component-name="Image2ToDOM"><div class="image2-inset"><picture><source type="image/webp" srcset="https://substackcdn.com/image/fetch/$s_!VLmW!,w_424,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb7b3626f-f810-4dc9-b0c7-d5ecec4515b0_524x386.jpeg 424w, https://substackcdn.com/image/fetch/$s_!VLmW!,w_848,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb7b3626f-f810-4dc9-b0c7-d5ecec4515b0_524x386.jpeg 848w, https://substackcdn.com/image/fetch/$s_!VLmW!,w_1272,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb7b3626f-f810-4dc9-b0c7-d5ecec4515b0_524x386.jpeg 1272w, https://substackcdn.com/image/fetch/$s_!VLmW!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb7b3626f-f810-4dc9-b0c7-d5ecec4515b0_524x386.jpeg 1456w" sizes="100vw"><img src="https://substackcdn.com/image/fetch/$s_!VLmW!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb7b3626f-f810-4dc9-b0c7-d5ecec4515b0_524x386.jpeg" width="524" height="386" data-attrs="{&quot;src&quot;:&quot;https://substack-post-media.s3.amazonaws.com/public/images/b7b3626f-f810-4dc9-b0c7-d5ecec4515b0_524x386.jpeg&quot;,&quot;srcNoWatermark&quot;:null,&quot;fullscreen&quot;:null,&quot;imageSize&quot;:null,&quot;height&quot;:386,&quot;width&quot;:524,&quot;resizeWidth&quot;:null,&quot;bytes&quot;:60657,&quot;alt&quot;:null,&quot;title&quot;:null,&quot;type&quot;:&quot;image/jpeg&quot;,&quot;href&quot;:null,&quot;belowTheFold&quot;:false,&quot;topImage&quot;:true,&quot;internalRedirect&quot;:&quot;https://theproductman.substack.com/i/180180652?img=https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb7b3626f-f810-4dc9-b0c7-d5ecec4515b0_524x386.jpeg&quot;,&quot;isProcessing&quot;:false,&quot;align&quot;:null,&quot;offset&quot;:false}" class="sizing-normal" alt="" srcset="https://substackcdn.com/image/fetch/$s_!VLmW!,w_424,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb7b3626f-f810-4dc9-b0c7-d5ecec4515b0_524x386.jpeg 424w, https://substackcdn.com/image/fetch/$s_!VLmW!,w_848,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb7b3626f-f810-4dc9-b0c7-d5ecec4515b0_524x386.jpeg 848w, https://substackcdn.com/image/fetch/$s_!VLmW!,w_1272,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb7b3626f-f810-4dc9-b0c7-d5ecec4515b0_524x386.jpeg 1272w, https://substackcdn.com/image/fetch/$s_!VLmW!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb7b3626f-f810-4dc9-b0c7-d5ecec4515b0_524x386.jpeg 1456w" sizes="100vw" fetchpriority="high"></picture><div class="image-link-expand"><div class="pencraft pc-display-flex pc-gap-8 pc-reset"><button tabindex="0" type="button" class="pencraft pc-reset pencraft icon-container restack-image"><svg role="img" width="20" height="20" viewBox="0 0 20 20" fill="none" stroke-width="1.5" stroke="var(--color-fg-primary)" stroke-linecap="round" stroke-linejoin="round" xmlns="http://www.w3.org/2000/svg"><g><title></title><path d="M2.53001 7.81595C3.49179 4.73911 6.43281 2.5 9.91173 2.5C13.1684 2.5 15.9537 4.46214 17.0852 7.23684L17.6179 8.67647M17.6179 8.67647L18.5002 4.26471M17.6179 8.67647L13.6473 6.91176M17.4995 12.1841C16.5378 15.2609 13.5967 17.5 10.1178 17.5C6.86118 17.5 4.07589 15.5379 2.94432 12.7632L2.41165 11.3235M2.41165 11.3235L1.5293 15.7353M2.41165 11.3235L6.38224 13.0882"></path></g></svg></button><button tabindex="0" type="button" class="pencraft pc-reset pencraft icon-container view-image"><svg xmlns="http://www.w3.org/2000/svg" width="20" height="20" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="lucide lucide-maximize2 lucide-maximize-2"><polyline points="15 3 21 3 21 9"></polyline><polyline points="9 21 3 21 3 15"></polyline><line x1="21" x2="14" y1="3" y2="10"></line><line x1="3" x2="10" y1="21" y2="14"></line></svg></button></div></div></div></a></figure></div><p>I believed it once. Early in my career, I could recite the frameworks, draw the Venn diagram, explain how the PM sits at the intersection of business, technology, and user experience. Then I actually did the job. The definition stopped fitting around month three.</p><p>People ask me what I actually do for a living. I give them an answer. They nod confidently. All of them are wrong.</p><p>The role exists in every technology company. No two companies agree on what it means.</p><div><hr></div><h3>The Many Species of Product Manager</h3><p>Observe the PM in its natural habitat and you will encounter remarkable variation. The taxonomy is extensive.</p><p>There is the <strong>Historian</strong>, who alone remembers why the login flow works the way it does and what happened to the team that tried to change it. Their value is institutional memory. Their calendar is full of meetings where they explain decisions made by people who left two years ago.</p><p>There is the <strong>Diplomat</strong>, who spends most of their time translating between engineering and sales. Engineering says the feature is impossible. Sales says they already promised it. The Diplomat finds language that allows both parties to leave the room believing they won.</p><p>There is the <strong>Therapist</strong>, who listens to stakeholders describe their anxieties about the product and responds with validation and a Jira ticket. The ticket may or may not be actioned. The validation is the point.</p><p>There is the <strong>Archaeologist</strong>, who excavates deprecated Confluence pages to decipher workflows that no one understands but everyone depends on. They inherit systems built by teams that no longer exist, documented in formats no one knows how to open.</p><p>There is the <strong>Air Traffic Controller</strong>, who exists primarily to prevent two teams from building the same thing. More commonly, they notice after both teams have already shipped.</p><p>And there is the <strong>Political Heat Shield</strong>, who attends leadership meetings so the engineers do not have to, absorbing questions about timelines and returning with answers that are technically accurate and practically meaningless.</p><p>I have been all of these. Sometimes in the same week. The role does not select for a type; it selects for people willing to become whatever the situation requires.</p><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://www.theproductman.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">If you&#8217;re enjoying this so far, consider subscribing for more posts like this.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div><div><hr></div><h3>The Role That Changes Shape</h3><p>Even within one organisation, the PM&#8217;s function is surprisingly unstable.</p><p>I once ran a discovery workshop where the VP opened by telling the room the goal was alignment. The engineering lead interrupted to say it was challenge. Halfway through, I realised I had no authority to steer either of them, and the best I could do was take notes and write a summary afterwards that described a consensus no one had actually reached. Everyone accepted the document. The project moved forward. I still do not know what the workshop was for.</p><p>Consider the roadmap review. The PM presents the plan. The CEO asks why Feature X is not included. The PM explains the prioritisation framework. The CEO nods thoughtfully and adds Feature X to the roadmap. The PM updates the document. The prioritisation framework remains in the deck for the next meeting, where it will be ignored again. I have been through this cycle enough times that I can now explain prioritisation with complete conviction while fully expecting it to be abandoned within a week.</p><p>I used to believe the PM owned the roadmap. Then I worked somewhere with a founder who changed it weekly based on whatever he had read that morning. I now believe the PM owns the document, not the direction.</p><p>Sometimes the PM discovers that the most important feature on the Q3 roadmap was added by accident. I inherited one of these once. No one remembered who requested it. No one remembered why. Everyone agreed it was critical, but no one could explain the use case. I spent three weeks trying to get it removed before accepting that building the feature would cost less political capital than deleting it. We shipped it. I do not know if anyone used it.</p><div><hr></div><h3>Responsibility Without Authority</h3><p>The PM is theoretically accountable for outcomes. They control almost nothing that determines those outcomes.</p><p>They do not manage the engineers. They do not set the budget. They do not approve the marketing spend. They do not hire the designers. They cannot force sales to stop promising features. They cannot prevent the founder from reading an article about AI and arriving at the Monday meeting with a new strategic direction.</p><p>The job, if described honestly, is largely translation. Translate business goals into requirements. Translate technical constraints into timelines. Translate user feedback into something the roadmap can accommodate. Translate leadership&#8217;s changing priorities into a narrative that engineering will not find demoralising. Most of my job involves absorbing competing narratives and returning them to the team in a form that will not derail the sprint. I tell myself this is leadership. It might just be coping.</p><p>Most PM work is not decision-making. It is making decisions possible for other people while maintaining the illusion that a decision has already been made.</p><p>Even now, after years in this role, there are days where I have no idea what I am actually supposed to be doing. The job descriptions mention vision and strategy. The reality is more often confusion wrapped in confidence, held together by calendar invites and a tolerance for ambiguity. Impostor syndrome is not a phase you get past. It is part of the operating environment.</p><div><hr></div><h3>The Function That Remains</h3><p>Strip away the frameworks, the certifications, the job descriptions. What persists?</p><p>Organisations are complex systems. Complex systems generate ambiguity. Someone has to hold the ambiguity so that others can pretend the world is simpler than it is. Someone has to remember the context, own the contradictions, and attend the meetings that have no clear purpose.</p><p>The PM is whoever ends up doing that. The title is a label applied after the fact.</p><p>I have stopped trying to define the role. The job is whatever keeps the system coherent for one more week. The contradictions do not resolve. You just get better at carrying them.</p><div class="subscription-widget-wrap-editor" data-attrs="{&quot;url&quot;:&quot;https://www.theproductman.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe&quot;,&quot;language&quot;:&quot;en&quot;}" data-component-name="SubscribeWidgetToDOM"><div class="subscription-widget show-subscribe"><div class="preamble"><p class="cta-caption">Thanks for reading! Subscribe for free to receive new posts and support my work.</p></div><form class="subscription-widget-subscribe"><input type="email" class="email-input" name="email" placeholder="Type your email&#8230;" tabindex="-1"><input type="submit" class="button primary" value="Subscribe"><div class="fake-input-wrapper"><div class="fake-input"></div><div class="fake-button"></div></div></form></div></div>]]></content:encoded></item><item><title><![CDATA[The Meeting Trap]]></title><description><![CDATA[How managerial insecurity creates pointless work]]></description><link>https://www.theproductman.com/p/from-burnout-to-balance-how-to-overcome-meeting-fatigue-ecc29d0b069b</link><guid isPermaLink="false">https://www.theproductman.com/p/from-burnout-to-balance-how-to-overcome-meeting-fatigue-ecc29d0b069b</guid><dc:creator><![CDATA[The Product Man]]></dc:creator><pubDate>Sun, 25 Jun 2023 18:41:34 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!u6hb!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3d422122-a0b0-4220-8f31-b10e1d1e88f1_1024x608.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<div class="captioned-image-container"><figure><a class="image-link image2 is-viewable-img" target="_blank" href="https://substackcdn.com/image/fetch/$s_!u6hb!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3d422122-a0b0-4220-8f31-b10e1d1e88f1_1024x608.png" data-component-name="Image2ToDOM"><div class="image2-inset"><picture><source type="image/webp" srcset="https://substackcdn.com/image/fetch/$s_!u6hb!,w_424,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3d422122-a0b0-4220-8f31-b10e1d1e88f1_1024x608.png 424w, https://substackcdn.com/image/fetch/$s_!u6hb!,w_848,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3d422122-a0b0-4220-8f31-b10e1d1e88f1_1024x608.png 848w, https://substackcdn.com/image/fetch/$s_!u6hb!,w_1272,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3d422122-a0b0-4220-8f31-b10e1d1e88f1_1024x608.png 1272w, https://substackcdn.com/image/fetch/$s_!u6hb!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3d422122-a0b0-4220-8f31-b10e1d1e88f1_1024x608.png 1456w" sizes="100vw"><img src="https://substackcdn.com/image/fetch/$s_!u6hb!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3d422122-a0b0-4220-8f31-b10e1d1e88f1_1024x608.png" width="1024" height="608" data-attrs="{&quot;src&quot;:&quot;https://substack-post-media.s3.amazonaws.com/public/images/3d422122-a0b0-4220-8f31-b10e1d1e88f1_1024x608.png&quot;,&quot;srcNoWatermark&quot;:null,&quot;fullscreen&quot;:null,&quot;imageSize&quot;:&quot;normal&quot;,&quot;height&quot;:608,&quot;width&quot;:1024,&quot;resizeWidth&quot;:null,&quot;bytes&quot;:null,&quot;alt&quot;:null,&quot;title&quot;:null,&quot;type&quot;:null,&quot;href&quot;:null,&quot;belowTheFold&quot;:false,&quot;topImage&quot;:true,&quot;internalRedirect&quot;:null,&quot;isProcessing&quot;:false,&quot;align&quot;:null,&quot;offset&quot;:false}" class="sizing-normal" alt="" srcset="https://substackcdn.com/image/fetch/$s_!u6hb!,w_424,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3d422122-a0b0-4220-8f31-b10e1d1e88f1_1024x608.png 424w, https://substackcdn.com/image/fetch/$s_!u6hb!,w_848,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3d422122-a0b0-4220-8f31-b10e1d1e88f1_1024x608.png 848w, https://substackcdn.com/image/fetch/$s_!u6hb!,w_1272,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3d422122-a0b0-4220-8f31-b10e1d1e88f1_1024x608.png 1272w, https://substackcdn.com/image/fetch/$s_!u6hb!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3d422122-a0b0-4220-8f31-b10e1d1e88f1_1024x608.png 1456w" sizes="100vw" fetchpriority="high"></picture><div class="image-link-expand"><div class="pencraft pc-display-flex pc-gap-8 pc-reset"><button tabindex="0" type="button" class="pencraft pc-reset pencraft icon-container restack-image"><svg role="img" width="20" height="20" viewBox="0 0 20 20" fill="none" stroke-width="1.5" stroke="var(--color-fg-primary)" stroke-linecap="round" stroke-linejoin="round" xmlns="http://www.w3.org/2000/svg"><g><title></title><path d="M2.53001 7.81595C3.49179 4.73911 6.43281 2.5 9.91173 2.5C13.1684 2.5 15.9537 4.46214 17.0852 7.23684L17.6179 8.67647M17.6179 8.67647L18.5002 4.26471M17.6179 8.67647L13.6473 6.91176M17.4995 12.1841C16.5378 15.2609 13.5967 17.5 10.1178 17.5C6.86118 17.5 4.07589 15.5379 2.94432 12.7632L2.41165 11.3235M2.41165 11.3235L1.5293 15.7353M2.41165 11.3235L6.38224 13.0882"></path></g></svg></button><button tabindex="0" type="button" class="pencraft pc-reset pencraft icon-container view-image"><svg xmlns="http://www.w3.org/2000/svg" width="20" height="20" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="lucide lucide-maximize2 lucide-maximize-2"><polyline points="15 3 21 3 21 9"></polyline><polyline points="9 21 3 21 3 15"></polyline><line x1="21" x2="14" y1="3" y2="10"></line><line x1="3" x2="10" y1="21" y2="14"></line></svg></button></div></div></div></a><figcaption class="image-caption"></figcaption></figure></div><h2><strong>Meeting Fatigue Is a Management Failure</strong></h2><p>For about eighteen months, my calendar was full. Not strategically full, just full. I accepted meetings because there were empty slots. I rarely questioned whether a meeting was necessary, or whether I needed to be there. Most days ended with hours of calls and nothing to show for them.</p><p>I was not a victim of this system. I was part of it. I called meetings that did not need to happen. I scheduled syncs because I was unsure whether someone was on track and did not want to ask directly. I used meetings to defer decisions I could have made alone. Meetings felt like progress. They were not, but they provided cover. The calendar filled because filling it was easier than doing the work that would have made the meetings unnecessary.</p><h2><strong>Why Meetings Multiply</strong></h2><p>Meetings proliferate not because they are effective, but because they are safe. Scheduling a meeting signals activity. It distributes accountability. It creates a record of alignment. For managers under pressure, calling a meeting is easier than making a decision, writing a document, or trusting someone to do their job.</p><p>Many meetings serve political or emotional functions rather than operational ones. They exist to demonstrate oversight, to cover risk, or to perform momentum where none exists. A recurring sync is often not coordination. It is organisational theatre.</p><h2><strong>A Taxonomy of Useless Meetings</strong></h2><p>I have been responsible for most of these.</p><p><em>Status updates.</em> Called by someone senior who wants visibility into progress. They serve accountability, not coordination. Their frequency correlates with a trust deficit between layers of the organisation.</p><p><em>Read-alouds.</em> A host reads through a slide deck or document while attendees sit in silence. The meeting exists because writing is harder than talking, and because sending a document does not guarantee it will be read.</p><p><em>Undefined outcomes.</em> Labelled as brainstorming or syncs. They end without action items. If the only output is another meeting, the first one had no purpose.</p><p><em>Zombie recurrences.</em> These start with a reason but persist through inertia. No one cancels them because cancellation requires a decision, and decisions require ownership.</p><p><em>Agenda drift.</em> These begin with a structure but expand. Without time limits or a facilitator willing to cut discussion, any topic fills the available time.</p><p>Most people running these meetings are themselves overloaded and operating in systems that reward presence over output. That does not make the meetings useful. It explains why they continue.</p><h2><strong>What Actually Helped</strong></h2><p>I made changes. They left the underlying problem untouched.</p><p><em>Buffers.</em> I started ending meetings five minutes early and beginning them five minutes late.</p><p><em>Focus blocks.</em> Both Google Calendar and Outlook allow you to reserve time for uninterrupted work. I did this. The blocks held about 70% of the time.</p><p><em>Scheduling tools.</em> Calendly, and later Google Workspace&#8217;s equivalent, let others book time within defined windows. I controlled when I was interruptible.</p><p><em>Agendas as filters.</em> I declined meetings without a stated purpose. A list of topics lets attendees assess whether they need to be there. It also forces organisers to clarify their own thinking, which sometimes results in the meeting being cancelled.</p><p><em>Recorded actions.</em> A meeting without documented outcomes is a conversation that will be forgotten. AI transcription tools help, but they do not replace someone taking ownership of follow-through.</p><p>These are mitigations. They protect individuals. They do not change the incentives.</p><h2><strong>The Problem Remains Structural</strong></h2><p>The incentives that generate meeting overload are still in place: unclear ownership, lack of trust, risk-averse cultures, weak documentation practices. Meetings remain the path of least resistance for coordination, even when they are inefficient.</p><p>The assumption that more meetings produce more alignment is rarely examined. Excessive meetings often indicate the opposite: that responsibilities are unclear, that decisions are not being made, and that written communication has failed.</p><p>This is not unchangeable. But change requires someone with authority to redesign the incentives. Those people are usually the ones whose calendars are fullest. They have the least time to notice the problem and the most investment in the current system. Meeting overload persists, in part, because it benefits those who create it.</p><p>I have fewer bad meetings now. The calendar is quieter, not because the organisation changed, but because I learned to defend my time. That is a workaround. The system remains intact.</p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://www.theproductman.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe now&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="https://www.theproductman.com/subscribe?"><span>Subscribe now</span></a></p><p></p>]]></content:encoded></item></channel></rss>