An industrial design statement of work questions list can help you decide whether a proposal describes the work your product actually needs. Before signing, clarify the intended outcome, what the team will do, what you will receive, and which decisions or responsibilities remain with your organization. A useful SOW is not just a menu of activities. It is a shared plan for turning an agreed need into defined work and outputs.
Discuss your product development needs
That distinction matters because familiar phase names can hide different commitments. One proposal might use “concept development” for broad exploration and several alternatives. Another might use the same phrase for refining a direction your team has already selected. Neither label tells you enough on its own. Ask for specific activities, decision points, deliverable formats, and exclusions.
Colorado State University Procurement Services recommends describing what the work is, how it will be accomplished, and what is outside the scope. That is a useful standard for reviewing a design proposal too: read its guidance on developing a statement of work. The questions below help you translate that principle into a practical review.
What should the SOW say the project is meant to achieve?
Start with the outcome rather than the activity list. Research, sketching, modeling, and prototype work are means to an end. The proposal should explain which product question or business decision those activities are meant to resolve. A clear outcome gives both sides a way to judge whether the proposed scope is relevant.
What user or business problem are we addressing? Describe the need in plain language. Separate the problem from a solution that has not yet been tested. “Make a smaller dispenser” is a proposed direction; “help users store and operate the dispenser in a crowded bathroom” explains the context behind it.
What decision should this project enable? The decision might be whether to proceed with a product direction, which of several concepts merits further work, or what information is still needed before a larger commitment.
What does success look like at the end? Name observable results, such as a selected concept, a prototype evaluated against named questions, or a defined set of files prepared for a specified next phase.
Where does this engagement end? Is the endpoint an early concept, a tested model, a detailed design package, or defined production-preparation outputs? Avoid assuming that “complete design” means the same thing to every participant.
What is expressly excluded? List adjacent work that is not included, such as packaging, software, testing, regulatory planning, supplier selection, or production support, unless those activities appear in the scope.
Imagine your team wants a handheld device that is easier to use with one hand. The outcome should say whether the engagement will explore grip options, test interaction with representative users, select a direction, or also prepare detailed files. If the proposal only says “design a handheld device,” it does not establish which of those tasks are included or how you will make the next decision.
Ask the firm to connect each proposed activity to a project question. If a task has no clear relationship to an outcome or decision, ask why it is included. If an important product risk has no corresponding activity, ask how it will be addressed or whether it sits outside the work.
Which phases and activities are actually included?
Ask for the sequence of work and the purpose of each phase. A phase name is a label, not a complete description. “Discovery,” for instance, could mean a review of supplied materials, interviews, a market scan, or a working session with your team. A scope that names the actual work lets you assess whether the plan fits your uncertainty.
What activities happen in each phase, and which project question does each answer?
What information, product access, user access, or decisions must your team provide?
How many concepts or alternative directions are included, and how developed will each be?
Are user conversations, competitive reviews, material exploration, or feasibility checks part of the plan?
What event or decision triggers the start of the next phase?
Can either side pause after a phase if the evidence changes the project direction?
Ask what each activity will produce. A user discussion may lead to a short summary of observed needs, while a review of supplied research may produce only a team working session. Both could be useful, but the SOW should not leave you expecting a formal report if none is planned.
For prototype work, ask what the model is meant to test. A simple appearance model can help people discuss size and form. A fit model can check how parts come together. An interactive model may help expose confusing controls. A functional prototype may answer a different question again. Specify the question, level of fidelity, test method, and known limitations. The word “prototype” alone does not promise a particular capability.
Also ask what is deliberately deferred. A team may learn that an assumption about a material, interface, or production method needs more investigation. The SOW can state whether that work is included, reserved for a later phase, or dependent on a separate specialist. Naming the boundary early is more useful than discovering it when the project is already at a review gate.
What will each deliverable include and be used for?
Deliverables should be described so both parties can identify them when they arrive. “Design files,” “final concepts,” and “prototype” are too broad if the format, level of detail, and intended use remain unstated. Ask for a list that names the deliverable, its format, its purpose, and any limitations.
Visual material: Are sketches, renderings, layouts, or presentation boards included? How many options and views will be provided? Are they intended for internal decisions, customer communication, or another use?
Digital files: Which native and export formats will be supplied? Are editable source files included or only presentation files? Identify any file versions or transfer method that matter to your team.
Physical outputs: Are mockups, prototypes, samples, or presentation models included? State the quantity, who pays for fabrication and shipping, who keeps them, and whether they can be modified or reused.
Technical documentation: Does the scope include design-intent drawings, dimensions, part definitions, material recommendations, assembly information, or other handoff material? Do not assume all such information is bundled into a final concept.
Evidence and decisions: Will the team provide observations, a recommendation, a decision record, or a concise account of open issues? Specify how much documentation is useful to your next decision.
Then ask what each output is suitable for. A polished rendering can explain appearance but does not necessarily define dimensions or manufacturing details. A physical model may help assess hand feel without representing internal components. A set of visual files may be sufficient for a direction review but not for a supplier handoff. Record what the output can support and what work remains before it can support another purpose.
One useful way to test a deliverable description is to ask a colleague who did not attend the proposal meeting to explain what they think it means. If that person assumes a supplier-ready file package while the proposal only promises presentation images, the description needs more precision.
How will reviews, revisions, and approvals work?
Reviews need an owner, a response window, and a defined decision. Otherwise, feedback can arrive in pieces, conflict across stakeholders, or reopen an issue that the team thought was settled. Put the review process in writing before the first milestone.
Who is the client-side decision maker, and who may offer input?
Who consolidates comments into one response?
How many review rounds are included for each major deliverable?
How long does each side have to review and respond?
What does approval mean: acceptance of a direction, sign-off on a file, or permission to start the next phase?
How will new requests or changed assumptions be evaluated?
Distinguish a correction from a change of direction. If a deliverable does not match an agreed requirement, correcting it may be different from adding a new feature or asking the team to revisit an approved concept. The SOW should explain how each type of request is handled and how it may affect scope, schedule, and fees.
For example, suppose a review group approves a compact enclosure and later asks for a second battery compartment. That is more than a wording correction: it may affect volume, layout, appearance, and the model already under review. The group should know who can authorize that request and what impact information the firm will provide before work changes. A written approval record makes the decision traceable and keeps a request from becoming an assumed obligation.
Ask whether approval is tied to clear criteria. “Looks good” may be enough for a visual preference check, but it is not a precise sign-off if the next phase depends on usability, dimensions, or a specific constraint. Agree on the evidence that the decision maker needs, and record unresolved points rather than treating silence as agreement unless the contract explicitly sets that rule.
What schedule, dependencies, and client duties belong in the plan?
A useful schedule shows the work and the conditions that affect it. A single estimated finish date does not tell you when reviews happen, how long prototype fabrication may take, or what information your team must supply. Request milestones with dependencies and realistic review periods.
What are the planned phases and milestone dates?
How much review time is built into each milestone?
Which dates depend on your feedback, product samples, outside suppliers, or access to users?
What materials or decisions must be ready before each phase can start?
How will a delayed response or late input affect the schedule?
How often will the team report progress, risks, and decisions needed?
Consider the project as a chain rather than a single date. If a prototype depends on a chosen concept, the concept review must happen first. If the next review depends on a fabricated part, fabrication and shipping time need a place in the plan. If your team must gather feedback from several departments, that internal work also needs a reasonable window.
Write down your side of the plan too. Name the person who supplies reference materials, the person who consolidates feedback, and the person authorized to make decisions. If your team must provide a sample, confirm who prepares it and when. These are not minor administrative details; they determine whether the proposed sequence can happen as described.
Ask how the team handles a missed dependency. A practical SOW can say that dates will be reviewed when an input is late, that the firm will flag a schedule risk, and that both parties will agree on the revised sequence. It need not predict every delay. It should explain how the parties will make the schedule visible and respond when an assumption changes.
How should fees, assumptions, and scope changes be explained?
Ask what the quoted fee covers and which assumptions make it possible. The proposal should identify its pricing basis and describe how expenses, external purchases, and work outside the listed scope are handled. Do not infer a price or a particular commercial model from a phase name.
Is the fee fixed, time-based, or tied to defined milestones?
Are prototype materials, fabrication, shipping, travel, or supplier charges included or separate?
How many concepts, models, meetings, and review rounds did the estimate assume?
Which client inputs or decisions are assumed to arrive by particular dates?
How does either side request a scope change, and who must approve it?
Will the firm explain the impact on cost, schedule, deliverables, and responsibilities before additional work begins?
Read the assumptions alongside the activities. A budget might assume one selected direction, while your team expects several alternatives. The gap is not a matter of a small wording choice if it changes the amount of exploration. Likewise, a plan might list a prototype but assume that fabrication costs are paid separately. State those expectations before approval.
Good change control creates a decision point. It lets the client decide whether a new request is worth its effect on the project, and it lets the firm avoid proceeding on an unapproved assumption. Ask that a proposed change be described in writing, with the reason, added or altered work, affected outputs, schedule impact, cost impact, and approving parties. Keep the original scope and the approved change together so the current agreement is easy to understand.
For a simple example, your team may ask to add a second material direction after the first review. Before work begins, the firm can explain whether that means new research, extra renderings, another prototype, or only a brief comparison. You can then decide whether to add the request, exchange it for another activity, or defer it. This is more useful than relying on a general promise to “stay flexible.”
Who owns the work, and how will confidential information be handled?
Ownership, permitted use, and confidentiality deserve direct answers in the agreement. Ask what rights apply to project-specific deliverables, when a transfer or license takes effect, and whether pre-existing materials or tools are treated differently. If the product depends on confidential information, clarify who may access it and how the parties will handle it.
Which project-specific outputs will your organization own or be licensed to use?
Are editable source files included, and are there limits on modifying or sharing them?
Are pre-existing templates, methods, or components treated separately?
May either party show the work publicly, and is written approval required?
How will confidential information be shared, stored, returned, or deleted?
Do any third-party assets or materials carry separate usage conditions?
Do not rely on informal assurances if ownership or disclosure could affect fundraising, launch planning, supplier conversations, or a future partnership. Review the actual contract language and raise ambiguity before signing. Questions about legal rights or confidentiality may warrant advice from a qualified legal professional. The practical goal is to know what you can use, what must remain private, and what files you will receive when the work ends.
What work remains between a design decision and production?
“Ready for production” can mean different things to different teams. Ask exactly what evidence and files are included at handoff, what remains open, and whether the scope covers any supplier, sample, or production-preparation activity. The answer can be a clear boundary; not every engagement has to continue through manufacture.
What documents, files, and decisions will a supplier receive?
Are materials, finishes, assembly details, and part choices resolved or still open?
Will the design team review supplier feedback or sample builds?
Who is responsible for confirming requirements and resolving issues found during a build?
What work requires another phase or a separate agreement?
Separate a design concept from the information needed to make and check a product. A concept may communicate form and intended interaction while leaving dimensions, material selection, tolerances, internal layout, or assembly questions unresolved. Ask the firm to name any such open items, assign an owner, and state what evidence or decision is needed next.
If production support matters, define the activities and outputs rather than using an open-ended word such as “support.” It might mean joining a supplier review, assessing a sample against agreed criteria, or revising specified files after a review. Each activity has a different level of effort. If it is outside the engagement, identify who takes over and what information that person will need.
For a broader view of how product work can connect early decisions with physical outcomes, review the product design services overview. To understand the kind of examples a firm may discuss, browse selected product work. These pages can inform a conversation, but the signed scope should still define the specific outputs and responsibilities for your project.
How can you compare two SOWs fairly?
Use the same questions with every candidate and compare what each proposal commits to, not how polished or lengthy it is. A one-page proposal can be clear, and a long proposal can still leave key responsibilities undefined. Create a simple review note for each firm and capture the actual answer, its evidence, and any item that needs clarification.
Clarity: Can you identify included work, exclusions, deliverables, approval points, and client duties?
Fit: Does the plan address the product risks and decisions your team actually has?
Traceability: Does each major activity lead to a useful output, observation, or decision?
Practicality: Can your team meet the requested review dates and provide the required inputs?
Continuity: Does the document show what comes next and who owns each open item?
Change clarity: Is there a defined way to assess and approve work that was not in the original plan?
Do not treat every difference as a weakness. One firm may propose more exploration; another may recommend resolving a technical uncertainty first. The better fit depends on the question your project needs to answer and the evidence you need to move forward. Ask each firm to explain why its sequence suits the stated need, then compare that reasoning against your priorities.
If an answer is unclear, request a written clarification or an example deliverable. Compare the revised scope documents rather than informal impressions from a meeting. A useful selection record can include the decision criteria, the remaining risks, the preferred approach, and the reason for that choice. This makes the decision understandable to stakeholders who were not in every discussion.
Which warning signs should you resolve before signing?
Early projects always have some unknowns. The concern is not uncertainty by itself; it is an unknown that the document ignores or treats as settled. Pause and ask for clarification when you see:
A broad promise without an observable endpoint or decision criterion.
Deliverables described only by generic labels, with no format or intended use.
No distinction between included revision rounds and a new request.
A schedule that omits review time, dependencies, or prototype lead time.
Client responsibilities that are assumed but not assigned to a person or date.
Unclear ownership or public-sharing terms.
Unstated fees for fabrication, samples, shipping, or outside purchases.
No defined route for documenting a change or resolving a disagreement.
A claim that a concept is ready for production without explaining what files, checks, or decisions that phrase includes.
Ask the firm to address each concern in the SOW, proposal, or contract before approval. You do not need to eliminate every possible risk before a project begins. You do need to agree on how the team will recognize a problem, who can make a decision, and how a response will affect the work.
How should you prepare for the SOW conversation?
A short project brief can make the review more useful. Give the firm enough context to understand the need, but label assumptions so no one confuses them with confirmed requirements. Include what your team knows, what it needs to learn, and what decision should follow from the proposed work.
Write an outcome statement. Describe the user or business need and the decision the project should enable. Keep it separate from any preferred solution.
List constraints and known facts. Include relevant size, environment, intended use, materials, existing components, or production considerations when known. Mark unknowns explicitly.
Separate evidence from hypotheses. Identify which claims come from user feedback or testing and which are still assumptions to investigate.
Name the decision makers. Agree internally on who approves a direction and who consolidates comments from other stakeholders.
Set your own availability. Estimate when your team can supply files, samples, feedback, and approvals. Flag any dates that cannot move.
Mark boundaries. State what you expect the firm to do, what your organization will do, and what remains undecided.
Review each proposal line by line. Use the questions in this guide to identify missing outputs, hidden dependencies, and assumptions that need written answers.
Before the meeting, choose the few decisions that matter most. If time is limited, prioritize the project endpoint, included outputs, client duties, change process, and what remains after handoff. You can return to secondary details later, but do not approve a scope whose basic boundaries are unclear.
You can also use the prototyping overview to prepare questions about what a proposed model should prove, and review manufacturing and sourcing information if your project depends on a defined next step. A practical design handoff guide can help your team think about continuity after the agreed deliverables are complete. Use these resources as context, not as a substitute for project-specific terms.
Once your team has the brief and questions ready, compare proposals against the same needs and record the remaining decisions. If you would like to discuss your product brief and the scope questions that matter for it, book a product design consultation or contact Jackson Hedden.
Talk through your project scope
Frequently Asked Questions
What is an industrial design statement of work?
It is a project document that defines the work, deliverables, responsibilities, schedule, assumptions, and boundaries for an engagement. It helps the client and design firm agree on what completion means and which work remains outside the agreement.
What should I ask before signing a design SOW?
Ask about the intended outcome, included activities, deliverable formats and uses, reviews and approvals, client duties, schedule dependencies, fees and changes, ownership, confidentiality, and what remains between design and production. Request written answers wherever a proposal uses broad or ambiguous language.
Does a concept rendering mean the product is ready for production?
Not necessarily. A rendering can communicate appearance or a design direction, but it may not include the detailed dimensions, material choices, part information, supplier review, or other documentation needed for a production step. Ask what the image can support and which decisions or files are still outstanding.
How many revision rounds should an SOW include?
There is no single number that suits every project. The SOW should state the included review rounds for each major output, how feedback is consolidated, and how the team will distinguish a correction from a new request or an approved direction change.
What should happen when the project scope changes?
Use the written change process. Describe the requested work, ask for its effect on deliverables, timing, responsibilities, and fees, then approve or decline the change in writing before the added work begins.
Should production support be part of the SOW?
Include it when your team needs defined help with supplier reviews, samples, or production preparation. State the specific activities and outputs. If that work is not included, name the boundary, the next owner, and the information that person will need.
A careful SOW conversation turns a proposal into a shared plan. By clarifying the work, decisions, outputs, and remaining responsibilities before signing, your team can start with a more practical understanding of what comes next.
