Write a useful purchase specification

Use this short workshop to describe the result you need before deciding what to buy. The fictional Northstar Services example follows a team trying to move shared equipment between work areas; the image shows colleagues planning, not that fictional organization.

Colleagues around a whiteboard covered in sticky notes

A 30-minute working session

A suggested agenda for a requester and procurement partner; adapt the timing to the discussion.

  1. 1

    Describe the outcome — 5 minutes

    Ask what should work better when the purchase is in use. Name the people, work area, and task affected.

  2. 2

    Separate must-haves from preferences — 8 minutes

    For each proposed requirement, ask what would prevent the outcome if it were absent. Label useful but negotiable features as preferences.

  3. 3

    Make acceptance observable — 8 minutes

    Agree what someone could see, count, or demonstrate to tell whether each must-have is met. Avoid words such as “easy” unless you define what they mean.

  4. 4

    Surface constraints and open questions — 9 minutes

    Record known boundaries, assumptions, and unresolved points for the procurement partner to explore. Do not turn an assumption into a requirement without checking it.

Worked example: move shared equipment between work areas

Illustrative Northstar Services scenario. The need is the work outcome; the proposed product is only one possible route.

Need, not product

The requester says, “Teams need to move shared equipment between the service and staging areas without carrying it by hand.” This describes the task and intended improvement.

Premature specification

“Buy six electric carts” selects a product and quantity before the team has established whether powered carts suit the routes, loads, storage space, or actual usage.

A more useful starting point

Describe the equipment and typical load to be moved, where it travels, how often the task occurs, and what must be true for staff to move it and park it as part of their work.

Evidence and boundaries

For example, a walkthrough could check that a proposed option carries the stated typical load along the route and fits the identified parking area. The fictional team has not yet confirmed route dimensions or whether powered movement is necessary; those remain questions, not requirements.

Four parts of a useful specification

Prompts and examples below are illustrative, not an approved standard. On a phone, read each row as one prompt and one example.

Four parts of a useful specification
Part Ask Illustrative example
Outcome What work should improve, for whom, and where? Move shared equipment between the service and staging areas without carrying it by hand.
Must-haves What conditions are essential for that outcome? Accommodate the typical equipment load and travel the identified route.
Acceptance evidence What could someone observe or demonstrate to check a must-have? A route walkthrough demonstrates the proposed option carrying the stated load and fitting the identified parking area.
Constraints What boundaries, assumptions, or unresolved facts could affect a suitable option? Route dimensions and the need for powered movement are not yet confirmed.

Prompts to test the draft

Use these questions to make the discussion more specific without narrowing the solution too early.

Outcome

Test the outcome

Ask the requester to describe the current task and the difference a successful purchase would make. If the statement names only a product, ask what work that product is meant to support.

  • Who performs the task, and in which work area?
  • What should they be able to do that is difficult today?
Must-haves

Distinguish essential from preferred

Ask what would make an option unsuitable if the feature were missing. Keep a feature as a must-have only when the answer connects it to the stated outcome or a known boundary.

  • Must-have: carries the typical equipment load on the identified route.
  • Preference: powered movement, unless the team confirms it is necessary.
Evidence

Make evidence checkable

Replace broad claims with something a person could verify. For example, replace “easy to use” with a demonstration of the actual movement task by the intended users.

  • Name the activity, setting, and condition to observe.
  • Record who can confirm the requirement and what remains unknown.
Constraints

Bring constraints into view

Separate confirmed boundaries from assumptions. Share unresolved facts with the procurement partner rather than filling gaps with a preferred product specification.

  • Capture known space, route, timing, or compatibility limits.
  • Mark unverified dimensions and quantities as open questions.

Hand off a clear starting point

Share the agreed outcome, must-haves, how each must-have could be checked, and known constraints with your procurement partner. List open questions separately so they can be explored rather than mistaken for settled requirements.

For the Northstar example, the handoff would include the movement task, typical load, route and parking conditions to check, and the unresolved route dimensions and need for powered movement. That gives procurement room to explore suitable options without treating “six electric carts” as a foregone conclusion.

This specification supports a sourcing conversation; it does not replace your organization’s purchase instructions or determine approval. Use your established procurement partner or procurement process for the next step.