从0到1,做一款互联网产品需要关注的五个执行重点

7 评论 16854 浏览 113 收藏 9 分钟

现在聊聊从零到一做一款互联网产品,需要注意的重点。这些点,我看了很多相关的文章,很少有讲清楚的。在此简单列个几点,与你分享。

1.一切方案以「可执行」为标准

写出来的东西定义不明确,拆分的不够细,规则模糊,东西扔给研发之后,人家满脑子都是问号。这是新人最常犯的错误。

举个例子,假设某款应用有用户间评分的功能,后台需要一个列表监测那些连续被打差评的用户,看看是否存在恶意行为。于是,有人在需求中写了这句:「若一个用户连续多次被打低分,则列入观察列表」。

看到这句我就很恼火。「连续」「多次」是什么意思?什么时间内?几次?中间有一次例外还算不算连续?「低分」又是什么意思?低于多少分是低分?是低于绝对值,还是整个系统平均值,还是别的什么值?这种东西就是写出来无法执行的,定义的不够细,写了跟没写一样。

这种细节缺失的背后是逻辑的不清晰和一种「总会有人帮我把事情想清楚」的懒惰,它们会在紧张的「从零到一」过程中产生非常多的无效沟通成本,浪费大量时间去解释、修改。

如果项目中的产品经理都这样,结果将是毁灭性的。

2.设计机制

不得不说,业内太关注交互、视觉等表层设计了。其实产品设计中更具魅力的,是机制的设计。

机制,就是游戏规则。

往小的说,朋友圈的「关系链封闭」机制远比它的UI更重要,Twitter的关注和转发机制也是同理。放在游戏里,Tom Clancy’s The Division 中的暗区机制也是整个游戏的核心,引来了无数捧场和吐槽。

往大的说,房屋限购政策、公司注册制度、股票期权交易规则,都是机制。一个国家或不同国家之间的贫富差距,很大程度上也是由社会的机制(制度)决定的。

机制有好有坏。好的机制能缔造一个均衡的系统,让用户生产与产品定位相符的内容,发生对产品有价值的行为,减少垃圾内容和恶意行为发生的规模和几率。坏的机制,则能产生相反的效果,让系统行为完全脱离控制。

为什么打开各种产品blog,很少看到关于机制设计的内容呢?

第一,可能是因为这里没有duang这么炫酷的效果;第二,很多产品的机制都是核心秘密,于是没人拿出来分享是正常的。

所以我也没办法拿出来分享,我只能说这个很重要……

3.设计产品管理系统

产品本身重要,产品管理也很重要。数据后台,运营后台,这些都属于产品管理的内容。

数据后台比较好办,友盟等成熟工具一般都能搞定绝大部分问题。但数据需求要尽早定下来,而确定数据需求的过程中,就需要解决几大重要问题:我想判断的事实能通过哪些数据体现?这些数据通过哪些节点定义、采集?这些数据能为以后的迭代路线有哪些指导意义?这些都要提前想好。

与数据后台不同,运营后台一般需要自己搭建。这也是一个产品非常基本和重要的东西,其需求描述的量甚至会超过用户侧的设计。

举几个例子,内容类产品绝对都有个内容运营后台。如果内容是UGC的,那还有一个通过某种规则发现精品内容的运营后台。所有的社交类产品都要搭建一个举报审核后台、异常行为检测后台,以及可以执行的禁言/封号类操作。此外,所有产品都会有最最基础的用户反馈查看后台、全局消息发送后台、文案/入口配置后台。如果产品增长到一定的体量,还需要设计一套灰度发布机制和相应的后台,这个就更复杂了……

设计运营后台的一件要事,是设计运营专员的工作流。

公司雇人是要花钱的,为运营专员设计一套高效的流水线就是在为公司创造价值。而这套流水线也会在运营后台中体现。举个例子,运营专员要做举报审核,首先要浏览:考虑要展示哪些信息?怎么排版效率最高?然后进行操作:无视,或执行惩罚措施,是否有需要标记恶意举报?若没法当场判定惩罚措施,是否有需求打上一个「待定」标签?完事之后怎样汇报?如何评估运营专员做这件事的准确性,并以此为依据进行考核?

其实考虑到了这里,我们的格局就不止是产品设计本身了。

如果加入一个大公司的已有项目,上述这些东西多半是已经弄好的,不用费心去做。但如果是从零到一,情况就不一样了,你必须事无巨细地把这些东西搞定。

4.通过管理优化效率

从零到一考验的是整个团队的品质,而作为处在整个团队hub位置的人,更有责任影响并驱动整个团队往更聪明、更高效的方向发展。

我们需要做的是:

  1. 传播自己对产品的思考和理解,让团队每个人都在一定程度上理解产品的规划与设计;
  2. 督促研发等岗位对产品设计细节的了解和执行(当然前提是你写得够好);
  3. 搞好私人关系,建立影响力。

一个「无脑」的研发,会用错误的方法,把你的设计实现的乱七八糟,让你看到 daily build 后勃然大怒,结局必然是返工、延期、加班,而且这锅还得你背。

而一个「有脑」的研发,会用聪明的方法,实现你的设计,而且还会补全很多你没想到的 corner case,更有可能挑出你设计中的问题并提出建设性建议。

能跟有脑的研发合作,是产品的一件幸事。既然如此,为何不主动点,把身边的研发都变成「有脑的研发」呢?

5.提前进行营销准备

无它,就是预先做好准备:

  • 在产品设计之初就要明确定位,在执行中不断提取出卖点,特别是文案以及平面品牌元素(最好拉个专业人士一起参与)
  • 提前寻找推广和渠道运营的资源
  • 列好发布计划,提前设计首发活动
  • 提前收集活动运营idea,以后逢年过节可以拿出来用
  • 等等,正在探索中……

总的来说,从零到一做件事情,相对而言会复杂很多,但也更有乐趣。在这个过程中,你会发现自己的短板(设计、技术、运营、推广),并想办法去学习、寻找资源而弥补它。同时,你思考的格局、完整性也会比以前更上一个档次。

 

作者:吴亮(微信公众号:LumiSpace)

本文由 @吴亮 授权发布于人人都是产品经理,未经作者许可,禁止转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 个人意见:新产品从0到1的过程不用制定流程,不用特别详尽的文档。应该把精力用在验证产品假设上,只要产品能够稳定运行核心功能,就要拿着产品去找用户验证产品,后期才是制定流程提高效率。如果一个创业团队效率都不高,那直接开掉那个效率慢的,对其他员工更公平。

    来自福建 回复
  2. 求小编微信

    来自北京 回复
  3. 哈撒偷渡ASAP虐QAQ饿了偷渡DVD特色特特特特特特乐呵呵磕头fuel恶略特特特科特JDK

    回复
  4. 😯

    来自北京 回复
  5. 谢谢分享
    谈一些个人看法:
    针对第一个问题,个人认为应该是开发团队的问题,这种看似模棱两可的需求,其实是可以通过丰富产品设置解决的,开发团队应该能理解并且做好这部分工作.如果一个产品事无巨细,势必再某种程度上影响对产品的把控.
    第二个问题,产品设计的制度的均衡,起初可以越简单越好,这样也利于用户在使用中尽情发挥,也会对产品未来发展的起到积极的影响作用,如果设计过于严谨,难免会失去一些观察用户的机会. 也算是各有利弊吧.
    第三个问题,产品上线初期,没必要拿出太多精力来设计管理系统,早期可以通过直接查询修改数据库方式,而非必须开发一套完整的管理系统,太浪费时间,甚至一旦产品前端进行调整,后边的管理系统也必然跟着进行调整,成本过高,当然这只是在产品推出的初期试水阶段,到了中后期必然会有相应的管理系统与之配合
    第四个问题 没啥好说的,这跟产品经理性格有关系,一人一套路,哈哈.
    第五个问题 补充一下:营销运营是要配合产品凋性的,因为无论任何产品的开发,前提都是看到了利润区,才去组织开发的.运营推广过程中的任何策略,渠道都是以把握好产品特性为基础的.
    写的比较仓促,各种不足之处,请多多指教.

    来自天津 回复
    1. 写错字,咋改啊?

      来自天津 回复
    2. 改不了,哈哈。

      来自北京 回复