先区分学习对象与适用范围
产品经理学区块链技术有哪些常见问题？首先是把不同系统的机制混为一谈。比特币开发者指南讨论账本、交易和工作量证明；OpenZeppelin Contracts 文档讨论智能合约访问控制。前者帮助理解记录如何被验证，后者帮助理解谁能执行特定操作，不能直接互相套用。
问题一：上链是否意味着记录绝对不会改变
比特币通过区块关联和工作量证明提高修改历史的成本，全节点独立验证区块。网络可能出现竞争分支，并在有效分支中依据累计工作量选择链。因此，“已进入区块”仍需要结合后续确认理解。
在产品需求中，可以分别定义已提交、已收录和满足业务确认条件等状态，并明确发生链重组时如何重新核对。避免让一个“成功”提示同时代表网络接收、区块收录和业务完成。
问题二：钱包余额能否直接套用账户余额模型
比特币交易消耗未花费交易输出，即 UTXO，并产生新的输出；同一输出不能在链上被重复花费。产品经理需要理解展示余额与底层可用输出之间的关系。
描述支付功能时，应把用户看到的金额、交易引用的输出和最终业务记录分开说明。这样更容易与研发对齐数据含义，也能避免把比特币的交易结构当成所有区块链通用的账户模型。
问题三：智能合约是否不需要管理员
OpenZeppelin 提供单一所有者与基于角色的访问控制机制。执行某项操作的权限，与授予或撤销该权限的管理权可以分开；放弃所有权后，受仅限所有者条件保护的功能将无法调用。
对于存在管理功能的合约，需求应写明每项操作由谁执行、谁能调整授权，以及管理身份如何交接。单一管理者可对应所有权模型；需要职责分工时，可讨论角色模型，并按职责限制权限范围。
问题四：产品经理需要学到多深
学习目标可以落在可评审的需求表达上：能说清记录何时被业务接受、异常时如何处理、关键操作由谁授权。理解这些边界后，再根据具体系统补充实现细节。
评审时可用场景检验需求，例如交易暂未被收录、已收录记录遇到链重组、操作人员权限被撤销、管理身份需要转移。把每种场景对应到页面状态和处理规则，比单独记忆术语更有助于形成完整设计。