How I Work
The answer is almost always yes. The questions are the job.
Before I built software, I was the person stuck using it.
My first real job out of college was doing sales analysis and forecasting the inventory needs for a pet products manufacturer. I managed the sales forecast that drove the inventory levels and purchasing decisions of about 2,000 SKUs across accounts like Petco and PetSmart. If you walked into a PetSmart to pick up one of those black and pink tiger print dog collars between 2013 and 2015 and they were all out of stock, it was likely due to one of my poor decisions (sorry). One year into a three-year stint there, we implemented a much-needed forecasting system, and I ended up being the one who trained and led the other divisional sales planners in using the software.
The software itself worked fine. The forecasting engine was genuinely incredible, technically. But the UI was clunky. 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 a core truth of software design that I still hold onto: 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 later, I have found that the answer to the "can we build it?" question is a more resounding "yes!" than it's ever been. The questions below are the ones that didn't get easier. They're where I spend my time, and they're the reason the things I build get used.
Will anyone actually use this?
The usual diagnosis for low adoption is that users need more training, or better documentation, or that leadership needs to push harder and start handing out mandates to use the software. That's almost always backwards. If people are looking for ways to work around your system, they're actually pointing out a hard truth about it, and no amount of mandatory training (or ego) fixes a tool that fights the way the work actually happens.
This matters more than it sounds, because Salesforce is not an inexpensive investment and adoption is the entire ROI argument. A beautifully architected system nobody uses returns zero. Those KPIs that Salesforce promises you will help steer your business? They're worth nothing if the real data is in spreadsheets scattered across your team's computers. There's no version of the math where elegance makes up for people not touching it.
There's a specific way this usually goes wrong, and I've watched it at a lot of companies across many different industries. Leadership decides on a process because it drives a KPI that they say that they need, the process gets built without the input of the people who will live in it every day, and then can't figure out why everyone hates 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 that nobody actually using it was asking. (Every client I've lost, I lost this way.)
Most consultants I've worked with struggle to push back on that, and it's easy to understand why. The person defining the requirements and 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 outcome more valuable.
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?"
The answer is almost always yes, which is sort of the problem.
Design the solution to answer the real question. It might sound obvious, but almost without fail, a few weeks into any Salesforce implementation the requests shift from "is it possible to do this?" or "what are our options?" to "can you add a field for this?" And it makes sense in the space I operate in: convincing spreadsheet users to adopt a system. The hit of dopamine that comes from populating a cell or checking a box is undeniable. But maybe not having to do that at all in favor of a better or more efficient process is better in the long run. So my alarm bells go off when I hear questions like that, because it means the people being paid to be the experts need to step back in and figure out the best way to actually build it.
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: 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.
Show your work. Trust is king. A number on a dashboard is a claim. If somebody can't see where it came from, they won't trust it enough to 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 was verification, not missing data. So I build the explanation next to the number. Totals you can trace, drill-down that doesn't lose your place, correction on the spot when the room agrees it's wrong. It's the same reason my card scanner keeps the raw scanned text visible under a tap: the claim and its source, one screen apart.
Is it good, or just good enough?
It's almost a meme at this point, but the rise in my use of AI as a tool to build things has me often thinking about the 60 Minutes interview of Rick Rubin when Anderson Cooper quips that "exactly what he does and how is difficult to describe." Eventually Rick says "I have no technical ability and I know nothing about music" and Anderson asks "so what are you being paid for?" Rick's response highlights the value that people in roles like mine will continue to hold through to the other side of the AI revolution: "the confidence that I have in my taste and my ability to express what I feel has proven helpful for artists". The confidence that I have in my taste and my ability to make impactful decisions positions me well for whatever comes next.
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 details are how trust gets built, usually before anyone can explain why. 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.
Do I understand it yet?
Automating a process you don't understand doesn't fix the process. It makes it break faster, and somewhere harder to find.
I mentioned it earlier, but I spend a lot of time in that phase of a customer relationship where 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.
Read the schema before you design anything. 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. 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. 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 asked about.
Understanding includes the vocabulary. Understanding the language is a prerequisite to truly understanding the business. You also can't communicate an outcome's value or a decision's weight if you don't understand the meaning of the words. One of the bullet points we used to sell TrebleHook on was that we know the AEC industry. We've pre-built our solution to meet the needs of the industry and that saves 80% of the time it takes to implement Salesforce. Luckily this is something you can start doing before you walk into the room. (I wrote the field guide.)
If I can't write the test, I don't understand it yet. 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.
Whose call is this?
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, and it earned its own article. 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.
The division of labor that seems to work best looks like this: technical decisions are mine, business rules are not. Formula field or flow, how the data model handles a many-to-many, that's my job and handing it to a committee is ducking it. What the policy should be, who gets to override what, which number wins: those belong to the people who have to live with them. I advise hard, and then I make sure the right person decides.
What's the machine's job?
The newest tool in the kit is an AI coding agent. (Mine is named Claudio. There's a whole story.) A real share of what I've shipped this year was built in partnership with it, including things in frameworks I was still learning, on timelines I couldn't have hit alone.
I don't think of this as "vibe coding," where you describe a feeling and ship whatever comes back. The division of labor is deliberate. I bring the architecture, the industry judgment, and the testing on real hardware with real data. The agent brings speed and range in code I couldn't yet write myself. I can tell whether its output is right because I know what the thing is supposed to do, and that sentence is doing all the work. Without it, this way of building is just gambling with better graphics.
The design rule that makes the partnership safe: let the machine be wrong where it's cheap to be wrong. Fast guesses fill the screen, but the raw inputs stay visible, every field stays editable, and everything can be undone in a tap. When a mistake costs one tap to see and one tap to take back, you can move fast without betting the data on it. When a mistake saves silently into a system people trust, you get the shadow spreadsheets from my first job.
And the machine's work is held to the same standard as anyone's: understand it before you automate it applies to the agent too.
If I can't explain what the agent built, it doesn't ship.
I'm not a hoarder. I'm not trying to gatekeep any of the lessons I've been learning while exploring the world of AI. I have weekly meetings with my team where we showcase our builds and teach each other new ways of thinking with AI. It's incredible to see my own passion and excitement reflected in each of my teammates. They have built some truly inspiring solutions using some of the lessons we're learning together now.
What I'm still working on
The evidence I lean on 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.
The thing I'm still chasing is numbers on the AI work: what the partnership actually saves, not a feeling.
If you've solved this well on your own team, I'd like to hear how you did it.