发布时间：2019-9-6 分类： 行业资讯
别人的成功经验是无法复制的，但我们可以隐藏在别人遇到的坑中。你可以逃脱越多的坑，你越接近目标。
别人的成功经验是无法复制的，但我们可以隐藏在别人遇到的坑中。你可以逃脱越多的坑，你越接近目标。虽然我已经在互联网行业工作了一年多，但我没有很好的经验。然而，在过去的6年里，我的管理和业务咨询经验让我在短短的一年里看到了很多陷阱。本文概述了我在这一年多的工作中所看到的内容。
我首先要写这篇摘要，感谢我的老板和这家公司。毕竟，敢于问我这个零互联网基础的人自己是一个非常有力的决定。当我来到这家公司时，这个职位是产品运营，但事实上没有固定的责任。在此期间，他进行了竞争产品分析，用户研究，业务分析，主持BC微站需求讨论会，做OSS产品经理，做业务分析，花时间在运营部门指导新人，以及也参与应用程序开发。利益集团。在此期间的工作使我从以前的咨询战略研究中退出到特定的业务，并看到了更多的实际问题。在这个过程中，我也躺在一些坑里，正是这些坑让我不断成长。
我在APP兼职平台，被认为是O2O领域。离线非常沉重。这是一个需要同时获得BC两端的行业。它刚刚融化了1000万美元。这笔钱在互联网上并不多，但它已经能够做很多事情。然而，该公司选择了一个模糊的在线工作，APP仍处于冷启动阶段。现在看来，这个结局的一个重要原因是互联网行业经常说的：快速反复试验。是的，这个互联网的人经常挂在嘴边，实际上是天坑。让我们谈谈我从产品，运营和公司三个层面看到和看到的维修站。当然，一些意见可能有偏见。请指正。
1、产品层面的小坑
在产品层面总结的问题可能不是很深，它们都是小坑。除了下面提到的坑。个人也发现坑是一个品质问题：一些产品人员过于感性，缺乏商业知识，很多地方容易出错。因此，个人觉得产品经理还需要学习一些逻辑，业务，营销，统计，管理等方面的知识，毕竟相对于如何做功能易于使用，澄清什么是重要的功能是产品人员首先要考虑的事情。在咨询时我经常说的一件事是做正确的事比做正确的事更重要。
1.1让我谈谈我已经制定的几个坑
1.1.1不确定优先事项
产品经理本质上是项目经理。在许多地方，产品有望得到优化。关键是要明确产品优化的优先顺序。
在早期，我来到公司，基于直觉感觉促进UI的美化。然而，我后来意识到，在当时频繁的功能变化的情况下，如果使用UI的大型修订来美化UI，则功能更新的进度将减慢。其次，如果功能被反复更新，如果整个UI框架无法一步完成。如果你以后调整开发团队，你会发疯的。第三，事实上，APP的UI美化并不急于公司的发展，因为几个月内用户不会很多。作为一种工具产品，核心是它是否可以帮助用户获得他想要的东西，UI实际上只是一块锦上添花。
这个问题让我意识到难看的地方不必立即改变，而是要全面考虑各个方面，包括：开发任务对用户的实际价值，当前产品优化的关键任务，以及采用在后期开发过程中衡量。可能的影响，发展任务的紧迫性等将在适当的时候得到解决。
1.1.2听取用户的说法后面没有真正的需求
很多时候用户不知道他们想要什么，我们需要根据用户反馈挖掘出真正的吸引力。特别是当用户的反馈涉及一些重要过程时，您应该谨慎，否则可能会适得其反。
我们正在做兼职APP。由于许多接受采访的兼职员工报告说下载应用程序太麻烦，每个城市负责人员也表示用户下载APP非常费力。因此，我们推出了微站版本，以方便用户注册作业，然后在结算时下载应用程序。然而，后来发现大多数在APP上注册的用户都是从APP注册的，而从微站点注册的用户很少独立注册。这意味着此举已导致活跃用户减少。
这次有两个经验教训：一方面，微站只是许多用户在微信上的过路人，APP将在手机上安顿下来。不想下载应用程序的原因是我们的应用程序提供的值不够，而且帖子仍然相对较小。重点应放在提高应用程序本身的价值上。另一方面，尽管注册微站的用户最终将导致下载APP接收薪水，但该过程无形地向用户提供APP用于接收薪水的心理暗示。进一步削弱了APP的价值观念。因此，在流程设计中，我们需要考虑流程对用户感知的影响。
总而言之，用户不舒服的原因往往不是他们所说的，产品人员需要更进一步。挖矿的核心人物被认为是“价值感知”。它之所以不好是因为这一步并没有让他觉得有价值。借用福特的名言：如果你问客户他们需要什么，他们只会告诉你他们需要更快的马。
1.1.3想一步完成功能
在最后一个功能开始时总是追求功能模块的完整性，但一个功能可以满足基本需求就行了，非必要的可以剪切，然后慢慢改进。
在第一次进行OSS设计时，我尝试一次完成一个完整的专业用户筛选功能，提供可执行的各种过滤维度，以及&，和，或者&，三个逻辑的组合。 rdquo;的然后在最初的需求讨论时被拒绝了。因为我们的操作员没有接受过逻辑训练，所以与&，或者根本不被理解的关系，以及多维复杂的筛选将消耗大量的系统资源。因此，只保留一些易于理解的筛选尺寸。在引入简化版之后，我们发现我们的操作员已经完全掌握了各种尺寸的组合，并且不能做同样的事情。我只能告诉他们哪些维度可以合并来整理出哪种用户，各种分析场景。需要通过哪些维度组合调用哪些数据。最后，实际应用程序只是开发内容的一半，而另一半不会被使用。
这个功能的设计教会了我三个教训：首先，在开发过程中，第一个版本应该尝试选择常用的功能。对于不常用的功能，您可以在迭代过程中根据需要逐步添加它们，而不是一次性追求。第二个是考虑用户的实际知识水平，一些需要专业素养的东西，一些局外人不能在短时间内学习;第三是考虑各种数据的积累，有些数据是少量积累的，没有可用性，因此相应的筛选维度不起作用。
