AgTech Startups — the first two components that will help you reduce your cost and time to MVP are almost ready for prime time!
I am excited to share some good progress on the “Tech Stack.” When Western Growers launched the Global Harvest Automation Initiative two years ago, one of the key things we discovered after analysis of the AgTech automation space and gathering feedback from startups was that the cost and time to get to the initial “Product 1.0” in AgTech was too long. Developing ways to reduce the capital and time (which indirectly is also capital because time represents cost in the form of employee expenses) for startups in the R&D and product roadmap stage represents a big idea. In fact, here’s a slide from the launch that includes, among other things, a Tech Stack as a key component. Am I happy to be finally bringing an announcement about the tech stack emerging from the catacombs and darkness two years later. Yes and no. On the one hand, a lot of good work has happened and is happening. On the other hand, just like an AgTech startup, how is this taking so long? Fair question — let’s dive in.
So we looked at the R&D process for automation startups, focusing initially on harvest and broadening the view later to other functions like weeding, thinning, planting, and spraying. It turns out that each of the startups often builds every component of the technology stack from scratch. At a high level, these components break down into a couple of key categories represented in the graphic below. The red dashed line boxes in the graphic represent the key interfaces in the R&D / Product Roadmap efforts for startups. Simplifying these interfaces and commoditizing them is the key premise of the Tech Stack).
1) Image library — the first thing you need to do is to build a library of images that shows the crop you will be working on in various conditions. Different stages of growth, different light and weather conditions, different types of weeds surrounding the plants, and images of conventional and organic growth of the product. This image library can take 6–9 months of engineering time to develop a machine that can go down the field and take the right resolution of images at enough scale to be used in the next part of the exercise. You then need to develop a system of tags for the pictures that help identify key attributes in a structured way so that developers can easily identify groups of images based on those structured attributes. For example, being able to identify 1,000 images of romaine lettuce out of an image library of 50,000 images of multiple crops is a huge help to developers who do not want or need to look at the other 49,000 images. And here is a subtle point — being able to identify which parts of the image are the actual crop that is of interest is not a trivial effort, but is an essential part of building an effective library and a huge value add for the library user.
2) Artificial Intelligence / Machine Learning — once the image library is captured, you can work on the AI/ML code to help the machine start to learn a lot more about the plant. What are the attributes to identify when it is ready to harvest? How do you identify the weeds and is everything that’s not the crop a weed or not? For a thinning machine, how do you look at 5 plants in a 10” stretch of row and determine which 4 to terminate and which 1 to keep? The more images provided for the system, the more the AI and ML code is able to learn and handle the base use cases and the edge cases. What does the robot do when two apples come out of the same grow spot (commonly referred to as a “double”)? A human harvester looks at the two apples and picks them one at a time — no problem. The apple harvest robot needs to understand what it is seeing and do the same thing. Sounds easy — and it is for humans, but it’s harder for robots. That’s the magic that AI can help happen — and needs to for AgTech to work.
3) End effector — this is the part of the robot that actually picks the fruits or vegetables. This is one of the toughest parts to get right. It has to be firm enough to pick the product but gentle enough not to damage it between the pick and the placement into the appropriate product holder on the way to the cold chain. End effectors come in many styles with many different physical interface types that interact with the plant. This is also why to date every harvest robot company has focused on one product to solve. The one exception to that showed up in 2022 when Advanced Farm added harvesting apples to a product roadmap that already included harvesting strawberries. It must be noted that Advanced did that at least partially on the back of some learning from a purchase of another startup’s IP. There will be cases of startups having harvest solutions for two crops, but it will take a while.
4) Robot arm — something has to be built to get the end effector to the right point so it can pick the product. This is generally the robot arm and even though there are several industries that have robot arms and manufacture at scale, many AgTech startups believe their use case is unique enough that the R&D to develop a proprietary robot arm is worth it. So they create a portion of the product roadmap that includes development and iteration of the robot arm that can sit between the images and the product to be picked and use code to move to just the right place at just the right time to allow the end effector to do it’s job.
5) Mobility — so you created an image library, wrote a lot of code to help the robot know what to do with the images, built an end effector that could pick the food, and built a robot arm to make the magic happen so the physical act that all of it was built to do can happen when it needs to — that just sounds like a lot of work when you type it all out and amazingly the job is not done. Because while the rest of the pieces are built to do their job, nothing can happen until the startup builds something to physically move the entire machine down the field. This can take many forms, shapes, and sizes, but for many startups the mobility piece is on their roadmap as something they need to build.
So you watch enough of these lists and you observe enough startups and one thing is clear — this is part of the reason AgTech robots take so long and cost so much to build. Everything is custom. Nothing is off the shelf. I did an earlier post on the startup costs to get to scale. The details are in the post — dive in if you like. The short version is at this moment (2022 math, but it hasn’t changed much), based on looking at startup funding and how much scale automation startups have been able to achieve (or not), it appears like the fundraising required to get a startup a finished product and into market starting to scale is somewhere between $50–100M. That’s a big number, and it breaks down into two components: (1) 60–70% is generally spent building product — defining the roadmap, listening to growers, redefining the product, and then iterating until you get to a 1.0 product, field trials, and then launch; (2) 30–40% is generally spent on go-to market — doing the sales and marketing work for direct sales, channel sales through partners, or both to drive revenue growth in an initial geographic market and then expanding to other markets as sales grow.
The $50–100M is a little more challenging than that, because that number was for harvest robots, and most harvest robots are only able to do one crop. So the market is often not big enough to justify that kind of investment capital, and it gets really tricky because AgTech startups compete with mobile apps (lucky bastard can write Wordle as a gift for his girlfriend and get a $1M sale to the New York Times in a year — that’s not happening in AgTech) and fintech (all those clever little apps that move money around in new ways and take a little bitty slice for themselves) startups.
After doing the math, it became obvious that the best way for Western Growers to help was to help startups reduce that $50–100M number, and the best way to do that was to commoditize some of the R&D and development items on the product roadmap so they became off the shelf components that startups could just plug in and they would work. The items to commoditize would be the 5 items already mentioned, or at least major components of each. Once we identified the need, we started to break down the components into smaller chunks and determine the right strategies to build a general purpose version of each piece. In short, while Western Growers was not a startup or a product builder, we could help startups by building general components for the aggregate group of startups in the space so that all could use them.
It was at this point that Mike Dentinger, the 30-year Trimble veteran who has forgotten more about auto-steer, GPS navigation, and AgTech wizardry than most of us know (and was leading the Tech Stack development with some super smart subject matter experts, or SMEs), released the 80–10–10 rule for our efforts. I can only give Mike so much credit for the idea — I’m sure he stole it and passed it off as his own work with some attribution — but it was the perfect framing for the issue. Mike said the goal should be to have 80% of the technology in the startup product roadmap comprised of off-the-shelf components built as part of our initiative, 10% should be tweaks and customizing the 80% to make the product built for specific purpose, and 10% should be new development work that should have IP associated with it that can be protected.
It’s worth noting at this point that the 80–10–10 rule was not viewed favorably by all. We got push back from some of the startups in the space on this breakdown on two issues: (1) you can’t commoditize 80% of the development roadmap, my stuff requires more custom development than that; and (2) if you remove that much of the tech stack and commoditize it, I won’t have enough IP left to keep my investors interested and writing checks. Our answers were short: (1) we don’t have to commoditize 80% — even 20% will be a big help (still true); and (2) investors will write checks for any product that gets to market with the right value proposition and economics — and there’s plenty of IP in the two spaces the group thinks will be where the 10% new development is most likely to occur, the AI/ML layer and the end effector development. Having addressed our critics (or at least deciding to agree to disagree), we moved forward.
The entire goal of the Tech Stack can be framed as a private-public fund raise of $15–25M that when built can save startups (that use it) 2–4 years of development time and $8–12M in R&D/product development. The table below shows some of the details of the Tech Stack. At least those are the walking around numbers I’m using for discussions with the private and public funders. We’ll see if actual mileage varies as we get things built and used. It has been a productive set of meetings, and Western Growers is working with great partners on multiple fronts. I’ll have more to say about the fundraising efforts in a future post. For now, let’s stay focused on the first two components of the Tech Stack.
So, with all of that as background, here’s the status of the first two items — the image library and the HarvestWiki/Automation Knowledgebase.
Image Library
The image library has been a very interesting journey, and I’m going to put a post out on it with a lot of the detail so people can appreciate both the journey that got us to this point and the deliverable that will be built and available for startups. For now, here’s the short version (you’re allowed to suppress a chuckle that after 2,600 words, I’m concerned about offering you the short version). We engaged Jason Mellow and Axis Ag to start building the image library. Jason spent a couple years at Farmwise, one of the early players in the AgTech automation space, and has a great “get it done” attitude that is serving the image library effort well. We ended up buying a Farm NG machine tricked out with some cameras and cool software and Jason took it to the desert and worked with multiple growers for weeks to get the basic image library to take shape. It involves 3 key activity sets: (1) taking images (not as easy as it sounds — way more variables than you would initially think); (2) identifying plants of interest (harder than it sounds — more in the detail post coming out later; and (3) tagging the images (for easy search and browse capabilities later).
We’ll dive in later, but for now here’s the key point — by the end of this quarter we will have a publicly available image library that any startup or early stage R&D team can use as a staring point for early prootype or R&D work for 4 (possibly 5) crops. Jason and the Farm NG team are off to a great start. It should be noted up front that these will not be production quality images. These are images that are only fit for purpose for early stage work — startups will need to budget for some image library work for production separately. All we are doing (but what we are doing) is offering an off-the-shelf image library for a few crops (lettuce, broccoli, and a couple of others) so that early-stage R&D work can start without the R&D team having to do that part. We’ll build it out for more crops later and put more functionality behind it, but that is the first marker we are laying down and it should be a good start.
The other part that Jason is working on is a playbook for doing this at scale. Jason and team are going to complete this process a couple times for a couple of crops, then offer the playbook and cool little Farm NG machine to Universities focused on specialty crops that will have Professor-student teams work with local growers to put their crops into the image library. Look for news on this front in Q2. If this paragraph gets your attention and you want to start a conversation, please let me know and we’re happy to start that conversation.
HarvestWiki / Automation Knowledgebase
The second item we are making good progress on is the (artist formerly known as) HarvestWiki. We launched HarvestWiki as an internal project working with the Washington Tree Fruit Research Commission Executive Director Ines Hanrahan and some of her apple grower members. The goal was to shorten the time startups need to spend on initial product development by giving them a set of use cases and market information that we could assemble for them so that not every startup needs to talk directly with a grower. They can start with a well built web page on how apple growers work, how apple harvesting works, operational needs the startup should know about, and specifics about harvesting (how to pick doubles, how to work with the wooden bins all apple growers use), including the basic economics apple growers are currently performing at (or at least targeting).
We built the apples page, spread the word, and hoped that people would come to the page (some are) and that the overall ag/AgTech community would crowdsource content for other crops (they are not). So after trying a few things to get the community engaged, we finally determined that this objective was not going to be met and we had to change course. It was at this point that we started working with Farmhand Ventures. Connie Bowen and Gideon Kotkowski have done a tremendous job of getting effort two of this project moving in a positive direction. They are starting with apples and building out the rest of the page. They have moved us from a WG internal project team working with Dokuwiki to a platform called Notion, which seems well suited to the task. The apples page is wrapping up soon — just a couple of finishing touches to put on it.
At that point, Connie and Gideon will start working on the next set of crops to build pages for and the future crops should be more and more efficient to put together because they’ve now done this one time end to end and can re-use the page template for new crops. We are no longer relying on crowdsourcing — instead Farmhand is driving the process and it’s working. By the end of Q1 there will be additional crops and they will really start to accelerate the work in Q2. As with images, one of the key objectives is to figure out how to scale from 3–5 crops to dozens and potentially hundreds of specialty crops. It’s not clear how we will figure the scale part out, but discussions are underway and we’ll share progress as we make it. We are also going to rebrand it from HarvestWiki (which explicitly commits to crowdsourcing) to something else that represents what is actually happening more accurately. Our marketing team is working on the best branding for the revised effort — stay tuned.
So, that’s the Tech Stack story as we wrap up January and head into February 2023. After a couple of false starts and some reasonably successful fundraising efforts, we are underway with both the image library and Knowledgebase having public releases out this quarter. I’ll have more details on both efforts in follow on posts and as we tackle future elements of the Tech Stack with one objective — reducing the capital and time needed for AgTech automation startups to get to first version of product and to scale.
