What Does a Traceability Software Product Do in Agribusiness?

Editor’s note: This article was originally published on LinkedIn.

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.

Advertisement

When you are a software Product Manager who strives to be self-aware about your own thinking processes, your thinking hat typically toggles between two modes.

I’ve borrowed these terms and summarized my understanding from Ryan Singer’s beautiful framework on Demand Thinking.

When you operate from Demand Thinking (DT) Mode, you think deeply about the Context: What goes on in the life of your customers? What is important in their working life?

And when you operate from Supply Thinking (ST) Mode, you think deeply about the Tool: What are you building? What are you making to make their lives easier, and those whose lives whom they care about easier?

I can’t emphasize enough how critical it is to discern the former from the latter, because, let’s face it, we often think we are operating in DT mode, when we are actually operating in ST mode. Call it a Techie Product Manager Cognitive Bias, if you will.

“Some clients will ask me for a boat. What they actually need is to cross a river.” — Ronald Shakespear

I would in fact go further to state that this ability to distinguish between DT mode and ST mode is a matter of life and death for a Product Manager, because if you mess things up, Product Death Cycle awaits you.

Image Credits: David Bland, who coined Product Death Cycle in Twitter

In the life of a product manager, there are moments when it feels as if you are walking a tightrope along a tensioned wire, delicately trying to bridge the chasm between these two modes.

Balancing can be tricky, especially, when you are building a software Product in a domain like agribusiness, which challenges most of our conventional assumptions about technology adoption.

How does one deeply analyze a software product in such a scenario?

In his recent blog, Ryan Singer writes,

Products are easier to reason about when you think of them as functions. They transform an input situation into an output situation.

DT mode at play here, defining a Product as a transformation of user contexts, rather than a tool containing a set of features.

Let me unpack this with an example, using neoInt, the software product my team and I are building for Agri-Input firms.

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?

Shall we toggle back to DT Mode? Can we examine what the software does to its customers? Shall we write the Product as a function?

When you write 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.

Consider the typical state of affairs in an agri-input firm:

It is no surprise that this unwieldy combination in most cases, whether in organizations large and small, buckle under the weight of the complexity in managing channel affairs in a largely unorganized market like India.

So, what is the next logical step?

The Input Situation X is still the same, and so, we plug in neoInt as f() to see what Y Situation it turns up.

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?

If you are building software products for agribusiness, try doing this exercise for your product and let me know how it helps. You can thank me later.

Now, if we zoom in into this output situation Y, you would understand that it is valuable, only when it manages traceability across most of the business processes in the agri-input value chain.

Given the fact that agri-inputs have very little brand pull, and are more often “pushed” (or call it pre-placement, if you will) into the trade channels to hedge against uncertainty of rains, ambiguity of pest pressure, yearly variation of acreages under different crops, it becomes all the more important to optimize inventory across sales, supply chain, and marketing functions.

Talking of optimization and supply chains, today, in circa 2018, it is obvious that Efficiency is no longer the high-horse virtue it used to be. In his classic article, “The Triple-A Supply Chain,” Stanford’s Dr. Hau Lee, in the Harvard Business Review, pointed out with empirical data that Agility, Adaptability, and Alignment of supply chain actors are more critical than Efficiency in developing a competitive advantage for firms.

What can help agri-input firms build “Triple-A Supply Chain”?

Now, when you explore this question seriously, it is only a matter of time before someone brings up Blockchain.

In the recent “Technology in Agribusiness” white paper report released by Stanford Value Chain Initiative, the same author of Triple-A Supply Chain shares his optimism towards Blockchain. Dr. Lee writes:

There is an opportunity for nascent and yet undeveloped technologies to facilitate traceability, finance, logistics, trade, and other activities across the value chain to improve system orchestration. Blockchain is one technology that has the potential to be applied to improve system orchestration in several areas.

When I critically examine this optimism, keeping aside my personal biases, I see a lot of challenges. Let me use the same Function Lens to examine the potential of Blockchain.

If you annotate what Dr. Lee is saying above in context with agri-input firms, it essentially boils down to this:

Leaving aside the technological challenges for the sake of this discussion (If you have time, you must read this grounding perspective of technological barriers to blockchain, articulated by Dheeraj here), 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.

Coming back to the Traceability in the agri-input value chain, there have been interesting developments happening at the edges of the value chain, to close the last and crucial link in the feedback loop between Farmer to Agri-Input firms.

Through Digital Agriculture technologies, site-specific crop management tools are quickly gaining acceptance in the market to gather and analyze information at the individual botanical plant level for improved agricultural practices.

These Crop Management Tools promise an array of benefits to the farmer beyond the fundamental promise of greater yield. Most importantly, they promise data-driven credit to farmers through insurance models churning the data of these crop management systems.

These are early days, and we need to critically analyze the impacts of digitization of agricultural practices. We need more informed, in-depth commentary to analyze the effects of digitization of agriculture and its second-order consequences. Talking of which, I highly recommend this excellent perspective from Dr.Charlotte Schumann.

What do you think about the efforts to bring Traceability across the Agri-Input Value Chain? Do you see any other alternative cost-effective approaches to bring Traceability? What makes Traceability a hard problem to crack?

Let’s talk.