Salescode never planned to build a Distributor Management System. It kept losing enterprise deals without one. I owned the 0→1 build — discovery to launch — and measured success by the one number that can't be faked: the share of orders processed end-to-end in the system.
I took a category Salescode had never built — with no public playbook to copy (no G2 pages, no teardowns) — from primary research to a shipped product live with Coca-Cola, Cavin Kare, NIIne and App Passeo. The hardest lesson wasn't technical: our cleaner UI was rejected by the people who'd use it most, and fixing that reshaped how I think about "better."
Salescode had a strong Sales Force Automation and eB2B product. But enterprise FMCG buyers increasingly wanted one vendor for the whole chain — SFA, eB2B and a Distributor Management System. Without a DMS, we were losing deals we should have won.
The catch: DMS isn't a well-documented category. There were no comparison pages, no public teardowns, no competitor demos to learn from. The product intelligence simply wasn't out there to borrow. Whatever we built would have to come from primary research — from sitting with the people who run distribution every day.
I spent four weeks embedded with distributors, sales heads, regional managers and finance teams. What I found mattered more than any feature list:
The real system was Excel + WhatsApp + phone calls. Distributors weren't intimidated by software — they were fluent in dense, tabular interfaces and fast in them. Finance needed audit trails, not flexibility. Field reps needed scheme visibility in low-connectivity environments. And sales heads were quietly exhausted from being human middleware — relaying orders, approvals and corrections by hand.
0→1 is mostly choosing what not to do. These four calls defined the build:
Finance lives or dies on trust. I made invoices immutable, with a corrections log — never free-form edits. Slightly less convenient, dramatically more auditable. A system finance could actually sign off on.
Permissions bolted on later become a security debt you never repay. I designed the product role-first — distributor, rep, sales head, finance — so governance was structural, not an afterthought.
Field reps and back-office staff don't work the same way. Rather than force a single responsive layout, I committed to phone-first for the field, desktop-first for admin and finance — each surface true to its user.
Logins and DAU are vanity — easy to hit, easy to fake. I defined adoption as the percentage of orders processed end-to-end in the DMS. You can't game it without actually using the product the way it's meant to be used.
Cavin Kare was our first pilot. The feedback was blunt — and it stung, because it targeted the thing we were proudest of: the clean, modern UI.
“It looks nicer. But it's slower. Give me back the dense grid — I know exactly where everything is.”— paraphrased from Cavin Kare pilot feedback
Two things had gone wrong. First, in chasing feature parity with the legacy DMS, we'd made several transactional flows more complex than they needed to be. Second — and this was the deeper miss — we'd assumed a cleaner interface was an upgrade. For power users entering 50–80 line orders a day, all that whitespace was friction. Density wasn't the problem. Density was the feature.
I didn't pick a side. We did both: simplified the critical transactional flows (order entry, scheme application, approval), and shipped a Classic / Density mode — a tabular, keyboard-friendly power-user view that sits alongside the cleaner default and toggles per user. Below is that resolution, on the Create New Order screen — the same order, built two ways:
The DMS went live with four enterprise customers in its first year. Manual order tracking dropped 30–35%; scheme and sales visibility improved ~40%. Most importantly, on the metric I'd chosen up front — orders processed end-to-end in the system — adoption held above target for two consecutive quarters after launch. Not a launch spike. A behaviour that stayed.
A DMS that records what happened is table stakes. The moat is a DMS that tells you what's about to happen. The roadmap I scoped pushes the product toward AI/ML — and the clearest first bet is outlet attrition prediction.
The product thinking matters more than the model. The signal is already in the data we now capture: declining order frequency, shrinking basket value, SKUs an outlet has quietly stopped buying. What the rep sees isn't a dashboard — it's a short, ranked “at-risk outlets” list inside their daily route, each with a one-line why. The guardrail is trust: precision has to be high enough that reps act on the flag instead of learning to ignore it. And the way I'd measure it isn't model accuracy — it's whether flagged outlets get retained versus a holdout, and whether reps actually act on the nudge.
Test density earlier. The Cavin Kare lesson was avoidable — I'd put the dense-vs-clean question in front of real distributors weeks sooner, before it was a launch risk.
Separate "feature parity" from "workflow parity." Matching the old system's feature list isn't the goal; matching how the work actually flows is. I now treat those as two different specs.
Instrument behaviour from day one. Orders-processed was the right headline metric, but I'd add richer drop-off and behavioural signals from the start — so the next "we got it wrong" shows up in the data before it shows up in a pilot.
Working backward from an ungameable adoption metric, role-first governance, and two honest UI paradigms — adoption stayed above target for two quarters.
The clean UI was rejected by power users, and feature-parity made flows too complex. Caught in pilot, not pre-pilot — later than I'd like.
Earlier density testing, a clear split between feature parity and workflow parity, and behavioural instrumentation from day one.
Not logins. Percentage of orders processed end-to-end in the DMS — and, for the AI roadmap, retention lift on flagged outlets vs a holdout.