02|小厂创业:做出一个产品,卖给所有人
02|小厂创业:做出一个产品,卖给所有人
讲述:正霖,叶芊
时长18:09大小16.58M
水友讨论区
拓展阅读
赞 13
提建议
精选留言(14)
- 无处不在2022-10-01 来自浙江问题1:有人说客户需求是个哲学问题,而不是与客户沟通的问题,不是客户提到的就是需求。 我的感受如下: 1、目前很多面向B端的项目交付,在宣传的时候,都是按照产品层面去介绍的,落地的时候,就变成了项目,对于小客户来说,买来用就可以,但是对于政府、银行这种来说,内部的用户数量也很大,权限也要有要求,目前定制化的需求就是那些SSO集成认证、数据库适配改造、各种安全审查等等。某些代码的抽象确实不太容易。 2、对于银行这种客户来说,中间件不是Tomcat、数据库不是Mysql,在做产品开发后,都会需要核心的产品开发人员去支持项目的前期交付,以确保项目的稳定上线,和客户的信任,个人的感受就是前期做产品开发交付感觉可以学到一些内容,时间长了以后,就发现每次都是从1-2的过程,而不是互联网化的从1-100这种挑战一直增长的过程,B端项目的量级不会发展的特别快,可能系统上线了几年后,才能迎来技术架构的升级和挑战。 3、B端客户通常认为自己招标的项目给乙方公司做,乙方公司不认为自己是外包,但是对于B端客户,大部分都认为非自己员工干活的公司都是外包,也导致了目前业界对外包的怀疑,以前可能大家觉得外包工资高,现在大家更想的外包没发展,工资高没啥太大用。这个时候的突破,也就是自己出去跳槽或根据当前部门的老板出去寻找更大的机会了。 4、项目的交付过程,通常需要有超过几个5年经验的开发人员,招标的需求中明确要求了,所以导致经常出现核心产品的开发人员,需要各个地方出差去维护前期的支持,这个情况在某些程度上也会影响产品原有的开发进度,尤其是创业类型的小公司。展开
作者回复: 这个感受比我的深刻很多,👍
共 2 条评论7 - 一步2022-10-04 来自浙江因为项目太少所以抽象不够,如果有 100 个项目我一定能抽象出一个东西 --------------- 这个深有体会,最后基本上很难落地。 回想起来只是一个美好的愿景。 是自己在一个接着一个重复项目过程中的 前进的动力
作者回复: 嗯,有美好的愿景,才能坚持下去吧。
2 - leslie2022-09-30 来自浙江目前可能也在重复毕老师早期的路:通过这篇文章倒是让我明白了服务型团队其实应当怎样走路。
作者回复: 很希望看到更多,这条路确实不容易。
2 - 陆洋2022-10-09 来自辽宁说实话,谁还没经历过将toB的软件做成产品的梦想呢?但是文章里说得很对,同水平公司买入产品,肯定想创新,只能往低水平公司卖拷贝1
- 大道至简2022-10-07 来自湖南“抽象成产品,卖给所有人” 个人觉得这个产品定位有问题,产品定位的目标人群应该是具象有范围的,譬如老年人/中年人/小孩,而不是泛泛指所有人,做一个面向所有人的产品,极大概率会失败。1
- 李勇2022-10-06 来自湖南2b 和 2g的,都是商务先行,是客户第一,客户说啥都对。你想做产品本质是客户第二,公司产品第一。所以做个产品适配所有的项目可能确实一开始就逻辑不对了1
- 术子米德2022-10-06 来自浙江🤔☕️🤔☕️🤔 【R】做项目,一直漂泊,很不爽,二来不规模化,每个都要重来。 【.I.】以前做项目,那个还真算很久以前,做些课题类的项目,有种错觉,自己技术不错,做出来就是不太满意,而且还会唠叨,怎么就不能事先把需求提清楚。后来听到一句话,那算是很后来,应该是最近5年内,听到一句话说,需求一直在那里,它一直没变,只是自己没有本事把需求发现提炼到位。这个做项目中,对需求理解转变的跨度,将近15年。 【.I.】如果给需求划定三个框,分别为基础设施型、领域知识 型、业务过程型,当项目里遇到具体需求时,先把需求的类型做个初步判定。如果该需求更多基础设施层面,那么就要看业界当前的技术进展,这部分拿得来就要用好,拿不来自己也很难搞出来。如果该需求更多业务过程型,那它的典型特点,就是能画出过程来,虽然会比较繁琐和场景耦合,但是这样需求的实现,才是客户最终肯掏钱的点。从业务过程里,总结出领域知识,当然在分析需求时,能直接划分为领域知识型就更好,这部分内容在做项目时容易被忽视,尤其在项目时间紧张时,补充说一句,哪个项目时间不紧张,实际上这部分就该是积累起来,而且必须是在项目过程里去积累,就像投资中的定投,项目过程里就要定投时间,投入更多思考去深入理解,进行梳理和抽象,转化为领域知识需求,开发成领域知识类产物,即所谓随项目产出的产品。或者说,做项目时,主线是能够积累的领域知识,辅线是完成项目交付。 【Q】项目和产品,到底有什么差别?表面看,项目是对方明确要哪些,针对性完成这些需求的过程,就算项目。产品是我做成这样,有满足你需求的,那就带个回去,就算产品。也就是说,项目的交付准确对应需求,产品的交付匹配某个需求。项目的主动在需求方,产品的主动在定义方。这是我对项目和产品的粗浅理解,毕玄老师能否再展开和深入谈谈,对于大部分普通软件工程师而言,参与项目类开发,对比参与产品类开发,哪方面更有利于开发人员的技能成长? ———— by 术子米德@2022.10.06展开
作者回复: 项目和产品,我现在的区分方法是: 假设做第一个客户用10个人投入半年,第二个基本同样类型的客户用2个人3个月,呈现收敛,我觉得可以认为这就是产品,所以项目和产品,我觉得最核心的是面向同类型的客户,交付的收敛性,但也不一定要收敛到0才是产品。 如果对开发人员的技能,按我上面的这个定义的话,那显然是产品会更有利于成长,但我觉得从项目做起,再转向做产品会更好,这样感受会更深刻。
1 - sesamegu2022-10-01 来自浙江经营业务的软件能否标准产品化,是个很值得讨论的问题。业界不少软件公司还在做类似的尝试,最近还听一位CTO说过类似的尝试。另外非经营类的,如财务,行政,HR等软件就能较好的产品化,SAP,salesforce 等公司就是代表
作者回复: 嗯,CRM/HR/财务方面这些确实是比较通用型的产品,标准化,规模化的可能性是大的,也相应的诞生了挺大的SaaS公司。
1 - 滕方2023-01-28 来自浙江很遗憾没有听到毕老师的原声,哈哈
编辑回复: 很遗憾没法放出来,之前确实计划过就用采访的原声剪辑上线,效果会好很多,但是有很多问题,音频噪音、内容整理,还有一些话没法公开等等原因,音频不太符合上线标准,还是放弃了
- WUYILIANG2022-10-12 来自浙江软件产品抽象复用难,saas有机会吗
作者回复: 就我目前看到的情况,我觉得也不太容易,但值得努力。 建议具体可以去看看各家上市的SaaS公司的财报,会看出其中销售成本的占比仍然是不低的,SaaS目前很大的好处应该是提升了销售的精准度。
共 2 条评论 - 健康的小牛犊2022-10-11 来自江苏现在各家的公有云感觉就是在卖产品,但是这个产品也是to B的,公司或者政府买了之后还是要在公有云产品的基础上进行各种各样的项目开发或者产品开发。
- Geek_7da1b32022-10-11感觉主持人对这个行业了解很少
编辑回复: 前5年毕玄的小厂经历确实没有聊太多细节,尤其是技术细节。一是考虑到当年比较早,都是零几年,技术的参考意义不大,二是时隔比较久老师也很难回忆起工作中具体遇到的技术问题和解法。 所以前两篇更多是在聊经历,而且毕玄当年是做政府项目的,访谈聊到的技术细节,也比较敏感,没法放出来。如果让你感觉收获不大,确实非常抱歉。 考虑到这个问题,每篇文末也特地整理了毕玄自己写的博客/公众号的相关链接,是他当年的第一手复盘资料,在技术准确度和可参考性上更强。希望有帮助~
- 码小呆2022-10-01 来自广东我走过你过的路
- novoer2022-10-01 来自福建不同的人都走相似的路