From fb659bd6b0973d9a883cf83830b6d63464fc9f99 Mon Sep 17 00:00:00 2001 From: cleo-pleurodon Date: Mon, 22 Dec 2025 19:22:30 -0500 Subject: [PATCH 1/6] Create what-to-do-when-product-velocity-breaks-the-speed-of-adoption.mdx --- ...-velocity-breaks-the-speed-of-adoption.mdx | 186 ++++++++++++++++++ 1 file changed, 186 insertions(+) create mode 100644 contents/blog/what-to-do-when-product-velocity-breaks-the-speed-of-adoption.mdx diff --git a/contents/blog/what-to-do-when-product-velocity-breaks-the-speed-of-adoption.mdx b/contents/blog/what-to-do-when-product-velocity-breaks-the-speed-of-adoption.mdx new file mode 100644 index 000000000000..fb721586c598 --- /dev/null +++ b/contents/blog/what-to-do-when-product-velocity-breaks-the-speed-of-adoption.mdx @@ -0,0 +1,186 @@ +--- +date: 2026-01-01 +title: What to do when product velocity breaks the speed of adoption +rootPage: /blog +sidebar: Blog +showTitle: true +hideAnchor: true +author: cleo-lant + - +featuredImage: >- + https://res.cloudinary.com/dmukukwp6/image/upload/posthog.com/contents/images/blog/posthog-blog-image.png +featuredImageType: full +category: Product growth +tags: + - Product + - Growth +seo: + metaTitle: 'What to do when product velocity breaks the speed of adoption' + metaDescription: 'When your team ships faster than users can adopt new features, you face a unique challenge. Here's how to balance product velocity with user adoption.' +--- + +Is it possible to ship too much – or too fast? + +Yes. Probably. Unfortunately. + +What used to take a full product org can now be done by a handful of people with good judgment and a lot of tokens. As a result, software powered by LLMs is [cheaper to build](https://martinalderson.com/posts/has-the-cost-of-software-just-dropped-90-percent/) and [scaling faster](https://smartdev.com/ship-product-faster-with-ai-real-data/) than at any point in history. + +Take our team at PostHog. With dozens of engineering teams shipping independently, product velocity is extremely high. Once you cross a certain threshold however, that velocity stops compounding and starts competing with itself. + +![product marketing at PostHog](https://res.cloudinary.com/dmukukwp6/image/upload/the_office_meme_a199c5af0a.png) + +## When you ship fast enough, user attention becomes the bottleneck + +Since PostHog is a work tool – not a [lifestyle brand](/merch) – even our most enthusiastic users won’t adopt an infinite number of new things per week. + +In practice, B2B SaaS users tend to adopt: +- one big new thing every few months +- a couple of medium improvements +- a handful of small quality-of-life upgrades + +Everything else gets ignored until someone explains why it matters. + +Luckily, someone has already figured out how to optimize for this problem in manufacturing and we can apply the same ideas to your startup. + +This simple principle comes from the **Theory of Constraints** (TOC): + +> When upstream output increases without increasing downstream capacity, the system destabilizes. + +In our case: +**Upstream**, we have: +- 39 small teams [working asynchronously](/newsletter/how-we-work-async) +- very high shipping velocity +- AI accelerating individual productivity + +**Downstrea**, we have: +- user attention (do they notice?) +- user comprehension (do they understand?) +- user engagement (do they care?) + +![product marketing at PostHog](https://res.cloudinary.com/dmukukwp6/image/upload/the_office_meme_a199c5af0a.png) + +When input exceeds the capacity of the bottleneck, a few predictable things happen: + +### 1. Queue buildup +In manufacturing, this looks like excess inventory. In software, this creates a kind of invisible backlog – work that’s finished on your side, but unfinished in terms of user value. + +The result is diffuse impact: lots of progress shipped, but less progress felt. + +### 2. Time-to-value increases +As that backlog grows, lead times stretch – not in engineering, but in adoption. Your team keeps shipping, but each new capability takes longer to move from available to useful. + +Users struggle to keep up with what’s changed. Support and sales spend more time explaining context. Marketing lags releases instead of amplifying them. + +### 3. Quality degredation +When a bottleneck is overloaded, quality degrades through forced tradeoffs. + +In software, that shows up as: +- partial adoption instead of full behavior change +- misunderstood capabilities +- features used narrowly when they were designed to be foundational + +Your product keeps getting bigger and better, but not proportionally clearer. + +![product marketing at PostHog](https://res.cloudinary.com/dmukukwp6/image/upload/the_office_meme_a199c5af0a.png) + +## Does that mean you should slow down? +No. Maybe? Definitely not. + +Slowing down is what companies do when they run out of ideas (and clearly that's the not problem). Fortunately, the Theory of Constraints is quite explicit about what _not_ to do here: + +> Improving non-bottlenecks is a waste of resources. You improve the system by elevating the bottleneck. + +You could market harder. Push more announcements. Buy more attention. Top-of-funnel always looks good on a dashboard. But adoption still happens one human at a time, and each individual user has a finite amount of mental bandwidth. + +So the real question is: how do you elevate adoption without killing velocity? (and without [losing your edge](/newsletter/how-startups-lose-their-edge)). + +That means that the real question isn’t whether to slow down. It’s this: +How do you elevate adoption without killing velocity? (and without [losing your edge](/newsletter/how-startups-lose-their-edge)). + + +## How to address the real bottleneck of user attention +If you’re building anything serious (and using AI to increase throughput), you’ll hit this wall eventually. + +We’re still figuring out what to do about it at PostHog, but directionally this is where the work needs to shift: + +## 1. Treat attention like a scarce resource (because it is) +Small teams will naturally optimize for their own product space, but suboptimally for users’ overall cognitive bandwidth. Marketing everything as soon as it’s shipped turns internal velocity into competition for the same slice of user attention (and everyone loses). + +### What failure looks like +- Creating elaborate campaigns for every new feature +- Not having a [launch tier framework](https://aakashgupta.medium.com/the-launch-tier-system-that-transforms-product-teams-fddbb55a785c) +- Email blasting users without [segmentation](https://www.reforge.com/blog/what-is-user-segmentation) +- Producing lengthy demo videos that are sincere-but-forgettable +- Marketing on the same exhausted channels as everyone else (https://andrewchen.substack.com/p/every-marketing-channel-sucks-right) + +### Instead +- Make [human-centric](https://www.youtube.com/watch?v=QeU5MmpqBg0&list=PLnOY1RYHjDfw2joBxUPADaadeX5IradbH&index=2), [absurd](https://www.youtube.com/watch?v=EXisgy6eWJ0&list=PLnOY1RYHjDfw2joBxUPADaadeX5IradbH&index=4), entertainment-first content +- [Partner with people](https://www.linkedin.com/feed/update/urn:li:activity:7401713037386379265) and brands who have mindshare and trust with your ICP +- Build [cool things](/deskhog) that delight your target audience without selling your product +- Turn internal jokes into [public canon](https://www.youtube.com/watch?v=_eLZqBVkxCc&list=PLnOY1RYHjDfw2joBxUPADaadeX5IradbH&index=3) +- If you’re doing founder-led marketing, [commit to the bit](https://www.linkedin.com/in/j-hawkins/) +- [Design a world](https://www.linkedin.com/posts/lottiecoxon_i-was-unsure-how-to-promote-that-we-are-now-activity-7368966636244049920-S3mU?utm_source=share&utm_medium=member_desktop&rcm=ACoAACADwYwBS3M192eUP4W-otEA2PKzmVWImH0) (not a funnel) that people want to live in, and let them [explore it](https://x.com/MichaelAshmead/status/1966136656265687134) when they have the context to care + +## 2. Sequence launches based on user capacity, not team readiness +Marketing everything as soon as it’s shipped turns internal velocity into competition for the same slice of user attention (everyone loses). + +### What failure looks like +- Treating launches as [outputs instead of outcomes](https://productschool.com/blog/analytics/output-vs-outcome) +- Existing users with [feature fatigue](https://www.linkedin.com/pulse/feature-fatigue-love-focus-derek-francis-mezxc/), and new users with release whiplash +- Expecting documentation to do the heavy lifting of product education +- Highlighting the what more than the why (*marketing [features > benefits](https://posthog.com/newsletter/marketing-for-devs) is typically a good move if you’re marketing to developers, but overindexing on ‘what’ makes adoption someone else’s problem) + +### Instead +- Classify launches as _events_ or _infrastructure_: If it’s an event, treat it like the [biggest event of the year](https://www.linkedin.com/feed/update/urn:li:activity:7398759974686076928) +- Instead of one-off updates, invest in producing a [narrative series](https://www.youtube.com/playlist?list=PLnOY1RYHjDfxcuWI_L1xwuhoXAsxR59VL) that users can follow +- Encourage engineers to [do support](/newsletter/engineers-do-support) and see first-hand where users get stuck + +## 3. Build discovery into the product +If realizing value requires explanation outside the product, you haven’t removed the adoption bottleneck – you’ve just moved it downstream to marketing, sales, or support. + +- Treating external platforms as your main discovery engine (performative presence on Product Hunt, G2, Hacker News may not be [worth it](https://news.ycombinator.com/item?id=29864157)) +- Relying on social media and emails broadcasts to communicate everything you shipped this week +- Disrupting the in-app experience with too many tooltips, banners, modals and popups +- Adding so much to the UI that it subtracts from [user experience](/blog/redesigned-nav-menu) + +### Instead +- Define [activation criteria](/product-engineers/activation-metrics) for new products, and track user behavior over time +- Leverage AI to surface features when a user is already doing the related job +- Embed docs within your product to keep users in flow (linking to an external help center is a form of context switching) +- Leverage habit loops (trigger → action → reward → reinforcement) and other [PLG](https://productled.com/blog/product-led-growth-framework-for-saas-companies) tactics to keep users engaged +- Commit to [continuous discovery](https://www.youtube.com/watch?v=9RFaz9ZBXpk). Let user feedback and behavior influence what gets amplified next + + + +### Instead +- Publish deep thinking, [learnings](/8-learnings-from-1-year-of-agents-posthog-ai), works-in-progress, and durable mental models that are useful with, or without your product +- Give space for all seniority levels and roles to [author content](/blog) that matters to them +- Publish uncomfortable things like [postmortems](/blog/nov-24-shai-hulud-attack-post-mortem) for incidents +- Turn internal knowledge into [public artifacts](/handbook) +- Be a good citizen, create space for [others to thrive](/handbook/people/hogpatch), help developers (or whichever community you market to) without asking for anything in return + +4. Measure learning, not just usage +Adoption doesn’t really start with features. It starts with people getting better at their jobs. That’s why a lot of our marketing content isn’t really about PostHog at all – it’s about [how to be a better product engineer](https://newsletter.posthog.com/). + +### What failure looks like +- Overemphasizing vanity metrics like clicks, impressions and daily active users (DAU) +- Incentivizing your product team to be a [feature factory](https://xenoss.io/blog/product-velocity-trap-solutions) instead of taste makers +- Publishing content that only talks about your product – instead of the market, community, and problems your users actually think about +- Believing other people care about your product as much as you do (they don’t) + +### Instead +- Publish [learnings](/blog/8-learnings-from-1-year-of-agents-posthog-ai), [works-in-progress](/blog/multi-modal-llm-user-behavior-analysis), and durable mental models that are useful with, or without your product +- Teach others about your domain (Hubpsot teaches you how to be a [better marketer](https://blog.hubspot.com/), Figma teaches you how to be a [better designer](https://www.figma.com/blog/insights/)) +- Share uncomfortable things like [postmortems](/blog/nov-24-shai-hulud-attack-post-mortem) for incidents +- Be a good citizen, [create space](/handbook/people/hogpatch) for others to thrive, help developers (or whichever community you market to) without asking for anything in return +- Turn internal knowledge into [public artifacts](/handbook) and give space for all every role to author content that matters to them + +## Fast, not frantic +It's tempting to treat “shipping too fast” as a humblebrag, but that’s lazy thinking. If users can’t adopt what we ship, it’s not velocity – it’s waste. + +Practically, that means we need to be explicit about what matters, get better at sequencing the big launches, make a select number of things very loud, and let everything else be quietly excellent. + +And of course, do more things that would make a normal SaaS company nervous. Not everyone will like it, and that’s what makes velocity convert to value. + + + From 6220ffecd537aa4acc10cf5d1e460b68e8f962ad Mon Sep 17 00:00:00 2001 From: cleo-pleurodon Date: Mon, 22 Dec 2025 19:30:59 -0500 Subject: [PATCH 2/6] spelling and grammar --- ...-velocity-breaks-the-speed-of-adoption.mdx | 30 +++++++------------ 1 file changed, 10 insertions(+), 20 deletions(-) diff --git a/contents/blog/what-to-do-when-product-velocity-breaks-the-speed-of-adoption.mdx b/contents/blog/what-to-do-when-product-velocity-breaks-the-speed-of-adoption.mdx index fb721586c598..12d36e821253 100644 --- a/contents/blog/what-to-do-when-product-velocity-breaks-the-speed-of-adoption.mdx +++ b/contents/blog/what-to-do-when-product-velocity-breaks-the-speed-of-adoption.mdx @@ -6,7 +6,6 @@ sidebar: Blog showTitle: true hideAnchor: true author: cleo-lant - - featuredImage: >- https://res.cloudinary.com/dmukukwp6/image/upload/posthog.com/contents/images/blog/posthog-blog-image.png featuredImageType: full @@ -52,7 +51,7 @@ In our case: - very high shipping velocity - AI accelerating individual productivity -**Downstrea**, we have: +**Downstream**, we have: - user attention (do they notice?) - user comprehension (do they understand?) - user engagement (do they care?) @@ -71,7 +70,7 @@ As that backlog grows, lead times stretch – not in engineering, but in adoptio Users struggle to keep up with what’s changed. Support and sales spend more time explaining context. Marketing lags releases instead of amplifying them. -### 3. Quality degredation +### 3. Quality degradation When a bottleneck is overloaded, quality degrades through forced tradeoffs. In software, that shows up as: @@ -86,15 +85,13 @@ Your product keeps getting bigger and better, but not proportionally clearer. ## Does that mean you should slow down? No. Maybe? Definitely not. -Slowing down is what companies do when they run out of ideas (and clearly that's the not problem). Fortunately, the Theory of Constraints is quite explicit about what _not_ to do here: +Slowing down is what companies do when they run out of ideas (and clearly that's not the problem). Fortunately, the Theory of Constraints is quite explicit about what _not_ to do here: > Improving non-bottlenecks is a waste of resources. You improve the system by elevating the bottleneck. You could market harder. Push more announcements. Buy more attention. Top-of-funnel always looks good on a dashboard. But adoption still happens one human at a time, and each individual user has a finite amount of mental bandwidth. -So the real question is: how do you elevate adoption without killing velocity? (and without [losing your edge](/newsletter/how-startups-lose-their-edge)). - -That means that the real question isn’t whether to slow down. It’s this: +So the real question isn't whether to slow down. It's this: How do you elevate adoption without killing velocity? (and without [losing your edge](/newsletter/how-startups-lose-their-edge)). @@ -111,7 +108,7 @@ Small teams will naturally optimize for their own product space, but suboptimall - Not having a [launch tier framework](https://aakashgupta.medium.com/the-launch-tier-system-that-transforms-product-teams-fddbb55a785c) - Email blasting users without [segmentation](https://www.reforge.com/blog/what-is-user-segmentation) - Producing lengthy demo videos that are sincere-but-forgettable -- Marketing on the same exhausted channels as everyone else (https://andrewchen.substack.com/p/every-marketing-channel-sucks-right) +- Marketing on the same exhausted channels as everyone else ([every marketing channel sucks right](https://andrewchen.substack.com/p/every-marketing-channel-sucks-right)) ### Instead - Make [human-centric](https://www.youtube.com/watch?v=QeU5MmpqBg0&list=PLnOY1RYHjDfw2joBxUPADaadeX5IradbH&index=2), [absurd](https://www.youtube.com/watch?v=EXisgy6eWJ0&list=PLnOY1RYHjDfw2joBxUPADaadeX5IradbH&index=4), entertainment-first content @@ -126,7 +123,7 @@ Marketing everything as soon as it’s shipped turns internal velocity into comp ### What failure looks like - Treating launches as [outputs instead of outcomes](https://productschool.com/blog/analytics/output-vs-outcome) -- Existing users with [feature fatigue](https://www.linkedin.com/pulse/feature-fatigue-love-focus-derek-francis-mezxc/), and new users with release whiplash +- Existing users experiencing [feature fatigue](https://www.linkedin.com/pulse/feature-fatigue-love-focus-derek-francis-mezxc/), and new users with release whiplash - Expecting documentation to do the heavy lifting of product education - Highlighting the what more than the why (*marketing [features > benefits](https://posthog.com/newsletter/marketing-for-devs) is typically a good move if you’re marketing to developers, but overindexing on ‘what’ makes adoption someone else’s problem) @@ -136,8 +133,9 @@ Marketing everything as soon as it’s shipped turns internal velocity into comp - Encourage engineers to [do support](/newsletter/engineers-do-support) and see first-hand where users get stuck ## 3. Build discovery into the product -If realizing value requires explanation outside the product, you haven’t removed the adoption bottleneck – you’ve just moved it downstream to marketing, sales, or support. +If realizing value requires explanation outside the product, you haven't removed the adoption bottleneck – you've just moved it downstream to marketing, sales, or support. +### What failure looks like - Treating external platforms as your main discovery engine (performative presence on Product Hunt, G2, Hacker News may not be [worth it](https://news.ycombinator.com/item?id=29864157)) - Relying on social media and emails broadcasts to communicate everything you shipped this week - Disrupting the in-app experience with too many tooltips, banners, modals and popups @@ -151,15 +149,7 @@ If realizing value requires explanation outside the product, you haven’t remov - Commit to [continuous discovery](https://www.youtube.com/watch?v=9RFaz9ZBXpk). Let user feedback and behavior influence what gets amplified next - -### Instead -- Publish deep thinking, [learnings](/8-learnings-from-1-year-of-agents-posthog-ai), works-in-progress, and durable mental models that are useful with, or without your product -- Give space for all seniority levels and roles to [author content](/blog) that matters to them -- Publish uncomfortable things like [postmortems](/blog/nov-24-shai-hulud-attack-post-mortem) for incidents -- Turn internal knowledge into [public artifacts](/handbook) -- Be a good citizen, create space for [others to thrive](/handbook/people/hogpatch), help developers (or whichever community you market to) without asking for anything in return - -4. Measure learning, not just usage +## 4. Measure learning, not just usage Adoption doesn’t really start with features. It starts with people getting better at their jobs. That’s why a lot of our marketing content isn’t really about PostHog at all – it’s about [how to be a better product engineer](https://newsletter.posthog.com/). ### What failure looks like @@ -173,7 +163,7 @@ Adoption doesn’t really start with features. It starts with people getting bet - Teach others about your domain (Hubpsot teaches you how to be a [better marketer](https://blog.hubspot.com/), Figma teaches you how to be a [better designer](https://www.figma.com/blog/insights/)) - Share uncomfortable things like [postmortems](/blog/nov-24-shai-hulud-attack-post-mortem) for incidents - Be a good citizen, [create space](/handbook/people/hogpatch) for others to thrive, help developers (or whichever community you market to) without asking for anything in return -- Turn internal knowledge into [public artifacts](/handbook) and give space for all every role to author content that matters to them +- Turn internal knowledge into [public artifacts](/handbook) and give space for every role to author content that matters to them ## Fast, not frantic It's tempting to treat “shipping too fast” as a humblebrag, but that’s lazy thinking. If users can’t adopt what we ship, it’s not velocity – it’s waste. From b2ed76bd38f0ea1dcd317e8a17924f5760179748 Mon Sep 17 00:00:00 2001 From: cleo-pleurodon Date: Tue, 23 Dec 2025 09:01:30 -0500 Subject: [PATCH 3/6] moved to newsletter --- ...-velocity-breaks-the-speed-of-adoption.md} | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-) rename contents/{blog/what-to-do-when-product-velocity-breaks-the-speed-of-adoption.mdx => newsletter/what-to-do-when-product-velocity-breaks-the-speed-of-adoption.md} (96%) diff --git a/contents/blog/what-to-do-when-product-velocity-breaks-the-speed-of-adoption.mdx b/contents/newsletter/what-to-do-when-product-velocity-breaks-the-speed-of-adoption.md similarity index 96% rename from contents/blog/what-to-do-when-product-velocity-breaks-the-speed-of-adoption.mdx rename to contents/newsletter/what-to-do-when-product-velocity-breaks-the-speed-of-adoption.md index 12d36e821253..5eead8299da4 100644 --- a/contents/blog/what-to-do-when-product-velocity-breaks-the-speed-of-adoption.mdx +++ b/contents/newsletter/what-to-do-when-product-velocity-breaks-the-speed-of-adoption.md @@ -1,22 +1,19 @@ ---- date: 2026-01-01 title: What to do when product velocity breaks the speed of adoption -rootPage: /blog -sidebar: Blog -showTitle: true -hideAnchor: true -author: cleo-lant +author: + - cleo-lant featuredImage: >- - https://res.cloudinary.com/dmukukwp6/image/upload/posthog.com/contents/images/blog/posthog-blog-image.png + https://res.cloudinary.com/dmukukwp6/image/upload/why_we_killed_our_ai_assistant_9e9565192e.png featuredImageType: full -category: Product growth tags: - Product - Growth +crosspost: + - Blog + - Founders seo: metaTitle: 'What to do when product velocity breaks the speed of adoption' metaDescription: 'When your team ships faster than users can adopt new features, you face a unique challenge. Here's how to balance product velocity with user adoption.' ---- Is it possible to ship too much – or too fast? @@ -56,8 +53,6 @@ In our case: - user comprehension (do they understand?) - user engagement (do they care?) -![product marketing at PostHog](https://res.cloudinary.com/dmukukwp6/image/upload/the_office_meme_a199c5af0a.png) - When input exceeds the capacity of the bottleneck, a few predictable things happen: ### 1. Queue buildup @@ -80,8 +75,6 @@ In software, that shows up as: Your product keeps getting bigger and better, but not proportionally clearer. -![product marketing at PostHog](https://res.cloudinary.com/dmukukwp6/image/upload/the_office_meme_a199c5af0a.png) - ## Does that mean you should slow down? No. Maybe? Definitely not. From cc0700d2ebe97c18311627832cc6b7e8ef85a123 Mon Sep 17 00:00:00 2001 From: Ian Vanagas <34755028+ivanagas@users.noreply.github.com> Date: Tue, 23 Dec 2025 11:26:41 -0800 Subject: [PATCH 4/6] change filename, fix frontmatter, formatting --- ...duct-velocity-breaks-speed-of-adoption.md} | 82 +++++++++++++++---- 1 file changed, 65 insertions(+), 17 deletions(-) rename contents/newsletter/{what-to-do-when-product-velocity-breaks-the-speed-of-adoption.md => when-product-velocity-breaks-speed-of-adoption.md} (93%) diff --git a/contents/newsletter/what-to-do-when-product-velocity-breaks-the-speed-of-adoption.md b/contents/newsletter/when-product-velocity-breaks-speed-of-adoption.md similarity index 93% rename from contents/newsletter/what-to-do-when-product-velocity-breaks-the-speed-of-adoption.md rename to contents/newsletter/when-product-velocity-breaks-speed-of-adoption.md index 5eead8299da4..5b3a8d8a4e66 100644 --- a/contents/newsletter/what-to-do-when-product-velocity-breaks-the-speed-of-adoption.md +++ b/contents/newsletter/when-product-velocity-breaks-speed-of-adoption.md @@ -1,5 +1,6 @@ -date: 2026-01-01 +--- title: What to do when product velocity breaks the speed of adoption +date: 2025-12-23 author: - cleo-lant featuredImage: >- @@ -13,7 +14,8 @@ crosspost: - Founders seo: metaTitle: 'What to do when product velocity breaks the speed of adoption' - metaDescription: 'When your team ships faster than users can adopt new features, you face a unique challenge. Here's how to balance product velocity with user adoption.' + metaDescription: "When your team ships faster than users can adopt new features, you face a unique challenge. Here's how to balance product velocity with user adoption." +--- Is it possible to ship too much – or too fast? @@ -43,12 +45,15 @@ This simple principle comes from the **Theory of Constraints** (TOC): > When upstream output increases without increasing downstream capacity, the system destabilizes. In our case: + **Upstream**, we have: + - 39 small teams [working asynchronously](/newsletter/how-we-work-async) - very high shipping velocity - AI accelerating individual productivity **Downstream**, we have: + - user attention (do they notice?) - user comprehension (do they understand?) - user engagement (do they care?) @@ -56,16 +61,19 @@ In our case: When input exceeds the capacity of the bottleneck, a few predictable things happen: ### 1. Queue buildup + In manufacturing, this looks like excess inventory. In software, this creates a kind of invisible backlog – work that’s finished on your side, but unfinished in terms of user value. The result is diffuse impact: lots of progress shipped, but less progress felt. ### 2. Time-to-value increases + As that backlog grows, lead times stretch – not in engineering, but in adoption. Your team keeps shipping, but each new capability takes longer to move from available to useful. Users struggle to keep up with what’s changed. Support and sales spend more time explaining context. Marketing lags releases instead of amplifying them. ### 3. Quality degradation + When a bottleneck is overloaded, quality degrades through forced tradeoffs. In software, that shows up as: @@ -76,6 +84,7 @@ In software, that shows up as: Your product keeps getting bigger and better, but not proportionally clearer. ## Does that mean you should slow down? + No. Maybe? Definitely not. Slowing down is what companies do when they run out of ideas (and clearly that's not the problem). Fortunately, the Theory of Constraints is quite explicit about what _not_ to do here: @@ -87,78 +96,118 @@ You could market harder. Push more announcements. Buy more attention. Top-of-fun So the real question isn't whether to slow down. It's this: How do you elevate adoption without killing velocity? (and without [losing your edge](/newsletter/how-startups-lose-their-edge)). - ## How to address the real bottleneck of user attention + If you’re building anything serious (and using AI to increase throughput), you’ll hit this wall eventually. We’re still figuring out what to do about it at PostHog, but directionally this is where the work needs to shift: -## 1. Treat attention like a scarce resource (because it is) +### 1. Treat attention like a scarce resource (because it is) + Small teams will naturally optimize for their own product space, but suboptimally for users’ overall cognitive bandwidth. Marketing everything as soon as it’s shipped turns internal velocity into competition for the same slice of user attention (and everyone loses). -### What failure looks like +**What failure looks like:** + - Creating elaborate campaigns for every new feature + - Not having a [launch tier framework](https://aakashgupta.medium.com/the-launch-tier-system-that-transforms-product-teams-fddbb55a785c) + - Email blasting users without [segmentation](https://www.reforge.com/blog/what-is-user-segmentation) + - Producing lengthy demo videos that are sincere-but-forgettable + - Marketing on the same exhausted channels as everyone else ([every marketing channel sucks right](https://andrewchen.substack.com/p/every-marketing-channel-sucks-right)) -### Instead +**Instead:** + - Make [human-centric](https://www.youtube.com/watch?v=QeU5MmpqBg0&list=PLnOY1RYHjDfw2joBxUPADaadeX5IradbH&index=2), [absurd](https://www.youtube.com/watch?v=EXisgy6eWJ0&list=PLnOY1RYHjDfw2joBxUPADaadeX5IradbH&index=4), entertainment-first content + - [Partner with people](https://www.linkedin.com/feed/update/urn:li:activity:7401713037386379265) and brands who have mindshare and trust with your ICP + - Build [cool things](/deskhog) that delight your target audience without selling your product + - Turn internal jokes into [public canon](https://www.youtube.com/watch?v=_eLZqBVkxCc&list=PLnOY1RYHjDfw2joBxUPADaadeX5IradbH&index=3) + - If you’re doing founder-led marketing, [commit to the bit](https://www.linkedin.com/in/j-hawkins/) -- [Design a world](https://www.linkedin.com/posts/lottiecoxon_i-was-unsure-how-to-promote-that-we-are-now-activity-7368966636244049920-S3mU?utm_source=share&utm_medium=member_desktop&rcm=ACoAACADwYwBS3M192eUP4W-otEA2PKzmVWImH0) (not a funnel) that people want to live in, and let them [explore it](https://x.com/MichaelAshmead/status/1966136656265687134) when they have the context to care -## 2. Sequence launches based on user capacity, not team readiness +- [Design a world](https://www.linkedin.com/posts/lottiecoxon_i-was-unsure-how-to-promote-that-we-are-now-activity-7368966636244049920-S3mU) (not a funnel) that people want to live in, and let them [explore it](https://x.com/MichaelAshmead/status/1966136656265687134) when they have the context to care + +### 2. Sequence launches based on user capacity, not team readiness + Marketing everything as soon as it’s shipped turns internal velocity into competition for the same slice of user attention (everyone loses). -### What failure looks like +**What failure looks like:** + - Treating launches as [outputs instead of outcomes](https://productschool.com/blog/analytics/output-vs-outcome) + - Existing users experiencing [feature fatigue](https://www.linkedin.com/pulse/feature-fatigue-love-focus-derek-francis-mezxc/), and new users with release whiplash + - Expecting documentation to do the heavy lifting of product education + - Highlighting the what more than the why (*marketing [features > benefits](https://posthog.com/newsletter/marketing-for-devs) is typically a good move if you’re marketing to developers, but overindexing on ‘what’ makes adoption someone else’s problem) -### Instead +**Instead:** + - Classify launches as _events_ or _infrastructure_: If it’s an event, treat it like the [biggest event of the year](https://www.linkedin.com/feed/update/urn:li:activity:7398759974686076928) + - Instead of one-off updates, invest in producing a [narrative series](https://www.youtube.com/playlist?list=PLnOY1RYHjDfxcuWI_L1xwuhoXAsxR59VL) that users can follow + - Encourage engineers to [do support](/newsletter/engineers-do-support) and see first-hand where users get stuck -## 3. Build discovery into the product +### 3. Build discovery into the product + If realizing value requires explanation outside the product, you haven't removed the adoption bottleneck – you've just moved it downstream to marketing, sales, or support. -### What failure looks like +**What failure looks like:** + - Treating external platforms as your main discovery engine (performative presence on Product Hunt, G2, Hacker News may not be [worth it](https://news.ycombinator.com/item?id=29864157)) + - Relying on social media and emails broadcasts to communicate everything you shipped this week + - Disrupting the in-app experience with too many tooltips, banners, modals and popups + - Adding so much to the UI that it subtracts from [user experience](/blog/redesigned-nav-menu) -### Instead +**Instead:** + - Define [activation criteria](/product-engineers/activation-metrics) for new products, and track user behavior over time + - Leverage AI to surface features when a user is already doing the related job + - Embed docs within your product to keep users in flow (linking to an external help center is a form of context switching) + - Leverage habit loops (trigger → action → reward → reinforcement) and other [PLG](https://productled.com/blog/product-led-growth-framework-for-saas-companies) tactics to keep users engaged + - Commit to [continuous discovery](https://www.youtube.com/watch?v=9RFaz9ZBXpk). Let user feedback and behavior influence what gets amplified next +### 4. Measure learning, not just usage -## 4. Measure learning, not just usage Adoption doesn’t really start with features. It starts with people getting better at their jobs. That’s why a lot of our marketing content isn’t really about PostHog at all – it’s about [how to be a better product engineer](https://newsletter.posthog.com/). -### What failure looks like +**What failure looks like:** + - Overemphasizing vanity metrics like clicks, impressions and daily active users (DAU) + - Incentivizing your product team to be a [feature factory](https://xenoss.io/blog/product-velocity-trap-solutions) instead of taste makers + - Publishing content that only talks about your product – instead of the market, community, and problems your users actually think about + - Believing other people care about your product as much as you do (they don’t) -### Instead +**Instead:** + - Publish [learnings](/blog/8-learnings-from-1-year-of-agents-posthog-ai), [works-in-progress](/blog/multi-modal-llm-user-behavior-analysis), and durable mental models that are useful with, or without your product + - Teach others about your domain (Hubpsot teaches you how to be a [better marketer](https://blog.hubspot.com/), Figma teaches you how to be a [better designer](https://www.figma.com/blog/insights/)) + - Share uncomfortable things like [postmortems](/blog/nov-24-shai-hulud-attack-post-mortem) for incidents + - Be a good citizen, [create space](/handbook/people/hogpatch) for others to thrive, help developers (or whichever community you market to) without asking for anything in return + - Turn internal knowledge into [public artifacts](/handbook) and give space for every role to author content that matters to them ## Fast, not frantic + It's tempting to treat “shipping too fast” as a humblebrag, but that’s lazy thinking. If users can’t adopt what we ship, it’s not velocity – it’s waste. Practically, that means we need to be explicit about what matters, get better at sequencing the big launches, make a select number of things very loud, and let everything else be quietly excellent. @@ -166,4 +215,3 @@ Practically, that means we need to be explicit about what matters, get better at And of course, do more things that would make a normal SaaS company nervous. Not everyone will like it, and that’s what makes velocity convert to value. - From b02ba13c5651fb168bbb18505cefe26b616dadfe Mon Sep 17 00:00:00 2001 From: Cleo Date: Wed, 24 Dec 2025 09:16:22 -0500 Subject: [PATCH 5/6] structure improvements Co-authored-by: Ian Vanagas <34755028+ivanagas@users.noreply.github.com> --- ...oduct-velocity-breaks-speed-of-adoption.md | 88 ++++++++----------- 1 file changed, 39 insertions(+), 49 deletions(-) diff --git a/contents/newsletter/when-product-velocity-breaks-speed-of-adoption.md b/contents/newsletter/when-product-velocity-breaks-speed-of-adoption.md index 5b3a8d8a4e66..2a41d95d77a8 100644 --- a/contents/newsletter/when-product-velocity-breaks-speed-of-adoption.md +++ b/contents/newsletter/when-product-velocity-breaks-speed-of-adoption.md @@ -32,33 +32,23 @@ Take our team at PostHog. With dozens of engineering teams shipping independentl Since PostHog is a work tool – not a [lifestyle brand](/merch) – even our most enthusiastic users won’t adopt an infinite number of new things per week. In practice, B2B SaaS users tend to adopt: -- one big new thing every few months -- a couple of medium improvements -- a handful of small quality-of-life upgrades -Everything else gets ignored until someone explains why it matters. +- One big new thing every few months +- A couple of medium improvements +- A handful of small quality-of-life upgrades -Luckily, someone has already figured out how to optimize for this problem in manufacturing and we can apply the same ideas to your startup. +Everything else gets ignored until someone explains why it matters. This is a classic bottleneck. -This simple principle comes from the **Theory of Constraints** (TOC): +Luckily, bottlenecks have solutions. Manufacturers discovered this and crystallized it in a concept called **Theory of Constraints** (TOC). There's one principle of TOC that is particularly relevant here: > When upstream output increases without increasing downstream capacity, the system destabilizes. In our case: -**Upstream**, we have: +- **Upstream** we have 39 small teams [working asynchronously](/newsletter/how-we-work-async), shipping at a high velocity, and AI accelerating individual productivity. +- **Downstream** we have limited user attention, comprehension, and engagement capacity. -- 39 small teams [working asynchronously](/newsletter/how-we-work-async) -- very high shipping velocity -- AI accelerating individual productivity - -**Downstream**, we have: - -- user attention (do they notice?) -- user comprehension (do they understand?) -- user engagement (do they care?) - -When input exceeds the capacity of the bottleneck, a few predictable things happen: +TOC can again help us understand the consequences of this mismatched capacity: ### 1. Queue buildup @@ -77,9 +67,10 @@ Users struggle to keep up with what’s changed. Support and sales spend more ti When a bottleneck is overloaded, quality degrades through forced tradeoffs. In software, that shows up as: -- partial adoption instead of full behavior change -- misunderstood capabilities -- features used narrowly when they were designed to be foundational + +- Partial adoption instead of full behavior change +- Misunderstood capabilities +- Features used narrowly when they were designed to be foundational Your product keeps getting bigger and better, but not proportionally clearer. @@ -94,7 +85,8 @@ Slowing down is what companies do when they run out of ideas (and clearly that's You could market harder. Push more announcements. Buy more attention. Top-of-funnel always looks good on a dashboard. But adoption still happens one human at a time, and each individual user has a finite amount of mental bandwidth. So the real question isn't whether to slow down. It's this: -How do you elevate adoption without killing velocity? (and without [losing your edge](/newsletter/how-startups-lose-their-edge)). + +**How do you elevate adoption without killing velocity?** ## How to address the real bottleneck of user attention @@ -118,19 +110,19 @@ Small teams will naturally optimize for their own product space, but suboptimall - Marketing on the same exhausted channels as everyone else ([every marketing channel sucks right](https://andrewchen.substack.com/p/every-marketing-channel-sucks-right)) -**Instead:** +**Do this instead:** -- Make [human-centric](https://www.youtube.com/watch?v=QeU5MmpqBg0&list=PLnOY1RYHjDfw2joBxUPADaadeX5IradbH&index=2), [absurd](https://www.youtube.com/watch?v=EXisgy6eWJ0&list=PLnOY1RYHjDfw2joBxUPADaadeX5IradbH&index=4), entertainment-first content +- Making [human-centric](https://www.youtube.com/watch?v=QeU5MmpqBg0&list=PLnOY1RYHjDfw2joBxUPADaadeX5IradbH&index=2), [absurd](https://www.youtube.com/watch?v=EXisgy6eWJ0&list=PLnOY1RYHjDfw2joBxUPADaadeX5IradbH&index=4), entertainment-first content -- [Partner with people](https://www.linkedin.com/feed/update/urn:li:activity:7401713037386379265) and brands who have mindshare and trust with your ICP +- [Partnering with people](https://www.linkedin.com/feed/update/urn:li:activity:7401713037386379265) and brands who have mindshare and trust with your ICP -- Build [cool things](/deskhog) that delight your target audience without selling your product +- Building [cool things](/deskhog) that delight your target audience without selling your product -- Turn internal jokes into [public canon](https://www.youtube.com/watch?v=_eLZqBVkxCc&list=PLnOY1RYHjDfw2joBxUPADaadeX5IradbH&index=3) +- Turning internal jokes into [public canon](https://www.youtube.com/watch?v=_eLZqBVkxCc&list=PLnOY1RYHjDfw2joBxUPADaadeX5IradbH&index=3) -- If you’re doing founder-led marketing, [commit to the bit](https://www.linkedin.com/in/j-hawkins/) +- If you’re doing founder-led marketing, [committing to the bit](https://www.linkedin.com/in/j-hawkins/) -- [Design a world](https://www.linkedin.com/posts/lottiecoxon_i-was-unsure-how-to-promote-that-we-are-now-activity-7368966636244049920-S3mU) (not a funnel) that people want to live in, and let them [explore it](https://x.com/MichaelAshmead/status/1966136656265687134) when they have the context to care +- [Designing a world](https://www.linkedin.com/posts/lottiecoxon_i-was-unsure-how-to-promote-that-we-are-now-activity-7368966636244049920-S3mU) (not a funnel) that people want to live in, and let them [explore it](https://x.com/MichaelAshmead/status/1966136656265687134) when they have the context to care ### 2. Sequence launches based on user capacity, not team readiness @@ -146,13 +138,13 @@ Marketing everything as soon as it’s shipped turns internal velocity into comp - Highlighting the what more than the why (*marketing [features > benefits](https://posthog.com/newsletter/marketing-for-devs) is typically a good move if you’re marketing to developers, but overindexing on ‘what’ makes adoption someone else’s problem) -**Instead:** +**Do this instead:** -- Classify launches as _events_ or _infrastructure_: If it’s an event, treat it like the [biggest event of the year](https://www.linkedin.com/feed/update/urn:li:activity:7398759974686076928) +- Classifying launches as _events_ or _infrastructure_: If it’s an event, treat it like the [biggest event of the year](https://www.linkedin.com/feed/update/urn:li:activity:7398759974686076928) -- Instead of one-off updates, invest in producing a [narrative series](https://www.youtube.com/playlist?list=PLnOY1RYHjDfxcuWI_L1xwuhoXAsxR59VL) that users can follow +- Insteading of one-off updates, invest in producing a [narrative series](https://www.youtube.com/playlist?list=PLnOY1RYHjDfxcuWI_L1xwuhoXAsxR59VL) that users can follow -- Encourage engineers to [do support](/newsletter/engineers-do-support) and see first-hand where users get stuck +- Encouraging engineers to [do support](/newsletter/engineers-do-support) and see first-hand where users get stuck ### 3. Build discovery into the product @@ -168,17 +160,17 @@ If realizing value requires explanation outside the product, you haven't removed - Adding so much to the UI that it subtracts from [user experience](/blog/redesigned-nav-menu) -**Instead:** +**Do this instead:** -- Define [activation criteria](/product-engineers/activation-metrics) for new products, and track user behavior over time +- Defining [activation criteria](/product-engineers/activation-metrics) for new products, and track user behavior over time -- Leverage AI to surface features when a user is already doing the related job +- Leveraging AI to surface features when a user is already doing the related job -- Embed docs within your product to keep users in flow (linking to an external help center is a form of context switching) +- Embedding docs within your product to keep users in flow (linking to an external help center is a form of context switching) -- Leverage habit loops (trigger → action → reward → reinforcement) and other [PLG](https://productled.com/blog/product-led-growth-framework-for-saas-companies) tactics to keep users engaged +- Leveraging habit loops (trigger → action → reward → reinforcement) and other [PLG](https://productled.com/blog/product-led-growth-framework-for-saas-companies) tactics to keep users engaged -- Commit to [continuous discovery](https://www.youtube.com/watch?v=9RFaz9ZBXpk). Let user feedback and behavior influence what gets amplified next +- Committing to [continuous discovery](https://www.youtube.com/watch?v=9RFaz9ZBXpk). Let user feedback and behavior influence what gets amplified next ### 4. Measure learning, not just usage @@ -186,7 +178,7 @@ Adoption doesn’t really start with features. It starts with people getting bet **What failure looks like:** -- Overemphasizing vanity metrics like clicks, impressions and daily active users (DAU) +- Overemphasizing vanity metrics like clicks, impressions, and daily active users (DAU) - Incentivizing your product team to be a [feature factory](https://xenoss.io/blog/product-velocity-trap-solutions) instead of taste makers @@ -194,24 +186,22 @@ Adoption doesn’t really start with features. It starts with people getting bet - Believing other people care about your product as much as you do (they don’t) -**Instead:** +**Do this instead:** -- Publish [learnings](/blog/8-learnings-from-1-year-of-agents-posthog-ai), [works-in-progress](/blog/multi-modal-llm-user-behavior-analysis), and durable mental models that are useful with, or without your product +- Publishing [learnings](/blog/8-learnings-from-1-year-of-agents-posthog-ai), [works-in-progress](/blog/multi-modal-llm-user-behavior-analysis), and durable mental models that are useful with, or without, your product -- Teach others about your domain (Hubpsot teaches you how to be a [better marketer](https://blog.hubspot.com/), Figma teaches you how to be a [better designer](https://www.figma.com/blog/insights/)) +- Teaching others about your domain (HubSpot teaches you how to be a [better marketer](https://blog.hubspot.com/), Figma teaches you how to be a [better designer](https://www.figma.com/blog/insights/)) -- Share uncomfortable things like [postmortems](/blog/nov-24-shai-hulud-attack-post-mortem) for incidents +- Sharing uncomfortable things like [postmortems](/blog/nov-24-shai-hulud-attack-post-mortem) for incidents -- Be a good citizen, [create space](/handbook/people/hogpatch) for others to thrive, help developers (or whichever community you market to) without asking for anything in return +- Being a good citizen, [create space](/handbook/people/hogpatch) for others to thrive, help developers (or whichever community you market to) without asking for anything in return -- Turn internal knowledge into [public artifacts](/handbook) and give space for every role to author content that matters to them +- Turning internal knowledge into [public artifacts](/handbook) and give space for every role to author content that matters to them ## Fast, not frantic It's tempting to treat “shipping too fast” as a humblebrag, but that’s lazy thinking. If users can’t adopt what we ship, it’s not velocity – it’s waste. -Practically, that means we need to be explicit about what matters, get better at sequencing the big launches, make a select number of things very loud, and let everything else be quietly excellent. - -And of course, do more things that would make a normal SaaS company nervous. Not everyone will like it, and that’s what makes velocity convert to value. +Practically, that means we need to be explicit about what matters, doing things that would make normal SaaS companies nervous, get better at sequencing the big launches, make a select number of things very loud, and let everything else be quietly excellent. Doing this right helps velocity convert to value. From c09b5b0b92003aa10a3f472cbca1afed25b7dd1b Mon Sep 17 00:00:00 2001 From: Cleo Date: Wed, 24 Dec 2025 09:23:17 -0500 Subject: [PATCH 6/6] minor updates --- .../when-product-velocity-breaks-speed-of-adoption.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contents/newsletter/when-product-velocity-breaks-speed-of-adoption.md b/contents/newsletter/when-product-velocity-breaks-speed-of-adoption.md index 2a41d95d77a8..94cf4a0e130c 100644 --- a/contents/newsletter/when-product-velocity-breaks-speed-of-adoption.md +++ b/contents/newsletter/when-product-velocity-breaks-speed-of-adoption.md @@ -58,7 +58,7 @@ The result is diffuse impact: lots of progress shipped, but less progress felt. ### 2. Time-to-value increases -As that backlog grows, lead times stretch – not in engineering, but in adoption. Your team keeps shipping, but each new capability takes longer to move from available to useful. +As that backlog grows, the gap between production and adoption stretches. Your team keeps shipping code, but each new capability takes longer to move from available to useful. Users struggle to keep up with what’s changed. Support and sales spend more time explaining context. Marketing lags releases instead of amplifying them. @@ -200,8 +200,8 @@ Adoption doesn’t really start with features. It starts with people getting bet ## Fast, not frantic -It's tempting to treat “shipping too fast” as a humblebrag, but that’s lazy thinking. If users can’t adopt what we ship, it’s not velocity – it’s waste. +It's tempting to treat “shipping too fast” as a humblebrag, but that’s lazy thinking. If users can’t adopt what you ship, it’s not velocity – it’s waste. -Practically, that means we need to be explicit about what matters, doing things that would make normal SaaS companies nervous, get better at sequencing the big launches, make a select number of things very loud, and let everything else be quietly excellent. Doing this right helps velocity convert to value. +Practically, that means you need to be explicit about what matters, do things that would make normal SaaS companies nervous, get better at sequencing the big launches, make a select number of things very loud, and let everything else be quietly excellent. Doing this right helps velocity convert to value.