google机翻+人工阅读调整
在 Linear，我们相信软件可以给人一种神奇的感觉。软件的质量取决于其创建者的才能以及他们在制作软件时的感受。
为了重新回到正确的焦点，这些是 Linear 所建立的基础和不断发展的想法。
介绍
- 原则与实践
方向
- 路线图设定您的团队方向
- 设定有用的目标
- 优先考虑促成因素和阻碍因素
- 缩小项目范围
建筑
- 创造动力
- 写任务而不是用户故事
- 管理设计项目
- 与用户一起创建
- 启动并持续启动
- 公共创建
原则与实践
原则
为创作者打造
软件项目管理工具的构建应考虑到最终用户（即创建者）。保持个人生产力比生成完美报告更重要。
有偏见的软件
生产力软件应该有主见。这是该产品能够真正为您完成繁重工作的唯一方法。灵活的软件让每个人都可以发明自己的工作流程，这最终会随着团队规模的扩大而造成混乱。
创造动力——不要冲刺
我们应该找到工作的节奏和惯例。在循环中，我们决定优先事项并分配责任。我们的目标是与我们的团队保持健康的势头，而不是急于结束。
有意义的方向
我们的日常工作可能充满任务，但我们应该了解并提醒我们的团队我们工作的目的和长期目标。在我们计划每周的日程安排时，牢记路线图、项目和里程碑都很重要。
力求清晰
如果可能的话，不要发明术语，因为这些术语可能会造成混淆，并且在不同的团队中具有不同的含义。项目就应该叫项目。
对忙碌的工作说不
我们的工具不应该让我们成为它们的设计者和维护者。我们应该扔掉或自动化繁忙的工作，这样你就可以专注于更重要的工作。
先简单，后强大
不同规模的团队有不同的需求。工具应该易于上手，并随着时间的推移变得更加强大。
决定并继续前进
并不总是有最佳答案。重要的是做出决定，然后继续前进。
实践
设定月度、季度 or/and 年度路线图
雄心勃勃的目标是产生重大影响的唯一途径。公司在定义高层方向时应该关注它们。在路线图上为经常出现的意外和反应性工作预留一些空间，并允许您的路线图在需要时进行更改。
通过项目将日常工作与更大的目标联系起来
所有项目和工作都应与这些目标直接相关。在路线图会议期间审查项目及其交付日期，并在规划开发计划时从项目中提取内容。
以 N 周为周期工作
循环周期创造了健康的流程，并使团队专注于接下来需要发生的事情。2周的迭代周期在软件构建中最常见。它们足够短，不会忽视其他优先事项，但又足够长，可以构建重要的功能。周期应该感觉合理。不要让周期超载任务，让未完成的任务自动转移到下一个周期。
保持可管理的待办工作
您无需保存每个功能请求或反馈。重要的问题会重新出现，而低优先级的问题将永远不会得到修复。更有针对性的待办工作可以更轻松、更快速地规划周期，并确保工作真正完成。
混合功能和质量工作
所有软件都有缺陷，其数量超出了我们所能修复的范围。将错误和其他修复项纳入您的周期中。投资在工具上，因为如果做得好，它会成为力量倍增器。
指定项目和任务所有者
每个项目都应该有一个指定的负责人，负责自己的交付并编写项目简介。对于任务也是如此。其他人应该合作，但责任应该由一个人承担。
编写项目规格书
力求简洁。简短的规格更有可能被阅读。规范的目的是向团队的其他成员简要传达项目的“原因”、“内容”和“方式”。理想情况下，这些简短的文档迫使团队确定工作范围，以便明确优先级，并避免团队构建错误的东西。
了解您的用户
您的产品越受欢迎，您获得的反馈就越多。收件箱爆满是一个好兆头，除非它们是错误报告。不要太担心管理所有反馈。收集它并在开发新功能时将其用作需求库。尝试发现趋势。利用反馈（甚至投诉）作为了解用户的机会，并要求他们解释为什么需要特定功能，以便您了解他们的需求。解决问题——不仅仅是构建功能。
任务范围尽可能小
在处理大型任务时很难看到明显的进展，这可能会让人失去积极性。将工作分解为更小的部分，并尽可能为每个部分创建一个问题。理想情况下，您每周可以完成几项具体任务。将问题标记为已完成的感觉很棒。
用实际工作衡量进度
查看某些内容是否完整的最清晰方法是显示代码或设计文件中的差异。当任务范围较小时，您的更改也会很小并且也更容易审查。避免大量拉取请求或大型设计更改。
运行跨职能团队
设计师和工程师应该在项目上合作，创造自然的推拉关系。设计师利用他们的技能来探索想法并推动团队的思考。工程师可以挑战实施方面的思考，并将获胜的想法变为现实。最好的创作者往往同时具备这两方面的天赋。直接将其他团队纳入构建他们将使用的功能中，或者要求他们与客户互动以使用。
写一个变更日志
回顾并庆祝团队所取得的成就非常重要。一致的变更日志还可以向用户传达新功能、他们从您的产品中获得的价值以及您对改进产品的承诺。这也是将团队的个人工作与他们创造的集体价值联系起来的简单方法。详细了解我们如何编写我们的内容。
通过路线图设定团队方向
设定方向是构建产品和公司时要做的最重要的事情之一。明确的方向使每个人都朝着同一个目标努力。它可以帮助个人做出日常决策，团队确定项目的优先顺序，并且组织的所有成员都感到有动力朝着共同的目标前进。如果没有方向，就很难一起工作、知道要关注什么并取得有意义的进展。
路线图是塑造这一方向的关键工具。创建路线图的过程迫使您阐明愿景并决定如何实现它。最终的路线图为不久的将来设定了一条执行路径，就在你面前，理想情况下有点遥不可及。公司中的任何人都可以查看路线图，以快速了解要做什么以及为什么它很重要。浏览路线图可以清楚地显示进展情况，并可以帮助您识别需要关注的项目。
无论您是三人初创公司还是一千名员工公司的一员，路线图都可以帮助您和与您一起工作的每个人更快地做出更好的决策并专注于更有价值的工作。即使个人独立工作，清晰的路线图也能让团队保持一致。雄心勃勃的路线图促使人们挑战自我，做到最好。可见的路线图可以激励个人，让他们明白自己的工作为何重要，并创造一种透明的文化，建立信任，使协作变得更容易，甚至意外地激发协作。
以下是构建和管理路线图时应遵循的做法：
- 投资于规划
- 致力于重大项目
- 优先考虑影响
- 定期审查
- 保持灵活
投资于规划
规划路线图有不同的方法。您可能会选择一小群公司领导来构建它，除非您规模足够小，如果整个团队都参与，您可以召开有效的计划会议。在第一次会面之前留出有意义的时间来思考公司的目标以及您最想改进产品的哪些部分。运用您的产品直觉。查看客户反馈和功能请求。查看注册、激活、保留和收入等公司指标也很重要，这样您就知道如何在功能之间进行权衡，以及应用程序的特定区域是否应优先于其他区域。
虽然您将与一个小团队一起构建初始路线图，但人们喜欢被包容的感觉，并且如果他们以某种方式参与规划过程，就会感到更多的主人翁感。让每个人都有机会做出贡献。让团队提出自己的项目，您甚至可以设置一个时间窗口，让任何人提交反馈和想法。另外，与您的客户交谈。联系那些要求您考虑优先考虑的功能的客户，尤其是当您不清楚客户需求或项目范围时。无论您如何规划路线图，对流程进行时间限制并开发可重复的结构都会很有帮助，这样随着时间的推移，创建就会变得更容易。
致力于重大项目
理想情况下，您选择从事的项目会以某种方式取得具体进展。他们可能会创建新功能、发起活动或改进产品的现有领域。构建完整的功能，并避免将项目分解为小块，以免进展变得没有意义。有些项目无论如何都必须完成，例如构建工具和文档，因此将它们纳入路线图并使用它们来平衡工作的类型和强度。有时，团队也会将较小的问题捆绑到一个项目中，以使其变得更有趣。例如，您可以创建一个名为“错误周”的项目，其重点是解决待办事项中的优先错误。
优先考虑影响
使用更高级别的里程碑来帮助将工作重点放在更有意义的项目上。首先优先考虑基础项目和那些对客户体验影响最大的项目。取消那些不能为客户改进产品、不能帮助您实现公司目标或提高工作质量和速度的项目的优先级。
一旦您有了要处理的项目列表，就可以根据需要调整顺序，以兼顾队友的可用性和项目强度。在发布较大的功能后，再处理几个较小的项目，以避免倦怠。轮换项目负责人，这样优秀的员工就不会感到负担过重，并且每个人都有机会发展项目管理技能。无论作为团队还是个人，您都应该一次处理尽可能少的项目。在开始新项目之前交付现有项目。专注可以带来更高质量的工作，而运输则可以将执行力培养成一种习惯。订购项目，以便新的工作建立在以前的项目之上，这将使变化感觉有机并可能产生复合效应。交付三个重要项目也比以十个半完成的项目结束路线图更好。
定期审查
创建围绕审查路线图和评估项目进展的例行程序。您可以在每周的团队会议中进行路线图审查，并直接与项目负责人联系。创建一个积极鼓励项目负责人诚实分享并寻求帮助的环境，而不仅仅是报告状态或预期完成日期。对于公司领导者来说，减少定期检查也很有帮助，你可以从整体上查看路线图上取得的进展，重新确定即将进行的项目的优先顺序，并根据新信息或客户的反馈进行其他更改。除非你坚持执行，否则再好的计划也没有任何帮助，而且如果没有定期回顾，你就不会知道自己做得有多好。
保持灵活性
路线图应该让人感觉很充实，但又不是不可能的。平衡的路线图将最多三分之一的总工作时间花在错误、修复和积压项目上。尽最大努力估算项目，并预计它会比你想象的花费更长的时间——事情总是如此。最好要有雄心壮志，不要在路线图中添加太多项目，而不是太少。比实际情况多一些的项目将激励团队交付。项目太少可能会导致您陷入按计划速度工作的陷阱，从而减慢动力。
将路线图视为可以更新的动态文档也很有帮助。情况会发生变化，有时您需要移动项目、添加项目或延迟项目。只是不要过于频繁地更改或调整项目，否则您将面临偏离原始方向或失去动力的风险。
我们如何在 Linear 制定路线图
我们按季度制定路线图。每个季度都有一个明确的主题来集中工作并帮助我们选择要开展的项目，例如 2020 年第四季度核心用户体验。
我们通过审查业务需求、产品目标和客户反馈来选择重点，然后选择属于该目标的项目。我们也确保在路线图中保留一些喘息空间。理想情况下，路线图反映了 60-80% 的可能工作，并为处理积压的问题、修复错误和处理意外需求留下了空间。
我们在每个季度初都会花几周时间来制定路线图。没有严格的流程，但通常需要在大约两周的时间内召开几次会议才能最终确定。在会议间隙，我们通过 Slack 或 Zoom 通话讨论反馈和想法。一旦我们确定了本季度的项目，我们就会按时间顺序排列它们的优先级，并将项目所有者分配给第一组项目。如果没有明确的所有者，那么我们会在接近开始日期之前将项目保留为未分配状态，因为很难预测谁将有空或以前的项目何时关闭。
我们为每个项目分配一个领导。他们负责创建项目规范、领导项目团队会议并撰写变更日志帖子。各个项目团队成员在项目中创建自己的问题，尽管领导负责确保项目交付。
我们以回顾路线图开始每周的公司会议。我们按时间顺序逐一浏览项目列表，每个项目所有者都会向团队更新状态。如果出现阻碍或问题，我们可能会快速讨论或在会议后解决。
在整个季度中，由于工作表面更加紧急或机会主义，项目通常会花费更长的时间或在时间表上上下移动。这是意料之中的，也是正常的。我们也不喜欢为单个项目指定具体的发布日期。我们可以通过查看项目详细信息侧栏中的图表找到预计完成日期，并通过审查周期和变更日志获得总体动力感。有时，截止日期是有帮助的或必需的，例如在我们必须与外部各方合作的情况下，或者当工作时间限制有助于缩小范围时。例如，为了调整主页而推迟发布是很容易的，但稍好的像素并不能转化为客户或公司的附加值，因此团队最好专注于产品功能工作。不过，我们必须承认，我们在最新版本的抛光像素方面获得了很多乐趣，并且在 Big Sur 徽标上花费的时间比我们可能需要的时间还要多。时间花得值。
设定有用的目标
初创公司发展如此之快，以至于不知道第二天要做什么很正常，更不用说下周了。目标很重要，可以提醒您什么对公司的中长期成功至关重要。您可能觉得自己没有足够的用户或历史数据来决定您的目标应该是什么。这是正常的，在这种情况下，制定一个目标，以某种可衡量的方式推动你前进。
在早期，当您从零开始时，可能很难实现这些目标。思考的方法是从那个目标往回走，那里的路是什么。通往 10 个用户的道路从 1 个用户开始，首先是拥有一个可供其他人找到并开始使用的产品。实现这一目标的第一个有意义的目标可能是找到 10 个用户使用您的产品，然后是 100 个用户，然后是 1000 美元的 MRR。成功的初创公司通常从小事开始，找出解决办法，然后扩大规模。请记住，您的成长速度是没有限制的。
优先考虑促成因素和阻碍因素
学会很好地确定工作的优先顺序，并能够清楚地解释为什么你做了或没有优先考虑某件事，这一点非常重要。你没有无限的资源或时间，尤其是在建立公司的早期阶段，所以你必须好好利用它。
首先，将新功能视为附加“推动因素”或消除“阻碍因素”是有帮助的。推动者启用新功能，通常会使产品更有价值或更有趣。障碍是阻止用户/客户使用您的产品的间隙或摩擦。在构建功能之前，您应该尝试了解问题是否确实阻碍了某人使用该产品或阻碍了他们的用户体验。公司的成长来自于将精力和精力投入到正确的推动因素上并消除关键的阻碍因素。
其次，重要的是要考虑构建某些东西的及时性。总有比您拥有的资源更多的东西需要建造。在早期阶段，您最终需要构建很多功能。优先考虑那些能帮助你在本周或本月取得进展的事情。你想问自己现在做这件事是否重要，或者可以稍后做。如果您成功完成项目或任务，它是否有助于您实现更高层次的目标？还要弄清楚现在构建它是否会产生复合效应，以及它如何增加复杂性或成本（例如更多的定制支持）。
例如，我们仅在支持 Google Logins 的情况下推出了 Linear 测试版，因为这是构建身份验证的最快方式。然后我们转向其他功能，而不是扩展身份验证选项。我们知道，最终我们必须支持纯电子邮件和其他登录方法才能吸引更多用户和更大的客户，但没有必要让我们的测试版用户社区启动并运行。这让我们能够更快地开发其他功能。
项目范围缩小
在早期阶段，确定项目范围尤其重要。设计项目，使 1-3 人的团队能够在 1-3 周内完成。较小的修复或添加应该只需要几个小时或一天。
较短的项目迫使您优先考虑最重要的功能集。它们还可以让您养成持续更新版本的习惯，从而与客户建立快速的反馈循环。较小的团队可以帮助您更快地行动并减少管理和沟通开销。当您处于产品构建阶段的早期时，您没有足够的知识来预测项目是否会产生影响，因此最好避免大型项目。如果无法缩小项目范围，则将其分解为多个阶段。
例如，我们 在启动 Linear 的头几个月内发布了 Cycles和Projects 的第一个版本。 这两个功能的 MVP 版本花了我们大约两周的时间来设计和构建。我们在第一周将早期版本发送给我们自己和私人测试版用户，并立即开始收集用户反馈并在接下来的几周内修复它们。从那时起，我们对“周期”和“项目”进行了大量改进，现在它们都已成为该产品的主要功能。
产生动力
您和您的整个团队应该始终努力采取迅速行动并每天取得进步。你不是思考或谈论做某事，而是决定做或不做这件事。然后你今天做而不是明天做，这周做而不是下周做。
也有几周的时间，您不一定知道什么是最重要的事情，或者您不确定在产品中做出什么决定。不要在这些时刻变得瘫痪——而是找到一种行动的方式。相信你的直觉，做一些看似有意义的事情。与更多用户交谈。随着更多反馈的到来，您将获得更清晰的认识。如果您将运营设计为快速行动和学习，那么您可以纠正或恢复决策。
初创公司很少会因为取得了太大的进步或因为一个错误的决定而死亡，但当他们行动太慢或放弃时，他们就会死亡。
写任务而不是用户故事
在 Linear，我们不编写用户故事，并认为它们是产品开发中的反模式。我们编写简短的任务，用简单的语言描述任务。
写任务的目的是传达任务。它需要足够清晰，以便任务人可以执行它，并提供足够的背景信息，以便需要知道的团队成员了解正在做什么工作。因此，撰写任务时的目标应该是尽可能有效且快速地完成此任务。
为什么用户故事已经过时
用户故事是二十多年前发展起来的一种将客户想要的内容传达到软件团队可以交付的产品需求中的一种方式。快进到今天，我们构建软件的方式发生了很多变化。客户精通技术，足以阐明基本的产品要求。我们已经为购物车、待办事项列表和通知等常见功能制定了标准，因此无需解释它们应该如何工作。最好的产品和工程团队深入了解他们的用户，并熟悉他们的产品应该如何工作。
用户故事已经成为一种产品崇拜仪式，感觉良好，但浪费了大量资源和时间。它们是一种迂回的方式来描述任务，模糊了要完成的工作。用户故事的编写和阅读非常耗时，并且会让工程师陷入机械角色，他们根据问题需求进行编码，而不是在产品级别全面考虑用户体验。用户故事复杂且难以确定范围的原因之一是它们将本应是产品级细节的内容带入了任务级别。坦率地说，它们与我们在真实对话中交流软件的方式不符。
更好的写任务的方式
用简单的语言写出清晰、简单的问题来描述任务。写下自己的问题。在产品和功能级别而不是任务级别讨论用户体验。与其花时间创建用户故事，不如花时间与用户交谈并在构建功能之前思考功能。
描述具体任务或问题
问题应该描述具有清晰、明确结果的任务。这可以是一段代码、设计、文档或要采取的操作。如果它不是任务，则它不属于问题跟踪器。也许这是一个需要在文档或对话中充实的项目想法，或者是一个更大的功能，应该分解为更小的、有形的工作片段。
这条规则也有例外。例如，在开发某个功能之前，您将花时间探索设计和技术方法。您可以在这些实例中创建占位问题以便稍后分解（例如探索设计）或将其框架为可交付成果（例如编写项目规范）。
写得清楚、直接
编写简短的问题标题，直接说明任务是什么。标题应该易于浏览，因为大多数人会在其他问题的背景下在列表或板上阅读它。描述应该是可选的——不是必需的——并且可以包括相关的想法或背景以及更深入讨论的链接。仅编写执行任务和向团队传达相关信息所需共享的内容。
共享功能请求或错误报告时，直接引用用户反馈而不是进行总结。通常，客户描述的痛点比你总结的更真实，而且复制和粘贴的速度也更快。链接到客户对话，以便在需要更多信息时可以轻松获取。
写下自己的问题
团队中的每个人都应该写自己的问题。对于了解如何完成工作的人来说，编写描述该工作的问题会更快、更容易。它还可以帮助您的团队做得更好。当你写自己的问题时，它会迫使你深入思考问题。这为提出更好的方法创造了空间，并且更容易发现计划中的捷径或遗漏部分。这种做法还彻底改变了你处理工作的方式。您的重点不是构建以标记已完成的任务或检查需求列表，而是关注产品或项目的可交付成果。
在某些情况下，为其他人编写问题更有意义，例如在提交错误报告时。应该鼓励这样做，但要注意问题的写法略有不同。撰写问题时，将其框架为询问或描述问题。让受让人提出解决方案，然后将问题重写为任务。
将用户体验讨论保留在产品级别
当您指定项目并构建路线图时，讨论产品级别的客户体验。让整个团队（设计师、工程师和面向客户的人员）参与这些对话，以便每个人都深入了解用户需求、限制和产品要求。然后将工作委托给项目团队并期望他们交付。他们会直观地理解用户体验，因此您无需在任务级别进行澄清。
我们在 Linear 的工作方式
在决定实施计划之前，我们会深入讨论某个功能或项目。项目所有者编写规范并收集反馈，直到我们觉得我们有了正确的方法。然后我们才开始编写代码。在构建一个功能之前花费几周的时间来思考它的情况并不少见，但是一旦我们提出了正确的计划，它就会直接进入执行模式。项目所有者委派工作，从个人撰写自己的问题开始。
管理设计项目
在 Linear，我们在应用程序中管理设计任务，设计师和工程师在构建功能时紧密合作。设计过程似乎与典型的项目管理实践不兼容。在项目开始时很难预测设计会是什么样子，更不用说估计它何时准备就绪了。这些是我们处理项目设计工作的一些方法，可以帮助我们取得平衡并有效地合作。
验证问题
任何项目的首要设计任务都是理解和验证问题。有时问题很明确且简单，例如构建一个页面。有时问题不明确或定义不明确，需要在实施之前进行一些研究。当从产品之外工作的客户或团队收到功能请求时，这种情况尤其常见。用户会要求您构建特定功能 X 来解决他们的问题 Y。销售团队可能会敦促您构建功能 X 以满足客户请求。然而，他们的 X 通常是由他们对问题的看法来定义的，并受到他们对如何改变产品来解决问题的理解的限制。程序设计面临的挑战是调查表面问题，找出根本原因，然后解决。作为程序设计师，最重要的一步是验证问题确实存在并且是需要解决的正确问题。
在 Linear，我们通过自己使用产品来进行大量的设计和研究。设计团队定期审查用户通过帮助 + 反馈 模式或公共 Slack 社区提出的功能请求。如果这是我们计划实现的功能，我们将作为一个团队在 Slack 或线性问题上随意讨论这些问题。在构建任何东西之前，我们还会投资为每个功能编写详细的项目规范，这迫使我们深入思考问题。
探索阶段
一旦问题得到澄清，就该探索不同的设计方案了。我们在 Linear 中创建一个名为“探索设计”的问题，并将其作为占位符问题保留在项目中。
在这个阶段，重要的是自由地探索解决方案，而不是判断某件事是否可行、是否适合您的设计系统或者根本是一个好主意。糟糕的想法是创作过程中的自然步骤，可以帮助澄清你的想法，甚至向你展示为什么其他想法是更好的想法。根据问题的不同，探索可能需要几个小时或几天。它将包括部分研究以学习最佳实践并寻找灵感，部分包括尝试 Figma 中的选项。一个小功能可能需要使用不同的 UI 进行多次尝试。在您找到自己喜欢的功能之前（通常是在收到其他人的反馈之后），一项较大的功能最终可能会朝多个方向发展。
观看 Karri 的 Figma 设计演示：Linear 2020.12 发布页面
使用反馈来指导您
经过一些初步探索后，您应该从其他人（从您的队友开始）获得反馈和反应。观察他们的反应。当他们谈论有关设计的事情时，不要只注意他们所说的内容，还要问他们为什么这么说。您应该在探索过程中获得反馈，因此不必担心细节和润色。如果人们给你负面反馈，不要认为这表明方向一定不好，而要专注于了解原因。可能您正朝着正确的方向前进，但当前版本不太正确或不符合他们对问题的理解。找到你的设计或故事中的空白，然后填补它们。
当获得设计反馈时，交替审查整体设计和收集特定细节的意见。人们通常很难同时提供良好的反馈，而且如果反馈请求不集中，很容易偏离无益的切线。设定期望并让人们知道什么类型的反馈对您来说是有价值的。
选择方向
最终您需要选择设计方向。进一步充实方向可能需要几个小时或几天的时间，至少您需要在设计中完成一轮内部反馈，包括将构建该功能的工程师。
到此阶段，您应该更好地了解需要创建哪些资产，并能够列出具体的设计任务列表。即使细节可能发生变化，解决方案支架仍然存在。您应该列出要重点关注的设计作品清单，并逐一完成它们。标记已完成的事情感觉很好，并且可以帮助您专注于手头的下一个任务（即使您在进行整体设计时也是如此），这样您就可以避免过度旋转。
最终的解决方案和各个部分应由工程师告知。他们将能够指出技术限制并与您讨论替代方案。一般来说，这也是一个很好的实践，它可以提供工程背景和对他们正在解决的问题的更深入的理解，并使协作变得更容易。
设计和工程移交
我们收到很多关于如何在 Linear 管理设计和工程团队之间的交接的问题。我们在整个项目设计和实施过程中进行协作，并在编写项目规范时开始合作。我们在项目团队中工作，团队中总会有一名设计师负责任何面向用户的功能。我们的 Linear 工作空间中有一个单独的设计团队，但我们的项目由设计团队和开发团队共享。设计师提出了自己的问题。程序开发师提出了自己的问题。对于任何需要协作的事情，我们将使用子问题来划分设计和工程任务。
我们在 Linear 的工作方式：Karri 的设计流程
作为一名设计师，我个人之前曾在这种任务系统中挣扎过。设计某些东西通常让人感觉是整体性的，很难分解为具体的任务。一旦您更改了设计的一部分，您可能想要更改其他部分。一开始还有很多未知因素，因此很难提前计划。
总的来说，作为一家公司，我们在构建功能时使用项目来组织工作。在我们写完项目规范后，第一个设计任务通常是“探索设计”，我只是用一些时间（一天到一周）来探索不同的方向和选项，并找出设计的各个部分。然后与团队分享以获得反馈。我经常将 Figma 屏幕或屏幕截图粘贴到线性评论中，并@提及我想要反馈的人。除了发布 Figma 链接之外，Adrien 还喜欢分享 Loom 视频，并快速概述更改以及他想要反馈的内容。
一旦我对设计和方向有了更好的认识，我就会创建一个更具体的任务，例如“设计 X 视图”。拥有一项可以完成并最终完成的独立任务比拥有一项需要数周时间的庞大任务更有动力。设计完成后，我经常创建一个实施子问题，并将其分配给团队领导或工程师。然后，他们可以在实现该功能时参考设计任务中的设计决策和 Figma 链接。
与用户一起构建
早期启动过程的大部分内容都是为了了解客户的需求。您应该寻找用户或潜在用户的反馈、迭代并灵活地满足客户和市场的需求。
愿景与反馈
当然，作为创造者，您的任务是在实现您的愿景/直觉和构建用户想要的东西之间找到平衡。过于基于视觉的产品可能会错过用户和市场的需求，而过于反应性的产品会成为没有明确目的的弗兰肯斯坦创作(运用技术创造的“怪物”)。您需要根据用户反馈不断完善您的产品愿景。
解决问题而不是功能
了解用户将从他们当前看到的上下文或产品（而不是您正在尝试构建的产品）中预测他们的需求。用户询问您应该添加的功能是很常见的。每当他们这样做时，作为产品构建者，你向他们提出问题很重要。使用案例是什么？他们试图通过此功能或解决方案解决什么问题？如果问题得到解决，他们对产品的体验会有什么不同？
通过将对话从功能请求转向解释他们试图解决的问题，您可以将讨论引向痛点。在这次对话中，您将了解该问题是否值得解决或值得拥有。它还允许您探索问题的多种解决方案，并在您更广阔的视野中选择正确的解决方案。
为合适的用户构建
您还可以与那些有大量反馈但不在您的目标人群中或现在不在您的目标人群中的用户进行交谈。如果您认为自己正在为早期初创公司构建产品，那么倾听企业客户的意见可能会让您走上错误的道路，而且他们甚至不太可能成为客户。
整合反馈并让它完善您的产品，但不要让用户反馈单独决定您构建的内容。您可能会对用户反馈过于敏感。这就是为什么拥有目标和路线图是件好事，可以帮助您平衡用户的需求和公司的需求。
启动并继续启动
有一种错误的观念认为，发布需要一个单一的时刻。情况并非一定如此，很多时候许多初创公司都会多次启动。它通常比一次大规模发布效果更好。大规模发布的问题在于需要时间准备并且风险更大。发布失败以及所有工作都被浪费的风险也会增加。通过多次发布，您可以随着时间的推移构建自己的故事和品牌，并提高人们的兴趣。每次发布都会吸引更多关注者，这有助于您未来的发布。
其次，在最初的几个月或几年里，你的产品可能并不适合所有人。最好尽早推出并开始吸引用户和动力，而不是试图等待完美的时刻。
与变更日志类似，发布不断提醒市场您的公司存在并且您正在取得进展。
例如，当我们推出 Linear 时，我们在产品构建之前就宣布了公司名称。当我们筹集种子资金并改进产品时，我们就推出了。当我们向所有人开放产品并增加定价时，我们就推出了。当我们进行 A 轮融资并改进产品时，我们就推出了这款产品。每一次的发布都比之前的发布吸引了更多的人并产生了更多的客户。如果我们只推出一次，我们需要 1.5 年才能达到这个状态，而且我们不会像今天学到那么多，也不会拥有那么多客户。
公开构建
展示您正在构建的内容可能会让人感觉很危险，但通常它更有用。如果有的话，你的竞争对手可能会因为你的速度而泄气，要么被迫模仿你，要么避免模仿你。
公开构建的一种方法是发布变更日志。当您没有很多用户时，在变更日志中总结您的工作可能看起来很愚蠢，但我们认为这很有帮助。对于您和团队来说，它每周都会提醒您发生了什么，并鼓励您不断发布版本。对于用户来说，这说明产品越来越好。对于投资者来说，这表明了进步。有时，当你觉得事情进展得不那么快时，你可以回顾一下你已经取得了多少成就。