A good part of my week is talking to the people who need the software. In enterprise that's rarely someone with a credit card. It's an editorial team, a legal department, a product owner on another floor or in another country. They know the domain far better than I do, and they come with requests.
The requests arrive as solutions. Add a checkbox here. Put the save button at the top as well. Make the date a dropdown. Export this column too. And for the first year or so of leading the team, my answers were some flavour of yes, no, or we'll see.
Two of those three are bad answers. I'll get to which.
The question before the answer
Every request is a solution to a problem I haven't been told. So before I answer anything I ask one thing: what happens today, without it?
"Put a second save button at the top." What happens today is that the form is long, they fill in the top half, scroll up to check something, and can't find the button. The request is a second button. The problem is a form where the button leaves the screen. A bar that stays put fixes it, and so would a shorter form, and neither is a second button.
"Show the effective date in red." What happens today is that a rule changes, the document gets a new date, and nobody notices until a customer does. So a change in the data doesn't reach a person. That calls for a notification or a filter, and red text would have been a day's work that fixed nothing.
A request is a solution. I want the problem.
Once I have the problem, the answer is one of three, and all three start with yes.
Yes, and it's small
Sometimes it is a checkbox. The problem is real, the fix is an afternoon, and nothing else moves. Then the answer is yes, with a date, and the date is soon.
I used to pad these. Let me think about it, I'll put it in the backlog, we'll pick it up next sprint. That turns an afternoon into a month, and the person on the other side learns that asking for small things is slow. Small yeses are cheap, and they buy the trust I spend on the other two answers.
Yes, instead of
The request is bigger than an afternoon and the plan is full. The answer is still yes, and here's what comes out of the plan to make room.
This is the one that changed the conversations most. A no is my decision and they argue with me. A yes instead of is their decision and they argue with themselves. More often than I expected, they look at what it would push out and say the new thing can wait. Sometimes they say the old thing can wait, and they're right, they know what matters this quarter.
What I need from them is a choice. What they get from me is that the plan stays honest: nothing gets added to it without something leaving.
Yes, and here's what it costs
The request is big and nothing in the plan can move. Then the answer is the cost, and the cost has two parts.
The first is the work, as a range, with what I don't know said out loud. "Two to four weeks, and the four is if the export library can't do the layout you drew." The unknown is the useful part. A number without it is a promise I can't keep.
The second part is the one nobody budgets for: the cost of having it. A new option is a thing to test on every release from now on, a line in the documentation, a setting that someone will set wrong and open a ticket about. A checkbox is never a checkbox. I say so once, without making a speech of it, and let them decide with the whole price in front of them.
The three answers side by side:
| Answer | What they hear | What I need from them |
|---|---|---|
| Yes, and it's small | It's coming, with a date | Nothing |
| Yes, instead of | It's possible, something else waits | A choice |
| Yes, and here's what it costs | It's possible, here's the price | A budget, or a no |
The no that's still in there
Some things get a plain no. The request would break a rule the product exists to follow, which in a regulatory application happens more than you'd think. Or it would quietly harm the other users. Or it's a solution to a problem that a two minute conversation dissolved.
The no is said once, with the reason, and with the nearest thing I can offer. Then I stop. A no that gets re-explained three times is a no that's being negotiated, and nobody enjoys that.
The answer I banned
We'll see. We'll look into it. Let me get back to you.
That's a no that costs the other person hope. They go back to their team and say it's being looked at, and three months later they ask how the looking is going, and I have to say the no I should have said in the meeting. Every one of these I gave in my first year came back as an awkward conversation in my second.
If I don't know yet, I say when I will know, and I give a date.