Bring the decision hidden inside the feature request

“We need a course comparison app” sounds like a useful project brief. It does not yet identify who compares the courses, what makes one option acceptable or what the person must do with the result. The first conversation should uncover that decision before anyone estimates a feature list.

In this fictional example, an employer wants three staff members to attend a practical programme. The training office already publishes clear descriptions and two sets of dates. The employer's difficulty is not finding those pages. It is preparing a staff-release proposal that its operations manager can assess without leaving a shift uncovered.

Watch the proposal being assembled

The reviewer asks the coordinator to reconstruct the last attempt with invented staff references. The coordinator opens both course schedules, checks the work rota, copies dates into an email and then waits while the manager works out who would still be available.

The request for a comparison app came from the copying. The consequential decision sits elsewhere: whether a proposed attendance pattern is workable for the employer. Course eligibility, available places and acceptance still belong to the training provider. The employer can approve time away from work without establishing any of those facts.

This distinction changes what the project needs to show. A polished comparison of course features would leave the manager doing the same shift calculation outside the application.

Put the actual alternatives on one page

The coordinator prepares proposal R-14. Programme option A runs on two Mondays; option B runs on two Thursdays. In the fixture, both published schedules have been checked against their current source pages. The employer's rota requires qualified cover for each attendee's assigned duties on both course days. The three staff members have different responsibilities and are not interchangeable simply because they share a shift.

The result is deliberately incomplete in one place. Assigning S-3 to whichever option has fewer names would produce a tidier screen but contradict the actual operating requirement. The proposal records the uncovered shift and the person who must resolve it.

The training-office enquiry then asks about two proposed attendees and the relevant course dates. It does not present three confirmed registrations or claim that the employer's internal approval establishes a place.

Choose a first scope that serves the decision

The team compares three possibilities. A public course comparison page would improve browsing but not show the employer's rota dependency. A full scheduling engine would require detailed coverage rules, qualifications and changing staff availability that have not been scoped. A structured proposal worksheet can make the current decision reviewable with the information already available.

The owner selects the worksheet and a linked enquiry preparation step. Its first version records the source schedule, proposed attendees, relevant cover observation, unresolved constraint and manager's decision. It prepares a clear request for the training office after the employer has reviewed the proposal.

This choice does not promise that a worksheet will solve every future scheduling problem. It addresses the task actually observed. The project can reconsider automation if repeated proposals reveal stable rules, sufficient source access and enough recurring work to justify maintaining them.

Verify the output with its recipient

The manager reviews R-14 without the coordinator explaining it aloud. They can identify the two proposed attendance options and the unresolved shift for S-3. The coordinator can trace each course date to its published source. The training-office message contains the approved proposal rather than the employer's entire internal rota.

As a contrary check, the reviewer removes cover for S-2's second Thursday. The worksheet now shows that proposal as unresolved; it does not silently move S-2 to Mondays or invent a substitute. The unchanged S-1 proposal remains intact. A separate employer proposal does not inherit R-14's staff names or cover notes.

These checks define what a useful first delivery means. They also expose where judgement remains necessary and what private information should stay inside the employer's process.

Prepare your own first conversation

Bring the requested feature, but also bring the decision behind it. Identify its recipient, the alternatives they consider and one reason an apparently convenient choice would be wrong. Use invented or redacted material until an appropriate handling arrangement is agreed.

The request map helps describe that sequence. A development discussion becomes much more concrete when the receiving person can say, “This is enough to make the decision, and this is the question still open.”