Origin story, principles, and the gaps I haven't closed.
Before I built software, I was the person stuck using it.
My first real job out of college was forecasting inventory for a pet products manufacturer. About 2,000 SKUs across accounts like Petco and PetSmart. One year into a three-year stint there, we implemented a much-needed forecasting system, and I ended up being the one who trained the sales planners on it.
The software worked fine. It calculated what it was supposed to calculate. But it required the sales planners to enter data in an order that didn't match how they thought about their accounts, and it buried the one screen they actually needed about six clicks deep. So they kept their real numbers in spreadsheets and typed things into the system afterward, mostly to stop it from nagging them. Everyone had a "shadow system." Nobody brought it up in the status meetings.
A system can be completely correct and still fail, and the people working around it are not the problem.
That's where I learned the thing that's shaped everything since: a system can be completely correct and still fail, and the people working around it are not the problem.
Ten years in the Salesforce ecosystem since then. Consultant, admin, lead, and now director of technical solutions at a company building CRM for architecture, engineering, and construction firms. The tools got a lot better. The spreadsheet problem never really went away.
The usual diagnosis for low adoption is that users need more training, or that leadership needs to push harder. That's almost always backwards. If people are routing around your system, they're telling you something accurate about it, and no amount of mandatory training fixes a tool that fights the way the work actually happens.
This matters more than it sounds, because adoption is the entire ROI argument. A beautifully architected system nobody uses returns zero. There's no version of the math where elegance makes up for people not touching it.
There's a specific way this goes wrong, and I've watched it at a lot of companies. Leadership decides on a process, has it built without talking to the people who will live in it, and then can't work out why nobody adopted it. Years later, that system is usually abandoned for the next one, and the cycle repeats. The build is usually fine. It just answers a question nobody on the floor was asking.
Most consultants I've worked with struggle to push back on that, and I understand why. The person specifying the process is the person approving the invoice. But the job isn't to build what was specified, it's to get the real requirement named out loud, and that usually means persuading whoever's in charge that the people doing the work should have a say in how it gets done. The conversation is uncomfortable, but it makes the whole project faster.
So the question I keep coming back to isn't can we build this? The answer is almost always yes, which is sort of the problem. It's will this survive contact with the person who has to use it 40 times a week?
Automating a process you don't understand doesn't fix the process. It makes it break faster, and somewhere harder to find.
Most requests arrive already shaped as solutions. We need a field for this. We need an approval step here. The need underneath is real, but the translation lost something on the way. So I ask two questions, more or less always: why do you want this, and what are you going to do with the data once you have it?
That isn't obstruction, it's the thing I was hired for. Clients can tell when they're talking to an order taker, and they don't get much for their money from one. Often those two questions lead someone to talk themselves out of the request mid-sentence, which saves everybody the build, the maintenance, and the tech debt. Just as often the honest answer is that the platform already does this out of the box, and the right response is can I show you, which is a better outcome than anything I would have built.
The corollary is that I spend a lot of time with the people entering the data, not just the people reporting on it. Leadership usually wants a number, which is legitimate and frequently just a dashboard. Whether that number is any good depends entirely on the people filling in the fields, and those people go quiet the second their boss joins the call. Getting them talking again is most of the job.
Building software is part engineering and part judgment, and the judgment half is hard to discuss without sounding precious. It's real, though, and it's a lot of what separates a system people tolerate from one they like.
Most of it is small. If something takes two clicks and I can make it take one, I'll go find the way. Not because a single click costs anything, but because 50 of them a day is how a tool starts to feel like a tax. The exception is when the friction is doing a job. A confirmation step in front of something irreversible is a click worth keeping, and stripping it out to hit a number is how you get a fast interface and a busy support queue.
The other half is that details are how trust gets built, usually before anyone can explain why. If a client asks me for an email template, they're getting one with their branding on it, laid out properly, instead of a plain text block that technically satisfies the request. It costs me very little, and it changes how they feel about the entire system.
The discipline is knowing which details carry that weight and which are just me enjoying myself. A branded template the client can maintain on their own is a gift. One so elaborate they have to call me every time it needs a change is a liability with nice typography.
The best version of this is when one decision serves both audiences and nobody gives anything up.
On a billing project, a stakeholder asked for a simple flag. Hot or Not Hot, just a checkbox. 20-minute build, and I nearly just did it. But when I asked what they'd do with it, the answer was that they wanted to group their billing chart by it. A checkbox gives you two values and nowhere to go. What they needed was a three-category formula field: Won or In Progress, Hot Prospect, and Open Opportunity. Less work for the person entering data, since it derived from values already on the record, and a real groupable dimension for the person running the chart.
Small example, but it's the whole idea. The question got asked before the field got built, which is the only reason it worked.
A number on a dashboard is a claim. If somebody can't see where it came from, they won't act on it, and eventually they stop opening the report.
I watched this happen in a pursuit review meeting. People kept leaving the screen mid-conversation, and most of it wasn't to find missing data. It was verification. Someone would look at a total and then go check whether it was accurate.
The numbers themselves are rarely the hard part. Summing weighted revenue by region is arithmetic, and any competent build gets it right. What's hard is presenting a total that survives somebody senior asking where it came from. A figure with no visible derivation isn't usable in a room, however accurate it is. It just moves the argument into a different window.
So I try to build the explanation next to the number. Totals you can trace, drill-down that doesn't lose your place, and the ability to correct something on the spot when the room agrees it's wrong, rather than writing it down to fix later, which nobody ever does.
None of the soft stuff pays off if the technical work underneath it is sloppy.
I work on a managed package, so the data model is already sitting in the client's org. Real objects, real relationships, real API names. Reading it is a discovery activity, not a chore you get through before the real work starts. On one build, the constraint that governed the entire feature turned out to be a schema fact nobody had mentioned in a single meeting: a project supported exactly one client account. That same org also had a field that looked perfectly relevant and modeled something completely different, which is the kind of thing that quietly eats a week if you trust the label.
Nobody says any of this out loud in a requirements call. You find it by opening Object Manager, which is deeply unglamorous and saves an enormous amount of pain.
Half of what shows up in UAT as a "requirement change" was never a requirement change. It was something nobody checked.
I also try not to call anything done until it's testable. Given a project with two client accounts, when the estimator marks one as the winner, then the others move to inactive history. If I can't write that sentence, I don't understand the requirement well enough to build it yet.
Some conflicts aren't mine to resolve. When two people at the same level disagree about a business rule, not leadership versus the floor but two owners of different pieces of the same policy, the move is to lay out the tradeoffs, say plainly who owns the decision, log it, and keep going.
That one took me a while. The instinct is to be decisive and unblock the room, and it feels great for about six weeks. Then UAT arrives, and everybody discovers a decision got made that nobody actually agreed to, usually by me, usually in a meeting no one remembers being in.
I argue that adoption drives return, and I can't yet hand you a chart that proves it.
What I have instead is a pattern. I haven't lost many clients, and the ones I lost all went the same way: they couldn't get their teams to use the system. The reports came out useless because the data underneath them was thin, the cleanup quote was expensive, and by then nobody trusted the numbers enough to fund fixing them. Different industries, different builds, same ending every time.
I hear the other half of it constantly, from people who show up with a bad Salesforce experience already behind them. Nearly always the same two complaints: the system wasn't intuitive, or they couldn't get to the data they needed without asking someone for help. I used to assume the team before me had been careless. I've since built enough of these to know that's usually not it. They were handed a specification by people who weren't going to use the thing, and they built what they were told.
What I'm short on is the quantitative version. Active users before and after, cycle time, the support tickets that stopped arriving. It's a strange gap for somebody whose whole argument leans on the data, so I've started instrumenting properly instead of leaning on the pattern. I'd rather admit that out loud than build a whole site around adoption and ROI without a single number of my own on it.
If you've solved this well on your own team, I'd like to hear how you did it.