Write a Useful Purchase Specification

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. A 30-minute working session A suggested agenda for a requester and procurement partner; adapt the timing to the discussion. Describe the outcome — 5 minutes Ask what should work better when the purchase is in use. Name the people, work area, and task affected. 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. 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. 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. 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. 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? 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. 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. 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.