Short answer: people bring you solutions, not requirements, and your job is to walk backwards from the solution to the problem without making anyone feel interrogated. “Can you add a checkbox to the Opportunity” is the end of a thought process you did not see. Ask what happens today, what goes wrong, and how often, and roughly a third of requests turn out to be something else entirely. Saying no is a skill, and the useful version always comes with an alternative.
Getting from request to requirement
Four questions, asked in a friendly tone, will do most of the work:
- “Walk me through what you do today.” Not what the process says. What they actually do, including the spreadsheet.
- “What goes wrong when it goes wrong?” This gets you the problem, and it is usually not the one in the request.
- “How often, and how much does it cost when it happens?” Separates a daily irritation from a twice-yearly annoyance. Both are real. Only one justifies a fortnight.
- “Who else is affected?” Finds the people who will complain after you build it.
Then read it back in your own words and let them correct you. Being slightly wrong out loud is the fastest way to get precision, because people who cannot describe a process from scratch will happily fix your version of it.
Watch them work if you can. Twenty minutes sitting with a service agent tells you more than three requirements workshops, and you will see the workaround they have stopped noticing they do.
Where requests come from
Knowing the origin changes the response:
- A single person’s irritation. Legitimate and often small. Ask whether anyone else has the problem before building anything shared.
- A manager wanting visibility. Usually turns into a reporting question, not a data entry one. Resist adding fields that exist to make a dashboard work.
- Something broke and this is the guard rail. Check whether the underlying cause is fixable. Validation rules accumulate as scar tissue from incidents nobody addressed.
- A process nobody has questioned in eight years. The best opportunities and the most political conversations.
Saying no usefully
A flat no gets routed around. Someone will ask a different admin, or build it in a spreadsheet, and you will find out in a year. Three forms that work:
The alternative. “I would not add a field for that, because it will be empty on most records. What I can do is X, and you would get the same report.” Most people want the outcome and are indifferent to the mechanism.
The cost, stated plainly. “That is about three weeks, which means the renewals work moves to next quarter. Which do you want first?” This converts a refusal into a decision, and it puts the decision with the person who owns the priorities.
The smaller version. “We can do the reporting part this sprint and see whether the automation is still needed.” A surprising share of requests evaporate once the reporting exists.
What does not work: technical explanations. Governor limits, sharing recalculation and the order of execution are your problems, not theirs, and using them as a reason reads as obstruction. Translate into time, risk or cost to the business.
Keeping the relationship
Show something early and rough. A half-built screen in a sandbox generates better feedback than a document, and people are far more willing to say “that is not right” about something that clearly took an hour than about something that clearly took a month.
Tell them when their thing is not happening. The damage comes from silence, not from the delay. A request sitting in a backlog with no update for four months is how a stakeholder decides the Salesforce team does not deliver.
Go back after it ships. Two weeks later, ask whether they are using it. Sometimes they are not, and finding out is more valuable than the compliment you were hoping for.
Frequently asked
How do I handle conflicting requirements from two teams? Do not arbitrate. Put the trade-off in front of both, with the cost of each option, and make someone with authority choose. Deciding yourself makes you the reason one team did not get what it wanted.
What if they insist on a bad solution? Build it if it is reversible and the relationship matters. Write down the concern and the date. If it is not reversible, escalate before building, not after.
How much detail should a requirement have? Enough that someone can tell whether it works. Behaviour and examples, particularly the edge cases the business already knows about and never mentions.
