AI Product Development: The Idea-to-Prototype Workbook

The goal is not a production-ready specification. The goal is a decision-ready concept brief: a document that makes the current assumptions visible, names what evidence is missing, and tells the next specialist what you need them to resolve. A useful brief can support a go, revise, pause, or stop decision. It should make uncertainty cheaper to discuss before detailed CAD, certification work, supplier quotes, or tooling make changes expensive.

Treat every AI output as a proposal. A model can help organize questions, generate alternatives, and expose contradictions, but it cannot inspect your intended use, validate a material, certify a safety claim, clear intellectual property, or promise a manufacturing cost. The workbook therefore separates proposed facts from verified facts. Each important statement gets an owner, a source, a confidence level, and a next test. That separation is the central habit behind the entire process.

• ✓Deliverable: one-page problem and user definition.
• ✓Deliverable: measurable requirement table with verification methods.
• ✓Deliverable: ranked assumption and risk register.
• ✓Deliverable: prototype learning plan with budget and stop conditions.
• ✓Deliverable: source trail and open-question handoff for specialists.

Begin with a specific person in a specific situation. Describe what they are trying to accomplish, what makes the current approach frustrating or risky, what they use today, and what better would look like. Avoid demographic decoration that does not change the design. A statement such as for busy parents is weak. A statement such as for a caregiver who must portion dry pet food at 6 a.m. without waking a sleeping child creates observable constraints around noise, light, speed, cleaning, and error recovery.

Write at least three current alternatives, including doing nothing. For each, record the time, money, skill, inconvenience, and risk the user accepts. This prevents the concept from being compared only with imagined competitors. It also creates a testable value threshold: the proposed product must beat at least one real alternative on an outcome the user cares about. Interview notes should describe past behavior, not promises about what someone might buy later.

• ✓User and context: who is doing what, where, and under which constraints?
• ✓Current workaround: what happens today, including manual and no-purchase options?
• ✓Desired outcome: what observable change means the job is done?
• ✓Failure consequence: what happens when the product is late, wrong, unavailable, or confusing?
• ✓Adoption threshold: which advantage must be large enough to justify switching?

Words such as durable, intuitive, affordable, safe, portable, and sustainable are directions, not requirements. Rewrite each as a measurable condition with a context and a verification method. Portable might become carried by one adult for fifteen minutes, fits inside a specified bag envelope, and weighs no more than a stated limit. Easy to clean might become all food-contact parts can be removed without tools, survive a defined wash cycle, and be reassembled correctly by a first-time user.

Separate user needs from design solutions. The need may be confirm the lid is fully closed; a green LED is only one possible solution. This distinction keeps the team from locking onto a mechanism before it understands the requirement. For every requirement, record priority, rationale, target, tolerance, verification method, and status. If a target is unknown, label it TBD and add a test. Do not hide a guess inside a precise-looking number.

A concept becomes clearer when it states what it will not do. Write boundaries for users, environments, loads, temperatures, power, connectivity, maintenance, lifetime, and markets. If the first version is indoor only, say so. If it is not for medical use, do not use diagnostic language. If a connected feature will not work without a cloud service, make that dependency visible. Boundaries protect the first prototype from becoming an unreviewable bundle of imagined future features.

Non-goals are not permanent rejections. They are scope decisions for the current evidence cycle. Record what would have to become true before a non-goal is reconsidered. For example, outdoor use may require an ingress target, ultraviolet exposure evidence, a broader temperature range, and different electrical review. This turns scope debate into an evidence conversation and prevents the phrase later from acting as an unlimited backlog.

• ✓Named users and excluded users.
• ✓Normal, foreseeable misuse, and explicitly prohibited use.
• ✓Environmental ranges and storage conditions.
• ✓Interfaces, services, accessories, and external dependencies.
• ✓Target markets and claims that are outside the current concept.

Start with the product category, intended use, users, energy sources, materials, and possible harms. For U.S. consumer products, the CPSC Regulatory Robot and Business Education Library can help identify requirements to investigate. A product that becomes a medical device because of its intended use may enter an FDA classification and design-control pathway. Electrical, battery, radio, children's, food-contact, wearable, or load-bearing concepts may raise additional standards and specialist-review needs. The correct output of early triage is a question list, not a compliance badge.

Build a preliminary hazard table. For each hazard, describe the hazardous situation, affected person, possible harm, current control, missing evidence, and responsible reviewer. Include foreseeable misuse rather than only ideal operation. Risk controls should follow a hierarchy: eliminate the hazard through design when practical, reduce it with protective measures, and communicate residual risk. A warning label is not a substitute for a safer mechanism when the mechanism can reasonably be improved.

• ✓Mechanical: pinch, cut, crush, tip, ejection, sharp edge, stored energy.
• ✓Electrical and thermal: shock, short, battery event, hot surface, fire.
• ✓Chemical and material: exposure, allergy, migration, cleaning-agent incompatibility.
• ✓Human factors: confusion, hidden state, incorrect assembly, inaccessible control.
• ✓Lifecycle: wear, maintenance error, software support, resale, disposal, and recall response.

A discovery search can reveal terminology, classifications, old approaches, failure modes, and design space. It cannot tell you that you are free to operate, that a claim is valid, or that an idea is patentable. Start with the problem and functional elements rather than your proposed brand name. Search synonyms, component combinations, and use contexts in Patent Public Search. Record useful document numbers, dates, applicants, classifications, cited references, and the exact query that found them.

Read the claims and drawings, not just titles. Follow backward citations to earlier work and forward citations to later developments. Use classification codes to escape vocabulary differences. Then write what changed in your brief: perhaps the mechanism is crowded, a safety feature is common, a material choice creates a new constraint, or the differentiator should move from form to service. If intellectual-property stakes matter, give the documented search trail to qualified counsel rather than converting your notes into a legal conclusion.

A prototype is an experiment embodied in something people can inspect or use. Name the decision it must inform before choosing a process. Paper and foam may answer layout and reach questions. A visual model may test desirability or communication. Additive manufacturing may explore fit, geometry, or assembly quickly, while machined or cast parts may better represent material behavior or finish. No process is automatically the next level. The right choice is the least expensive credible method for the evidence you need.

Write a prototype card with hypothesis, method, sample, conditions, measurements, acceptance threshold, budget, owner, and decision date. Separate appearance prototypes from functional prototypes when combining them would create false confidence. A beautiful render can make an impossible mechanism feel resolved; a rough mechanism can answer a high-value question while looking nothing like the final product. Label every demonstration with what it does and does not prove.

List every physical part, purchased assembly, process, joining operation, finish, inspection step, package, and expected source. Use low, base, and high ranges rather than one attractive number. Then add tooling amortization, scrap and yield, labor, quality checks, inbound freight, duty assumptions, warehousing, outbound fulfillment, warranty reserve, payment costs, and channel margin. The point is not to predict the penny. It is to reveal which assumptions dominate the business case and which need quotes or experiments.

Connect cost to requirements. A waterproofing target may add seals, fasteners, assembly time, and leak testing. A premium finish may increase cosmetic reject risk. A custom battery pack may add certification and supply dependencies. Record the cost effect beside each requirement so value and complexity can be debated together. If a supplier quote omits tooling ownership, minimum order, test fixtures, packaging, or change-control terms, the number is not yet comparable with another quote. Record its exclusions, expiration date, currency, volume, origin, and shipping boundary before using it in a scenario.

A lifecycle view asks what happens before manufacture, during use and maintenance, and after the product's first owner is finished. The EPA's sustainable materials guidance emphasizes looking across raw material acquisition, manufacture, production, use, reuse, maintenance, and waste management. Add questions about expected life, replaceable wear parts, access to fasteners, battery replacement, software support, cleaning, spare parts, material identification, take-back, resale reset, and disassembly.

Avoid broad green claims that the brief cannot support. Instead document concrete decisions: a battery can be replaced with named tools; a wear component has a target service interval; two polymer families are marked and separable; repair instructions will exist; a firmware support period has an owner. The EU ecodesign framework is also expanding attention to durability, circularity, and product information. Market-specific obligations require current specialist review, but early design choices determine whether later evidence is even possible.

The evidence ledger is the memory of the concept. Give every important assumption an identifier. Record the statement, why it matters, current evidence, source, date checked, confidence, owner, next test, and decision affected. Link raw notes and measurements rather than summarizing them beyond recognition. When an assumption changes, preserve the prior value and reason for change. This prevents the team from repeatedly rediscovering the same uncertainty or presenting old estimates as current facts.

Use four evidence states: proposed, observed, verified, and approved by the responsible specialist. Proposed means generated or reasoned but not tested. Observed means something happened in a named test or interview. Verified means the observation was checked against a defined method or independent source. Approved means a qualified owner accepted it for a specified use. These labels make AI assistance safer because fluent text no longer gets to choose its own evidence level.

• ✓Keep source title, publisher, URL or document identifier, and access date.
• ✓Store the exact revision of drawings, test method, and prototype used.
• ✓Record negative and inconclusive results, not only successful demonstrations.
• ✓Name the decision that each piece of evidence can change.
• ✓Set a review date for volatile prices, regulations, supplier claims, and software dependencies.

A gate review is a decision meeting, not a presentation ceremony. Send the brief and evidence ledger before the meeting. Review the user outcome, requirements, top risks, prior-art findings, prototype result, cost range, lifecycle decisions, and open specialist questions. Ask which assumption is most likely to reverse the project, which evidence is weakest, and what the next dollar of work should learn. Do not let the volume of generated pages substitute for evidence quality.

Choose one outcome: proceed to a named next prototype, revise the concept and retest, pause until a dependency changes, or stop. Record the rationale, owner, budget, next review date, and stop conditions. A pause or stop can be a successful output when it prevents avoidable tooling, certification, or inventory expense. If the project proceeds, create a change log so new features cannot silently invalidate earlier safety, cost, or test assumptions.

• ✓Decision and date are explicit.
• ✓Remaining risks have owners and evidence plans.
• ✓The next prototype has one primary learning objective.
• ✓Budget and schedule include rework and review, not only fabrication.
• ✓The handoff states which claims remain prohibited or unverified.

Project and revision: name the concept, owner, date, and revision. User situation: describe the person, context, current workaround, desired outcome, and failure consequence. Scope: list intended use, excluded use, environments, interfaces, and non-goals. Requirements: include measurable targets, tolerances, priorities, and verification methods. Concept: show the mechanism and experience without calling the illustration engineering proof. Risks: list the top safety, technical, supply, usability, cost, and lifecycle uncertainties.

Evidence: link interviews, searches, calculations, test records, quotes, and specialist input with dates. Prototype: state the learning question, method, result, limitations, and next decision. Economics: provide low, base, and high cost ranges with the assumptions that move them. Compliance questions: name possible authorities and standards without claiming approval. Decision: proceed, revise, pause, or stop, with owner and review date. This one page is the index; the evidence pack holds the detail.

ConjureAnything can help turn a prompt into a structured concept, visual direction, proposed technical details, and an initial cost discussion. Use that output to accelerate questions and alternatives. Then run the concept through this workbook. Replace generated assumptions with sources, tests, quotes, and qualified review. A convincing image is useful for communication, but it does not validate geometry, materials, safety, intellectual property, regulatory status, supplier capability, or market demand.

The practical workflow is generate, inspect, challenge, test, and hand off. Preserve the prompt and output revision so reviewers know what they are evaluating. Mark uncertain fields instead of smoothing them into a polished narrative. If your idea affects health, children, food, electrical safety, lifting, pressure, vehicles, or other consequential uses, seek appropriate engineering and regulatory expertise early. The readiness score on the resources page is a planning aid, not approval.