Too busy running a business for our tools

As I sat watching the tiles on screen fill in with scores of my colleagues, I wondered whether this would be the meeting where the engagement number finally got the attention it deserved. The slide I was expecting came, and just as quickly, we moved on to the next topic. Once again, the elephant in the room went unexamined, though I’m not sure it counts as an elephant if you’re the only one who sees it.

In my previous experience, a number that low would have been the only thing we talked about. Here the conversation turned to data collection: how to squeeze more data out of the few sales agents already engaged with our platform, independent businesspeople who sell our seed to farmers, and never why most of them weren’t.

The logic behind it was sound. The business needed on-farm data to show R&D how each seed performed, so the next generation could perform better. We also needed it so our software platform could make better predictions about product placement and which products to buy. But farmers are wary of handing that data to a seed company, and they are very busy. So the platform was turning toward the sales agents, who could map the farms, plan the planting and upload the data on the farmers’ behalf. I’d been hired as a Staff Product Designer to improve that platform across the portfolio.

There was a phrase you would often hear: building carrots on a stick. The problem with these carrots was that they weren’t solving the right problem. By glossing over the engagement number to crank out features built for collecting data, we were blinding ourselves to what our sales agents were actually living with. We were designing more work for people who barely had enough time in a day for themselves and their customers, and hoping they would somehow find more of it for us.

It wasn’t one meeting. It had become a pattern, and the pattern was becoming the problem.

My first answer was journey management. For months I mapped sales agents’ journeys, looking for steps we could measure and improve one at a time, and the longer I worked at it, the less sense it made.

The more sales agents I talked to, the clearer it became that there was no path to map. Weather changed, disease happened, budgets shifted, and commodity prices fluctuated, and each of those became a farmer on the phone with a need that couldn’t wait. One sales agent told me that at certain times of year they work 80- to 100-hour weeks, and they answer every call, whenever a farmer calls. If they don’t pick up, the farmer calls someone else, and that’s a lost sale.

I had made the same assumption the carrots did: that sales agents moved in straight lines. Journey management is built to measure a repeatable path and improve it a step at a time, and there was no repeatable path to measure. So I scrapped it and turned to jobs-to-be-done, layering systems thinking on top of outcome-driven innovation. If we could identify the outcomes sales agents were trying to reach, we had a far better chance of designing high-quality solutions for them than of forcing solutions into inflexible journeys. Their days were unpredictable, so the solutions had to flex with them. The months of mapping showed me exactly where a linear model broke down, and that understanding carried into everything after. The trade-off was familiarity. People knew journey maps, but they read them as business processes: steps to make more efficient. Jobs-to-be-done gave them something they could feel instead: what a sales agent was trying to get done, and what stood in the way. It pointed us at what we had been blind to: some of the biggest problems sales agents faced.

The question became how to give sales agents their time back, and answering it meant raising the elevation. Each sales agent was running a business across a hundred or more farmers, and the ones who weren’t engaged had no time to learn tools built for work in the field. What we weren’t delivering was help running that business. The problems worth solving sat at the level of the whole territory and the agency behind it.

The opportunity came into focus in documents our commercial team was putting together. Their strategy pushed sales agents to consolidate their agencies with other agents to cover more territory, so many of them were becoming business managers for the first time in their lives, with little sense of how to run the operation. Could our software become a tool for running that business, as well as for planning and planting? I only saw it because I was reading strategies being set outside my own org and following how they would land on ours.

Planning, when I arrived, happened piecemeal. Teams wrote white papers and proposals, passed them around for comment and sent them in. Our portfolio team chose which problems to solve with a data scientist’s eye: product performance, and how sales agents used the platform. It was careful, technical work, but the lens was narrow, and it stopped at the edge of our software. We knew the sales agent’s clicks and workflows in detail. What we couldn’t see was the rest of their day: the call from a farmer that reshuffles everything, the farm they drive past and decide to stop in on.

What I built was a system. The outcomes our sales agents were trying to achieve had to make it from the field to a funding decision without getting lost along the way, and at that time, nothing carried them that far.

Much of it came together through trial and error, and not everything stuck. What did stick came in layers. First, a home: a Design Strategy Center of Excellence, with service design among its capabilities, which I proposed and founded. Most of the organization was focused on what we would build and how. The Center of Excellence covered who we were building for and why: it worked a year ahead of everyone else, doing longer-horizon research that connected business goals and customer needs to the technology we had. Then a shared language. Jobs-to-be-done gave us words for what sales agents were trying to get done, and a taxonomy connected our features, capabilities and business processes to those jobs, so business units that rarely talked could finally argue about the same thing. Last, a place where decisions got made: an annual planning process I redesigned around those jobs.

Changing that meant getting the rest of the organization asking my question with me. I was a team of one with no dedicated budget, asking people to change how they worked. Shining a light on gaps nobody had been looking at is uncomfortable in any organization.

I didn’t build any of it alone, and this is where the change really happened. My head of design, who was also my manager, and one of our senior UX researchers were my closest partners, and each of us worked in different corners of the org. I mentored them, and a senior product designer, in jobs-to-be-done and how to put it to work, and they carried it into rooms I wasn’t in. My head of design and I stood up Persona Experience Teams for sales agents, employees and farmers, which drew in people from across business units and carried the perspective back into their own teams. Our senior UX researcher had relationships everywhere and was often pulled into research for both commercial and product, so the perspective began showing up in studies I never touched. We would each go off into our own projects, then come back together, build on what the others had seen and realign. It spread through conversations, stories and people who believed in it, with no mandate behind it.

I proposed a new planning process to the senior leadership team, built around the jobs sales agents were trying to get done, and once they approved it, I facilitated it. It traded the comfort of passing documents back and forth for a full day together in one room, which asked a lot of busy leaders and risked losing their commitment along the way. My bet was that changing how people saw the problem meant working through it together, out loud. The planning workshop was where it all met. Leaders from across the org spent the day inside a sales agent’s world, including all the hours a sales agent spends nowhere near our software: the calls, the customers, the business they have to keep running. The question on the table was how we could help with all of it, and it came before anyone argued for a technology. What came out of that room shaped the year’s investment white papers.

The first time I heard jobs-to-be-done language from someone who had never been near the work, it was a quiet hell-yes moment. It caught me by surprise. My aim had been to move us from inside-out thinking to outside-in, with jobs-to-be-done as the way in, and here was the language traveling on its own, turning up in meeting after meeting. It was resonating. The elephant was getting harder to miss.

The white papers that came out of that planning cycle were approved, and they turned the roadmap toward the sales agent’s whole territory and toward capabilities for running the agency as a business, so sales agents could get their time back. The planning process outlasted me. It is still how the org plans where its $50M a year goes.

Smaller bets moved the same way. Our relationship with customer support had been thin: we made sure they understood the product so they could answer questions, but nothing carried what customers logged back into product planning. I designed an all-day workshop to build that feedback loop and show that real opportunities could come out of it. With our head of product and leaders from commercial, marketing and customer support, we worked through about 120 support tickets together, and the white paper I wrote from it won funding for expanded reporting, including GenAI-generated summaries.

We could see the shift in the numbers, too. Working with our UX research manager and our analytics lead, I reshaped what we measured: the quarterly customer survey began scoring at the level of the job, and analytics tracked the customer jobs I defined, so the engagement goal finally pointed at something specific. Engagement later closed at 44% against a goal of 35%, and adoption at 52% against 50%. The following year, the quarterly survey showed perceived success up 13%, trust up 11% and satisfaction up 6%, across about 1,400 respondents.

The data the business wanted was still the point, and it was farmers who were wary of sharing it. My bet was that they would share it more comfortably as their relationships with their sales agents grew stronger, with more trust and loyalty there, and a platform that helped sales agents run their business gave them more time for those relationships. That was the better bet. Underneath all of it was the relationship and trust between a farmer and a sales agent, and the way seed finds its way to the field.

People move through the world in messy, unpredictable ways, and the way our customers met our brand was rarely a straight line. Software development tends to solve problems in one. A systems lens helped me find where a system has its boundaries and limits, and where it can flex. The harder lesson was about comfort. It is tempting to force a nonlinear reality into a tidy, measurable artifact, because ambiguity is uncomfortable to look at, for other people and for me. But that messiness is how real change unfolds inside a system, and part of the work is making it comfortable to adopt.