原文摘自：https://svpg.com/product-fail/

Marty Cagan|Jun 5, 2015

NOTE: This article is a narrative version of a talk I’ve given for developers at the Craft Conference and for product managers and designers at Mind The Product.

注意：本文是Marty Cagan在Craft 会议上为开发人员，在Mind The Product会议为产品经理和设计师演讲的叙述版本。

In this article I’d like to discuss the root causes of so many product failures.

在本文中，我将讨论很多产品失败的根本原因。

I see the same basic way of working at the majority of companies, and I can’t help but notice that this is not close to how the best companies actually work.

我发现大多数公司都采用相同的工作方式，但是我不禁注意到，这与实际优秀的公司相差甚远。

Let me warn you that this discussion can be a little depressing, especially if it hits too close to home, so if that’s the case, I’ll ask you to hang in there.

我可能要提醒您，这篇文章的讨论可能会让你有点失望，尤其当您快要接近目的地，如果是这样的话，我将会让你悬在那儿。

Let’s start by walking through the process that the vast majority of companies still use to create products.  I’ll try not to editorialize yet; let me first just describe the process:

让我重新了解一下大部分公司仍然在使用的产品开发流程。我尽量不做编辑；首先让我来描述一下这个过程：

Everything starts with ideas.  In most companies, they’re coming from execs or key stakeholders or business owners, or big customers (or prospective customers), but in any case there are always a whole bunch of things that different parts of the business need us to do.

所有的产品都是从想法开始。在大部分公司，这些想法来自于执行者，主要股东，或者企业主，或大客户（或潜在客户），但是在任何情况下，总是有一堆来自企业不同的部门的需求需要我们实现。

Now most companies want to prioritize those ideas into a roadmap, and they do this for two main reasons.  First, they want us to work on the most valuable things first, and second, they want to be able to predict when things will be ready.

现在，大多数公司出于两个原因希望对这些想法按优先级列入产品规划路标。第一，他们希望一开始实现最有价值的需求，第二，他们想要知道何时产品可以完成。

In order to do this, there is almost always some form of quarterly or annual planning session where the leaders consider the ideas and negotiate a product roadmap. But in order to prioritize, they first need some form of a business case for each item.

为了做这些，经常会有某些季度或者年度形式的规划会议，领导考虑并商讨产品路标。但是为了确定优先级，对于每个项目他们需要某些形式的商业案例。

Some companies do formal business cases, and some are informal, but either way it boils down to the need to know two things about each idea: 1) how much money will it make? and 2) how much money or time will it cost?  This info is then used to come up with the roadmap, usually for the next quarter but sometimes as much as a year out.

有一些公司做一些正式的商业案例，有些则是非正式的。无论哪种想法，都是为了了解每个想法的两件事情：1）这个想法可以赚多少钱；2）这个想法的时间和金钱成本。这些想法将用于制定产品路标，通常用于下个季度，有时也长达一年。

At this point the product and technology organization has its marching orders, and they typically work the items from the highest priority on down.

到这一节点，产品和技术团队开始进行任务拆解，他们将从优先级最高到最低进行处理。

Once an idea makes it to the top of the list, the first thing that’s done is for a product manager to talk to the stakeholders and flesh the idea out and come up with a set of “requirements.”

一但某个想法优先级最高，产品经理要做的第一件事就是与主要相关人员进行交流，细化这个项目，然后形成一系列的需求文档。

These might be user stories or they might be more like some form of a functional spec but it’s purpose is to communicate with the designers and engineers what needs to be built.

这些可能是用户故事，或者更多的可能是某种形式的功能说明，但是这主要的目的是为了和设计师和工程师交流这个需求该如何实现。

Once the requirements are gathered up, the user experience design team (assuming the company has such a team), is asked to provide the interaction design, the visual design, and in cases of physical devices, the industrial design.

当需求都收集到一起后，用户体验设计团队（假设公司有这样的团队）开始进行交互设计，视觉设计，对于硬件产品来说需要提供工业设计。

Finally the requirements and design specs make it to engineers.  This is usually where Agile finally enters the picture.

最后，将需求和设计规范交给工程师。通常这个时候，将进入敏捷开发。

Anyway, the engineers will typically break up the work into a set of iterations – called “sprints” in the Scrum process.  So maybe it takes 1-3 sprints to build out the idea.

无论如何，工程师一般将工作分解为一系列的迭代-在Scrum中称为“sprints”。一般需要1-3个Sprint才能实现一个想法。

Hopefully the QA testing is part of those sprints, but if not, the QA team will follow this up with some testing to make sure the new idea works as advertised, and also doesn’t introduce other problems (known as regressions)

希望QA测试是这些sprint的一部分，如不是，QA团队将在此之后进行一些测试来保证新的想法可以向广告宣传那样进行工作，同样需要确保不引入其他问题（称作为回归）。

Once we get the green light from QA, the new idea is finally deployed to actual customers.

一旦我们获得QA质量的批准，新想法就将流向实际的客户中去。

In the vast majority of companies that I first meet, large and small, this is essentially how they work, and have worked, for many years.  Yet these same companies consistently complain about the lack of innovation and the very long time it takes to make it from idea to customer’s hands.

在最开始我遇到绝大多数无论大小的公司，这是他们基本的工作方式，并且持续很多年。然而，这些公司经常抱怨缺少创新，从想法到交付到顾客手中需要花费很长时间。

You might recognize that while I mentioned Agile, and while almost everyone today claims to be Agile, what I’ve just described is very much a Waterfall process.  In fairness to the engineers, they’re typically doing about as much Agile as they can given the broader Waterfall context.

你可能已经意识到，虽然我提到敏捷，而且今天很多人声称自己是敏捷，然而我刚才描述的内容很多都是瀑布式的过程。为了公平起见，对工程师来说，在这种瀑布是的背景下，他们朝着敏捷尽最大努力。

OK, so that may be what most teams do, but why is that necessarily the reason for so many problems?

没错，这也许就是大多数团队所做的事情，但是为什么这一定是造成这么多问题的基本原因呢？

What I want to do now is to connect the dots for you to show you why this very common way of working is actually responsible for most failed product efforts.

我现在就想向你们展示这其中的联系，为什么这种常见的工作方式实际上是导致大多数产品失败的原因。

Now I could literally talk all day long about the problems with this process, but what I’m going to do here is share what I think are the “top 10” most serious problems with this way of working.  To be clear, I’m arguing that all ten of these are very serious issues, any one of which could derail a team, but many companies actually have most or even all of these problems.

关于这个过程的问题我可以谈论一整天，但是，这里我只想分享我认为最严重的10个问题。明确的说，我所认为的10个严重的问题，其中任何一个问题都能使团队脱轨，但是很多公司实际都面临大多数甚至所有的这些问题。

1. Let’s start at the top – the source of ideas.  This model leads to sales-driven specials, and stakeholder-driven products.  Lots more to come on this key topic, but for now let me just say that this is not the source of our best product ideas.  Another consequence of this approach is the lack of empowerment of the teams – in this model they’re just there to implement.  Mercenaries.

1.让我们从最初开始---想法的来源。这个模式导致销售驱动的特色和主要股东者驱动的产品。在这个关键主题上会有很多想法，但是现在让我来说，这并不是产品想法最好的来源。这种方法导致的另外一个原因就是缺乏团队的能力--这种模式下，他们仅仅是一个实施者。就像佣兵。

2. Next let’s talk about the fatal flaw in these business cases.  Now to be clear, I’m actually in favor of doing business cases, at least for ideas that need a larger investment.  But the way most companies do them, at this stage, in order to come up with a prioritized roadmap, is truly ridiculous. Here’s why. Remember those two key inputs to every business case?  How much money you’ll make, and how much it will cost?  Well, the cold truth is that at this stage, we have no clue on either of these, and we can’t know.

2.接下来我们将讨论这些商业案例的致命缺陷。但是需要明确的是，实际上我是赞成做商业案例，至少对于那些需要大规模投资的一些想法。但是在这一步，大部分公司在为了能得到产品规划的优先级采取的方式十分荒谬。这就是为什么。是否还记得商业案例的两个关键输入？将赚多少钱及将花多少钱？残酷的事实是在这个阶段我们根本没有有效的办法获取这些。

We can’t know how much money we’ll make because that depends hugely on how good the solution turns out to be.  If the team does an excellent job, this could be wildly successful and literally change the course of the company.  On the other hand, the truth is that many product ideas end up making absolutely nothing.  And that’s not an exaggeration for effect.  Literally nothing.  In any case, one of the most critical lessons in product is knowing what we can’t know, and we just can’t know at this stage how much money we’ll make.

我们不能知道将会赚多少钱，主要是因为这个很大程度依赖于我们的解决方案可以达到什么程度。如果团队出色完成任务，就有可能取得巨大成功，并将逐渐改变公司的发展方向。另一方面，实际上很多产品的想法最终是一无所获。这并不是夸大的效果，确实是几乎一无所有。无论如何，在产品中最重要的一课就是了解我们所不知道的，而这个阶段我们至少不知道我们能赚多少钱。

Likewise, we have no idea what it will cost to build.  Without knowing the actual solution, this is extremely hard for engineering to predict.  Most experienced engineers will refuse to even give an estimate at this stage, but some are pressured into the old “t-shirt sizing” compromise – just let us know if this is “Small, Medium, Large and Extra Large.”

同样，我们也不知道我们的建造成本。不知道实际的解决方案，工程师很难进行预测。大多数经验丰富的工程师都不会在这个阶段给出一个估计值。但是一些工程师迫于压力会给出一个类似“T恤尺寸”的折中方案--仅仅让我们知道是“小，中，大，巨大”。

But company’s really want those prioritized roadmaps, and in order to get one they need some kind of system to rate the ideas, so people play the business case game.

但是公司确实十分想依据优先级获取产品的路标，为了获得这样这样的路标图，他们就需要一套相关的准则进行评分，因此可以玩一些商业案例的游戏。

3. An even bigger issue comes next.  Companies get very excited about their roadmaps.  I’ve seen countless roadmaps and the vast majority of them are essentially prioritized lists of features.  Marketing needs this feature for a campaign.  Sales needs this feature for a new customer. Someone wants a PayPal integration.  You get the idea.

接下来是更大的问题。公司对他们的产品路标感到十分兴奋。我已经见过无数的产品路标，其中绝大部分都是产品功能列表的优先级。市场营销活动需要此功能。销售需要这个功能给新客户。有些人希望集成PalPay。你获得这些想法。

But here’s the problem, and it’s maybe the biggest problem of all.  I call this the “two inconvenient truths about product.”

但是这是有问题的，这也许是最大的问题。我称这个为“产品两个不可忽视的真相”。

The first truth is that at least half of our ideas are just not going to work.  There are many reasons for an idea to not work out.  The most common is that the customers just aren’t as excited about this idea as we are.  So they choose not to use it.  Sometimes they want to use it, but they try it out and it’s so complicated that it’s simply more trouble than it’s worth, which ends up as the same result – the users don’t choose to use it. Sometimes the issue is that the customers would love it but it turns out to be much more involved to build than we thought, and we decide we simply can’t afford the time and money to actually deliver.

第一个真相就是我们的想法至少有一半是行不通的。对于一个想法有诸多原因表示他是行不通的。最常见的就是顾客并不会向我们一样对这个想法感到兴奋，因此他们便不会使用。有时顾客想使用它，尝试了之后发现太复杂，以至于麻烦多余其本身的价值，这将导致同样的结果他们不再使用。有时候，问题在于客户十分希望这个功能，但是实际开发的复杂度远超我们想象，因此我们根本负担不起实际交付的时间和金钱。

So I promise you that at least half the ideas on your roadmap are not going to deliver what you hope.  By the way, the really good teams assume that at least three quarters of the ideas won’t perform like we hope.

因此，我保证在你的产品路标中，至少一半的想法是无法达到你的预期。顺便说一句，一个优秀的团队认为至少四分之三的想法是无法达到预期的。

If that’s not bad enough, the second inconvenient truth is that even with the ideas that do prove to have potential, it typically takes several iterations to get the implementation of this idea to the point where it actually delivers the necessary business value.  We call that “time to money.”

如果这还不够糟糕，第二个不容忽视的真相就是即使这个想法已经证明十分有潜力，也需要花几次迭代才能将想法进行实现，从而真正实现必要的商业价值。我们称之为“时间到金钱”。

One of the most important things about product that I’ve learned is that there is simply no escaping these truths, no matter how smart you might be.  And I’ve had the good fortune to work with many truly exceptional product teams.  The real difference is how you deal with these truths.

关于产最重要的事情之一就是无论你多聪明，都无法逃避这个事实。我十分有幸与一些十分杰出的产品团队一起工作。真正的区别在于你如何处理这些真理。

4. Next let’s talk about the role of product in this model.  In fact, we wouldn’t even really call this role product at all.  It’s really a form of project management.  In this model it’s more about gathering requirements and documenting them for engineers.  At this point let me just say that this is 180 degrees away from modern product management.

接下来我们讨论一下本文介绍模式下的产品的角色。实际上我们根本不会称这个角色为产品。它仅仅是一种形式的项目管理。在此模式下，更多的是需求的的收集，转化为文档提供给工程师。在这一点上，与现代产品管理大相径庭。

5. It’s a similar story with the role of design.  It’s way too late in the game to get the real value of design, and mostly what’s being done is what we call the “lipstick on the pig” model.  The damage has already been done, and now we’re just trying to put a coat of paint on the mess.  The UX designers know this is not good, but they try to make it look as nice and consistent as they can.

5.对于设计也是类似的问题。获得真正有价值的设计太晚，并且很多时候他们所做只是将已经毁坏的设计尽量美化。UX设计师知道这样并不好，但是他们还是尽量让他看起来漂亮和一致。

6. Maybe the biggest missed opportunity in this model, is the fact that engineering gets brought in way too late. We say if you’re just using your engineers to code, you’re only getting about half their value.  The little secret in product is that engineers are typically the best single source of innovation, yet they are not even invited to the party in this process.

6.在这个模型中，错失最大的机会就是让整个项目工程介入太迟。如果您只是让你的工程师编码，那你仅得到他们一半的价值。产品中的小秘密在于工程师通常是最佳创新的来源，但是在这个过程中他们甚至都没有被邀请参加会议。

7. Not only is engineering brought in way too late, but the principles and key benefits of Agile enter the picture far too late.  Teams using Agile in this way are getting maybe 20% of the actual value and potential of Agile methods.  What you’re really seeing is Agile for delivery but the rest of the organization and context is anything but agile.

不仅仅是项目工程介入太晚，关于敏捷的一些准则和优势发挥作用也太晚。在这种模式下团队使用敏捷，仅发挥了敏捷价值的20%。你所看到的敏捷仅仅是关于产品开发交付的部分，剩下的组织和内容并不不是敏捷。

8. This entire process is very project-centric.  The company usually funds projects, staffs projects, and pushes these projects through the organization and finally launches projects.  Unfortunately, projects are output and product is all about outcome. This process predictably leads to orphaned projects.  Yes, something was finally released but it doesn’t meet its objectives so what really was the point?  In any case, it’s a serious problem and not close to how we need to build products.

8.这一整个模式就是以项目为核心。公司常常为项目提供资金，配置资源，并通过组织推动项目并最终启动项目。不幸的是项目是产出，而产品只是一个结果。可以预见的是，这个过程将导致孤立的项目。最终，某些东西发布了，但是不能达到预期，那这真正的意义又何在。在任何情况下，这一系列严重的问题都与我们需要的产品开发过程不一致。

9. The biggest flaw of the old Waterfall process has always been, and remains, that all the risk is at the end.  This means that customer validation happens way too late.

传统瀑布是开发最大的缺陷就是将所有风险都在最后暴露。这就意味着客户验证太晚。

You’ve hopefully heard of Lean Startup methods, which are very much at the heart of the alternative.  The key principle is to reduce waste, and one of the biggest forms of waste is to design, build, test and deploy a feature or product only to find out it is not what was needed.  The irony is that many teams believe they’re applying lean principles, yet they follow this basic process I’ve just described.  And then I point out to them that they are actually trying out ideas in one of the the most expensive, slowest ways we know.

希望你已经听说过精益创业法，他是另一种选择的核心。该方法的关键准则就是减少浪费，而最大的浪费形式之一就是设计，开发，部署一个功能或者产品，最终发现这并不是我们想要的。更讽刺的是好多团队确信他们在实行精益准则，然而他们却在遵循我刚才描述的这个基本过程。然后，我向他们指出他们实际上是在使用一种最慢，最昂贵的方法进行产品开发。

10.  Finally, while we’re busy doing this process and wasting our time and money, the biggest loss of all usually turns out to be the opportunity cost of what the organization could have and should have been doing instead.  We can’t get that time or money back.

最后，当我们正在忙于这个过程浪费我们的时间和金钱时，所有的损失中最大的是企业本可以找到替代方案，但是却让替代方案成为机会成本，即放弃了选择替代方案。我们无法将时间和金钱收回。

To me it’s no surprise that so many companies spend so much time and money and get so little in return.  I warned you this could be depressing.

对于我来说，很多公司花费了大量的时间和金钱，却只收到一点点回报。我已经提醒过你，这可能会让你失望。

The good news is that I promise you that the best teams operate nothing like what I’ve just described.

我向你保证，最好的团队不会向我刚才描述的那样进行合作。

I have written many articles about the various aspects of how the best teams work.  Product Discovery is how we come up with winning solutions to the problems we are attacking.  Discovery is an active and ongoing collaboration between product, user experience design, and engineering. Continuous Discovery and Continuous Delivery happen in parallel.  Features on roadmaps (output) are replaced by business problems to be solved (outcome).  The goal is product/market fit.

我已经写了很多各方面关于一个团队如何工作的文章。产品发现是我们找到解决问题的办法。发现这个过程是产品，用户体验设计和工程师之前持续协作的过程。持续发现和交付是一个并行的过程，路标上的特性（输出）被一些要解决的商业问题所替代（结果）。目标是产品和市场相契合。

If your company is still running this old and long-obsolete process, then hopefully you can shine a light on this and start the transition to the future.  And hopefully you’ll do this before you find yourself disrupted by a startup or competitor that is able to move much faster and more effectively than you can.

如果你的公司依旧在使用这个过时而古老的流程，希望这篇文章可以是一盏明灯，对未来进行一些改变。并且希望在你发现你自己将要被一家更迅速，更有效的创业公司或者竞争对手打败之前进行这些改变。