首页 > 读 文 > 【推荐】新产品经理犯的十个错误
2023
02-21

【推荐】新产品经理犯的十个错误

我说“新”了吗?我想我要说的是"大部分"!

Let’s get this out of the way first: product management is basically an impossible job. No, seriously, it is. The sheer amount of things or people or processes that we need to wrangle in order to do our job effectively is frankly a bit insane, and none of us, no matter how practiced and seasoned, can claim a “perfect” launch or meeting or deck.

So when I discuss mistakes new PMs often make, please understand that while these may be most common in new PMs, experienced PMs make them all the time as well.

Ok, so let’s dive in. These are many of the mistakes I and many of my peers made when starting out, and if I’m being totally honest, I still struggle with a lot of these today! Let’s get after it.

让我们先说清楚:产品管理基本上是一项不可能完成的工作。不,说真的,它是。坦白地说,为了有效地完成工作,我们需要与大量的事情、人员或流程进行争论,这有点疯狂,我们中没有人,无论多么熟练和经验丰富,都不能声称拥有“完美”的发布、会议或平台。

因此,当我讨论新产品经理经常犯的错误时,请理解,虽然这些错误可能在新产品经理中最常见,但有经验的产品经理也经常犯这些错误。

好,让我们深入进去。这些都是我和我的许多同行在起步之初所犯的错误,如果我完全诚实的话,我今天仍然在这些错误中挣扎!我们继续。

错误1. Assuming you are the customer

假设你是顾客

This one is especially pervasive within consumer product companies, where the product managers also use the product or service in their personal life, and man is this one a hard one to shake. Yes, it is true, as a user of your company’s app or service, you do have valid insights into issues and opportunities.

I don’t want to rob you and your team of the joys of dogfooding your product and fixing or optimizing things you discover…but…you are a unique human being, and there are many other unique human beings that use your product, that when viewed more holistically fall into types of users (personas) that you can and should be more broadly building solutions for.

Again…this opportunity you have found within your product is likely an opportunity that other customers also resonate with, BUT the name of the game in product management is prioritization, and while you could solve for this opportunity, what other opportunities are you simultaneously leaving behind? You might have solved for a problem 5% of your customer base experiences and left a 60% problem on the table. This will be a theme in this article, but don’t assume anything. Ask questions, talk with customers, review quantitative data and find ways to test your hypothesis.

这一点在消费品公司中尤其普遍,产品经理在个人生活中也使用产品或服务,而人是很难动摇的。是的,作为贵公司应用程序或服务的用户,你确实对问题和机会有有效的见解。

我并不想剥夺你和你的团队对你的产品进行自我试用、修正或优化你发现的东西的乐趣,但是,你是一个独特的人,还有许多其他独特的人在使用你的产品,如果从更全面的角度来看,他们可以分为不同类型的用户(角色),你可以也应该更广泛地为他们构建解决方案。

同样,你在产品中发现的这个机会可能也是其他客户也会产生共鸣的机会,但是产品管理的游戏名称是优先级,当你可以解决这个机会时,你同时留下了其它什么机会?你可能已经解决了5%的客户体验的问题,而留下了60%的问题。这将是本文的主题,但不要做任何假设。提出问题,与客户交谈,查看定量数据,并找到方法来验证你的假设。

错误2. Assuming your stakeholders or designers or engineers are on the same page as you

假设你的利益相关者、设计师或工程师和你在同一页上

At the end of the day one of the most important roles you have as a product manager is to build “shared understanding” amongst your spheres of influence (business stakeholders, designers, engineers, QA, etc). Here’s what this doesn’t mean: you need to write more PRDs or Confluence Pages or Notion Docs.

It does mean that you need to have more conversations. It’s honestly this simple. Bring in design and dev early on. Share ideas, ask questions, listen a lot. When you are done having these conversations write down your assumptions and risks somewhere and reference them as you continue down the path of defining and building your solution.

在一天结束的时候,作为产品经理,最重要的角色之一是在你的影响范围(业务利益相关者、设计师、工程师、QA等)之间建立“共识”。这并不意味着你需要写更多的PRD或Confluence Pages或Concept Docs。

这只意味着你需要进行更多的对话。其实就是这么简单。尽早引入设计和开发。分享想法,提出问题,多倾听。当您完成这些对话时,请在某处写下您的假设和风险,并在您继续定义和构建解决方案时参考它们。

错误3. Trying to write all the requirements on your own

试着自己编写所有的需求

Honestly this is just an extension of #2. The old way we worked as product managers, even back before we had the title of “product manager”, was to talk with the business or customer, go into a room and bang out a crazy detailed “Product Requirements Document”, hand it to a designer to design, and then have that handed to developers to develop.

Please. Don’t. Do. This.

Yes, as a PM it is your primary job to determine the right problems to solve and to understand business feasibility and viability around the proposed solution, but you need to have conversations with your designers and engineers as you put together the requirements.

These are people that are also touching the product or customers and they have really good ideas or thoughts or opinions. Use these early conversations to help shape your vision of the future and keep the open lines of communication open as you progress towards having a solution in customer’s hands.

老实说,这只是第二条的延伸。我们作为产品经理的旧工作方式,甚至在我们有“产品经理”头衔之前,是与业务或客户交谈,走进房间,拿出一份非常详细的“产品需求文档”,交给设计师进行设计,然后交给开发人员进行开发。

请。不要。这样。做。

是的,作为一个产品经理,你的主要工作是确定要解决的正确问题,并理解围绕所提议的解决方案的业务可能性和可行性,但是当你把需求放在一起时,你需要与你的设计师和工程师进行对话。

这些人也在接触产品或客户,他们有很好的想法或见解或意见。利用这些早期的对话来帮助塑造你对未来的愿景,并在你向客户提供解决方案的过程中保持开放的沟通渠道。

错误4. Trying to jump into the work too quickly

试着过早地投入工作

It’s day one in the new gig and, as expected, you are SO excited. You meet the team, get access to your squad’s JIRA board, get an overview from your leader about the area of the product or customer journey they want you to focus on aaaaaaaand…what now?

Well, you don’t want to be lazy, or even worse be perceived as lazy, and so you jump right in. You’ve used products like this one before (see #1), and you see a previously prioritized list of stories and features, and so you pick one up that feels right, get with design and work furiously to produce “real value”. You were hired to ship features, no sit around and twiddle your thumbs, after all…right?

As a new (or experienced) PM getting started at a new company, this is one of the worst things you can do. There is nothing more destructive to a technology company than an un-informed product manager. The short version of what you should be doing is becoming an expert on your industry, business, product, team, and technology.

There is nothing more destructive to a technology company than an un-informed product manager.

This is such an important topic I wanted to dedicate an entire article to covering it. If you are starting out at a new company, I would highly recommend you give it a read — it’s a quick one.

Product Management Survival Guide: Your First 3 MonthsProduct Management Survival Guide is a series of highly practical articles aimed at helping new PMs quickly get a grasp…productcoalition.com

今天是新工作的第一天,不出所料,你很兴奋。你会见了团队,进入了团队的JIRA看板,从你的领导那里得到了关于他们希望你关注的产品领域或客户旅程的概述……然后呢?

好吧,你不想偷懒,或者更不想让别人觉得你懒,所以你就直接跳进去了。你以前使用过这样的产品(见错误1),你看到了一个之前优先考虑的故事和功能列表,所以你选择了一个感觉正确的产品,进行设计,并疯狂地工作以产生“真正的价值”。毕竟,你是被雇来发布特征的,而不是坐着无所事事,对吧?

作为一个新公司的新PM(或有经验的PM),这是你能做的最糟糕的事情之一。对于一家科技公司来说,没有什么比一个无知的产品经理更具破坏性了。简而言之,你应该做的就是成为你所在行业、业务、产品、团队和技术的专家。

对于一家科技公司来说,没有什么比一个无知的产品经理更具破坏性了。

错误5. Looking to validate your ideas

去验证你的想法

I couldn’t help myself…this picture was too perfect not to use twice.

Do you hate being wrong? I HATE it. It’s my least favorite thing, and I would bet you’re a little bit like me in this way. Here’s the rub: many of us dislike this feeling so much that we let it sneak its way into how we work in some pretty deceptive and destructive ways.

One of the most destructive ways this can show up is when we are asking teams, customers and the data itself to not test our idea, but rather to validate it as a good one. The difference here can be slight, but impactful. It can be as simple as your phrasing when interviewing customers. Look at these two questions and see if you can spot the difference:

“Would you be interested in a “Favorites” button that made it easy to filter through our entire catalog to find the ones that you really loved?”

OR

2. “Today how do you finding items that you previously enjoyed? What pain points do you have with this process?”

In the first question, I have both the problem (trying to find items that I previously purchased and liked) and the solution (a favorites button) in mind, and I really want to hear the customer validate my idea so I can say to myself “a customer said they would like it, so therefore I can clear my conscious and go build it”. The second question is simply intended to dig further into the problem space to understand more about how this problem manifests in customers lives.

Seek to understand the customers problems on a deeper level, don’t get too attached to any one solution, and work to test your ideas as much as possible, looking for holes and ways they can fail. This will ultimately lead to a much better solution.

我无法自已,这张照片太完美了,不能不用两次。

你讨厌犯错吗?我讨厌它。这是我最不喜欢的事情,我敢打赌你在这方面有点像我。问题就在这里:我们中的许多人非常不喜欢这种感觉,以至于我们让它以一些相当具有欺骗性和破坏性的方式潜入我们的工作方式。

最具破坏性的一种表现方式是,当我们要求团队、客户和数据本身不测试我们的想法,而是验证它是一个好想法时。这里的差异可能很小,但影响很大。这可以像你访谈客户时的措辞一样简单。看看这两个问题,看看你是否能发现它们的区别:

1.“你会不会对一个‘收藏夹’按钮感兴趣,这样你就可以很容易地从我们的整个目录中筛选出你真正喜欢的东西?”

2. “现在你怎么找到你以前喜欢的东西?”在这个过程中你有什么痛点?”

在第一个问题中,我心里既有问题(试图找到我之前购买过并喜欢的商品),也有解决方案(一个收藏按钮),我真的很想听到客户验证我的想法,这样我就可以对自己说:“有客户说他们喜欢它,所以我可以清理自己的意识,开始制作它”。第二个问题只是为了进一步挖掘问题空间,以更多地了解这个问题如何在客户生活中表现出来。

在更深层次上理解客户的问题,不要太依赖于任何一种解决方案,尽可能多地测试你的想法,寻找漏洞和可能失败的方法。这将最终导致一个更好的解决方案。

错误6. Fear of discussing assumptions and risks

害怕讨论假设和风险

This picture perfectly describes my gut-reaction to considering issues or risks with one of my features/products. I want to bury my head in the sand, cover my ears, say “LALALALALA!” and pretend I didn’t just realize there’s a giant risk in my release, because I think deep down I believe that if I just push forward and DON’T think about these things, they won’t happen. Maybe you’re the same, or maybe I’m just a weirdo.

Regardless, reality obviously doesn’t work this way, and I cannot over-emphasize the importance of spending at least a little time thinking through how things can go wrong, up-front. Some product teams take this so far that they conduct what are called “pre-mortems”, a play on the term post-mortem”, a common practice of reviewing what went wrong after something launches.

A pre-mortem is nothing more than pretending that this feature or product has already launched and stuff did in fact go wrong. Maybe even very wrong. Then, as a cross functional team, you sit down and discuss what did go wrong, and what could have been done to avoid it. No matter what approach you take, put in the time up front to document these so you can move forward with eyes wide open.

这张照片完美地描述了我在考虑我的特征/产品的问题或风险时的本能反应。我想把头埋进沙子里,捂住耳朵,说“LALALALALA!”,假装我没有意识到我的版本存在巨大的风险,因为我认为我内心深处相信,如果我只是向前推进,不去想这些事情,它们就不会发生。也许你也一样,也许我只是个怪人。

无论如何,现实显然不是这样的,我不能过分强调至少花一点时间思考事情如何会出错的重要性。有些产品团队甚至会进行所谓的“事故预分析(pre-mortems)”,这是对“post-mortem”一词的模仿,是在产品发布后检查问题所在的一种常见做法。

事故预分析是假设这个特征或产品已经发布,而且确实出了问题。甚至可能是非常错误的。然后,作为一个跨职能团队,你们坐下来讨论哪里出了问题,以及本可以做些什么来避免它。不管你采取什么方法,提前花时间把这些记录下来,这样你就可以睁大眼睛继续前进。

错误7. Asking why

问为什么

Pretty soon I am going to be writing an entire article about this one word — this is how impactful I think the question “why?” is for product managers. It’s one of our super powers as a PM, and so often we forget to use it. There are many ways to use this question, but the most fundamental is to get to the “base desire” that underpins customer and stakeholder requests.

When a customer or stakeholder explains what they want out of your product, ask “Why?” a few times, enough until you get to the core desire behind their request (this is what people are talking about if they reference “The 5 Why’s” — the idea is if you ask “why?” five times, you will always get to this core desire).

Let’s use this lens to look at the classic Henry Ford quote, “If I had asked people want they wanted, they would have said a a faster horse.” This is true, of course. But if he had asked “why do you want a faster horse”, they might have said “because we want to be able to get from point A to point B faster”. There we go. Only had to ask “why?” once, and now we see the deeper desire that needs a solution.

很快我就会完整写篇关于这个词的文章——这就是我认为“为什么?”这个问题有那么大的影响。是写给产品经理的。这是我们作为产品经理的超能力之一,但我们经常忘记使用它。有很多方法可以使用这个问题,但最基本的是得到基础客户和利益相关者请求的“基本愿望”。

当客户或利益相关者解释他们想从你的产品中得到什么时,问“为什么?”几次,直到你达到他们要求背后的核心愿望就足够了(这是人们在提到“The 5 Why’s”时谈论的东西——这个想法是如果你问“为什么?”5次,你总是会达到这个核心愿望)。

让我们从这个角度来看看亨利·福特的经典名言:“如果我问人们他们想要什么,他们会说要一匹更快的马。”当然,这是事实。但如果他问“为什么你们想要一匹更快的马”,他们可能会说“因为我们想更快地从a点到达B点”。好了。只需要问“为什么?”,现在我们看到了需要解决方案的更深层次的愿望。

错误8. Trying to build processes on your own

尝试自己构建流程

Here’s a fact that alludes a lot of us, especially when we are first getting started in product management. Product Management is a craft, which is to say it is a definable type of work with best practices and the ability to get better and better (or worse and worse). Not only this, but there are a lot of people, just like me, who dedicate LOTS of time writing, teaching, coaching and evangelizing the craft of Product Management.

Many of these people (also like me!) additionally develop processes, practices and ways of working that are designed to help you scale your efforts and more quickly tackle whatever it is you are trying to tackle. This could be discovery, validation, testing, business modeling, etc. The callout here is to use your old pal Google, and look for other people that have already solved for the thing you are trying to solve for, and use their methods to start with.

Sure, you can grow and morph these to suit your needs, and eventually you may generate an entirely new way of working, but for now, when you are starting off, try and stand on the shoulders of those that come before you.

这里有一个事实暗示了我们很多人,尤其是当我们初涉产品管理的时候。产品管理是一门技艺,也就是说,它是一种具有最佳实践和变得越来越好(或越来越差)的能力的可定义类型的工作。不仅如此,还有很多人,就像我一样,花了大量的时间写作、教学、指导和传播产品管理的技巧。

这些人中的许多人(也像我一样!)还开发了流程、实践和工作方式,旨在帮助你增强努力,更快地解决你正在试图解决的任何问题。这可以是发现、验证、测试、业务建模等。

当然,你可以根据自己的需要进行调整,最终你可能会创造出一种全新的工作方式,但现在,当你刚开始的时候,试着站在前人的肩膀上。这会让你在工作上比那些不这么做的同事做得更好。

错误9. Thinking “MVP” means a crappy version of the final product

认为“MVP”意味着最终产品的蹩脚版本

“MVP” stands for “Minimally Viable Product”. The concept is solid, and lies at the very heart of agile development. The notion is to start with a version of your final product that is simple enough that it solves your customer’s core problem without adding any additional complexity that isn’t absolutely needed at the offset. It should be as simple as possible, but still something that users enjoy and want to keep coming back to, and such that you can continue to enhance it as you learn from customers and look to add incrementally more value with each release.

Here’s the problem, though: it is actually pretty dang hard to determine what your product’s MVP actually is. To do this effectively you need to 1) talk with a LOT of customers, 2) go through practices like User Story Mapping to understand how customers would narratively flow through your product to solve their problems and 3) spend time with your business to make sure that the MVP meets the business or financial needs of the company. This is work. You will not arrive at your MVP after a few meetings. You won’t figure it out in a vacuum. Spend the time up front, because once you release, you often can’t get those customers back.

“MVP”代表“最低可行性产品”。这个概念是坚实的,并且是敏捷开发的核心。我们的理念是,从一个足够简单的最终产品版本开始,它可以解决客户的核心问题,而不会增加任何额外的复杂性,而这些复杂性在偏移时是绝对不需要的。它应该尽可能简单,但仍然是用户喜欢的东西,并希望继续回来,这样你就可以继续增强它,因为你从客户那里学习,并期望在每个版本中增加更多的价值。

但问题是:要确定你的产品的MVP实际上是相当困难的。为了有效地做到这一点,你需要1)与大量客户交谈,2)通过用户故事地图等实践来了解客户如何叙述你的产品来解决他们的问题,3)花时间与你的业务打交道,以确保MVP满足公司的业务或财务需求。这是工作。你不会在几次会议之后就得出你的MVP。你不可能在真空中找到答案。把时间花在前期,因为一旦你发布产品,你通常就无法把这些客户争取回来。

10. Failing to celebrate

不去庆祝

Let’s end with a fun one. Believe it or not, celebrating wins and generally inspiring your team is a huge part of your job. Like, a really huge part. As it is primarily your job to introduce and inform on the customer problems or opportunities your design or development team takes on, it is also your job to let the team(s) know how the release(s) went, what learnings were gleaned, and who we should be throwing confetti and champagne at!

Too many developers (and designers for that matter) build in a vacuum. They receive their intake, do the work, push it to production, and move onto the next task. A few months go by and they think “I wonder how that feature ended up doing”? This adds friction and can lead to lower team morale, reduced innovation, and ultimately greater attrition.

As human beings we desire to be bought in to a company and team’s vision and mission, to make an impact on the world around us and to be praised for work well done, and without these full loops of information or celebration, teams just aren’t as effective or resilient as they could be.

让我们以一个有趣的问题结束。信不信由你,庆祝胜利并激励你的团队是你工作的重要组成部分。一个非常大的部分。由于您的主要工作是引入和告知您的设计或开发团队所面临的客户问题或机会,还包括让团队知道版本的进展情况,收集了哪些知识,以及我们应该向谁投掷五彩纸屑和香槟!

太多开发人员(和设计师)在真空中构建。他们接收他们的摄入,完成工作,将其推向生产,然后转移到下一个任务。几个月过去了,他们会想:“我想知道这个功能最后做得怎么样?”这会增加摩擦,降低团队士气,减少创新,最终导致更大的损耗。

作为人类,我们渴望被公司和团队的愿景和使命所吸引,对我们周围的世界产生影响,并因工作出色而受到赞扬,如果没有这些完整的信息循环或庆祝,团队就不会像他们应该的那样有效或有弹性。


本文》有 0 条评论

留下一个回复