一、需要先学到什么程度
产品经理的学习重点，是能解释用户操作如何变成链上记录，以及系统在什么条件下接受这次操作。可以围绕四个问题建立知识框架：记录由谁维护，操作由谁授权，规则在哪里执行，结果如何确认。需求讨论时，先说明这些边界，再深入具体实现。
二、区块链与普通数据库有什么不同
比特币开发者指南将区块链描述为有序的公开交易账本：节点独立验证区块，区块通过哈希引用前序区块；交易使用未花费输出，共识涉及工作量证明，链尾可能出现临时分叉。
这意味着产品需求不能只描述“保存成功”。还需要说明成功指提交请求、被区块收录，还是达到业务要求的确认条件。判断是否适用时，可以先问：业务是否需要多方独立验证同一记录？仅有存储需求，尚不足以说明采用区块链的必要性。
三、以太坊、ETH和智能合约如何区分
以太坊技术介绍区分了网络、执行环境与程序：EVM负责执行计算，智能合约是部署在网络上的可复用程序，ETH用于支付链上计算等资源成本；网络采用权益证明机制。
产品设计可据此拆开三个问题：业务规则如何表达，谁能触发规则，执行需要什么资源。智能合约适合表达条件明确、可由程序检查的逻辑。需求中的“自动完成”必须落实为明确的触发条件、输入参数和执行结果。
四、点击提交是否就代表业务完成
提交请求与形成网络认可的记录，是不同阶段。产品经理应与研发共同定义状态展示和异常处理，例如请求尚未被收录时如何提示，执行结果如何反馈，业务何时允许进入下一步。
不同网络的确认机制不能直接套用。比特币的分叉处理和以太坊的交易执行各有技术背景，因此不宜给所有链上操作设置同一种完成标准，也不宜脱离业务条件承诺固定完成时间。
五、不可篡改是否等于输入真实
记录难以被改写，描述的是历史记录受到的保护，不能据此推导输入内容一定符合现实。设计涉及外部信息的功能时，应明确谁提供数据、如何验证，以及出现错误由谁处理。
同样，规则被程序执行，也不代表规则本身完整。评审智能合约相关需求时，需要检查权限、触发条件和异常分支，避免把技术执行能力理解为对业务正确性的保证。
六、如何把学习成果变成需求文档
可以选取一个简单的链上记录场景，依次描述参与者、授权方式、输入内容、执行条件、状态变化和失败反馈。对每一步标明哪些由链上规则保证，哪些依赖应用自身处理。能够清楚回答这些问题，才算把基础概念转化为可供研发评审的产品需求。