产品经理的42个原则-原则11:No Surprises:无需惊奇!

The only surprise a product manager should give anyone is, “Hey, we blew away our forecast!” The type of surprise you never want is, “WTF!?”

一个产品经理应该给任何人的唯一惊喜是:“嘿,我们的预测是让人心服口服的!”

你永远不想要的惊喜是,”搞什么!?

Consider your Market Requirements Document (MRD).

考虑一下你的市场需求文档

It can be filled with surprises, and I mean that in a bad way.

它可以充满惊喜,我的意思是,这是一种糟糕的方式。

Before you hand it to your engineering group, talk to them about it. Before writing your ideas down, share them in person. Tell the team what (and how) you’re thinking. Ask them what format works best. Do they prefer story mode or tables with rows of categories, priorities, sources, etc.? Do they understand the difference between “shall” and “should,” or my preference of “must” and “may”?

在你把它交给你的工程团队之前,先和他们谈谈。在写下你的想法之前,把它们分享给人们。告诉团队你在想什么(以及如何)。问他们哪种模式最适合。他们更喜欢故事模式还是带有目录行、优先级和资源等等的表格?他们是否理解“应该”和“可以”之间的区别,或者我的倾向是“必须”还是“可能”?

I mention that last one because I was once surprised when half way into the development cycle engineering decided not to implement a requirement I had listed as a “shall.” When I asked how could they drop an absolute requirement, they argued with me about—I’m not kidding—the definition of “shall.” WTF? I reminded them when Moses came down from the mountain with those Ten Commandments they were not nice-to-haves—they were absolutes written as “You shall.”

我提到了最后一点,因为我也曾经很惊奇,当我进入开发周期的时候,工程决定不执行我列出的“应该”的要求。当我问他们怎么能放弃一个绝对的需求时,他们和我争论——我不是在开玩笑——“应该”的定义。“搞什么?我提醒他们,当摩西带着十诫从山上下来的时候,不是可有可无的——他们绝对是被写为“你应该”的。

As you are writing the MRD, talk through the ideas informally with them, clarifying the customer’s need and why it is important. If you deliver a document loaded with surprises, they will not take ownership of it and may not support your efforts (or worse, may simply ignore it). Even before submitting your first draft of the MRD, all of your readers should (no, make that “shall”) have heard of its contents from you firsthand. This goes for all of your stakeholders (customers, salespeople, support, engineering, marketing, management, etc.)

就如你在写MRD的时候,与他们非正式地讨论想法,明确客户的需要,以及为什么它很重要。如果你交付了一份充满了惊喜的文件,他们将不会全身心的投入,也可能不支持你的努力(或者更糟的是,可能会忽略它)。甚至在提交MRD的初稿之前,你所有的读者都可以(不,用那个“应该”)从你的第一手资料中已经听说过它的内容。这适用于所有的涉众(客户、销售人员、支持、工程、营销、管理层等)。

Be transparent with everyone on how you gather and prioritize requirements.

对每个人都要透明,告诉他们你是如何收集和优先级需求的。

Explain your method of prioritization.

解释你的优先排序方法。

Many times people just want to know their ideas are being considered. If you reassure them and show them that you have a logical way of capturing and prioritizing, they will be much more accepting if their feature doesn’t make in.

很多时候,人们只是想知道他们的想法正在被考虑。如果你让他们放心,并告诉他们你有一种合乎逻辑的捕捉和排序优先级的方法,即使他们想的特征没有出现,他们也会更容易接受。

When attending or running meetings that include a potential bad surprise, especially with people who have strong opinions, always float those ideas by them beforehand. Phrase the idea in the form of a question and ask what they think (engineers love to think). They’ll likely be so engaged with explaining everything down to the minutiae that they’ll not realize you’re pandering to their intellect. It’s like Judo. They want to look smart (and make you feel dumb). The idea of no surprises also includes avoiding the risk of blindsiding the person in a public setting with something that might be a sensitive. If you surprise them in a meeting this way, there’s no predicting what could happen. You don’t want this to happen.

当参加或主持包括有潜在的坏消息的,尤其是那些有强烈观点的人参加的会议时,最好事先把这些想法都提出来。用问题的形式来短语化这个想法,并询问他们是怎么想的(工程师们喜欢思考)。他们可能会专注于正在解释的所有细节,以至于他们不会意识到你是在迎合他们的智力。这就像柔道。他们想看起来很聪明(让你觉得自己很傻)。没有惊喜的想法还包括避免在公共场合用可能是敏感的东西让人蒙上眼睛的风险。如果你在这样的会议上给他们一个惊喜,那就不会预测任何事情发生。你不希望这种事发生。

I shouldn’t have to mention this, but it happens way too many times not to highlight it. The biggest source of surprises (and abuse) is email. Email is a great tool, but the tone and content can easily be misinterpreted. It is always better to talk live with a person to avoid misunderstandings.

我不应该提这个,但它发生的次数太多了,而不是强调它。惊喜(和滥用)的最大来源是电子邮件。电子邮件是一个很好的工具,但是它的语气和内容很容易被误解。与人交谈总是更好的,以避免误解。

Lastly, and most importantly, don’t surprise anyone about what your role actually is.

最后,最重要的是,不要让任何人对你的真正角色是什么感到惊奇。

This is usually a big surprise and a bad one.

这通常是一个大的惊喜,也是一个糟糕的惊喜。

There’s a long list of responsibilities for a product manager, and few people understand them. They probably think they own some of that list. Be clear on what you do and don’t do with everyone, and evangelize this. If they don’t have a good understanding of how you view your job and priorities, they may have expectations that are very out of line and it can cause bad surprises.

对于一个产品经理来说,有一长串的责任,很少有人理解他们。他们可能认为自己拥有这些责任列表中的一些。和每个人清晰你做什么和不做什么,并传播出去。如果他们对你的工作和优先事项的观点没有很好的理解,他们很可能就会有非常不一致的期望,并且可能导致糟糕的惊喜。



分享到QQ 分享到微信 分享到微博

0 条评论

发表我的观点

取消

  • 昵称 *
  • 邮箱 *
  • 网址