This interview is with Vipul Razdan, Product Manager, FarEye Technologies.
To introduce you to Connectively readers: as a Product Manager in logistics and supply chain, how do you describe your core expertise and the last‑mile problems you focus on solving?
As a Product Manager at FarEye Technologies, I develop logistics and supply chain solutions with an emphasis on last-mile delivery execution, carrier-shipper workflows, and AI-centric automation.
This has evolved into a four-year specialty, originating at Locus.sh, and now at FarEye, where I build feature roadmaps aligned to salient delivery problems. At Locus.sh, I had the opportunity to work on enterprise logistics customer accounts from pre-sales to solution design and formal account management.
I am interested in execution reliability and visibility for last-mile delivery problems, such as:
- inefficient first-attempt delivery
- uncooperative delivery dispute resolution between shippers and carriers
- inadequate smart automation for everyday logistics processes
Current projects at FarEye include:
- optimizing first-attempt delivery with FarEye Ship
- designing digital dispute management
- providing direction for a focused AI vertical, smart agents, with the goal of automating delivery process interventions
What I appreciate is designing features for customers, making time-sensitive operations easier and more predictable. In order to accomplish this, one must develop an understanding of the supply chain and the customers on both ends. It is this understanding I try to bring to the products I build.
Tell us about a pivotal experience that led you into last‑mile and supply‑chain product management and shaped how you build products today.
I got my degree in Information Science expecting a career in software engineering and had no intention of becoming a product manager.
However, while I was studying and in my early professional career, I found myself drawn to other concerns. I was interested in questions such as:
- why users behaved in ways that were inconsistent with the software design documents,
- why solutions that seemed logical were not the answer, and
- why the most important conversations occurred between teams rather than within a single team.
The most formative experience of my career happened during my time at Locus.sh, when I was working with warehouse employees and corporate clients. There was a sizable gap between the clean product specification and what occurred in reality. Drivers had to adapt. Dispatchers had to find workarounds. Clients had to create their own business processes. This gap was not a bug that needed to be fixed; it was the first example of the kind of gap I had encountered that needed to be addressed most urgently.
The lesson I learned then is something I have taken with me to every product I have developed since. Most of the time, product development does not fail because of a bad idea. Most often it fails because systems are built without true insight into how users will actually use them. I used this knowledge to focus on the constraints placed on the system, which made it easier to make the trade-offs that needed to be made. This is why I have spent the last 5 years in the logistics and supply chain tech product management market.
Building on that, which performance metrics are non‑negotiable for last‑mile success in your teams, and why did you choose them?
Three metrics I consider must-haves for product work related to last-mile delivery:
-
First Attempt Delivery Rate (FADR):
This shows how your product interacts with the real world. Failed deliveries impose costs and have a cascading negative effect: customers experience friction, and carriers suffer erosion of trust. Increasing FADR while working on FarEye Ship was my primary objective, and I’d support this metric in any stakeholder meeting since it combines operational effectiveness with the end-customer experience.
-
Order Automation Rate:
The pipeline we built for order management had to remove the friction caused by broken processes at high volumes due to over-reliance on manual touch points. We focused on full process automation for ingestion so that planners could spend their time on exceptions rather than day-to-day tasks. This metric also demonstrates the level of trust your users have in your product.
-
Dispute Resolution Cycle Time:
Disputes between shippers and carriers are inevitable in enterprise logistics, but they should not last weeks. This metric shows the maturity of your product, as it indicates the presence of dispute resolution systems with clarity in data and workflows.
Combined, these metrics demonstrate product elasticity and utility across your user base.
You’ve cited RICE/ICE and the Kano Model—share a specific instance where one of these frameworks changed a prioritization decision in last‑mile logistics and what impact it had.
Building the invoice reconciliation platform at FarEye brought many backlog challenges. From the engineering team, we wanted to initiate automated rate-card matching — a technically difficult and exciting task. On the other hand, the sales team wanted advanced exception trend reports and analytics dashboards. We also had a list of demands from our enterprise clients. Everyone believed their priority was most important, but we could not reach agreement.
We evaluated the features using RICE — Reach, Impact, Confidence, and Effort. The matrix brought a new focus to the discussion.
Sales dashboard features had high Reach, low Confidence, and low Effort. We were fairly certain those features would not change reconciliation behavior. The automated rate-matching engine was a high-Impact feature but required disproportionate Effort, making it a poor near-term bet. What surprised everyone most was a low-Effort feature that provided a reconciled view where shippers and carriers had shared invoice data with exception trends clearly highlighted.
That feature scored High Reach, High Impact, and High Confidence. All of the enterprise clients were creating this view manually, with thousands of reconciliations each month.
Although it was not an exciting feature for us, it reduced dispute resolution for our enterprise clients by 40-50%. Using RICE made the correct decision fairly obvious while removing other options.
From your automation pilots in reconciliation, where do you intentionally keep humans‑in‑the‑loop in the last mile, and what guardrail has protected service quality the most?
Logistics automation is not about taking jobs from people. It’s about changing where people work.
At Locus.sh, we automated 100% of order ingestion and reduced the effort needed for manual logistics planning by 70%. Of the 70% effort we eliminated, we decided to keep 30% for manual planning. This was a conscious design choice. Logistics is iterative and dynamic. Things like broken shipments, unexpected address changes, exceptions with the carrier, and SLA changes are not easily solved with a rule engine and would take a lot of time to develop automation for.
The same philosophy applied to invoice reconciliation. Automation is able to search for discrepancies, match rate line items, and pull exceptions. Still, the decision about disputed line amounts, especially in high-dollar shipments, was left to manual review. The system was advanced enough to provide an answer for the dispute, but we solved the problem by eliminating the risk for a highly valued shipment in exchange for a 10-minute review.
The automation systems we put in place focused on managing the volume of work. Our staff was able to manage the variance. Anything outside a defined confidence threshold was sent to a manual queue. This served as a safeguard against an unseen breakdown. Automated systems might make a decision on a transaction but would not notice when the decision was incorrect until the client raised it weeks later.
We never wanted fully automated systems. We wanted to be able to trust our systems. Trust comes from the edge, not the center.
Drawing from your NLP work on carrier contracts, what data asset or model has given you a durable competitive edge in logistics management, and how did it change daily operations?
The biggest advantage we can get from a data asset isn’t a new dashboard or a new predictive tool. It’s a structured, machine-readable version of something that has always been lodged in email: carrier contracts.
Enterprise shippers receive carrier rate sheets and contracts via email. These are often PDFs or other forms of attachments. Traditionally, you have to manually download, parse, and upload them into the system to perform any deviation calculations. For large tech carriers, the problem is worse because they do not log into the system. The data sits in emails until someone attends to it.
We are changing this with our NLP pipeline. It performs tasks that the reconciliation system currently requires day-to-day operational involvement to complete. It fully automates deviation calculations by ingesting contracts and rate structures from emails and piping them into the reconciliation system.
For clients with hundreds of carrier relationships, this actually changes the way their finance and logistics teams operate, as it is no longer a highly manual process.
Automating the pipelining of contracts and rate structures—from where they live in the real world (email) to where they are needed (the reconciliation and variances system)—gives them an edge over their competitors. This is our competitive advantage.
As a PM who runs A/B tests, what single change to delivery promises, SLA framing, or return policies most lifted conversions for a logistics product, and which metric proved it?
One of the biggest factors affecting conversion rate in a logistics product is not a change to the user interface, nor is it a change to the price. It is about how specific we are with our delivery promise.
We ran an A/B test for delivery estimates with the end customer. We compared a general estimate (Delivery in 3–5 business days) to a specific, confidence-scored delivery promise (Arriving by Thursday, 4 p.m.). The version with the specific promise showed a substantial increase in checkout conversion, and, more importantly, a substantial decrease in “Where is my order?” requests, which are a significant cost associated with the general delivery SLA.
The metric that proved the impact of the more specific delivery promise was the first-contact resolution rate for delivery inquiries. When we deliver general estimates, customers will, of course, keep asking for updates. By delivering specific estimates, we eliminate support requests and increase NPS.
The insight applies to all logistics. In logistics, anxiety is the conversion killer. Customers don’t give up on a product because delivery is slow. Customers give up on a product because they do not trust the delivery promise. A specific delivery estimate shows operational confidence. A specific delivery window says to a customer we know where your order is.
The most difficult part of this test was changing operations, agreeing to the new promise window. More than anything, this was a change to forecast accuracy.
This is what a great A/B test achieves. It improves the system by acknowledging the constraint.
When scaling a last‑mile capability from one lane or city to many, what operational constraint surprised you most, and how did you adapt the product roadmap?
The most unexpected challenge we faced when we began scaling wasn’t a traditional challenge: it was operational variance. Sameness in customers, products, and logic mattered little; it depended on the city we were operating in. This operational variance meant everything could change.
At Locus.sh, we took a client from a pilot program in Lucknow and developed a Pan-India rollout. The routing logic we developed worked in Lucknow because delivery density, carrier behavior, and the quality of addresses all aligned with our assumptions. However, when we took our operations to Kolkata, the same logic began to fail—not disastrously, but in a consistent way. Traffic, addressing systems, and carrier behaviors were all different.
The short-term fix was to patch it. The quickest way to handle Lucknow’s differences was to add a config flag so Kolkata was treated as a special case. Unfortunately, this needed to be done in 10 different cities.
This required us to change our plans. Instead of implementing the features we had planned, we spent the next sprint building the ability to adjust. This included flexible routing constraints, region-level parameters, and, most importantly, feedback loops that allowed the ops team to flag when there was a divergence between how the system was behaving and how it was operationalized. Patching the system on a city-by-city basis led us to a more flexible, adaptable, and less opinionated system.
What I learned after that pilot rollout: your pilot program is the proof of your idea; scaling the program is the proof of your assumptions. The first assumptions that are proven are often the ones you are not conscious of.
For product managers entering logistics, what is one micro‑metric they should instrument on day one to avoid costly misreads later in supply‑chain performance?
Rate of exceptions on day one. Not the total delivery success rate — the rate of exceptions.
Many PMs interested in logistics focus on delivery numbers: on-time deliveries, fulfillment ratios, SLA compliance. These metrics are critical, but they are all lagging indicators. By the time they affect delivery numbers, the issues have already caused disputes, frustrated clients, and an ops team in crisis.
The rate of exceptions gives you a metric that is both more timely and more candid: how often does your system encounter an unsolvable issue, like a failed geocode, a carrier that abandoned a status update, an order that has missed a routing deadline, or an address that cannot be read. These are small operational issues in your system; in aggregate, they represent where the operational system and your product assumptions are in conflict.
I saw this firsthand while I spent time across multiple cities at Locus.sh. On the surface, our success metrics appeared on track, but the exception rate was increasing in several target cities — an early warning sign of cross-city operational challenges that forced us to reshape the entire roadmap.
If you only capture metrics of success, you will only see costly metrics of failure.
The rate of exceptions is not a vanity metric. It’s the equivalent of a product health check in logistics — the edge-case scenarios that really stress a system are not edge cases. In this field, they represent a meaningful portion of the volume, each and every day.
Thanks for sharing your knowledge and expertise. Is there anything else you'd like to add?
If I could say one thing to readers, it would be this: logistics is one of the final great frontiers in product thinking.
The stakes are high in this industry. A delivery failure is not an abstract statistic: it is someone missing their medicine, a shipment that is important to a business being delayed, and a broken promise to a customer. There is real complexity and messy data. There is a huge difference between what will work in a demo and what will work at 3 a.m. in a tier-3 city.
That real complexity makes this industry a great one to build in.
I have spent the past five years working with warehouse teams, carrier ops, enterprise clients, and engineers to close the chasm between the neat product thinking and the messy reality of logistics. It has only made me more convinced that opportunities in this area are vast and unfilled. I am talking about:
- true regional, adaptive, variance-type automation,
- frictionless reconciliation at scale between shippers and carriers,
- making last-mile logistics execution truly self-correcting with AI.
If any of this interests you, let’s connect.
The best logistics products are those designed by people in the field who know what will break.