# You need to find product-market fit again (sorry)
**作者**: PostHog
**日期**: 2026-08-25T17:43:07.000Z
**来源**: [https://x.com/posthog/status/2092306793355673720](https://x.com/posthog/status/2092306793355673720)
---
If a team powered by AI rebuilt your flagship product today, what would they build and what would they skip? PostHog Desktop is our work-in-progress answer to that open question.
It came from a simple reality no company can escape: the [product-market fit game](https://posthog.com/founders/product-market-fit-game?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again) never really ends. Whether it’s frontier labs attacking your territory, or the hundreds of scrappy two-person teams determined to build “[Your App] for 2026”, now is the time disrupt yourself.
I’ve had the job of marketing our in-house disruption through every shape it’s taken. It started as[ PostHog Code](https://posthog.com/blog/self-driving-product?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again), an agentic coding tool and product editor. Then the most valuable thing that grew inside it, [self-driving](https://posthog.com/self-driving?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again), got de-bundled and shipped into PostHog Web.
The container it left behind became [PostHog Desktop](https://posthog.com/desktop?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again): a different product shape entirely, built around multiplayer spaces, generative UI artifacts, and the thesis that shared business context is key to a product that [builds itself.](https://posthog.com/blog/what-if-your-product-built-itself?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
This canvas captures the state of self-driving development. Because it's generative UI, we can visualize whatever data we want on it.
This isn’t advice from someone who’s run the PMF playbook and won – PostHog Desktop is now in open beta and doesn’t have product-market fit (yet). It’s mid-game observations that might help if you’re post product-market fit, and pre-whatever comes next.
# 1. Write down how you die
Disrupting yourself is about playing a good offense, but you still need to understand what you’re defending against. Write down the threats as three or four one-liners: who or what makes your product unnecessary? (we’ll counterattack later, so just speculate the future for now).
For example, Vercel built its agent tooling by running its own agents in production and shipping the gaps as products: [AI Gateway](https://vercel.com/ai-gateway), [Chat SDK](https://chat-sdk.dev/), and the [Agent Stack](https://vercel.com/blog/agent-stack). Your cause of “death” doesn’t have to be a villain. AI models getting so good that everyone can ship software is arguably utopia, but you don’t need me to tell you how disruptive that’s been.
# 2. Fund the attacker yourself
Give the “death-page” to a small team with big ideas – plus a blank slate to build something where your existing users won’t trip over it. 3-5 people, reporting to a founder rather than to the department they’re disrupting. You get to be the incumbent and the seed investor at once! (startups attacking you would kill for this setup).
# 3. Score it like a seed bet, not a business unit
In all likelihood, the new thing you build will have lower margins, worse retention, and more pivots than you expect. Don’t compare the metrics of your pre-PMF bet to those of your current PMF product (not yet, at least).
Write down, in advance, what the experiment will be judged on, the resources it’s allocated, and the runway it has before you even think about killing it. This is your defense against pulling the plug too early, and subsidized infinity.
# 4. Look for customers doing cool things with your product
With the PostHog MCP, you never have to open the web app at all – and that’s fine by us. Whether people reach PostHog through the [MCP](https://posthog.com/docs/model-context-protocol?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again), the [Slack app](https://posthog.com/slack?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again), Desktop, or the [CLI](https://posthog.com/docs/cli?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again), our job stays the same: give them tools they need to build successful products.
One of our largest customers took us up on that in a way we didn’t expect. They wired our MCP to Claude (plus a few other tools), and built their own working prototype of PostHog 2.0. This is the yellow flag every founder should watch for: when your users start assembling the next version of your product themselves, the demand is proven.
# 5. Build first, validate later
Your users are a great source of insight about how to improve your existing product. A good product team is obsessed with pleasing them, and every signal they send you compounds to growth.
The opposite is true when taking a bet on something new. Ask this amplification machine whether you should build a strange new thing for a strange new market (maybe even a whole new category) and it’ll probably say: “uh… no? Why risk what’s working?”
You can win these people round, but only after you’ve built something real, so don’t get hung up on validating your idea with them beforehand. We launched PostHog Code as a closed beta and validated it with real users, which led us to integrating its core ideas into PostHog Web.
# 6. Ask the disappointment question early and often
Once you have a prototype, dogfood it internally. The [classic Sean Ellis PMF survey](https://newsletter.posthog.com/i/137830990/3-launch-a-pmf-survey): “how disappointed would you be if this disappeared?” works on your own team (especially if they’re your [ICP](https://posthog.com/newsletter/ideal-customer-profile-framework?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)).
We did this before a recent product launch and scored 23%. The industry PMF benchmark is ~40%, so obviously this was painful. Your team will tell you the truth before your churn does, but only if you ask them.
# 7. Let usage overrule everyone, including you
Building a product runs on a mix of data (user interviews, session replays, product analytics) and, honestly, some plain vibes. Vibes are fine for deciding what to try – not what to keep on building. We set up a [Replay Vision](https://posthog.com/blog/replay-vision?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again) agent that watches session recordings of PostHog Desktop users and posts a daily summary in Slack. It contradicts our vibes constantly.
One thing to keep in mind: people who love your current product will land in the new version carrying assumptions. They’ll judge it against the workflow they already have, and read every change as something taken away. Net-new users have no map, and will show you what the new thing actually invites people to do. Both signals matter, but don’t try to average them.
# 8. Build the new thing on the asset your attackers can’t copy
Every incumbent has something a newcomer can’t copy – usually data, distribution, or both. Find a way to give your pre-PMF team that family advantage without the generational baggage.
In our case, Desktop shares almost no interface code with PostHog Web. What it shares is the data, including the same MCP we hand to customers. And because it’s a new app, long-time users keep the interface that works for them, while new users get to choose their own PostHog adventure.
GitHub did the same with Copilot: a brand-new product built on the two things only it and Microsoft had: the world’s largest pile of code, and distribution to millions of developers.
# 9. Ship before you’re ready
When you hop back on the PMF treadmill, it will feel bad in very specific ways. The new thing will lose in almost every comparison your company knows how to make. You’ll change the name too many times. You’ll kill features you were proud of two weeks after shipping them. And your own people will tell you they don’t “get” what you’re doing.
If none of that is happening, you’re probably not disrupting yourself.
But you’ve done this once before, so you’re better armed than any first-timer. You have revenue funding the experiment, real users telling you the truth, years of data to build on – and now agents doing half the building.
[PostHog Desktop](https://posthog.com/desktop?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again) is our version of this, and it’s out now for you to try (no waitlist). Come use it in ways we never imagined, and tell us what you’d fight to keep. If it all goes sideways, we’ll write the post-mortem post too (those are usually pretty popular).
Words by [Cleo Lant](https://www.linkedin.com/in/cleolant/), who thinks a sandwich cut into triangles tastes better. Originally published in [build mode](https://newsletter.posthog.com/), a free newsletter by [PostHog](https://posthog.com/).
## 相关链接
- [PostHog](https://x.com/posthog)
- [@posthog](https://x.com/posthog)
- [3.9K](https://x.com/posthog/status/2092306793355673720/analytics)
- [product-market fit game](https://posthog.com/founders/product-market-fit-game?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
- [PostHog Code](https://posthog.com/blog/self-driving-product?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
- [self-driving](https://posthog.com/self-driving?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
- [PostHog Desktop](https://posthog.com/desktop?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
- [builds itself.](https://posthog.com/blog/what-if-your-product-built-itself?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
- [AI Gateway](https://vercel.com/ai-gateway)
- [Chat SDK](https://chat-sdk.dev/)
- [Agent Stack](https://vercel.com/blog/agent-stack)
- [MCP](https://posthog.com/docs/model-context-protocol?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
- [Slack app](https://posthog.com/slack?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
- [CLI](https://posthog.com/docs/cli?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
- [classic Sean Ellis PMF survey](https://newsletter.posthog.com/i/137830990/3-launch-a-pmf-survey)
- [ICP](https://posthog.com/newsletter/ideal-customer-profile-framework?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
- [Replay Vision](https://posthog.com/blog/replay-vision?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
- [PostHog Desktop](https://posthog.com/desktop?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
- [Cleo Lant](https://www.linkedin.com/in/cleolant/)
- [build mode](https://newsletter.posthog.com/)
- [PostHog](https://posthog.com/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [1:43 AM · Aug 26, 2026](https://x.com/posthog/status/2092306793355673720)
- [3,991 Views](https://x.com/posthog/status/2092306793355673720/analytics)
- [View quotes](https://x.com/posthog/status/2092306793355673720/quotes)
---
*导出时间: 2026/8/26 08:55:29*
---
## 中文翻译
# 你需要重新找到产品市场契合点（很抱歉）
**作者**: PostHog
**日期**: 2026-08-25T17:43:07.000Z
**来源**: [https://x.com/posthog/status/2092306793355673720](https://x.com/posthog/status/2092306793355673720)
---
如果今天有一支由 AI 驱动的团队重建你的旗舰产品，他们会构建什么、又会舍弃什么？PostHog Desktop 就是我们对这个开放性问题的进行中的回答。
它源于一个任何公司都无法逃避的现实：[产品市场契合游戏](https://posthog.com/founders/product-market-fit-game?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)永远不会真正结束。无论是前沿实验室进攻你的领地，还是数百个决心打造“2026 版 [你的应用]”的两三人小团队，现在就是自我颠覆的时机。
我的工作就是为我们每一次形态各异的内部颠覆做营销。它最初是 [PostHog Code](https://posthog.com/blog/self-driving-product?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)，一个代理式（agentic）编码工具和产品编辑器。然后，其中孕育出的最有价值的东西——[self-driving](https://posthog.com/self-driving?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)——被拆分出来，集成到了 PostHog Web 中。
它留下的那个容器变成了 [PostHog Desktop](https://posthog.com/desktop?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)：一个完全不同的产品形态，围绕多人协作空间、生成式 UI 工件，以及“共享的业务上下文是[自我构建的产品](https://posthog.com/blog/what-if-your-product-built-itself?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)的关键”这一论点而构建。
这块画布展示了 self-driving 开发的状态。因为它是生成式 UI，我们可以在上面可视化任何我们想要的数据。
这不是来自某个已经跑赢了 PMF 打法并获胜的人的建议——PostHog Desktop 目前处于公开测试阶段，还没有产品市场契合点（目前还没有）。这是一些“中场”观察，或许能帮到那些已经找到了产品市场契合点、正迈向下一阶段的你。
# 1. 写下你会怎么“死”
自我颠覆是打一场漂亮的进攻，但你仍然需要理解你在防御什么。把威胁写成三四句简短的话：谁或什么会让你的产品变得多余？（我们稍后会反击，所以现在只管大胆推测未来）。
举个例子，Vercel 通过在生产环境中运行自己的智能体，并将暴露的缺口作为产品发布，构建了它的智能体工具：[AI Gateway](https://vercel.com/ai-gateway)、[Chat SDK](https://chat-sdk.dev/) 和 [Agent Stack](https://vercel.com/blog/agent-stack)。你的“死因”不一定是反派。AI 模型好到人人都能发布软件，这 arguably 是乌托邦，但它有多大的颠覆性，不用我多说。
# 2. 亲自资助“进攻者”
把这份“死亡清单”交给一个有大想法的小团队——外加一张白纸，让他们构建一个现有用户不会被绊倒的新东西。3 到 5 个人，向创始人汇报，而不是向他们正在颠覆的部门汇报。你可以同时扮演在位者和种子投资人！（攻击你的初创公司做梦都想要这种配置）。
# 3. 像种子赌注一样给它打分，而不是当作一个业务部门
很可能，你构建的新东西会有更低的利润率、更差的留存和比你预期更多的转型。不要把你处于 PMF 之前的赌注的指标与你当前 PMF 产品的指标相比（至少现在不要）。
提前写下这个实验将以什么标准来评判、分配了多少资源、以及多长的存续期，然后才考虑砍掉它。这是你防止过早放弃、也防止无限补贴的防线。
# 4. 寻找用你的产品做出酷事的客户
有了 PostHog MCP，你完全不需要打开 Web 应用——对此我们毫无意见。无论人们通过 [MCP](https://posthog.com/docs/model-context-protocol?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)、[Slack 应用](https://posthog.com/slack?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)、Desktop 还是 [CLI](https://posthog.com/docs/cli?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again) 使用 PostHog，我们的工作都一样：给他们构建成功产品所需的工具。
我们最大的客户之一以一种我们没料到的方式响应了这一点。他们把我们的 MCP 接入了 Claude（还有其他几个工具），并构建了他们自己可用的 PostHog 2.0 原型。这是每个创始人都应该警惕的黄旗信号：当你的用户开始自己组装你产品的下一个版本时，需求已被证明。
# 5. 先构建，后验证
你的用户是关于如何改进现有产品的绝佳洞察来源。一个好的产品团队痴迷于取悦他们，他们发给你的每一个信号都会复利成增长。
但对新事物下注时，情况恰恰相反。问这台放大器机器，你是否应该为一个陌生的新市场（甚至一个全新的品类）构建一个奇怪的新东西，它很可能会说：“呃……不要？为什么要冒这个险？”
你可以赢得这些人的支持，但前提是你已经构建出了真实的东西，所以不要执着于事先向他们验证你的想法。我们以封闭测试的形式发布了 PostHog Code，并用真实用户进行了验证，这引导我们将其核心理念整合进了 PostHog Web。
# 6. 尽早且经常提出“失望问题”
一旦有了原型，就在内部吃自己的狗粮。经典的 [Sean Ellis PMF 调查](https://newsletter.posthog.com/i/137830990/3-launch-a-pmf-survey)：“如果这个产品消失了，你会有多失望？”同样适用于你自己的团队（尤其是当他们属于你的 [ICP](https://posthog.com/newsletter/ideal-customer-profile-framework?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again) 时）。
我们在最近一次产品发布前做了这个调查，得分是 23%。行业 PMF 基准约为 40%，所以这显然很痛苦。你的团队会在你的流失率之前告诉你真相——但前提是你得问他们。
# 7. 让使用数据凌驾于所有人之上，包括你自己
构建产品靠的是数据（用户访谈、会话回放、产品分析）以及，坦白说，一些纯粹的直觉。直觉用来决定尝试什么没问题——但不能用来决定继续构建什么。我们搭建了一个 [Replay Vision](https://posthog.com/blog/replay-vision?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again) 智能体，它会观看 PostHog Desktop 用户的会话录像，并在 Slack 中发布每日摘要。它经常与我们的直觉相矛盾。
需要记住的一点：喜爱你现有产品的人进入新版本时会带着假设。他们会用已有的工作流来评判它，并把每一个变化解读为被拿走了什么。全新用户没有地图，他们会向你展示这个新事物真正在邀请人们做什么。两种信号都重要，但不要试图把它们平均化。
# 8. 把新东西建在攻击者无法复制的资产上
每个在位者都有新来者无法复制的东西——通常是数据、分发渠道，或两者兼有。想办法让你处于 PMF 之前的团队获得这种家族优势，同时甩掉代际包袱。
在我们的例子中，Desktop 几乎不与 PostHog Web 共享界面代码。它共享的是数据，包括我们提供给客户的同一个 MCP。而且由于这是一个全新的应用，老用户可以继续使用适合他们的界面，而新用户可以选择自己的 PostHog 冒险之旅。
GitHub 对 Copilot 做了同样的事情：一个全新的产品，建立在只有它和微软才有的两样东西之上：世界上最大的代码库，以及触达数百万开发者的分发渠道。
# 9. 在准备好之前就发布
当你重新跳上 PMF 跑步机，你会在非常具体的方面感到难受。这个新东西在你公司会做的几乎所有对比中都会落败。你会把名字改太多次。你会在发布功能两周后就砍掉那些你曾引以为豪的东西。你自己的员工会告诉你，他们“搞不懂”你在做什么。
如果这些都没有发生，那你大概并没有在颠覆自己。
但你以前已经做过一次了，所以你比任何新手都更有武装。你有收入为实验提供资金，有真实用户告诉你真相，有多年的数据可以依托——现在还有智能体帮你完成一半的构建工作。
[PostHog Desktop](https://posthog.com/desktop?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again) 就是我们的版本，现在已经开放试用（无需排队）。来用它做一些我们从未想象过的事情，并告诉我们你会拼命留住什么。如果一切都搞砸了，我们也会写事后复盘文章（那种通常都很受欢迎）。
文字由 [Cleo Lant](https://www.linkedin.com/in/cleolant/) 撰写，她认为切成三角形的三明治更好吃。最初发表于 [build mode](https://newsletter.posthog.com/)，[PostHog](https://posthog.com/) 的免费通讯。
## 相关链接
- [PostHog](https://x.com/posthog)
- [@posthog](https://x.com/posthog)
- [3.9K](https://x.com/posthog/status/2092306793355673720/analytics)
- [product-market fit game](https://posthog.com/founders/product-market-fit-game?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
- [PostHog Code](https://posthog.com/blog/self-driving-product?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
- [self-driving](https://posthog.com/self-driving?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
- [PostHog Desktop](https://posthog.com/desktop?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
- [builds itself.](https://posthog.com/blog/what-if-your-product-built-itself?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
- [AI Gateway](https://vercel.com/ai-gateway)
- [Chat SDK](https://chat-sdk.dev/)
- [Agent Stack](https://vercel.com/blog/agent-stack)
- [MCP](https://posthog.com/docs/model-context-protocol?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
- [Slack app](https://posthog.com/slack?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
- [CLI](https://posthog.com/docs/cli?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
- [classic Sean Ellis PMF survey](https://newsletter.posthog.com/i/137830990/3-launch-a-pmf-survey)
- [ICP](https://posthog.com/newsletter/ideal-customer-profile-framework?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
- [Replay Vision](https://posthog.com/blog/replay-vision?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
- [PostHog Desktop](https://posthog.com/desktop?utm_source=posthog-newsletter&utm_medium=post&utm_campaign=pmf-again)
- [Cleo Lant](https://www.linkedin.com/in/cleolant/)
- [build mode](https://newsletter.posthog.com/)
- [PostHog](https://posthog.com/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [1:43 AM · Aug 26, 2026](https://x.com/posthog/status/2092306793355673720)
- [3,991 Views](https://x.com/posthog/status/2092306793355673720/analytics)
- [View quotes](https://x.com/posthog/status/2092306793355673720/quotes)
---
*导出时间： 2026/8/26 08:55:29* 
