02- How will you built it?

Foreword by Paul Adams, VP of Product

When I joined Intercom there was no one whose job title said Product Manager or Product Designer. It was myself, Darragh (leading the engineering team), 6-8 engineers and our founders. For the first six months, the team was a nebulous bubble with huge overlap in responsibilities. I was the product designer, I was the product manager and I was the researcher, but so was everyone else to some degree. 加入Intercom后，没有人的职位称为产品经理或产品设计师。就是我自己，Darragh（领导工程团队），6-8名工程师和我们的创始人。对于第一个六个月，球队是一个模糊的泡沫，责任重大。我是产品设计师，我是产品经理，我是研究员，但在某种程度上也是其他人。

Our process for building product was very uid. We recorded our entire product roadmap on a whiteboard. We kept things very simple, a list of projects we wanted to build, each of which was focused on one very clear problem to solve, and how long we thought it was going to take. Every project was less than four weeks long. We were obsessed with shipping, and wanted to get product into the hands of our customers as soon as we could so we could learn if we had solved the problem for them. 我们建造产品的过程很漂亮。我们将整个产品路线图记录在白板上。我们保持的东西很简单，我们想要构建的项目列表，其中每一个都集中在一个非常明确的问题来解决，我们认为需要多长时间。每个项目都不到四周。我们痴迷于出货，想尽快将产品交给客户手中，以便我们能够了解如果我们为他们解决问题。

We outgrew this process when we hit about 20 people in our product and engineering team, but we still retain the core principles from the early days about how we build product: 当我们在产品和工程团队中碰到20个人时，我们超越了这个过程，但是我们仍然保留早期关于如何构建产品的核心原则：

• We have a ruthless focus on the exact problem we’re trying to solve. We do this by obsessively talking to customers and researching their problems, perceptions, wants and needs. Our PMs are directly connected to customers. 我们非常关心我们正在解决的确切问题。我们通过痴迷于客户的谈话和研究他们的问题，观念，需求和需求来做到这一点。我们的PM直接连接到客户。

When I think back to the companies I worked at earlier in my career, people were not obsessed with the speci cs of the problems the same way we are at Intercom. Many product ideas people had were not real world problems. Often they were the ideas of a senior person, pulled from an anecdote from their life. In rare cases these ideas worked, but in most cases they failed. At Intercom we don’t work that way. We need to know we’re spending our precious resources on real problems that lots of our customers have. We don’t have the luxury of guessing. 当我回想起我在职业生涯中早期工作的公司时，人们并不像我们在Intercom上那样痴迷问题的具体方式。许多产品思想人们并不是真正的世界性问题。通常他们是一个老人的想法，从他们的生活中的一个轶事中抽出来。在极少数情况下，这些想法有效，但在大多数情况下，它们失败在Intercom上，我们不会这样工作。我们需要知道，我们将宝贵的资源用于许多客户所面临的真正问题。我们没有奢望的猜测。

• We obsess about the smallest thing we can build that we think will solve the problem. We think big, but we scope right back to the absolute minimum. We are ruthless with scope. is is a painful process, but this pain means you’re remaining focused. 我们痴迷于我们认为可以解决问题的最小的事情。我们认为很大，但我们的范围可以恢复到绝对最小。我们是无情的。是一个痛苦的过程，但这种痛苦意味着你仍然专注。

• We ship to learn. Shipping is only the beginning of building product. We ship as fast and frequently as we can. A lot of startups misinterpret this idea as throwing shit at the wall and seeing what sticks. We’re not fans of lots of multivariate testing. We don’t run experiments. Startups that fall back to experiments to make product decisions aren’t focusing enough on the problem they’re solving. 我们将功能上限去学习。上线只是建筑产品的开始。我们尽可能快地经常出货。很多初创公司误解了这个想法，把这个想法扔在墙上，看到什么东西。我们不是很多多变量测试的粉丝。我们不运行实验。初创企业落后于做出产品决策的实验不足以满足他们正在解决的问题。

Shipping to learn is more about being con dent that you’ve understood and solved the problem, but humble enough to know you’ll only truly learn when it’s in the hands of customers. All the best product people I’ve worked with are obsessively curious after they ship something. ey need to know if what they designed and built helped their customers. 上线学习更多的是关于你理解和解决问题，但谦虚知道只有在客户手中才能真正学习。所有与我一起工作的最好的产品人物，在他们出货之后都非常好奇。需要知道他们的设计和建造是否帮助他们的客户。

This combination has in many ways been our secret. We obsess over the problem to be solved, we stay laser focused on the problem, we ruthlessly scope solutions that we believe will solve this very focused problem and we ship knowing that we have a lot to learn.

这种组合在很多方面都是我们的秘密。我们痴迷于要解决的问题，我们将激光集中在这个问题上，我们无情地解决我们认为将解决这个非常关注的问题的解决方案，我们知道我们有很多要学习的东西。

Many people have written about how internet businesses should build software, but there are few examples where startups show how it happens. Quite often it’s a messy reality few want to share.

许多人已经写了关于互联网业务如何构建软件，但是很少有创业公司显示出如何发生的例子。通常这是一个混乱的现实，很少想分享。

Since we started Intercom we’ve learned a lot about scaling a product building team, and the nitty gritty involved in getting valuable product out the door as fast as possible.

自从我们开始使用Intercom以来，我们已经学到了很多关于扩大产品构建团队的规模，以及尽可能快地获得有价值的产品。

Things to keep in mind: 注意事项：

• This process re fcts how we built product in an earlier iteration of Intercom when our team was about four product managers, four product designers and 25 product engineers. The team has grown substantially since then, so it’s not the exact process we use today.这个过程反映了当我们的团队有四个产品经理，四个产品设计师和25个产品工程师时，我们在Intercom的早期迭代中构建产品的方式。从那时起，团队已经大大增长，所以这不是我们今天使用的确切过程。

• How we build product is heavily in uenced by our culture. Your culture is diffenent, so what you do should be different. Nonetheless there are some general principles that we’ve used to great e ect, which will help you think about how you build your product.我们如何构建产品受到我们的文化的深深影响。你的文化是不同的，所以你应该是不同的。尽管如此，我们已经习惯了一些一般原则，这些原则可以帮助您思考如何构建产品。

1. CREATE A SET OF GUIDELINES FOR MAKING DECISIONS 制定一套制定决策的指导原则

In order to grow and scale a product team, you need a set of values to help you make good decisions that align with what you collectively believe. at’s why we have a set of guidelines.

为了扩大和扩大产品团队，您需要一套价值观来帮助您做出与您所集体认为相符的良好决策。为什么我们有一套准则。

Many small steps are better than bigger launches 许多小步骤比更大的发射更好

Greatness is achieved in 1,000 small steps. Ship the smallest, simplest thing that will get you closest to your objective as fast as possible and help you learn what works.

伟大在1000个小步骤中实现。发送最小，最简单的事情，尽可能快地让您最接近您的目标，并帮助您了解有效的内容。

Think about daily and weekly goals 考虑每日和每周的目标

Every single day of work counts. Every individual should know what their goals are for each day, how they relate to the team’s weekly goal and how they relate to what is being released by the company. 每一天的工作计数。每个人都应该知道他们每天的目标是什么，他们如何与团队的每周目标相关，以及它们与公司发布的内容有关。

Optimize for face-to-face collaboration 优化面对面协作

Work moves faster face-to-face. Two people at a whiteboard generate more ideas and reach consensus quicker than any other setup we’ve seen. Remote work can be great for many things, but not for speed and e ciency of decision making.

工作面对面更快。白板上的两个人会产生更多的想法，并比我们所见过的任何其他设置更快地达成共识。遥远的工作对于许多事情来说可以是伟大的，而不是速度和效率的决策。

Fight against “work work”

Using software to build software is often slower than using whiteboards and sticky notes. Fight anything beyond a lightweight process and use the fewest number of software tools to get the job done.

使用软件构建软件通常比使用白板和粘滞便笺慢。在轻量级的过程之外进行任何操作，并使用最少数量的软件工具来完成工作。

The outcome matters much more than the plan 结果比计划更重要

Plans are made with the information available at the time but things only become fully clear as you execute. e best teams absorb and react to new information and are able to build great product in spite of changing circumstances.

计划是在当时提供的信息，但事情只有在执行完全清楚。最好的团队吸收和反应新的信息，并能够建立伟大的产品，尽管情况的变化。

> “The MVP philosophy gets misused. It doesn’t mean ship crap product fast. Don’t focus on the minimum and forget about the viable. Test a prototype with your target users before you ship and you’ll ensure the first thing you ship is an MVP or better.” MVP的理念被滥用了。这并不意味着船舶产品的快速。不要专注于最低限度，忘记可行。在出货之前，先与您的目标用户进行原型测试，您将确保首次出货的产品是MVP或更好的。 – SIAN (DIRECTING PRODUCT RESEARCH)

2. DEMAND CLEAR ACCOUNTABILITY 要求清晰的责任

When building product, it must be crystal clear who is accountable for what. If it’s a design problem, it’s on the designer (next time around ensure they understand the research and the problem you’re addressing). If the product is shipped with too many bugs, it’s on the PM (next time ensure they test realistic usage and edge cases).

在建造产品时，必须清楚谁对谁负责。如果这是一个设计问题，那就是设计师（下一次确保他们了解研究和您正在解决的问题）。如果产品出货太多错误，它在PM（下次确保他们测试现实的使用和边缘情况）。

Product building teams have natural grey areas and collaboration often means a better end result. So people within teams work this out themselves. But when it comes to analyzing what your team spends their precious time building, the lines of accountability need to be very clear.

产品制造团队拥有自然的灰色地带，协作往往意味着更好的结果。所以团队里的人们自己做这个工作。但是，当分析你的团队花费宝贵的时间建设时，需要非常清楚问责制。

3. CREATE A LIGHTWEIGHT, TRANSPARENT ROADMAP 创造一个轻盈，透明的 ROADMAP

A good roadmap draws from a few primary sources (more on this shortly). Ours is based on things we believe in, new ideas we have, features that help us scale, qualitative feedback from customers and quantitative data based on measuring performance of our product.

一个良好的路线图来自几个主要来源（此短期内更多）。我们根据我们所信任的事物，我们拥有的新想法，帮助我们扩大客户的定性反馈功能，以及基于测量产品性能的定量数据。

The challenge is balancing these ingredients and synthesizing them into a clear plan for what to build over the next few months.

挑战是平衡这些成分，并将其合并成一个明确的计划，在未来几个月内建立什么。

When Intercom had a relatively small product team a really effective way to do that was to think about our product roadmap over three timelines: the next six years, six months and six weeks.

当Intercom拥有相对较小的产品团队时，真正有效的方法是在三个时间线上考虑我们的产品路线图：未来六年六个月六周。

The next six years 未来六年

This should be your picture of the world six years from now, taking into account how it will have evolved because of the change you enacted.

这应该是你六年后的世界的照片，考虑到由于你制定的变化，它将如何演变。

The next six months 未来六个月

This is your plan for building things that will make a signi cant impact on your journey toward the change you want to enact in the world. When you look at what you will build over the next six months you should be thinking, “We’re making great progress.”

这是你的建设计划，这将对您想要在世界上制定的变革的旅程产生重大影响。当你看看你将在未来六个月内建立什么，你应该考虑“我们正在取得很大的进步”。

Your six month plan is subject to change. Looking ahead six months, about 50–75% of things on the list might be built, while the other 25% might be things you hadn’t thought of before. is is a rolling timeline that is updated every couple of months.

您的六个月计划可能会更改。展望未来六个月，名单上的大概50-75％的物品可能会建成，而另外25％可能是以前没有想过的事情。是一个滚动的时间表，每几个月更新一次。

The next six weeks 未来六周

The plan for the next six weeks is very concrete. is is your immediate plan and what your team intimately understands. You know exactly what’s being built. Design work is well underway. is is a rolling timeline that is updated every week or two.

未来六个星期的计划是非常具体的。是您的直接计划，您的团队密切了解。你知道正在建造什么设计工作进展顺利。是一个滚动的时间轴，每周或更新一次更新。

4. CREATE A CULTURE OF GOAL SETTING 创造目标文化

To ensure you stay focused and on track, set weekly goals for your team. Daily and weekly goals are a great way of helping you prioritize.
e volume of stuff that comes up daily for a product team, added to the gravitational pull of seemingly meaningful distractions, makes it essential to haveＴ weekly goals.

为确保您保持专注和准确的轨道，为您的团队设定每周目标。每日和每周的目标是帮助您优先考虑的好方法。每天为产品团队提出的大量的东西，加上似乎有意义的分心的引力拉动，使得每周的目标必须达到。

To hit weekly goals, break them out as daily and sub-daily goals. is reinforces the idea that every day counts and rea rms that the cadence of building matters.

打击每周目标，将其打破为每日和次日的目标。加强了每一天都重视和重塑建筑节奏的想法。

Our process for building product is by no means perfect. We iterate on it constantly, and by the time you read this, we will have tweaked it again. Nonetheless, these four principles are a great starting point to re ect on how you build product and ultimately help you improve.

我们建造产品的过程绝非完美。我们不断地重复一遍，当你读到这个时候，我们将再次调整。尽管如此，这四个原则是您如何构建产品并最终帮助您改进的重要起点。

THE ANATOMY OF A PRODUCT ROADMAP 产品路线解析

Deciding what goes on your roadmap requires tough decisions and agonizing trade-o s. Should you build exciting new products or iterate on your existing product? Should you build features needed by prospective customers or focus on building around existing customer problems?

决定你的路线图上的内容需要艰难的决定和痛苦的交易。您应该创建令人兴奋的新产品或迭代您现有的产品吗？您是否应该构建潜在客户所需的功能或专注于围绕现有的客户问题？

We’ve worked really hard to ensure we have a balanced set of priorities. To aid this, we bucket all the ideas we have into ve categories:

我们努力工作确保我们有一套平衡的优先事项。为了帮助我们，我们将所有的想法都加入到我们的类别中：

1. New ideas we have 我们有新的想法

These are based on opinion rather than research.They include trends we see and ideas we have.They're not data driven. ey come from looking around us and seeing what excites us most.

这些都是基于意见而不是研究的。包括我们看到的趋势和我们拥有的想法。没有数据驱动。来自我们周围的人，看到我们最激动的。

For example, we knew we wanted emoji and stickers throughout Intercom. We knew it was an important part of modern messaging. Customers weren’t asking for them. But we built them because we believed in them and people love them.

例如，我们知道我们在Intercom上要表情符号和贴纸。我们知道这是现代信息的重要组成部分。客户不是要求他们。但是我们建立起来，因为我们相信他们，而且人们都爱着他们。

2. Iterate recently shipped products 迭代最近出货的产品

A common mistake most software companies make is shipping something and moving on to the next shiny thing. But one of the truths of building software is that you never fully get it right the first time. is is universally true, no matter how hard you try and no matter how much research you do. So we commit to making sure shipping is just the beginning and then we iterate and make things better. is takes deliberate planning and perseverance.

大多数软件公司的一个常见错误是出货，并转移到下一个闪亮的事情。但是，构建软件的真相之一就是你第一次没有完全正确地得到它。是普遍的真实，无论你尝试多么努力，无论你做多少研究。所以我们承诺确保出货只是一个开始，然后我们迭代，使事情更好。是刻意规划和毅力。

This is made much easier by knowing your success criteria prior to shipping. So we set success criteria, often in the form of metrics, measure them post launch and then follow up with customers where necessary for qualitative feedback.

在出货前了解您的成功标准，这样做容易得多。因此，我们设定成功标准，通常以指标的形式，衡量他们的发布后，然后跟随客户在必要时进行定性反馈。

3. Our most common customer problems 我们最常见的客户问题

Every week, our product management team reads hundreds of customer conversations. As our customer support team talks with customers, they diligently tag every conversation with a category (e.g. usability issue, feature request, bug) and they also tag the team that owns that area of the product.

每周，我们的产品管理团队读取数百个客户对话。随着我们的客户支持团队与客户进行交谈，他们会以一个类别（例如可用性问题，功能请求，错误）等方式刻意地标记每个会话，并且还标记拥有该产品区域的团队。

Once a week, our PMs scan these conversations and reach out to customers directly to learn more. On top of this, every few months our research team takes all the conversations, analyzes them and creates a “hit list” of the most common customer problems. Using the PMs’ weekly pulse and the researchers’ systematic analyses, we can easily determine which problems to address first.

每周一次，我们的PM将扫描这些对话，并直接与客户联系以了解更多信息。除此之外，我们的研究团队每隔几个月就会对所有的对话进行分析，并为他们创造出最常见的客户问题的“名单”。利用PMs的每周脉冲和研究人员的系统分析，我们可以很容易地确定哪些问题首先解决。

4. Improving quality 提高质量

All software has bugs. Aiming for zero bugs is unrealistic, impractical and certainly overly optimistic for something that gives you fast diminishing returns. So all issues need to be graded on a scale so you know which ones are most important. We use two primary measures for grading:

所有软件都有错误。针对零错误是不切实际的，不切实际的，并且对于给您快速递减回报的东西肯定过于乐观。所以所有问题都需要按比例分级，所以你知道哪些是最重要的。我们采用两项主要措施进行分级：

• How severe is the problem? 问题有多严重？

• How many customers does it a ect? 有多少客户呢？

You must ercely commit to a high bar for speed, latency and e ciency in what you build. It’s not glamorous, but much of what we ship simply addresses bugs.

您必须在建立的过程中严格遵守速度，延迟和效率的高标准。这不是迷人的，但我们出货的很多东西只是解决了错误。

5. Features to help you scale 功能来帮助你扩大规模

Finally, if you’re a fast growing company, you’re likely seeing new problems with your product as your company grows. You’re onboarding customers that are bigger than you’ve seen before. You’re signing up customers from industries that you haven’t seen before.

最后，如果您是一家发展迅速的公司，随着公司的发展，您可能会看到您的产品出现新的问题。您正在登上比以前更大的客户。您从未见过的行业注册客户。

While you should never build a feature to close a deal – that signals the beginning of the end for your product – having conversations with your sales team is an excellent way to research new types of potential customers and to understand the types of features they’re looking for.

虽然您不应该建立一个功能来完成交易 - 这标志着您的产品的最终结局 - 与您的销售团队进行对话是研究新型潜在客户的理想方式，并了解他们的功能类型寻找。

FINDING THE RIGHT BALANCE 找到正确的平衡

With these fuve inputs, the art is balancing competing demands.

凭借这五个的投入，艺术是平衡竞争的需求。

How can we build exciting new products, iterate on our existing product, deliver commonly requested features from existing customers and add new features needed by prospective customers, all while keeping everything high quality, bug free, fast and performant?

如何构建令人兴奋的新产品，迭代现有产品，提供现有客户的常用功能，并添加潜在客户所需的新功能，同时保持一切高品质，无bug，快速和高效？

Enter the world of hard trade-o s. If you develop only items from the “new ideas” list you’ll have an app that’s half-useless, half- nished, buggy and slow. Likewise if you just address the “most common customer problems” you’ll solve the problems customers have today, but ignore the ones they might have tomorrow.

进入艰难的贸易世界。如果您仅从“新想法”列表中开发项目，那么您将有一个无用的应用程序，半成品，越野车和慢速程序。同样，如果您只是解决“最常见的客户问题”，您将解决客户今天遇到的问题，但忽略他们明天可能遇到的问题。

SHIPPING IS ONLY THE BEGINNING　出货只是开始

All too often, shipping product is seen as an end, a milestone reached, a good time to move onto the next project, an even better time to move onto another team. In fact, the opposite is true. Shipping is the beginning.

经常，出货产品被视为一个目标，达成一个里程碑，是进入下一个项目的好时机，更好的时间转移到另一个团队。其实呢恰恰相反。出货是开始

“Software only becomes valuable when you ship it to customers. Before then it’s just a costly accumulation of hard work and assumptions.” 当您将其出货给客户时，软件才有价值。在此之前，这只是一个昂贵的努力和假设的积累。 – DARRAGH (GROWING ENGINEERING FROM 1 TO 90 PEOPLE)

To encourage this mindset in our team, we follow three principles: 为了鼓励我们的团队精神，我们遵循三个原则：

1. Be comfortable knowing new features aren’t perfect　认识新功能并不完美

You can’t become good at something without the freedom to be bad at it first. If you believe every idea you present must look and sound great, don’t be surprised if you have very few of them. If you have very few don’t be surprised if you pick a bad one. When you pick a bad idea no amount of iteration will make it great.

你不能在没有自由的情况下变得擅长。如果你相信你所呈现的每一个想法都必须看起来很好听，不要惊讶，如果你几乎没有。如果你很少，不要惊讶，如果你选择一个坏的。当你选择一个坏主意，没有多少迭代会使它伟大。

We’ve often shipped things that weren’t “perfect”. There is always a list of things that could be better, and additional features that could be added. But we deliberately chose not to build them in order to accelerate production. We believe that shipping is a company’s heartbeat and that we quickly learn from our customers whether what we left out is more important than we thought.

我们经常出货的东西不是“完美的”。总会有一张可以更好的东西的列表，以及可以添加的其他功能。但是，为了加快生产，我们故意选择不建造它们。我们相信，出货是一个公司的心跳，我们很快从客户那里了解到，我们所遗漏的是否比我们想象的更重要。

2. Carefully de ne self-contained, well-scoped projects　认真设计独立的，范围广泛的项目

Self-contained projects mean that engineers don’t have to understand lots of diffenent parts of the codebase to get building. is is great for new people because they can jump right in. Well-scoped projects mean being able to ship something within a week.

自给自足的项目意味着工程师不必了解代码库的许多不同部分来构建。对新人来说是非常好的，因为他们可以跳进来。有限的项目意味着能够在一个星期内出货。

The temptation is always to bite o something bigger, something more ambitious, something more groundbreaking. But the opposite approach often works better: paint the bigger picture, then break it down into lots of smaller pieces that ship bit by bit, gradually replacing parts of the experience. is means being comfortable knowing that parts of the product are inconsistent, but it also means you can adapt and learn as you continuously push code to production.

诱惑是永远叮咬一些更大的东西，更有野心的东西，更突出的东西。但相反的做法往往效果更好：画出更大的画面，然后将其分解成许多较小的片段，逐渐替代部分体验。意味着知道产品的部分不一致，但也意味着您可以随时将代码推送到生产中进行适应和学习。

3. Shipping is about learning　出货是关于学习

You can never fully predict how users will behave or react. You need to give people a basic feature set, see how they behave, and iterate quickly from there. We ship to learn. We know that we will be wrong more often than we will be right. Because we care most about learning, we prioritize speed to execution.

你永远不能完全预测用户的行为或反应。你需要给人一个基本的功能集，看看它们的行为，并从那里快速迭代。我们船去学习。我们知道，我们会比我们错误的更为错误。因为我们最关心学习，我们优先考虑执行速度。

“The quicker you can get feedback on what you’re thinking, the better your idea will be. Usage is oxygen for ideas.” 你可以越快得到关于你想法的反馈，你的想法就越好。用法是氧气的想法。 – DES (CO-FOUNDER)

We all get excited dreaming about all the amazing things our product will do. As a designer you envision one cohesive beautiful thing. As a developer you map it out: every method, class and edge case. A small piece of value you could have shipped months ago, that your customers would have loved, can teach you so much more.

我们都很高兴为所有令人兴奋的事情我们的产品将做。作为设计师，您设想一个凝聚美丽的东西。作为开发人员，您将其映射出来：每种方法，类和边缘情况。几个月前您可能已经出货的一小部分价值，您的客户将会喜欢，可以教你更多。