Questions to Ask When Developing a New Product
These are questions to ask when developing a new product, for the stretch between a promising idea and a commitment to build it: a founder with a sketch, a product manager with a business case to write, an R&D group with a working sample and no buyer yet. They run in the order the decision usually does, from the problem and the evidence for it, through the market and the cheapest test, to feasibility and the call to go on or stop. Ask them of yourselves first, then of whoever would fund, build, sell and support the thing.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
The problem
What problem does this product solve, and whose problem is it?
Why ask it
Write the answer as one sentence with a person in it: who they are, what they are trying to do and where they get stuck. If the sentence only works with the product's name in it, you have described a solution and have not yet found the problem. Have everyone on the team write theirs separately, then compare before anyone argues.
How are those people coping with the problem today?
Why ask it
Whatever they do now is what the product has to beat, however makeshift it looks from outside. Ask to watch it being done, since a description leaves out the steps people have stopped noticing. If they do nothing at all, the problem may not hurt enough to pay for.
Who exactly is the product for, and who is it not for?
Why ask it
The second half does the work. A team that can name a group it is willing to disappoint has made a choice, and a team that says 'anyone who needs it' has not. Follow up by asking which planned features exist only to please the people you just ruled out.
How often does the problem come up, and what does it cost them each time?
Why ask it
A daily irritation and a once-a-year crisis call for different products at different prices. Get the cost in the customer's own units: hours lost, orders missed, a fee paid, a complaint from their boss. If nobody in the room can answer, that is the first thing to go and find out.
Is the person who has the problem the same person who would pay to fix it?
Why ask it
When they differ, as with a tool a nurse uses and a purchasing office approves, there are two people to convince and they want different things. Name both, then ask which one could block the purchase alone. A product that delights its user and gives the payer no reason to sign will stall at the order form.
What have they already tried, and why did it not stick?
Why ask it
An abandoned attempt is strong evidence that the problem is real, and it doubles as a free list of mistakes. Pay attention to the reason it failed. If earlier fixes were dropped because of habit, budget or a boss who would not approve them, a better product walks into the same wall.
What happens to them if the problem is never solved?
Why ask it
'Nothing much' is a frequent honest answer, and it should slow the project down. Look for a deadline, a penalty or someone the customer answers to, because those are what turn interest into an order. A problem people can live with indefinitely tends to earn compliments and little else.
Why now: what has changed that makes this possible or necessary?
Why ask it
A new rule, a cheaper component, a shift in habits or a competitor leaving the field are all workable answers. If nothing has changed, ask why the product does not already exist. Someone has probably tried, and what stopped them is worth an afternoon of digging before you spend a budget learning it the same way.
Did we start from a problem we found, or from something we know how to build?
Why ask it
Research and engineering teams often begin with a capability, and that is a fair place to begin as long as everyone says so out loud. The next job is then finding who needs it most, and the customers the team first pictured are not always the ones who do.
The evidence
What do we know for certain, and what are we assuming?
Why ask it
Draw two columns and sort every claim in the business case into one of them. Early plans usually turn out to be mostly assumption, which is normal and no cause for embarrassment. The assumption column is now your list of things to test, so rank it by how much damage each item would do if it were wrong.
How many of the intended customers have we talked to or watched, and where are the notes?
Why ask it
Ask for the raw notes and read a few. Summaries written by people who want the project to continue lean toward the encouraging parts. If only two or three people were interviewed, or all of them are friends of the team, the honest status is that customer research has not started.
What have people done, as opposed to said, that shows they want this?
Why ask it
Joining a waiting list, paying a deposit, sharing their data or giving up an hour for a second meeting all cost the person something. Praise costs nothing. Rank each piece of evidence by what it cost the customer to give, and see how much is left near the top.
What can we learn from records we already have, such as support requests, lost sales and returns?
Why ask it
An existing business is often sitting on evidence it never collected on purpose: what customers wrote in to complain about, why deals fell through, what people typed into the search box and did not find. Reading it takes a day or two and can redirect the research that follows. A founder starting from nothing can read public reviews of the products these customers use now for the same purpose.
Which single assumption, if it is wrong, ends the project?
Why ask it
It is usually one of three: that people want it, that it can be made to work, or that it can be made for less than they will pay. Once it is named, the next month's effort belongs there. Work on anything else first is a way of putting off the answer.
What have we learned so far that surprised us?
Why ask it
Research that only confirms what the team believed going in deserves a second look, because the questions may have been written to get that result. One real surprise, such as a buyer nobody had pictured or a feature nobody asked about, suggests the team has been listening. Ask what changed in the plan because of it.
Who has told us this is a bad idea, and what was their reason?
Why ask it
If the answer is nobody, only friendly people have been asked. Go to a skeptical customer, a salesperson who would have to sell it and the engineer who would have to maintain it. An objection does not need to be right to be useful, because a buyer is likely to raise the same one later.
The market
Who else is working on this problem, including in ways that look nothing like ours?
Why ask it
Direct rivals are the easy part of the list. Add the indirect ones: a service that does the job by hand, a feature inside a product the customer already owns, a tool built in-house. If the team says there is no competition, ask whether that means no rivals or no market.
What would make someone choose this over what they already use?
Why ask it
'Better' does not count until it is something a customer would notice on first use and could describe to a colleague in their own words. Being slightly ahead on every measure rarely moves anyone off a product that works. Look for one large difference, then check that customers care about that one.
How big is the market, and where did that number come from?
Why ask it
A large figure from an industry report multiplied by a small percentage proves very little. Build the estimate from the ground instead: how many of the people you named as the target exist, how many you can reach, and how many of those could plausibly buy in a first year. Label the result as an estimate wherever it appears.
How will this make money: a one-time sale, a subscription, a fee per use, or something else?
Why ask it
The choice shapes the product as much as the price does. A one-time sale has to earn its margin up front, a subscription has to keep being worth it every month, and a free product paid for by someone else has two sets of customers to please. Sketch a single customer's first year under each model you are considering and see which one the planned product could support.
What would customers pay, and what are they comparing that price to?
Why ask it
The comparison sets the ceiling. A product measured against a free workaround faces a different conversation from one measured against a salary or a penalty. The most trustworthy test is asking someone to pay, or to commit in writing, so plan how to do that with the first prototype.
What would a customer have to give up or change in order to adopt this?
Why ask it
Every new product asks for something beyond its price: retraining staff, moving data, approving a new supplier, breaking a habit. List those costs from the customer's side of the table. When the switch is heavy, ask whether the first version could sit beside what they use now instead of replacing it.
If a bigger company copied this within a year, what would we still have?
Why ask it
Possible answers include a patent, a head start with customers, data nobody else holds, a cost advantage or a relationship with a sales channel. 'They would never bother' is a hope and should be recorded as one. For a small team the realistic defense is often speed and closeness to one group of customers.
Do we already have a way to reach these customers, or would we have to build one?
Why ask it
A product that fits an existing sales team, store shelf or mailing list starts with an advantage that has nothing to do with its design. A new channel is a second project with its own cost and risk. Bring in whoever would sell it now, while their objections can still shape what gets built.
Does this strengthen what we already sell, compete with it, or stand apart from it?
Why ask it
Each answer brings its own politics. A product that eats into an existing line needs a sponsor senior enough to accept that, and one that stands apart will struggle for attention from sales and support. Founders with nothing on the shelf yet can skip this one.
The test
What is the smallest version that would tell us whether we are right?
Why ask it
Smallest means the least work that produces a real answer, which is often less than a working product: a clickable mock-up, a single feature, a service delivered by hand behind a simple front. If the proposed first version takes many months, ask which part could be faked or done manually for the first ten customers.
What question is this prototype supposed to answer?
Why ask it
A prototype built to learn whether people want the thing looks different from one built to learn whether it can be made. Mixing the two produces something too rough to sell and too polished to throw away. One sentence, written before building starts, keeps the prototype honest.
Can we test demand before we build anything at all?
Why ask it
A page describing the product with a way to order, a brochure taken to five buyers or a pre-order offer can each show interest for the price of a few days' work. Be straight with anyone who signs up about what exists and what does not. Rules on advertising and on taking money for something unbuilt differ from place to place, so ask how they work where you sell.
What must the first version do, and what are we leaving out on purpose?
Why ask it
The leaving-out list matters as much as the feature list, and it should be written down with a reason beside each item. Without it, cut features creep back one reasonable request at a time. Anything a stakeholder insists on restoring should arrive with a proposal for what comes out in exchange.
Who will we put it in front of, and how will we stop ourselves from explaining it?
Why ask it
Testers should come from the group named as the target, not from colleagues or relatives. Hand it over, say as little as possible and watch where they hesitate. Each time someone on the team steps in to help, make a note, since that is a place the product does not yet explain itself.
What result would count as a pass, and did we write it down before the test?
Why ask it
A threshold set in advance, such as a share of testers finishing the task unaided or a number of pre-orders, cannot be bent afterwards to fit the outcome. Set after the fact, almost any result can be read as promising. Have the person who will make the go or stop call agree to the figure.
How could this test give us a wrong answer?
Why ask it
Friendly testers, a free trial of something that will later cost money, novelty that wears off in a week and a sample of five are the usual culprits. State the weakness of the test alongside its result. A flawed test still teaches something if everyone knows which way it leans.
How long does one round of building, testing and learning take, and how many rounds can we afford?
Why ask it
Divide the money or months available by the length of a round and you have the number of chances to be wrong. Hardware and regulated products usually get fewer rounds than software, which raises the value of cheap tests early. If the answer is one round, the plan is a bet and should be presented as one.
What will we do if the results come back mixed?
Why ask it
Mixed is a very likely outcome and the one teams prepare for least. Decide beforehand whether a middling result means another round, a narrower target or a stop. Otherwise the default is to carry on, because carrying on requires no decision from anyone.
Feasibility
Can we build this with the people, tools and suppliers we have, and what is the hardest part?
Why ask it
Ask the people who would do the building, without their manager answering for them. The hardest part deserves its own small experiment before the rest is designed around it. If the honest reply is that nobody knows whether it can be done, that is a research project and should be funded and scheduled as one.
How long until a customer could be using a first version, and what is that estimate based on?
Why ask it
An estimate built from a similar job the team has finished is worth more than one built from optimism and a calendar. Ask what the last comparable project was forecast to take and what it took, then apply the same gap here. If a date has already been promised to someone, say so now, because a fixed date quietly decides what gets cut.
What will the next stage cost, and what will we know at the end of it?
Why ask it
An early estimate for a whole product is a guess, while the cost of one stage, a prototype or a round of customer tests, can be pinned down well enough to approve. Tie the money to the answer it buys, and ask for a fresh estimate of the remainder at each gate.
What does one unit cost to make and deliver, and how does that change as volume grows?
Why ask it
Work it out at three volumes: the first batch, a modest year and a good year. Include packaging, shipping, returns, payment fees and support time, which early costings tend to leave off. If the unit cost only falls below the price at a volume nobody can vouch for, the price or the design has to change.
Which rules, standards or approvals apply to a product like this in the places we plan to sell it?
Why ask it
Safety testing, labeling, data protection and licensing requirements differ by country, by state and by type of product, so the answer has to come from someone qualified in each market. Ask early, because an approval can take longer than the engineering and can change the design. Put the name of whoever is finding out next to this question.
Do we have the right to use everything this depends on, and is anything in it worth protecting?
Why ask it
Check the licenses on software, components, data and designs, and ask whether someone else may hold a patent or trademark in the same area. Whether and how to protect your own work depends on the jurisdiction and the kind of product, so take it to an intellectual property professional before showing the idea widely.
Who would work on this, and what do they put down to do it?
Why ask it
People described as available are usually busy with something that has its own sponsor. Get names, the share of each person's week, and the agreement of whoever loses that time. A project staffed with leftover hours from five people tends to move slower than one with two people on it full time.
What does this depend on that we do not control?
Why ask it
A single supplier, another company's platform, a partner's permission or a component with a long lead time can each halt the product on their own. For every item, ask what the fallback is and what it would cost to have one ready. Some dependencies are worth accepting, provided they were chosen knowingly.
If it works, who supports, repairs and updates it, and for how long?
Why ask it
A product keeps costing money after it ships, in spare parts, security updates, customer questions and returns. Bring the support or service lead into the room for this one. Their estimate belongs in the business case beside the development budget.
What could go wrong for the person using it, and how bad is the worst case?
Why ask it
Consider misuse as well as intended use: the wrong user, the wrong setting, a child getting hold of it, data ending up where it should not. Anything that could injure someone or cause serious loss needs a specialist's review and is a reason to slow down. For a low-stakes product, a short list with a named owner is enough.
The decision
What would make us stop?
Why ask it
Pick a few conditions and write them down: a test result under the agreed bar, a unit cost over a ceiling, a date reached with no paying customer. The moment to choose them is before there is a prototype anyone has grown fond of. Read them aloud at the start of each review.
What does success look like for this product, and how will we measure it?
Why ask it
Choose one or two measures that a customer's behavior produces, such as repeat orders, weekly use or renewals, over ones the team can move by working harder, such as features shipped. Give each a level and a date, and name who will report the figure. A sponsor and a team who picture different numbers tend to find that out at the first review after release.
Who decides at each stage whether this continues, and what do they need to see?
Why ask it
Get one name per gate, not a committee, plus the list of things that person wants on the table. Ask them directly, since teams often guess wrong about what a sponsor cares about. If the decider changes between stages, find out whether the next one accepts the evidence gathered for the last.
How much are we prepared to spend, in money and months, before we know whether this works?
Why ask it
A cap agreed at the start turns an open-ended commitment into a bounded experiment. A founder can set it against savings and runway, a team inside a company against the budget cycle. When the cap is reached, the choice is to stop or to make a fresh case, and drifting on is neither.
What would this have to earn, save or change to beat the next project on the list?
Why ask it
The real comparison is with what the same people and money would do otherwise. A product that would be modestly profitable can still be the wrong choice if it crowds out a better one. Ask the sponsor what the runner-up is, and judge both by the same measure.
Whose support inside the organization does this need, and who could quietly stall it?
Why ask it
Sales, manufacturing, legal, finance and support can each slow a product without ever saying no. Visit them early with questions, before there are decisions to defend, and write down their conditions. A solo founder can read this as a question about suppliers, co-founders and investors.
If we were not already this far in, would we start this today?
Why ask it
Money and months already spent do not come back whichever way the decision goes, so they should not be counted in it. Asking the question from a standing start strips them out. It is easier to answer truthfully with someone from outside the team in the room.
If we stop, what do we get to keep?
Why ask it
Customer notes, a component, a supplier relationship or a team that now knows the market can all outlast a cancelled product. Listing them makes a stop easier to call and easier to accept. It also shows whether a smaller or different product is sitting inside the work already done.
What is the next decision date, and what will we bring to it?
Why ask it
Leave every review with a date, an owner and the evidence expected by then. While the biggest assumptions are still untested, keep the gap between reviews short, since a long stretch without one is a long time to build on a guess.
How to work through these questions as a team
Practical guidance for the conversation itself
Who asks, and at which stage
Take one group per stage
The six groups follow the order a product decision usually takes, and each belongs to a different meeting. The problem and The evidence come before anything is built. The market and The test shape the first prototype. Feasibility and The decision are for the review where someone approves or refuses the next round of spending. Working through the whole list in one sitting produces tired answers to the later groups.
Answer alone before answering together
Send out the questions for the next stage a few days ahead and have each person write answers on their own. In a meeting, the first confident voice sets the answer and everyone else adjusts to it. Comparing written answers shows where the founder, the engineer and the salesperson are describing three different products.
Take each question to the person who would carry the work
A founder or product manager should put the questions about cost, support and selling to the people who would do those jobs, and should not answer on their behalf. The finance lead, the head of support and a salesperson will each hear a different product in the same description. Where their answers disagree with the team's, add the disagreement to the list of risks.
Keep a dated record
Write each answer down with the date and the name of whoever gave it. Six months on, nobody remembers what was assumed at the start, and the record is how you tell a change of plan from a change of memory. It also lets a new sponsor see why earlier choices were made.
Turning answers into tests
Mark every answer as known, believed or guessed
Known means there is something to point to: a signed order, a measured cost, a test result. Believed means a reasonable person on the team would bet on it. Guessed is everything else, and early on it covers most of the page. The marks show at a glance how much of the plan rests on evidence.
Test what could end the project before what is easy to test
Teams drift toward the experiments they already know how to run, so engineers prototype and marketers survey. Pick the next test by asking which guess would do the most damage if wrong, then find the cheapest way to check that one. An awkward test of the right question is worth more than a tidy test of a safe one.
Fit the prototype to the question
A question about demand can often be answered with a description, a price and a way to say yes. A question about whether the thing can be made needs a rough working part and no packaging at all. A question about whether people can use it needs something they can hold or click, with nobody from the team explaining.
Change one thing between rounds
If the second test has a new price, a new audience and a new design, a better result cannot be traced to any of them. Hold two steady and move one. It feels slow, and it is how a round of testing ends up telling you what to do next.
Running a go or stop review
Read the bar before the results
Open each review by reading out what was agreed last time as the evidence needed to continue. Then look at what arrived. Doing it in that order keeps the meeting from judging the results by how much everyone likes the product.
One person makes the call
A group can advise, and one named person should decide, with the reasons recorded. When a committee owns the decision, the likely outcome is to continue with reservations, which costs as much as continuing with enthusiasm.
Allow four outcomes
Go and stop are not the only choices. A review can also send the project back for one more specific test, or turn it toward a narrower customer or a different use. Naming all four at the start keeps a doubtful project from being waved through for lack of an alternative.
Make a stop ordinary
If cancelling a product is treated as a failure of the people on it, nobody will bring bad evidence to a review. Say plainly that a stop reached early, on evidence, is the process working. Then move the team onto something visible, so the next group believes it.
Where product teams fool themselves
Asking people whether they like the idea
Most people are kind to someone showing them a project, and their kindness reads as demand. Ask what they did the last time the problem came up and what they spent on it. Opinions about a product that does not exist yet are the weakest evidence on the table.
Polishing instead of testing
Another month of refinement always feels responsible. It also delays the moment a stranger sees the product, and the polish goes onto features that may be cut. Show it while it is still a little embarrassing.
Letting a launch date drive the build
Once a trade show or a board meeting fixes the date, the questions on this page get answered with whatever keeps the schedule. Settle whether the product should exist first. Planning the launch is a separate conversation with its own questions, and it starts after a go decision.
Hearing only from the people who stayed
Testers who dropped out, prospects who stopped replying and customers who went back to the old way hold the most useful answers, and they are the hardest to reach. Chase a few of them. One conversation with someone who walked away can explain a result that a dozen happy testers cannot.