注：Linear 是一款研发项目管理工具（https://linear.app）。

系列文章包含：

  • Part 1: Principles & Practices
  • Part 2: Roadmap sets your team direction
  • Part 3: Direction & Building

Set useful goals 设定有用的目标

Startups move so fast that it’s normal not to know what you’re working on the next day let alone the next week. Goals are important to remind you what matters for the medium or long term success of the company. You might not feel like you have enough users or historical data to make decisions on what your goals should be. That’s normal and in those situations, create a goal that propels you forward in some measurable way.

初创企业的发展如此之快，以至于经常都不知道第二天要做什么，更不用说下周了。目标对于提醒你什么是中长期的成功很重要。你可能觉得没有足够的用户或历史数据来决定目标应该是什么。这很正常，在这种情况下，创造一个目标，以某种可衡量的方式推动你前进。

In the early days, it can be hard to hit those goals when you start from zero. The way to think about it is to walk back from that goal, what is the path there. Path to 10 users starts with 1 user, which starts with having a product that someone can find and start using. Your first meaningful goal getting there could be to find 10 users to use your product, then 100, then $1000 in MRR. Successful startups often start with something small, figure it out, and then scale. And remember, there is no limit to how fast you can grow.

在早期，很难从零开始达到这些目标。思考的方式应该是倒推，看看到达目标的路径是什么。通往 10 个用户的道路是从 1 个用户开始的，这要先让产品被人发现，并且开始使用。你的第一个有意义的目标，可能是找到 10个使用你产品的用户，然后是 100个，然后是 1000 美元的 MRR。成功的初创企业往往从小事做起，想办法解决，然后再扩大规模。记住，你的成长速度是没有限制的。

Prioritize enablers and blockers 优先考虑使能因素和阻碍因素

It’s really important to learn to prioritize work well and to be able to explain clearly why you did or did not prioritize something. You don’t have unlimited resources or time, especially in the earlier stages of building a company, so you must use it well.

学会安排工作的优先级，并能清楚地解释为什么做某件事，或者不做某件事，这一点真的很重要。你没有无限的资源或时间，特别是在公司的早期阶段，所以你必须好好利用它。

First, it’s helpful to think of new features as additive enablers or removing blockers. Enablers enable new functionality that usually makes the product more valuable or interesting. Blockers are gaps or friction that prevents a user/customer to use your product. Before building a feature, you should try to understand if the problem is truly preventing someone from using the product or a nice to have in their user experience. Growth at a company comes from investing your energy and effort on the right enablers and removing critical blockers.

首先，所有功能都应该是增加使能因素或消除阻碍因素。使能因素能够实现新的能力，通常使产品更有价值或更有趣。阻碍因素是阻碍用户使用你的产品的问题。在实现一个功能之前，你应该了解这个问题是否真的阻碍了客户使用产品，还是说仅仅提升了一些用户体验。公司的增长来自于将你的精力和努力投入到正确的使能因素和消除关键的阻碍因素。

Secondly, it’s important to consider how timely something is to build. There will always be more to build than you have the resources to do so. In the early stages, there are a lot of features that you will need to build eventually. Prioritize things that help you move the needle this week or month. You want to ask yourself if this is important to be done now or can it be done later. If you are successful at completing the project or task, does it help you achieve your higher-level goals? Also figure out if there are compounding effects to building it now and how it adds complexity or costs (e.g. more customization support).

其次，重要的是要考虑实现的时间。总会有更多的功能需要实现，并超出了你的资源能力。在早期阶段，有很多功能是你未来某个时间需要实现的。优先考虑那些能帮助你在本周或本月取得进展的事情。你要问自己，这件事是现在做很重要，还是以后来做。如果你成功地完成了这个任务，它是否有助于你实现更高层次的目标？还要弄清楚现在实现它是否有复合效应，以及它是否增加了复杂性或成本（例如需要更多的定制维护）。

For example, we launched Linear in beta with Google Logins support only since that was the fastest way to build authentication. We then moved on to other features instead of expanding authentication options. We knew that eventually, we would have to support pure email and other login methods to bring in more users and larger customers, but it wasn't necessary to get our beta user community up and running. This lets us move faster on other features.

举个例子，我们在测试阶段推出的 Linear 时只支持 Google 账户登录，因为那是最快的授权登录方式。然后我们就去做其他功能了，而不是支持更多的登录方式。我们知道，终究某一天，我们将需要支持电子邮件和其他登录方式，以带来更多的用户和大客户，但这对于测试版上线是没有必要的。这样我们就能在其他功能上进展更快。

Scope projects down 缩小项目范围

At the early stages, it's especially important to scope projects. Design projects so that they can be completed in 1–3 weeks with a team of 1–3 people. Smaller fixes or additions should take only hours or a day.

在早期阶段，明确项目范围尤为重要。设计项目时，应使其能在 1-3 周内由 1-3 人的团队完成。较小的修复或补充应该只需要几个小时或一天。

Shorter projects force you to prioritize the most important feature set. They also get you into the habit of shipping continuously, which creates quick feedback loops with customers. Smaller teams help you move faster and reduce the management and communication overhead. When you’re early in the product building stage, you don’t know enough to predict whether a project will be impactful or not so it’s better to avoid massive projects. If there is no way to scope down the project, then break it down into stages.

较短的项目迫使你优先考虑最重要的功能集。它们还能让你养成持续交付的习惯，从而与客户形成快速反馈。较小的团队可以帮助你更快地前进，并减少管理和沟通的开销。当你在产品的早期阶段，你无法预测一个项目能产生多少影响，所以最好避免大规模项目。如果没有办法缩小项目范围，那就把它分解成几个阶段。

For example, we shipped the first versions of Cycles and Projects in the first couple of months of starting Linear. The MVP version of both of these features took us about two weeks to design and build. We shipped the early versions to ourselves and private beta users in the first week and started collecting user feedback immediately and fixing them in the following weeks. We’ve made a lot of improvements to Cycles and Projects since and both of them are now the major features of the product.

例如，我们在启动 Linear 的头几个月里就交付了 Cycles 和 Projects 的第一个版本。这两个功能的 MVP 版本花了我们大约两周的时间来设计和实现。我们在第一周就向自己和内测用户上线了早期版本，并立即开始收集用户反馈，在随后的几周内对其进行修复。此后我们对 Cycles 和 Projects 进行了大量的改进，现在这两个功能已经成为产品的主要功能。

Generate momentum 创造动力

You and your whole team should always try to take swift action and make progress each day. Instead of thinking or talking about doing something, you decide to do it or not to do it. Then you do it today instead of tomorrow and this week instead of next week.

你和你的整个团队应该总是试图迅速采取行动，每天都取得进展。与其思考或谈论做什么，不如直接决定做还是不做。今天做而不是明天做，这周做而不是下周做。

There will be also weeks when you won’t necessarily know what is the most important thing to do or you are not sure what decision to make in the product. Don’t become paralyzed in those moments–find a way to act instead. Trust your intuition and do something that seems to make sense. Talk to more users. You’ll gain more clarity as more feedback rolls in. If you’ve designed your operations to move fast and learn, then you can correct or revert decisions.

有时候，你不一定知道什么事情是最重要的，或者你不确定该做出什么决定。在这些时候，不要变得麻痹大意 —— 找到一种方法来代替行动。相信你的直觉，做一些看起来有意义的事情。与更多的用户交谈。随着更多的反馈，你会获得更多的确定性。如果你已经练成了快速行动和持续学习的工作方式，那么你就可以不断纠正决策。

Startups rarely die because they made too much progress or because of a single bad decision, but they do die when they move too slow or give up.

初创企业很少因为取得了太多的进展或因为一个错误的决定而死亡，但当他们行动太慢或放弃时，他们确实会死亡。

Build with users 与用户共建

Much of the early startup process is about learning what your customers want. You should seek out users or potential users for feedback, iterate, and be flexible to meet the demands of your customers and the market.

早期的创业过程大部分是关于了解你的客户想要什么。你应该寻求用户或潜在用户的反馈，进行迭代，并灵活地满足客户和市场的需求。

Vision vs Feedback 愿景与反馈

However, your task as a founder is to find a balance between building toward your vision/intuition and building what the users want. Too vision-based products might miss user and market needs while too reactive products become Frankenstein creations without a clear purpose. You need to keep refining your product vision based on your user feedback.

然而，作为创始人，你的任务是在愿景和用户期望之间找到平衡。太过基于愿景，产品可能会错过用户和市场的需求。而太过被动的产品则会成为没有明确目的的科学怪人。你需要根据用户的反馈，不断完善产品愿景。

Solve the problem not the feature 解决问题而不是实现功能

Understand that users will project their needs from the context or product they currently see, not the product that you’re trying to build. It’s common for users to ask for features you should add. Whenever they do, it’s important as a product builder that you ask them questions back. What is the use case? What is the problem they’re trying to solve with this feature or solution? How would their experience of the product be different if the problem was fixed?

要明白，用户会从他们目前实际看到的产品中找到出他们的需求，而不是你正在试图打造的产品。用户经常会要求你增加些功能。每当他们这样做的时候，作为一个产品建设者，你一定要反问他们。用例是什么？他们想用这个功能解决什么问题？如果这个问题得到解决，他们对产品的体验会有什么不同？

By pivoting the conversation away from a feature request and toward explaining the problem they are trying to solve, you move the discussion towards the pain point. In this conversation, you’ll learn whether the problem is valuable to solve or nice to have. It also allows you to explore multiple solutions to the problem, and to choose the right one within the context of your broader vision.

通过将对话从功能要求转移到他们试图解决的问题上，你将讨论转向了痛点。在这个对话中，你会了解到这个问题是有价值的，还是锦上添花的。它还会让你探索更多解决方案，最终选择最正确的那个。

Build for the right users 为重要的用户创建

You may also talk to users who have a lot of feedback but who aren’t in your target demographic or aren’t it now. If you think you are building for things for early-stage startups, listening to an enterprise customer will likely set you on the wrong path and it’s unlikely that they will even become a customer.

你可以和那些有很多反馈的用户交谈，但他们可能并不是你的目标人群，或者说现在不是。如果你认为你的产品是为创业团队使用的，听取大企业用户的意见很可能会使你走上错误的道路，甚至他们都不太可能成为你的客户。

Incorporate the feedback and let it refine your product, but don’t let user feedback alone dictate what you build. You can become too reactive to user feedback. This is why it’s good to have goals and roadmaps, that help you balance the needs of the users and the needs of the company.

吸收反馈来完善你的产品，但不要完全让用户的反馈来决定你的产品。你会变得反应过度。这就是为什么要有目标和路线图，它可以帮助你平衡用户需求和公司目标。

Launch and keep launching 发布，持续发布

There is a false belief there needs to be a singular moment for launch. This doesn’t have to be the case and a lot of times many startups launch multiple times. It usually works better than having one massive launch. The problem with massive launches is that it takes time to prepare and they are riskier. There is also an increased risk that the launch won’t work and all the work is wasted. By launching multiple times, you are building your story and brand over time and compounding the interested people have. Each launch builds more following, which then helps your future launches.

有一种错误的观点认为，需要有一个单独的发布时刻。情况并非如此，很多时候，许多初创企业都会多次发布。这比一次大规模的发布更好。大规模发布的问题是，需要长时间准备，而且风险更大。还有一个更大的风险是，发布可能会失败，那么所有的工作都白费了。通过多次发布，你建立了你的故事和品牌，随着时间的推移，人们对你的兴趣会越来越大。每次发布都会带来更多的追随者，又有助于未来的发布。

Secondly, in the first months or years, your product is likely not a fit for everyone. It’s better to launch early, start getting users and momentum, than trying to wait for that perfect moment.

其次，在最初的几个月或几年，你的产品可能不适合每个人。尽早的发布，开始获得用户和动力，比试图等待一个完美的时刻要更好。

Similar to changelogs, launching keeps reminding the market about the fact your company exists and you’re making process.

与更新日志类似，发布产品会不断提醒市场你的公司存在，你正在不断进展。

For example, when we launched Linear we announced the company before we had the product built. We launched when we raised seed funding and evolved the product. We launched when we opened the product for everyone and added pricing. We launched when we did a Series A and evolved the product. Each of the launches had reached more people and generated more customers than the previous ones. Had we only launched once, it would have taken us 1.5 years to get to the state and we wouldn’t have learned as much and would have as many customers as we have today.

举个例子，当我们推出 Linear 时，我们在产品建成之前就宣布了公司的成立。我们在筹集种子资金和开发产品的时候就发布一次。我们在对外公开产品时和推出定价时也发布了。我们在做 A 轮融资时也发布了，并迭代了产品。每一次发布的产品都比之前的产品触达到更多的人，产生更多的客户。如果我们只发布了一次，我们会花 1.5 年的时间来达到这个状态，而且我们不会学到那么多东西，也不会有我们今天这么多的客户。

Build in public 公开构建

It might feel dangerous to show what you’re building but often it’s more useful. If anything, your competition might be discouraged by your speed and either forced to copy you or avoid copying you.

展示你正在建造的东西可能感觉很危险，但它往往更有用。你的竞争对手可能会因为你的速度而感到气馁，要么被迫复制你，要么避免复制你。

One way to build in public is to publish a changelog. It might seem silly to summarize your work in a changelog when you don’t have many users, but we think it’s helpful. For you and the team, it reminds you every week what happened and encourages you to ship constantly. For users, it shows the product is getting better. For investors, it shows progress. At times, when you feel things not moving as fast, you can look back at how much you achieved already.

公开的方式可以是发布更新日志。当你没有很多用户时，更新日志可能看起来很傻，但我们认为这是很有帮助的。对于你和团队来说，它每周都会提醒你发生了什么，并鼓励你不断交付。对于用户来说，它表明产品正在变得更好。对于投资者来说，它显示了进展。有时，当你觉得事情进展得不那么快时，你可以回顾一下你已经取得了多少成就。

There are other reasons why the changelog can be useful. Read more: Startups Write Changelogs

还有其他一些原因可以说明为什么更新日志是有用的。阅读更多：创业公司写更新日志