首页 「二次创业」的窘境
文章
取消

「二次创业」的窘境

《创新者的窘境》一书提到一种现象:一个运营良好的企业,有充分的客户基础,他们倾听客户声音,不断增强产品,但却最终倒闭。听起来似乎不合理,但却真实的发生。

过去一段时间,我们以「二次创业」的形式,上线了新产品 浩客。在已经有了金数据从零到千万用户的经验之上,整个过程应该要比较顺利才对,但还是经历了不少的的磨合与反复,还是值得思考。

借用该书的名称,这也许就是「二次创业」的窘境。

依赖的惯性

  • 设计师依赖产品经理给出Lo-Fi
  • 研发依赖产品经理出详细的AC
  • 研发依赖设计师给出Hi-Fi

从角色上划分来看,上面的依赖十分正常,也是该角色该做的产出。

但是在初创阶段,特别是整个产品的基础框架已经上线后,这种依赖不会带来更大的收益,反而可能会是前进的阻碍。

产品经理要关注客户需求

创业不是交付产品,而是帮助用户完成他的工作。此时产品经理的关注点更多应是客户的使用情况和需求反馈,他需要从宏观上保证产品方向的准确,是基于客户的,而不是闭门造车的。

每一个合格的研发和QA有着足够的逻辑思考能力,来梳理不同功能的细节,产品经理澄清该功能的背景和价值,给出关键的场景,也许还有Lo-Fi就已足够。

所以产品经理越是花费精力在功能的细枝末节,将自己这部分工作做到极致,反而越可能给整个产品带来方向性的风险。

设计师要关注价值的呈现

设计师在产品基础框架上线的过程中,与研发一起确定常用组件和UI规范,在这个规范之内,双方都进行有约束的设计和开发。

在这之后,设计师需要更关注和思考产品的价值是否能准确的通过自身传达给用户。合格的研发有能力根据已有的页面进行组件的排布,设计师投入部分精力进行质量的验收即可,而无需每个功能都输出Hi-Fi。如果整个过程中,没有Hi-Fi就无法进行,那么或者前面的规范不足,或者基础框架没有扩展性。

(BTW,Matine 是很推荐的React 框架,支持良好的自定义,对开发和设计都很友好)

所以设计师越是专注在将产品的所有细节不断精深,在这个阶段产品整体可能越无法优化。

研发要发散思考但深入浅出

初创团队中的研发,绝不应是所谓的「工具人」或「螺丝钉」,作为团队中最理性的角色以及构建者,在开始着手编码前,需要:

  • 协助产品经理明确其价值,其实简单的问几次为什么都很有作用
  • 提出与直觉不相符、规范不匹配或者实现复杂的设计问题,避免做错误的事
  • 仔细梳理逻辑,将缺失的不重要分支「自行补全」
  • 思考当前功能是否可以拆分,而不是必须当做一个完整的功能一起上线
  • 根据历史经验考虑扩展,但避免过度预先设计

所以研发越是按部就班完成任务,那么就越会将产品经理和设计师拖入到内部视野之中,从而恶化上述两点。

稳妥的惯性

  • 任何需求,都需要产品经理拍板
  • 任何样式,都需要设计师拍板
  • 任何bug,都需要QA测试

对于成熟产品,以上三点也许不仅重要,还会增加很多更多环节,来保证准确无误,因为在广泛的用户基础上,一点错误可能都会无限放大。

对于初创产品,容错率会高很多,尽快的上线,解决某个需求到80%的程度,用户可能都非常开心。在细小的环节上,当成员有足够的信心时,这些稳妥的惯性不会带来更多好处。

所以整个团队越是稳妥的前进,就越会失去创业最该需要的活力。

想做正确的惯性

工作中,谁都不愿意犯错,产品经理尤其如此,因为他是整个链条的入口,他的错误可能会带来整个团队无效的工作。

但在初创阶段,唯一确定的就是不确定。通常情况下:

  • 我们根据自身规划,来构建产品框架。但适用于最初阶段,或者某个大模块的开启之前
  • 我们根据用户反馈,来优化产品功能。但用户量级不够,输入不足

此时,试错是很好的突破。用小的成本进行线上验证和引导,启发用户来开拓更多方向和场景。这时,想做正确的惯性,会阻碍着尝试。

所以越是想要做正确,就越会缺失了可能破局创新的机会。

「二次创业」的窘境

首次创业时,没有这些「良好」的惯性,可以在前进和探索中,轻装上阵,快马加鞭。

二次创业时,这些「良好」的惯性,反而可能带来各种的束缚,这就是「二次创业」的窘境。

「二次创业」的解答

《创新者的解答》对如何避免陷入《创新者的窘境》做了解答,对于这里讨论的窘境问题,后续再来分享我们的解答。

本文由作者按照 CC BY 4.0 进行授权

重视贡献,为成果而工作

二十四分钟精通ClickHouse Materialized View