Skip to content

Principles

Jump to bottom
ManshiangLi edited this page Sep 12, 2026 · 1 revision

产品原则

一句话：只管把自己的产品打磨好，用差异化回答"为什么是我们"，而不是用功能清单回答"我们也有"。

1. 打磨自己的产品，不追赶竞品

功能清单不是目标，用户的日常痛点才是。

不从"某个同类工具有了 X"倒推"我们也要有 X"。先问"这解决谁的什么问题"，答案站得住才动手。

落地

  • 每个新功能都要能回答：它解决的是真实痛点，还是只是出现在别人的功能列表里？
  • 宁可把一件事做透（比如把会话记录读到每一处细节），也不铺开一堆半成品。
  • 同类工具做得好、而且确实解决真实问题 → 学它的思路，但按我们自己的方式实现，不照搬它的形态。

2. 差异化来自取舍，不来自堆功能

差异化不是"我们也有"，而是"在我们这里不一样，而且更好"。

落地

  • 每个功能都要能回答"为什么在我们这里更好"；答不出来，就后做或者不做。
  • 敢于不做、敢于移除：估算的积分不够准，就从统计面板和文档里拿掉——哪怕它看起来像个亮点。
  • 保持一条清晰的技术主线：例如"直接读会话自己留下的记录"，而不是要求用户去装钩子、配环境。

3. 只做我们自己相信的判断

  • 用户真实反馈的优先级高于竞品的动作。
  • 短期热度不改变长期主线。
  • 宁可慢一点，也不做让自己事后想删的东西。

怎么用这条原则（动手前的四问）

决定做一个功能、或做一次改动之前，问自己：

  1. 它解决谁的什么问题？（不是"别人有没有"）
  2. 为什么在我们这里更好？
  3. 它让产品主线更清晰，还是更模糊？
  4. 如果今天不做，用户会失去什么？（答不上来，就先不做）

Product Principles

In one line: earn the right to exist by polishing our own product and being genuinely different — not by matching a competitor's feature list.

1. Polish our own product; don't chase competitors

A feature list is not a goal — the user's daily friction is.

We do not work backwards from "a comparable tool has X" to "so we need X". We ask whose problem does this solve first, and only build when the answer holds up.

  • Every feature must answer: does this solve a real pain, or is it just on someone else's feature list?
  • Better to make one thing thorough (reading a conversation's own records, down to the details) than to ship a pile of half-finished ones.
  • When a comparable tool solves a real problem well, learn the idea — then implement it our own way instead of copying its shape.

2. Differentiation comes from trade-offs, not from feature count

Differentiation is not "we have it too" — it is "here it is different, and better".

  • Each feature must answer "why is it better here?". If it cannot, it ships later or not at all.
  • Have the nerve to skip and to remove: our credit estimate was not accurate, so we took it out of the stats panel and the docs — even though it looked like a selling point.
  • Keep one clear technical spine: for example, read what the conversation already records, instead of asking users to install hooks and configure environments.

3. Trust our own judgement

  • Real user feedback outranks a competitor's moves.
  • Short-term hype does not move the long-term spine.
  • Prefer slow over shipping something we will want to delete later.

How to use this (four questions before building)

  1. Whose problem does this solve? (Not "does someone else have it?")
  2. Why is it better here?
  3. Does it make the product's spine clearer or blurrier?
  4. If we don't do it today, what do users lose? (No answer → don't start.)

Clone this wiki locally