笔记:This article is a narrative version of a talk I’ve given for developers at theCraft Conferenceand for product managers and designers atMind 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’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.

为了做到这一点,几乎总是有某种形式的季度或年度计划会议,领导者考虑了这些想法并谈判了产品路线图。但是为了确定优先级,他们首先需要为每个项目的某种形式的业务案例。

有些公司做必威体育黑钱的吗?正式的业务案例,有些是非正式的,但无论哪种方式都需要了解每个想法的两件事: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.”

这些可能是用户故事,或者它们可能更像是功能性规范的某种形式,但其目的是与设计师和工程师进行交流。

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.

最后,要求和设计规格将其授予工程师。这通常是敏捷最终进入图片的地方。

无论如何,工程师通常会将工作分解为一组迭代 - 在Scrum过程中称为“冲刺”。因此,也许需要1-3个冲刺才能建立这个想法。

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)

一旦我们从质量保证中获得绿灯,新想法最终将部署给实际客户。

在我最初遇到的绝大多数公司中,大小的公司本质上是必威体育黑钱的吗?他们工作和工作多年的方式。然而,这些同一家公司一直抱怨缺必威体育黑钱的吗?乏创新以及将其从想法到客户手中所花费的很长时间。

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.

好的,这可能是大多数团队所做的,但是为什么这必然是造成这么多问题的原因呢?

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.

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.

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.

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.”

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.

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.这是一个类似的故事,具有设计的作用。在游戏中获得真正的设计价值为时已晚,大多数情况下,我们称之为“猪上的口红”型号。损坏已经造成,现在我们只是试图在混乱中涂一层油漆。UX设计师知道这不好,但是他们试图使其看起来尽可能好,一致。

6.也许该模型中最大的错失机会是工程学得以为时已晚。我们说,如果您只是使用工程师来代码,那么您的价值只有大约一半。产品的小秘密是工程师通常是创新的最佳单一来源,但在此过程中甚至没有邀请他们参加聚会。

7.工程不仅使工程学得为时已晚,而且敏捷的原理和关键好处输入图片太晚了。以这种方式使用敏捷的团队可能获得了敏捷方法的实际价值和潜力的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.

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.

你希望听到精益创业的方法,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.最后,当我们忙着做这个过程nd 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.

如果您的公司仍在运行这个古老而长期的过程,那么希望您能为此发光并开始过渡到未来。希望您能在发现自己被初创公司或竞争对手的破坏之前做到这一点,该初创公司或竞争对手能够比您更快,更有效地移动。

Share This