在这呢……在这呢……再这呢……一个产品评审会出现的最高频的词汇！虽然你的东西确实做了，但其实隐患也在这句“在这呢！”中开始诞生了！

某年某月某日某公司XXXX产品评审会现场：

XX产品经理：各位领导好，现在是XXXX产品评审，请各位领导和其他部门同事多提意见！

XXX领导：你先开始吧！

XX产品经理：好的，我们的产品是这样……这样……这样……

运营同事：运营中的XXX功能在什么地方？

XX产品经理：（翻了几页产品原型）在这呢！

运营部门同事：嗯。

营销同事：我们需要的那个XX功能在什么地方呢？

XX产品经理：（翻了几页产品原型）在这呢！

营销部门同事：哦。

XXX领导：我想看到的XXX数据，XXX动态什么的好像没看到？

XX产品经理：嗯，好的，您稍等！（翻了几页产品原型）在这呢！

在这呢……在这呢……再这呢……一个产品评审会出现的最高频的词汇！

一句“在这呢！”绝大多数提问者都会立马闭嘴，因为自己需要的东西人家做了，确实有，找到了！这个时候产品经理是非常高兴地因为同事们、领导们关注的东西自己都做了！

其实隐患也在这句“在这呢！”中开始诞生了！

很多人会问为什么？

因为客户体验度和工作效率，在这一刻都打上了“？”号。

首先来说下客户体验度：

有多少好的商业模式因为客户体验差而死在了发展的初期？他们死的原因有两个：一个是客户的不买账，一个是竞品的抄袭！

（1）客户不买账

客户不买账原因很多，最核心的原因是客户体验很差。

当你的商业模式解决的客户痛点并非是完全不可调和的痛点的时候，对你的商业模式和产品往往会抱着试试看的态度去体验。而在这一刻你的产品体验很差，客户会立即流失而且很难激活，请记得“客户只会给你一次机会！”当客户流失了你前期的引客投入成本将付之东流。

很多人会说这个不是需要经常长期客户体验积累下来数据后进行迭代升级吗？

其实大部分的客户体验差在“产品评审会”中就体验出来了，因为参加评审会的是同事和领导，但他们同样是客户，如果不能在他们希望看到的地方第一时间点看到找到，那么这个产品的客户体验度会差到一定的程度。

（2）竞品抄袭

一个互联网平台/工具产品的壁垒期不会超过3-6个月，因此能否在这3-6个月内实现种子用户的积累，那么这个平台只能等死了。

所以这3-6个月的关键周期客户是否会留下来成为关键，而客户体验度成为了关键的关键。一个体验度差的产品/平台，即使你的营销费用再多，活动再多客户也很难留下来。

因为互联网客户的忠诚度很低，如果竞品在极短的时间内将同样的产品投放市场，却把客户体验度做到了极致，再辅以营销和活动的投入，那么竞品能很快占领市场将你打倒！

那么这种情况的发生是否可以避免呢？

答案是：可以的！

当产品评审的过程中产品经理“在这呢！”的时候，你问一句为什么？如果他的回答不满意，那么你可以直接依据客户体验度提出自己的意见。

产品经理自身的改进，产品经理在设计产品的时候是否基于客户体验度，而不是简单地功能流程走通为设计的初衷。

产品经理完全可以在两方面展开：

• 常用大平台的技术逻辑，首先大平台往往应用最前沿的技术将客户体验度提升到极致；其次大平台客户比较广泛其获取的客户体验数据也是网民长期积累下来的，所以借鉴大平台的技术逻辑提升客户体验度（非简单指有竞争关系的大平台）。
• 产品设计逻辑的时候多和一线同事沟通，多听取他们的意见，最前沿的同事才是最了解用户的人，他们能给你提供更有益用户习惯。

其次说下工作效率：

很多人会说产品经理设计的逻辑和功能里面有各部门想要的东西，都在那摆着呢！

在这我想说，产品经理规划的功能板块和逻辑真的是他们想要的？

举个例子：

记得之前开产品评审会的时候，因为我们的企业有面向B端的板块，所以有一个对B端申请审核的动作，按照运营的逻辑应该是两道审核流程分一审和二审，而且这两个审核的人是不一样的！这样才能最大限度的规避掉很多人为因素。

我当时问了句新申请用户和审核通过用户在哪呢？

我的产品总监一句“在这呢！”，他居然给我设计了一个数据库，而B端的状态居然是个筛选项！分申请、审核通过和驳回！

我当时就想骂娘了！

第一：这个逻辑所有的账户权限是一致的，没有什么一审和二审！

第二：审核的逻辑是层级逻辑而非状态查询的单层逻辑！一审的账户权限只能做一审，他能看到的只能是新申请、一审通过进入二审和审核驳回（驳回分一审驳回和二审驳回），而二审只需看到一审通过和驳回，这样在制作角色用户权限划分的时候才会更方便。所以我的产品总监做出来的东西只会降低运营部门的工作效率和提高运营风险。

这还是我遇到的情况，这样的产品如果制作完成后再由运营部门提出，试问耽误多少时间，对运营部门的效率也将是一种极大地伤害。这样的例子还有很多就不一一例举了。

那么这种情况的发生是否可以避免呢？

答案是：可以的！

1. 多沟通：产品经理在设计后台功能的时候，首先多与各个部门的同事沟通，了解他们的工作逻辑和流程，需要他们提出应该注意的点，因为他们是一线对问题的规避肯定会比产品经理更熟悉。其次在设计某些功能逻辑的时候多了解他们想要什么，具体的逻辑是什么？
2. 功能权限细致化：超级管理员权限设置的时候要绝对的细致，逻辑流程一定要清晰。因为角色账户需要的功能完全不同，逻辑也不会只有一条逻辑通路，可能会出现多种逻辑交叉影响。

最后别再被1.0版本里没有的客户体验，2.0版本解决的鬼话欺负了！

如果1.0版本都没人用等你做出所谓的2.0版本的时候，可能也就是你故去的时候了，所以1.0就应该围绕用户深挖用户体验度！

客户只给你一次机会，不想投入打水漂请严格审核1.0版本的客户体验，多问几句为什么？是否是基于客户体验度来的？

如果后台产品功能逻辑设计降低了其他部门尤其是运营和营销的效率，那对这个平台这个产品也是致命的。

1.0版本不解决其他部门同事的体验，等到2.0再解决，那么时间和工作效率成本也将是可观的，也会成为一个产品生存的关键因素之一。

本文由 @北漠 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议