往下做限制
type
status
date
slug
summary
tags
category
icon
password
产品本质是把方法教给普通人用。
最近在设计数据产品，震撼于表间关系之复杂时，又惊觉一个问题：我自己都不会数据库表设计，怎么去设计一个能让普通人简单使用简单托拉拽，就能构建表关系的产品？
于是涌出了一个想法：设计工具产品时，本质是在把解决问题的方法教给不知道、不会用的用户。如果用户可以通过产品来使用这个方法，并且取得成效，那么可以说这个产品实现了用户价值。而且，通过具体的程序，用条件判断、算法推荐、自动化等更底层的方法，还可以减少人为失误的概率。这样，就可以帮助用户规避掉低级错误，提高了用户做事的成功率。
人都是喜欢成功的——而且更喜欢连续性成功。爱屋及乌，用户就会更喜欢帮助他成功的产品和工具了。比如 flomo，说白了就是一个自我对话、快速记录闪念的工具产品。它的本质是关注独处的自我交流和卡片记录。很多开发者会觉得，这不就是一个 IM 工具嘛，为什么能吹得那么高？肯定是流量加持加上产品创始人吹牛逼，才让用户狂热地相信这能改变自己的生活。
但实际上，产品的好坏不取决于它本身用了什么功能、技术，而在于它有没有持续性地满足用户需求，并让用户愿意回馈产品。
所以，想成为独立开发者，必须避开这样一个误区：不要以所有场景来审视产品形态，只做最核心的部分。比如美图秀秀和 PS，专家们都很喜欢 PS，可配置的细节和参数太多了，而且实时出效果。但是，美图秀秀却能让爱好者只成为爱好者，剩下的交给产品方案，它提供了很多内置模板和滤镜，让用户只是简单地套用滤镜，就能实现图片美化的目标。引申开来，可能当前的 SD 和 Midjourney 同样有窗口空间，去形成一款类“美图秀秀”的产品。（因为我认为 Prompt 一定不是产品化的关键要素，可以参考苹果的“捷径”。）
回到开头，当我无法解决业务上面临的问题、也没有概念时，我是一定无法把它产品化的。所以，产品经理接下来可以有两种选择：1、让自己成为那个能解决问题的人，深入一线，去调研业务问题解决方案上的共性，看看能不能提取一个局部较优的方法来保证产出的下限。 2、借助现有业务上的专家，和他们沟通，让他们提供知识和方法，先教会自己，解决问题。然后再把这个方法产品化，给用户使用。
这两种选择的本质都相差不大，都是“认知、实践、再认知、再实践”，最后落地产品的过程。仔细想想，前十年产品经理的神话更多在来自于时代性的需求和专家的方法没有被推广开来。以产品为媒介，让需求和方法接触在一起，发生化学反应时，则成为了信息化产品爆发性增长的一个助推力。所以，大多数独立产品都可以参考这个思路：没有方法时，去学习方法，然后产品化给为产品，给用户使用。有方法时，让方法更通俗易懂，并通过产品让用户感知到自己的成长和产出物。