When I joined Indigo Ag in 2020, they were offering transportation and logistics software and services to help connect farmers, grain buyers, and processing mills all across America.
They had a web interface and two mobile apps that enabled dispatchers and drivers to manage jobs through the supply chain, as well as help shippers (customers looking to have grain moved) with their work.
Due to the pandemic, there was a shift in demand for freight work. There were fewer drivers on the road. The costs of transporting grain had significantly increased. Through discussions with our customer account managers, we learned that shippers were struggling to find reliable drivers.
Goal: boost adoption and growth of the Transport product by addressing the supply and demand inbalance.
Together with Denis (my product manager), we focused on the carrier (driver) side, while John (design peer) worked with his PM, Misha. To ensure the four of us had clear objectives, we drafted "how might we"s and settled on two that would help drive our work over the next quarter...
We brainstormed and produced low-fidelity designs of how we could connect carriers and shippers on our platform. Then, we made a prototype to demo for our shipper customers.
It showed them inputting job details (origin and destination, the product, the quantity, the ideal “received by” date, and the rate) that would generate a draft job request.
John and Misha drove sales and research calls with shippers to learn their needs and solicited feedback on the prototype.
The shipper would send the request to carriers on our platform, from their own rolodex, or both. They could track the status(es) of the job(s) they’d sent and could edit or revoke. Once a carrier had accepted the job, the shipper could manage it from our platform.
While they were researching with shippers, Denis and I ran some research sessions for carriers.
We focused on what carriers would typically look for when seeking out and evaluating jobs. I had them stack-rank the ~15 most common job aspects (e.g. distance, hours of operation, rate).
We shared our insights and collectively validated what details were important when creating a job (e.g. rate, date range, distance traveled). But we learned there were “custom” job details that varied from job-to-job, such as:
- • seasonality
- • facility details
- • hours of operation
- • phone numbers
- • directions
- • on-site manager name
We decided to add one open text input, rather than adding six or more specific inputs (which required a database overhaul). This would allow the shipper to write in any additional notes. We had planned to scrape for common phrases and datapoints, and later revise the job request inputs.
With these insights and decisions made on the shipper side, I iterated on ideas for how carriers would receive, review, compare, and respond to job requests. And how they would manage those if they accepted them.
John and I collaborated (and iterated with our PMs and engineering leads) to build the core userflows that shippers and carriers would interact with on our platform. While we dreamt big, it had to be scoped down to hit our EOY 2021 target.
We designed six different prototypes as to how both sides of these jobs would interact with each other.
We shared our prototypes in customer calls and prompted our participants with the scenarios:
- 1. You’re a shipper who had one of their carriers drop out due to time conflicts. You need to find a new carrier or carriers on our platform. How would you do this?
- 2. You’re a carrier who has some upcoming capacity for more work. How would you find, receive, review, and respond to job requests?
During those research sessions, we determined that the custom job details and the ability to negotiate were critical for success.
In the MVP, shippers would send freight job requests to one or more carriers, who could claim them on a first-come-first-served basis, or they could order them based on their preferences. John and Misha bet that shippers who needed a last-minute job replacement would use the FCFS feature and send those to our network of carriers. But for jobs that were 4+ weeks out, they’d send those requests based on existing relationships.
If the carrier already used our platform, they would receive the request details via email and SMS (~97% of our carriers were owner-operators who were always on the road). SMS could communicate details to them at a glance.
The carrier could evaluate the job, accept it at the offered rate and offered quantity, or decline it. If they weren't already an Indigo Transport carrier, they'd receive an invitation from the shipper(s) that had sent them job request(s).
We launched our MVP in December 2021. A few shippers created and sent job requests, and many carriers had accepted. There was excitement from shippers, carriers, brokers, and the executive team.
For the second release in early January 2022, we launched a lightweight version of negotiations, where the carrier and shipper would only have one round of negotiating (mostly due to resource constraints).
But our engagement rates were low; we assumed it was because it launched at the end of year near the holidays. By mid January 2022, we only had a small, steady trickle of job requests come through.
I hypothesized as to why engagement was low:
- 1. The new request feature wasn’t discoverable.
- 2. No negotiation on-platform, so transactions were abandonded.
- 3. Traffic was low due to the holidays and snow blocking roads.
- 4. Little marketing spend or campaigns designed to drive traffic.
To help improve the feature (with limited insights), I led a design brainstorm with my team, specifically focused on negotiations (because it was a highly requested feature from our customers). We focused on a few HMWs...
The leading ideas:
- 1. Show carriers the current going rate averages for specific lanes or regions, so they can assess if the rate they’ve been given is fair.
- 2. Send monthly or weekly newsletters that highlight market trends.
- 3. Guide carriers to an ideal rate, and help them course-correct if an entered rate is overpriced (e.g. their counteroffer is 200% over the average), potentially saving them from unnecessary back and forth negotiation cycles.
- 4. Display cost of diesel/ethanol, weather conditions, road closures, routes, etc. to help them make an informed decision.
- 5. Let shippers send “requests for quotes” so the shipper doesn’t underestimate or overestimate and put the price decision in the carrier’s court.
Unfortunately, leadership decided to shelve the Transport product. If I could go back and do anything differently, I would:
- 1. Push for more research time and budget upfront to make sure that this was the right problem to be solving.
- 2. Spend fewer cycles iterating on the design explorations, and thereby get it launched sooner. This may have allowed us to ship earlier than the last few weeks of December 2021.
- 3. Advocate for closer collaboration with our marketing team, to better understand how we planned to drive traffic and convert customers.