View profile

恣意生长 by Hwang - Issue #2

恣意生长 by Hwang - Issue #2
By Hwang • Issue #2 • View online
恣意生长是一份自我观察的 Newsletter。如果不输出,那么输入会显得不那么有意义,自大地以为自己“无所不知”。所以做一份 Newsletter 似乎会是一个审视自己的好机会。这份 Newsletter 会为读者提供个人的关于视角/产品/设计/编程 四个方向内容的思考和感悟,他们会是杂糅而又恣意的。
最近这段时间和几位老板在聊新产品的事情。其中一位老板,80后,本科浙江大学的,这些年一直在温州经营生意,非常优秀的生意人,几次聊下来感觉思路很清晰,有「温州商人那股劲儿」。之前他在北京买过房,和俄罗斯做过生意,也和非洲做过生意,业务跨度也很大,从农贸到硬件设备都有经历过。这两年他这边主要业务遇到了一些不大不小瓶颈,过往渠道的伙伴们,因为这些年硬件生意越来越难做了,都在思考着转行做软件业务,所以也促使我们这边接触了起来。

视角 —— 工具是长久的生意
我一直相信每一代人都会有每一代人的问题,而每一代人也将会有每一代人的工具,从刀耕火种的石镰到计算机时代的PC、Mac,一贯如此。硬件生意和软件生意看起来相差甚远,但是说到底,都是在给用户提供工具。
就像我上期说的那样,软件对于不同行业的「渗透」,在过往其实一直是不足的。很多产品或者轮子都是在互联网行业内广泛使用,但在传统领域并没有太大的影响。前些年「长尾效应」曾经是个热词,即便是 C 端的产品,也很容易区隔大量用户,更不要说千差万别的 B 端的。在我看来,现在这些直接面向 B端用户的旨在解决行业所有问题的「低代码」、「无代码」工具似乎是有些自大了(另一方面,在业务前一环节的 Low Code 和 No Code 是非常有意义的),但是深入理解行业,解决需求的 B 端产品又是少有的。
像咨询一样做
没有人是天才,所有存在已久的行业都是有其规律和态度的,保持敬畏十分重要。前几天飞书 5.0 发布,有一个印象比较深的画面,是他们的 BD 小哥(宇宙条当然不会是这么个 title ,但是做的就是商务拓展的事),去和客户一起工作。简单而言就是深入实地的去做「田野调查」,为客户设计流程,并通过飞书去实现这个流程。
熟悉咨询行业的读者应该都知道,无论是麦肯锡还是美世咨询,他们的工作方式就是这样的——深入了解客户的工作流程、业务流程、工作内容,用各自的方法论梳理出可行性的建议,达成企业咨询的目标。而现在,工具类产品的 BD,也需要去做这个事情。很显然,这是一种不同于 PLG 产品的思路,这咨询+解决方案的一揽子兜售,这种套路,需要你去熟悉用户、了解用户。如果你是做工具的团队,那么可以试着思考一下,你能够为用户提供咨询服务吗?
管理好渠道
toB 行业使用者和付费者分离是一个普遍现象,所以很多时候「寻租」难以避免。阿里云有一套非常详细的经销商网络(不得不说,浙商非常熟悉这一套),比如你可以在阿里云的网站上,看到「伙伴计划」,线上线下也能经常性地有一些自称是「云服务商代理」的公司来上门合作。他们会给你一些官网价格基础上的折扣,这些就是传统行业的「代理商」制度。云服务商大多都会通过这样的方式去深化自己的销售网络,触达到那些自己本身很难触达到客户。
这样的方式,作为销售链条上最前端的生产者,云服务商自己可以有效地避免与客户进行直接的「寻租」往来,减少很多不必要的风险,同时也能较大地减少自己销售团队的支出。
代理商的方式卖软件服务,其实早在上世纪就在国内流行了,当时国内就有很多正版软件销售。更具体的事例,读者可能都知道2009年成立的 「苏州思杰马克丁」这家公司。Adobe、 Xmind、CCleaner 等等将产品都曾将销售独家外包给这家渠道商。「独家代理」是工具类产品在国内销售会选择的方式,但是显然上面几家没有找到好的伙伴。 无可否认 toB 的销售代理商渠道是非常重要的手段,但是不应该是一家代理商的事情,依靠一家所谓独家代理的方式,并不能帮助你像咨询那样「解决客户需求」。在有效接触客户的前提下,利用渠道扩大自己产品的边界才能做好这门生意,所以管理好渠道也是 toB 产品的重要一环。
深耕行业
PLG 的产品和渠道商驱动的产品有很大的差别,但是可以预见的,不用多少年,当企业老板真正感受到「数字化」对于管理、对于生产带来的帮助时,「糊弄」人的东西就越来越难存活了。
这里面对于产品经理而言,有一个需要的共识就是:软件是可以帮助解决生产问题的,是可以给组织提效的。 换而言之就是,软件对于目标行业是有价值的。国内的 toB 产品就是要做好「咨询」般的服务,理解业务,发现其中的问题,并且提出解决方案,落实到系统中去。过去,互联网行业一直在对自身做这样的事情,而接下来,越来越多的行业还「需要」这样的过程。最后,带着咨询理念做产品,做好渠道地管理,这都是不是一朝一夕能完成的,所以工具总会是长久的生意。
总之还是: 「做难而正确的事」
产品 —— B 端教父 Salesforce 的履历
咨询+解决方案的一揽子兜售,这种套路,需要你去熟悉用户、了解用户。而中间的鸿沟在于 —— 如何获得企业的信任? Salesforce 在这一方面做的一直很成功。了解 Salesforce ,对于 B 端产品经理来说非常重要,因为这几乎就是最成功的 toB 的软件服务企业。
Salesforce 由 Marc Benioff(原甲骨文高级副总裁)创办。Benioff在创业之初,计划开一家有别于传统软件的CRM公司,不提供封装软件,而提供网页端CRM服务,将客户数据储存在自家的服务器上。那可是在 90 年代,即便对数据不那么敏感,大家也依然对这种有可能「窥探」到自家「底裤」的方式表示排斥。所以公司开始并不那么顺利,不过,后面的故事证明 SaaS 是一项合理、有效的生意。
时间线:
  • 1999年2月公司成立,志在改变传统的软件销售模式,归集客户数据到自家服务器的方式进行销售。
  • 2001年推出了全球第一款Web端CRM产品。
  • 2004年登陆纽交所,市值从11亿飙升至两千亿美元。
  • 2008年提出了平台发展战略,搭建起Salesforce的PaaS平台Force.com。
  • 2009年成为首家年度收入达10亿美元的企业云计算公司。
  • 2016年前后,求购 Linkedin 和 Twitter,不过后来都失败了。
  • 2016年收购 Quip、Krux Digital。
  • 2018年收购 MuleSoft。
  • 2019年收购 Tableau、ClickSoftware。
  • 2021年7月 收购 Slack
2016以后 Salesforce 增速放缓,开始了买买买模式,Quip、Tableau以及大家耳熟能详的Slack 都是 B 端领域优秀的产品,不得不说眼光非常好。
2019年 Teams 的日活超越了 Slack
2019年 Teams 的日活超越了 Slack
这两年,Slack 在和微软的 Team 稍落下风,相信凭借 Salesforce 的销售渠道,可以再度红火起来。
设计 ——聊聊 Figma 中体现的一些编程理念
Figma 是一款不一样的设计工具,作为一个偶尔写代码的产品,我总能感觉到 Figma 越来越像前端开发。 Figma 产品的设计很好的平衡了 设计工具 与 编程理念 之间的关系。和 PhotoShop 之类操作像素的工具不同, Figma 围绕着组件的概念展开。在使用中,我总能感受到 Figma 与编程理念的契合。
设计领域的开源
Github 以其优秀的社区文化见长,你可以在其中发布自己的开源项目,其他人可以 Fork 你的项目,可以直接看到你的代码。而 Figma 的社区同样也是这样,你可以发布设计文件到社区,其他人可以 Duplicate 你的设计文件,同样也可以查看文件中的每一个图层。
越来越多机构开始在 Figma 分享自己的设计规范,无论是 Google Spotify 还是像腾讯、字节都在 Figma 共享了自己的设计规范,众多的开源项目也在 Figma 分享了自己的设计文件。
AutoLayout 与 前端Flex 布局
然后我们看看 Flex 布局的参数:
可以很容易的发现,Figma 的布局方式,几乎就是组合使用的 Flex 布局,甚至连 Space between 的名称都是一样的。
当然除了 AutoLayout 的对齐方式外, Constraints and resizing 的设置项,与 CSS 的布局也异曲同工。
组件化
组件化开发几乎是现代前端开发的基础范式之一,无论是 Vue 还是 React 都遵循这样的思想。Figma 设计也是这样的,并且其继承关系和前端开发也是如出一辙:当你给定属性A时,属性A的默认值被修改,而后续组件其他的变化并不会改变这个属性A的赋值。
当然,Figma 的组件化,除了基本的设计组件外,还有颜色、字体、阴影的组件化。这与现代前端常用的做法也是一致的。刚推出不久的 Figma 主题替换功能,其实在代码中也是这么实现:通过一个变量,将一个颜色与一个主题的对应关系存储起来。而在 Figma 中,设计并不用定义变量,但是需要指定颜色的对应关系。
TailwindCSS 的颜色
TailwindCSS 的颜色
Quasar定义颜色的css代码片段
Quasar定义颜色的css代码片段
——-
图片: How to Eat an Elephant, One Atomic Concept at a Time 
图片: How to Eat an Elephant, One Atomic Concept at a Time 
除了上述内容, Figma 依然可以在编程范式中汲取营养,比如版本控制、pull request 等等。在设计工具这件事情上,其实许多工具都有类似的将 代码 与 图形进行映射的尝试,不过 Figma 显示是其中的集大成者。她的抽象主够优秀,操作逻辑也足够直观。我时常猜测「是不是可以这样」,然后 Figma 就能做到「是可以这样」,这种幸福是其他许多工具所没有的。
最后,推荐一下 Figma 首席设计师 Rasmus Andersson,以及他关于 Figma 的工作总结https://rsms.me/work/figma/
编程 —— SwiftUI 的 TCA 模式
偶然在 weak self 中听到,SwiftUI 目前比较成熟的 TCA 模式,所以花了一点时间看了一下。
一些概念
TCA 就是 The Composable Architecture ,TCA 引入了单向数据流,简化了状态的组成。写过 SwiftUI 的应该都明白,@Environment、@EnvironmentObject、@ObservableObject 这些语法糖,“吃多了”确实很腻。
TCA中有几个关键概念:
  • State: 用于渲染用户界面的状态或者数据。A type that describes the data your feature needs to perform its logic and render its UI.Action:用户交互产生的行为。A type that represents all of the actions that can happen in your feature, such as user actions, notifications, event sources and more.Environment: 容纳该功能所需的任何依赖性的。A type that holds any dependencies the feature needs, such as API clients, analytics clients, etc.Reducer:描述如何将应用程序的当前状态发展到下一个状态的函数。 A function that describes how to evolve the current state of the app to the next state given an action. The reducer is also responsible for returning any effects that should be run, such as API requests, which can be done by returning an Effect value.Store:驱动功能。The runtime that actually drives your feature. You send all user actions to the store so that the store can run the reducer and effects, and you can observe state changes in the store so that you can update UI.
学习资料
一些资料:
最近读了啥 —— 随便看看
产品
设计
编程
恣意生长 大致2-3周每月(本来以为2-3周能整理一期,还是高估自己了)更新一期,每期我会针对这段时间所思所想,整理视角/产品/设计/编程 四个方向的内容。目前的小目标是写100期,完成进度:2/100。
感谢阅读,欢迎回信,敬颂时祺。
Hwang 📝 12月18日 📍 杭州

Did you enjoy this issue?
Hwang
By Hwang

恣意生长是一份自我观察的 Newsletter。这份 Newsletter 会为读者提供个人的关于视角/产品/设计/编程 四个方向内容的思考和感悟,他们会是杂糅而又恣意的。

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue