LinkedIn Post Ideas for Heads of Product

Forty-one percent of respondents in our Q3 customer survey asked for bulk export. Highest-requested item on the list, by a wide margin over anything else. We built it. Six weeks, two engineers, one designer. Shipped in October. Ninety days later: 3% adoption. Not 3% of survey respondents — 3% of our entire active base. I pulled the session recordings before writing this. What I found: people weren't asking for bulk export because they wanted to export in bulk. They were asking for it because our reporting dashboard didn't show the one comparison view they needed, and export-to-Excel was their workaround for a gap we hadn't named correctly. The request was real. The stated solution wasn't the actual job. What changed in our discovery process since: — Every feature request in the backlog now gets a mandatory "what will you do with this in the tool you'd export to" follow-up before it's scored. — We stopped counting survey mentions as a prioritization signal on their own. Mentions get a ticket for research, not a ticket for the roadmap. — Our PMs now sit in on three support calls a month, unscripted, specifically listening for the workaround behind the ask. We rebuilt the comparison view instead. Adoption on that: 34% in the first month. Users are excellent at describing pain and unreliable at prescribing the fix. Our job is the second part, not the first.

I stopped publishing a feature-and-date roadmap eighteen months ago. Sales was furious for about a quarter. The old roadmap had six features with target quarters next to each. It was wrong within five weeks, every single time — a dependency slipped, a bigger customer escalation jumped the queue, an eng estimate turned out optimistic by 3x. Every miss became a trust conversation instead of a planning conversation. What replaced it: three themes per half, no dates. This half — "reduce time-to-first-value," "close the enterprise permissions gap," "cut support load on onboarding." Each theme has a target metric, not a ship date. The pushback was immediate. Sales wanted specific features to promise in deals. My answer: I'll tell you the theme we're committed to and the metric we're accountable for. I won't promise a date I don't control. It took two quarters for sales to adjust their pitch from "X ships in March" to "reducing time-to-value is a committed priority this half, and here's what shipped last time we said that." The second pitch closed just as well, because prospects were vetting commitment to a problem, not a delivery date. Our roadmap accuracy — themes actually addressed within the stated half — sits at 89% now. Our old feature-date accuracy hovered around 40%. If your roadmap keeps breaking promises, the roadmap format is the bug, not your team's execution.

Our quarterly planning used to eat two full weeks — status decks, alignment meetings, re-alignment meetings. Now it's three days. Here's the structure: Day 1 (async): every team lead submits a one-page pre-read. Not a slide deck — a doc with three sections: what we're proposing, what we're NOT doing and why, and the capacity math showing how the numbers add up. No pre-read, no seat at the planning meeting. Day 2: I read every pre-read and flag conflicts privately before anyone's in a room together. Eng, design, and GTM leads get a shared doc showing where two teams claimed the same engineers or the same launch window. Day 3: one meeting, 90 minutes, capped at eight people. The only agenda: resolve the flagged conflicts. Everything not flagged is already approved by default — the pre-read did the alignment work. The rule that made this work: capacity honesty. Every team shows their real available engineering weeks, not their optimistic ones, and I hold them to a 20% buffer for support and incidents. Teams that lowballed their buffer in year one blew their roadmap by Q2. They don't lowball anymore. Result: planning dropped from roughly 80 person-hours to under 20, and our quarterly commitment hit-rate went from 61% to 84%. The old two weeks weren't buying us alignment. They were buying us the illusion of alignment through repetition.

We made weekly active users our north star metric for fourteen months. It was the wrong call, and I want to walk through why. WAU climbed steadily — 22% growth over the year. Leadership was thrilled. Then our NPS dropped nine points in the same window, and churn among our highest-value accounts ticked up. What was actually happening: WAU rewarded any login, including logins driven by a notification loop we'd built specifically to inflate the number. People were opening the app and bouncing in under ten seconds. We'd optimized for a metric that looked like engagement and was actually just interruption. We demoted WAU to a supporting metric and promoted "weekly completed core workflows" instead — a session only counts if someone finishes one of the three jobs the product exists to do. The new metric was flat for two months while we killed the notification loop. Painful to report upward. But by month four it was climbing on its own, and NPS recovered 6 of the 9 points we'd lost. The lesson I keep relearning: a north star metric is only as good as its resistance to gaming, including gaming by your own team under pressure to show growth. If a metric can go up while the product gets worse, it will, eventually, because someone will find the shortcut before they find the hard fix. What metric has burned your team this way?

I sunset our custom reporting builder last quarter. It had a 4.8-star in-app rating and the angriest churn-risk emails I've read in three years. Here's the memo structure I used to make the call. Section 1 — usage data: 6% of accounts had built a custom report in the last 90 days. Of those, 40% built exactly one and never returned. The 4.8-star rating came from a vocal 6%, not a broad base. Section 2 — maintenance cost: the builder touched our most fragile part of the codebase. It consumed roughly 25% of one senior engineer's time every quarter in bug fixes and edge-case support, for a feature 94% of accounts never opened. Section 3 — the angry-customer plan: I identified the 40 accounts with real dependency on it — not just usage, but revenue at risk. Personal calls, not an email blast, three months before sunset. We built a migration path to three pre-set report templates covering 90% of what custom builders had actually been used for. Outcome: 34 of 40 at-risk accounts migrated with no complaint. Four churned — all four under $200 MRR. The freed engineering time went into our permissions system, which had 40x the usage of the reporting builder. Deprecation isn't a failure to admit. It's a prioritization decision made in public, and it's the one most product leaders avoid making at all.

Our activation rate had been flat at 38% for two quarters. The funnel data showed nothing — every step looked healthy, drop-off evenly distributed, nothing screaming "fix me." I sat in on 30 customer interviews myself over five weeks, not delegated to research. Question 14 of my script asked people to walk me through what they did the day after signup, screen-share and all. What analytics couldn't show: 19 of 30 people were exporting our onboarding checklist into their own spreadsheet before actually using the product, then working through it there, offline, at their own pace — sometimes days later. Our activation event fired on in-app completion. Their real activation moment was happening in a tool we couldn't instrument. We'd been optimizing in-app nudges for a workflow step that, for two-thirds of our users, wasn't even happening in-app. The fix: we rebuilt the checklist as a lightweight in-app tracker that persisted state across sessions, so the offline habit didn't force people out of our funnel entirely. Activation moved from 38% to 51% in six weeks. Thirty interviews cost me roughly 20 hours. The insight would never have shown up in a dashboard, because the dashboard only measures what happens inside the product. If a metric's been flat for two quarters, the data has told you everything it can. Go watch someone's screen instead.

Every senior PM I've managed eventually asks the same question: principal, group PM, or director — and what's actually different? Here's the ladder I built after watching three good PMs leave because the path above senior was undefined. Senior PM: owns a product area, executes against agreed strategy, manages up effectively. Principal PM (IC track): owns strategy across 2-3 product areas without direct reports. The bar is influence without authority — can they get eng and design leads to change direction through argument alone, not org position? I require a track record of at least one cross-team initiative they drove without owning any of the teams involved. Group PM (hybrid): 2-4 direct reports plus a strategic surface area. The bar is different from principal — not "can you influence," but "can you develop other PMs while still carrying real product judgment yourself." I test this by asking them to walk me through a call they overruled a report on and why. Director: owns a portfolio, sets multi-quarter strategy, represents product to the exec team and board. The bar is translation — can they make a product bet legible to people who don't think in product terms. I publish this ladder internally with named examples at each level, not just descriptions. Ambiguity above senior is the single biggest reason strong PMs quit for a title, not a job. What does your ladder look like above senior?

I annotated my calendar for one full week last month, hour by hour, to see where my time actually goes versus where I think it goes. The real breakdown: — 28% exec and board alignment — pre-wires, the monthly board metric review, cross-functional priority fights with sales and finance. — 22% discovery — customer calls, interview synthesis, competitive review. — 19% hiring — two senior PM roles open all month, so this was inflated, but hiring never drops below 10% in a normal week either. — 16% firefighting — an incident retro, a churn-risk escalation, a data pipeline bug that broke our activation metric for four days. — 15% actual roadmap and prioritization work — the thing I assumed would be my main job. The gap between assumption and reality is the whole point of posting this. I thought I'd spend a third of my week on strategy and prioritization. It's closer to a sixth in a normal week, and firefighting alone can eat that entire sixth in a bad one. What I've changed because of this audit: I now block two protected discovery mornings a week that nothing, including exec requests, can bump. Before the audit, discovery was the first thing sacrificed to a calendar invite. If you're new to a head-of-product role and calibrating what "normal" looks like — this is closer to it than any job description you'll read.

Every competitor in our category shipped an AI summarization feature within the same six-week window last quarter. Including us. That tells you something: if four competing products can ship comparable AI capability inside six weeks, the capability itself was never the moat. It's now table stakes, same as SSO or mobile apps were a decade ago. Where I'm telling my team the actual differentiation lives now: Workflow depth. Anyone can bolt a chat interface onto existing data. Far fewer companies can rebuild the underlying workflow so the AI output plugs directly into the next three steps a user takes, with zero copy-paste. That integration depth takes quarters, not weeks. Data network effects. The AI feature itself is commoditized; the proprietary data feeding it is not. Our biggest edge isn't our model — it's 40,000 accounts' worth of workflow data our competitors don't have access to. Distribution. Two products with identical AI features will win or lose on who gets in front of the buyer first and who's already embedded in their existing tool stack. I've told my PMs to stop pitching "we have AI" as a roadmap win internally. It's not nothing, but it's not a differentiator on its own anymore — it's closer to a checkbox a prospect expects before evaluation even starts. Where is your team placing its actual differentiation bet post-AI-parity?

I want an honest answer, not a humble-brag disguised as one. Mine: I fought hard for a self-serve enterprise tier two years ago. I defended it in three separate leadership meetings against skepticism that enterprise buyers wanted a sales conversation, not a checkout page. I was wrong. Six months of data: enterprise self-serve signups converted to paid at 4%, versus 31% for the same segment when routed through a sales conversation. I'd mistaken my own preference for a frictionless PLG motion for what actually served the buyer. We killed the self-serve enterprise tier nine months in. I'd defended it publicly enough that reversing it cost me some credibility in the room — deserved cost, in hindsight. What's the decision you fought for that the data eventually proved wrong? Not the failed experiment you expected to fail — the one you were genuinely convinced of and had to publicly walk back. I'll go first in the comments with the full numbers if anyone wants the breakdown. Product leaders who can't name one of these either haven't made enough real decisions, or aren't being honest about the ones they've made.