这是创新者系列的第二本吧，其实整理成PPT估计就是十来页，但是作者还是一如既往的能写，这就是MBA作者的写作能力了。
既然遇到了创新者的窘境，就需要找到破坏性的业务，如何找，如何试错，什么样的流程才合适？什么时候给盈利的要求？企业高管如何介入？
逐一回答了上面的问题。
回到现实工作中，似乎我们还执行得不错，但是要复制这样的破坏性的业务的成功，最困难的还是找到合理的创新点。
因为以我目前看来，后面的流程、盈利要求、高管介入时机都有经验可循了。
唯一就是，如何剖析行业，找到那个朦胧的破坏点。
分类目录归档：不是技术
胎压
最近觉得outback噪声低了。另外，接触地面时偏软，感觉胎压不大够。
很艰难地想起来，我原来买过一个带电池的测气压+打气的工具。果然在工具箱里找到了它。
于是，我有三个法宝:
a.用于电池失效无法启动的随车打火充电宝
b.带电池的测气压+打气的工具
c.用来自检故障码OBD检测仪
虽然修车能力没见长，仪器倒是搞了一堆。
开到单位，检查了一下胎压，热车的情况下也只得2.0，2.1，于是统统加到2.3。
回来查查，发现冷车下的胎压为准，另外也要看车门边上贴着的标准。
于是等了3个小时，再下去看看，已经统一掉到2.2了。
这款outback的气压标准：
| 225/60R18 100V 225/60R18 100H（雪地） | 前轮 | 后轮 |
| 轻负载（3人+少量行李） | 2.3 | 2.2 |
| 满负载（5人+较多行李） | 2.4 | 2.5 |
| 牵引 | 2.4 | 2.7 |
| 备胎 215/60R17 96H | 2.9 | 2.9 |
我一般就自己开车，或者跟老婆孩子，于是就再把前胎加到2.3。估计噪声又会大起来了。
每一类商品的自助销售
相信用的最多的自助售卖机就是饮料型的。友宝也准备在香港进行IPO。
饮料有个好处就是，经历了可口可乐，百事可乐，各种矿泉水，运动饮料的多年趋同，外包装基本上是一致的，没有奇葩的设计。
比如易拉罐，比如塑料水瓶。于是自助售卖机就很好地兼容了这些饮料包装。于是有了全球比较一致的（饮料）自助售卖机。
牛奶/奶制品则有差异，一方面保存期不够长，对温度又有要求，对自助零售的不适应也导致其包装没有趋同的要求，独立发展出好多种不同的设计。反正都是放在开放的冰柜给顾客挑选，没必要为高度宽度考虑太多了。
所以，包装的趋同性推动了自助售卖的便捷，而自助售卖又要求同种商品有较一致的包装设计。
继续阅读电商参与线下零售的逻辑
首先是电商有仓储、物流、触及上的优势，已经对传统线下零售形成压倒性的优势。
体现在价格上。
但电商由于价格方面的低利润，（一方面来自抢线下而给消费者形成的印象，另一方面是电商之间的竞争）经营上要给到资本的回报其实不高，想象空间的薄纱也逐渐拉开。
回头一想，实体店利润还是丰厚，但消费者已经离开实体店有一段时间和较高比例了。
于是考虑如何将顾客吸引回来。
关键要让线下购物的客户体验比线上更好。
所以就是重构购物流程、砍掉不必要的部分以节约成本、增加BNPL等低门槛的消费方式。
实施CBDC的三个问题
越来越多的政体想实施其CBDC了（对抗低利率环境下的现金交易本能）。
1.工具——支持开发相关应用，支持使用CBDC
2.分布设计——支持有中心、分布式的设计，满足现金交易需要
3.基础设施——中央政府和商业机构都需要投入，网络、存储、运算等，业务上就是注册、验证、大数据分析。
PWA
感觉还是后知后觉了，一直把关注点放在Low code/no code上，没留意PWA已经成为又一波趋势，摆脱应用市场束缚的趋势。
PWA：Progressive web app(s)
即点即下载即用的模式。
几个流行的框架，其实也就是前端框架，比如：
Angular.js
React.js
Vue.js
Ionic
Polymer
开发工具，避免从零写代码，比如：
Magento PWA Studio
ScandiPWA
Webpack
SuperPWA
Lighthouse
我想，工具逐渐成熟，也可以作为MineCraft那样的MetaVerse的构建平台吧？
PWA的特点：
- Secure contexts (HTTPS)
- Service workers API (a JS script that works on browser background and enables caching and push-notifications on mobile)
- A web manifest that provides details about an app such as author, name, icon, and other UX and UI information.
纳什博弈论论文集
一本小册子，收了纳什关于博弈论的论文，当然是翻译过的。
有一部分是用解析几何和集合论的方法去构造博弈均衡点的。
现在看来是比较一般的想法，但作出初创者，确实给公众很耳目一新的感觉。
另，这个领域的更早的涉猎者是冯诺伊曼，真是神一般的人。纳什前期的工作也是在他的基础上所展开。
新的护城河是什么？
在行家的眼里，基本上不存在技术奥秘，所以知识产权的保护显得还是有点用。
但问题也来了，无论你对设计、硬件、软件系统、应用、商业模式等等如何做了多么高深的创新，在前沿的行家/专家眼里，一眼就看透的是，不存在知识盲点，要模仿是非常容易的。
另一方面，现代创新都是站在巨人的肩膀上，你的成就也可能成为他人的肩膀，所以开放总是比封闭要好。
用《Good to Great》的结论来看，技术上的领先根本不足以成就Great，只是一时的领先而已。
所以，贴地地说一下，新的护城河可能是什么？
无论是《原则》还是飞轮理论，依赖的是人和制度，然而我们讲护城河，必然是防守为主，人和制度也是会被挖角和复制的嘛。
从数据及数据应用的角度看，可以是订阅式的使用，引入比起单次付费更多的更广的客户群体，从而带来数据流，而基于数据流，必须进一步去理解客户，现在及将来（可能）需求是什么。
订阅制——（忠实及不忠实的）客户——数据流——（现在及将来）需求
形成闭环后，也就形成了适用于防守的护城河了。
新零售中的app
由于新零售很多是从线上入侵线下，从2C开始的，所以其app大多数以customer app为主，依靠顾客安装该应用而实现对顾客的定位、跟踪、人物画像、商品推荐等等。
容易被忽略的是，店员/店长有可能在相当长的时间里面仍然是零售场景里面沟通自动化环境和顾客之间的唯一桥梁（当然，远程客服也可以做，略显冷冰），面向他们的employee app的价值并不亚于customer app。
low code/no code for AI app dev
终于还是翻了一下现在流行的low code的平台，多数以表单、流程设计、前端、小程序等为主。
14年参与设计的low code工具现在依然被某五百强在用吧，从某种角度上来看，to B则必然是在某个特定领域上进行low code tools的开发，而不是一种通用的LCAP。
我的想法是，在AI的应用领域上，应该存在降低门槛和AI开发人员去认识各种编程语言的工具的机会。
查了一下，cognigy.ai做了一些，是语音对话方面的可视化编程，也称为low code吧。