Separate the need from the shape

You know by now that the ticket in front of you is somebody’s solution rather than their problem. This chapter is about what to do in the next ten minutes, which is a mechanical exercise rather than another conversation.

Take the request and split it into two lines.

Shape: add a CSV export to the invoices page Need: I cannot tell whether our numbers match the ones finance has

The split takes a minute and it changes what is on the table. The first line has exactly one implementation. The second has at least four, and one of them is probably better and smaller than what was asked for.

This is a documented requirements rule, not a preference

It is worth knowing that the discipline wrote this down decades before anybody was arguing about it in a Slack thread.

ISO/IEC/IEEE 29148, the international standard for requirements engineering, lists Implementation Free among the required characteristics of a well-formed requirement. The reasoning it gives is exactly the cost you are trying to avoid: when the solution is written into the requirement, potential design solutions may be overlooked or eliminated before anyone has priced them.

That is the whole argument. Not that stakeholders should stop suggesting solutions, which they will not and should not. Just that a suggestion which arrives inside the requirement stops being a suggestion and starts being a constraint, silently, without anyone deciding that it should.

The move

Write the need on one line and the shape on another, then put two more shapes against the same need before you cost anything.

The second half is what makes it real. A split with only one shape under it is a relabelling exercise. Three shapes forces the comparison that the original ticket had already foreclosed.

AS FILED                    SPLIT, THEN WIDENED

"Add a CSV export           NEED  I can't tell whether our numbers
 to the invoices page"            match the ones finance has

one shape                   SHAPES
one cost                     a  CSV export            ~3 days
one decision, already         b  a totals row on the
made by someone who              existing page        ~4 hours
was not costing it            c  a reconciliation view
                                 showing both sides
                                 and the difference   ~1 week
                              d  a nightly email with
                                 the delta, if any    ~2 days

                            b answers the need on Thursday.
                            c answers it permanently.
                            a answers it by making her
                              do the comparison herself,
                              which is the part she asked
                              you to fix.

Look at what option A actually does. The CSV gives her the numbers in a file so she can compare them in a spreadsheet, which is precisely the manual work the request exists to escape. It is the most expensive option except one, and it is the only one that does not answer the need.

That is not a rare outcome. It is the normal outcome, because the person writing the ticket was picturing the tool they already know how to use.

Where the shapes come from

You do not need to be inventive. Three questions generate most of the alternatives.

Can the answer be shown instead of exported? Most export requests are display requests that gave up.

Can it be pushed instead of pulled? If somebody checks a thing on a schedule, the schedule is a notification waiting to happen.

Can the difference be computed rather than the data delivered? If they are comparing two things, compute the comparison. This is the option people almost never ask for and almost always prefer.

What it costs

Widening looks like stalling. You have been handed a clear request and you have responded with options, which reads as delay to somebody who wanted a yes. Keep it to one message and put a recommendation in it. Options without a recommendation is where this move earns its bad reputation.

And sometimes the shape is load-bearing. Occasionally the CSV is genuinely the point, because their accountant requires a file, or a system downstream ingests it, or there is a regulation. Ask before you widen. Is the file itself required by anything, or is it how you’d get to the answer? takes one line and saves you proposing four alternatives to a legal obligation.

And the cost estimates in your comparison are guesses, which is a problem the next part of this book is about. Use them to rank, not to promise.

Try this week

Take the next request that arrives with a solution in it and reply with the split, in two lines, before you do anything else:

Just so I build the right thing: the need is that you can’t tell whether our numbers match finance’s. The shape you’ve suggested is a CSV export. Is that a fair split?

Almost nobody objects to this, because you have restated their problem accurately and taken their suggestion seriously in the same sentence.

Then spend fifteen minutes writing two more shapes against that need, with rough costs, and send them with your pick. You will find the conversation stops being about whether you will build the export and starts being about which thing to build, which is a conversation you are now in.