编者按：本文最初发表于 领英.
I’ve been traveling over the last one week, on-boarding our first large agrichemical customer onto the Agribusiness Intelligence neoInt Cloud platform. Energized by the conversations I’ve had, I’ve been thinking a lot about the intersection between software and agribusiness. So, today, for a change, you will see me wear my Product Manager’s hat, rather than that of an agribusiness professional. Regular programming starts next week onward.
当你是一名努力对自己的思维过程有自我意识的软件产品经理时，你的思维帽通常会在两种模式之间切换。
I’ve borrowed these terms and summarized my understanding from Ryan Singer’s beautiful framework on 需求思维.
当您以需求思维 (DT) 模式运作时，您会深入思考上下文：客户的生活中发生了什么？在他们的工作生活中什么是重要的？
当你以供应思维 (ST) 模式运作时，你会深入思考工具：你在构建什么？你做了什么让他们的生活更轻松，以及他们关心的人的生活更轻松？
I can’t emphasize enough how critical it is to discern the former from the latter, because, let’s face it, we often 思考 我们在 DT 模式下运行，当我们 实际上 工作在 ST 模式。如果你愿意，可以称之为技术产品经理认知偏差。
“Some clients will ask me for a boat. What they actually need is to cross a river.” — Ronald Shakespear
事实上，我想进一步说明这种区分 DT 模式和 ST 模式的能力对于产品经理来说是生死攸关的问题，因为如果你把事情搞砸了， 产品死亡周期 等着你。
图片来源：创造了 David Bland Twitter 中的产品死亡周期
在产品经理的生活中，有时感觉就像在拉紧的钢丝上走钢丝，微妙地试图弥合这两种模式之间的鸿沟。
平衡可能很棘手，尤其是当您在农业综合企业等领域构建软件产品时，这会挑战我们对技术采用的大多数传统假设。
在这样的场景下，如何深入分析一款软件产品？
在他的 最近的博客，瑞安辛格写道，
当您将产品视为功能时，它们更容易推理。他们将输入情况转化为输出情况。
DT 模式在这里发挥作用，将产品定义为用户上下文的转换，而不是包含一组功能的工具。
让我用一个例子来解压这个，使用 新诠释，我和我的团队正在为农业投入品公司开发的软件产品。
What is this Product? Is it an Agribusiness Intelligence Software? Or A Track-and-Trace Software Application to get Line of Sight into Channel Distribution? These things describe the solution and its capabilities. Did you see we’ve switched back to ST mode?
我们要切换回 DT 模式吗？我们可以检查什么软件 做 给它的客户？我们应该把 Product 写成一个函数吗？
当你写 f(x)= Y for your software Product, you are saying in plain English that your customer’s X circumstance will be transformed to a more favorable Y circumstance through the function of your product.
考虑一家农业投入品公司的典型情况：
毫不奇怪，在大多数情况下，无论组织规模大小，这种笨拙的组合都会在印度这样一个基本上没有组织的市场中管理渠道事务的复杂性的重压下崩溃。
那么，下一个合乎逻辑的步骤是什么？
输入情况 X 仍然相同，因此，我们将 neoInt 作为 f() 插入以查看它出现的 Y 情况。
neoInt takes the same input situation X and creates a different Output Y situation. Isn’t this a more precise way to define what the software does?
如果您正在为农业综合企业构建软件产品，请尝试为您的产品做这个练习，让我知道它有什么帮助。您可以稍后感谢我。
现在，如果我们放大这个输出情况 Y，您就会明白它是有价值的，只有当它管理农业投入价值链中大多数业务流程的可追溯性时。
鉴于事实 agri-inputs have very little brand pull, and are more often “pushed” （或者如果你愿意，也可以称之为预置）进入贸易渠道以对冲降雨的不确定性、虫害压力的不确定性、不同作物种植面积的年度变化，优化销售、供应链中的库存变得更加重要和营销功能。
谈到优化和供应链，今天，大约在 2018 年，效率显然不再是过去的高马美德。在他的经典文章中，“三甲供应链,” Stanford’s Dr. Hau Lee, in the 哈佛商业评论, 用实证数据指出，供应链参与者的敏捷性、适应性和一致性比为企业发展竞争优势的效率更为关键。
What can help agri-input firms build “Triple-A Supply Chain”?
现在，当你认真探讨这个问题时，有人提出区块链只是时间问题。
在最近 “Technology in Agribusiness” white paper report 由斯坦福价值链计划发布，Triple-A Supply Chain 的同一作者分享了他对区块链的乐观态度。李博士写道：
新兴且尚未开发的技术有机会促进价值链中的可追溯性、金融、物流、贸易和其他活动，以改善系统编排。区块链是一种有潜力应用于改善多个领域系统编排的技术。
当我批判性地审视这种乐观情绪，抛开我的个人偏见时，我看到了很多挑战。让我用同样的功能镜头来审视区块链的潜力。
如果你在农业投入品公司的背景下注释李博士在上面所说的话，它基本上可以归结为：
抛开技术挑战不谈（如果你有时间，你必须阅读这篇关于区块链技术壁垒的基础观点， 由 Dheeraj 在这里阐述), the moment you define what the function should be upfront, you are bending backwards to define the requirements, based on the function you’ve already defined, without a rigorous understanding of the ground reality -the actual Input situation X.
回到农业投入品价值链中的可追溯性，在价值链的边缘发生了有趣的发展，以关闭农民与农业投入品公司之间反馈回路中的最后一个关键环节。
通过数字农业技术，特定地点的作物管理工具正在迅速获得市场认可，以收集和分析单个植物水平的信息，以改进农业实践。
除了提高产量的基本承诺之外，这些作物管理工具还承诺为农民带来一系列好处。最重要的是，他们通过搅动这些作物管理系统数据的保险模型向农民承诺数据驱动的信贷。
现在还处于早期阶段，我们需要批判性地分析农业实践数字化的影响。我们需要更有见地、更深入的评论来分析农业数字化的影响及其二级后果。说到这里，我强烈推荐这个优秀的 夏洛特·舒曼博士的观点.
您如何看待在农业投入品价值链中实现可追溯性的努力？您是否看到任何其他具有成本效益的替代方法来实现可追溯性？是什么让可追溯性成为一个难以破解的问题？
Let’s talk.