Innovation gets real the moment you stop describing the idea and start interrogating it. The fastest teams I know do not win because they brainstorm harder. They win because they ask sharper questions earlier, then design small, disciplined experiments that force truth to show up. This is human-centered design with teeth: talk to the right people, map the friction, test the riskiest assumption, and measure what changes when your prototype meets the world.
These five questions are a practical filter you can run on any concept, whether you are building a physical product, a software workflow, or a lab-to-market spinout. Ask them in order. Write the answers down. If you cannot answer one, you just found your next research sprint. The goal is not to eliminate uncertainty. The goal is to buy certainty with the smallest proof of concept you can ship.
1. What specific person and moment are we building for?
Start with a real user in a real situation, not a demographic slide. Describe the moment of need: where they are, what triggered the search for a solution, what failure looks like today. If you use Jobs to be Done language, define the “job” as progress they are trying to make, plus the constraints that make it hard.
Action today: write a one-sentence “moment statement,” then test it in five interviews. Ask what they tried last time, what they paid, what they abandoned and why. If you cannot find the moment, you do not have a product problem yet. You have a storytelling problem.
2. What would have to be true for this to work?
List assumptions like you are trying to break your own pitch. Separate them into desirability, feasibility and viability. Then choose the single assumption that would kill the project if false. That is your riskiest assumption. Most teams waste weeks validating the easy parts and calling it momentum.
Action today: create an assumption table with three columns: assumption, how it could be wrong, fastest test. Borrow from lean startup practice and force every assumption to earn a test plan. If your riskiest assumption is “people will switch,” your test is not a survey. It is a behavior test, like a waitlist with a commitment step or a pilot with a real workflow change.
3. What is the smallest proof of concept that reduces the most uncertainty?
A prototype is not a mini version of the final product. It is a question in physical or digital form. Define what you need to learn, then pick the lightest prototype that answers it. This is rapid prototyping as a decision tool, not a demo.
Action today: choose one metric that signals progress, like task completion time, error rate, repeat usage or willingness to pay. Build a “thin slice” that isolates the risky part. For hardware, that might be a single function on a benchtop rig. For software, a manual concierge workflow behind a simple interface. Ship it to a small cohort and measure, then iterate.
4. What can we reuse, connect, or standardize instead of reinventing?
Real-world innovation scales when it plays well with what already exists. Look for open-source components, proven supply chains, and established standards. Design modularly so you can swap parts without restarting the whole build. Interoperability is not a nice-to-have. It is a go-to-market accelerator.
Action today: map your system as interfaces, not features. List every dependency, from sensors to APIs to packaging. Then ask: which pieces are commodity, which are differentiators, which are constraints. A good rule is to differentiate where you create unique value, and standardize everywhere else. This speeds iteration, lowers risk, and makes partnerships easier.
5. How will this ship, get adopted, and stay responsible at scale?
A prototype that works is not the same as a product that lands. Define the adoption path: who approves it, who uses it, who supports it, who pays. Then build for reality: onboarding, reliability, service, and support. Fold in accessibility and sustainability early, because retrofits are expensive and often incomplete.
Action today: write a one-page go-to-market sketch with four bullets: buyer, user, channel, and first measurable outcome. Add two guardrails: what you will not do to grow, and what “responsible” means for your category. If you cannot explain your unit economics or your maintenance plan, you are not blocked by engineering. You are blocked by product leadership.
Closing
These questions are not theory. They are a weekly operating system for makers who want outcomes, not applause. Run them at kickoff, after every major test, and anytime the team starts arguing in circles. When answers get sharper, roadmaps get shorter. Real-world innovation follows.
