诸位公司的产品经理都是怎么干活的啊？

[yyqxjwxy]

我司是直接截竞品的图写个说明，这活这么简单的吗？

[zw1196650986]

+1

[ahsjs]

如果只是抄竞品的话，那不需要产品，竞品就是原型图

[easyii]

直接抄对方的 都不用思考

[yxhzhang185]

哎，业务部门的传声筒。

[oV0dfQl4Nf8HA0y4]

给多少钱，干多少事的前提下，来讨论这个问题。
还要看你们公司产品工作范围。我们公司老板都要求产品开始做市场活动了。产品不是一个简简单单臭画原型的。其实产品也想自己就专注做好自己产品工作，但是不允许啊。

[yangzzz]

只会照抄，或者去业务端找几个自己觉得很牛逼的痛点

[SantuZ]

“我感觉这个功能得做”
“感觉你这个做的不行”

[yufeng0681]

@ahsjs #2 竞品就是高保真，就是验收标准

[ReZer0]

我司的产品经理（也可以叫负责人），相当于业务侧和信息部的中间人，整理业务侧需求，统筹安排周期，然后将任务布置下来的人。 估计是之前没有这种职位，导致业务侧有啥问题就直接找对应人，导致对应人手里头 N 个项目，几个都在加急，弄得手忙脚乱，于是就弄了这样一个人帮忙做需求整理，然后统筹布置。至少让内部有条不紊一点。

[FANGYK]

传话筒

[steve009]

建议转产品试试看 或者 跟产品同事交流下

[leejinhong]

@FANGYK 典型了哈哈哈 不过传话的时候甚至会出现理解偏差 。不能反驳，反驳就是说是老板要求的 ，最后出来是产品经理以为老板想要的。

[pioflight]

结论：作为初创团队，我们的产品压力很大。。

目前团队因为都是初创，倡导全员营销（就是只有一个转职做新媒体运营的同事，带着大家每周花时间做），每一个产品只有一个产品同事负责，所以这个产品同事需要对产品不能说有九分，得有十一分了解，还需要定期输出宣传辅助的文案（因为不是所有人都很了解每一个模块要如何宣传）
同时我们没有客服，所以产品负责人（一般是技术统管产品）以及产品同事需要兼职客服，了解客户的需求，或者 BUG 及时汇总反馈
以上是对外
对内，产品要对行业以及产品、竞品很了解，要求每个周期（我们是一个双月做一个 OKR ），对竞品要有所调研，竞品的动作要分析，以及新需求的对标
因为是初创，所以对内：
产品还要对需求原型进行输出，包括详细的功能说明，UI 的输出，以及和技术讨论需求的实现难度，当然这些应该算是产品本职的工作，只是多了 UI 以及需求分析、调研等
这样就完了吗？并不是，还有产品的用户数据分析，例如模块的使用率，事件数分析，热力图等

补充一点就是，我们要求技术也是半个产品，也就是对于技术，上面的内容都要或多或少会点，真的做到了人人都是产品经理。。

好处是，大家对产品都很了解，产品的底层逻辑，如何赚钱，如何推广宣传，在我们团队内是 0 信息差，也就是说每个人只要呆的够久，了解的够多，出去之后这一套可以直接站在比较高的角度都可以说清楚，不是螺丝钉的样子

坏处是，真的累

这导致我们的产品很不好招，因为大牛看不上，经验不足的又承担不起这么多工作内容

所以现在的团队基本就很稳定，毕竟团队确实没有解散的风险，就是累点，但是大环境这样，也算一个避风港吧

[flashBee233]

@pioflight #13 你们能做到 0 信息差是真滴厉害，我们这信息差大着呢，别说产品和研发了就是产品和产品之间也存在信息差

[wendon]

@pioflight 这种啥都管的累的很，以前也这么干

[yyqxjwxy]

@pioflight 讲道理技术也是半个产品就太扯了，除非工作不饱和，不然要产品经理干嘛的，而且技术再了解产品得去用代码实现，产品还是先把自己的原型输出好吧，原型做好了，自然技术就做好了，我司就是这个情况也是一个产品，原型有时候缺斤少两的，技术实现了，老板发现少东西

[estk]

小公司的话，人人都是产品经理

[ZeroYip]

原型图只是表现你对单一产品业务逻辑整合（ 或市场发展 ）的能力体现，不同公司制度下会有不同要求，高保真是锦上添花，切以为重要的是将「人物」-「场景」-「时间」-「成本」以某种形式表达清晰，既能让老板 / 领导 / 客户等非专业人士看懂，又能让技术实施人员了解业务和功能（ 或功能模块 ）间的联系和关系

[jasonchen168]

传话筒

[echen]

领导要的不能变，业务要的可以沟通

[timeance]

上到和行业龙头谈笑风生，在展会上讲行业趋势
下到工厂和 NPI 打螺丝，和研发及测试搞项目，拉着采购和供应商对线，跟着业务去拜访客户...

我都不知道除了收钱还有什么事情是可以不需要产品的

[buchikoma]

@yyqxjwxy 现在在很多公司都在推行需求前置和测试左移，一个让研发提前了解需求自己做设计开发，一个是让研发自测自己保证产品质量，这下 pm 和 qa 都不需要了

[daodao]

认真说，对于稍微有责任心和成熟点的产品经理，注意我说的是成熟和责任心，而不是优秀的、富有创造力的。产品经理在一般公司他的角色基本上就是一个传话筒，夹在程序员 设计师 领导 中间的，里外都不是人，平衡各方角色情绪。把领导一句话的需求包装出一个产品功能或者策略，不仅要写需求，可能还需要平衡下多方实现难度，还要回收数据，还有分析出所以然，最后写 PPT 给领导汇报工作的苦役。我是产品经理，曾经也是程序员，很累。显然大家都是牛马，程序员是体力上的消耗，产品经理是体力＋精神上的双重内耗。

[pioflight]

@yyqxjwxy 没办法 就是这样的，不是说技术要去兼职产品相关的工作，而是要能理解产品在做什么，甚至一些小的需求，在开发没有排满的情况下，中高级技术也要能自己出

[sunfly]

各有各的累，谁也别难为谁

[montaro2017]

需求文档没有，产品原型一团糟，需求说不明白，对话理解不了
总提些不合逻辑的奇葩需求，受够了

[bk201]

向上反馈的吧。给你看看竞品图就不错了，应该对 boss 会写一些 ppt 。这年头，用心做产品的不多，向上管理求高绩效的产品占大多数。

[tt67wq]

定会议室

[huang40614676]

产品经理确实不是人当的，真的是纯牛马

[tianzi123]

我们项目组 产品 技术方面别的不会,sql 和找 bug 倒是贼 6 了

[wildmaker]

羡慕楼上，我都找不到产品工作了，求捞

[hahahalololo]

@daodao 我们公司，it 归产品管，不用里外都不是人，他是老大，it 都得听他的

[tsuijinglei]

利益相关：产品

先角色，再分板块，再分阶段吧

角色可以分为大产品，小产品，板块可以大致分为 ToB 和 ToC ，阶段可以大致分为成事儿前，成事儿时，成事儿后

ToB 成事儿前：除了研发不做，其他的都做，包括但不限于调研市场、了解业务、商业谈判、售前方案、合规风控、成本规划。

ToB 成事儿时：研发、沟通，先把客户的业务 1：1 还原，交付项目，再想办法提效、抽象标准版，卖给下一个同类型客户。

ToB 成事儿后：大产品没事儿可做，小产品接新需求，在原有基础上加活儿。

ToC 成事儿前：会花大量的时间在市场调研、竞争格局调研上，每天头脑风暴不断地互相质疑，但最终得到一个终极目标
(产品定位)，和一个分阶段执行的方案(Roadmap)。大产品下结论，小产品集思广益。

ToC 成事儿时：出需求，一开始很简单，追求最简单的方式达成业务目标，验证后再想办法做扎实，这个阶段很多需求都比较潦草，可能就是抄了个竞品，也可能是自己写了个简单的逻辑，是研发最需要猜的是时候。大产品 Social 拉资源，小产品写方案。

ToC 成事儿后：看数据，天天盯着日活月活留存付费，一方面通过数据驱动做功能，一方面通过产品定位完善业务拼图。大产品招人，小产品做事儿。