Product strategy Kiwi insights
How to test a product problem before building software
Use focused research questions, interviews, and observed behavior to investigate a problem before committing to a solution.
A product idea can sound urgent and still rest on an untested understanding of the problem. Before building software, clarify who experiences the problem, what they do today, when the friction appears, and what would make a change worthwhile.
Frame one problem, not a preferred solution
Write a concise problem statement that identifies the people affected, the context, the impact, and the unknowns. Keep proposed features out of it. NN/g notes that discovery works best when it investigates the problem rather than beginning with a solution.
Ask research questions that change a decision
Examples include: What causes people to look for an alternative? What do they currently do? Where do they lose time, confidence, or control? What constraints would make a new workflow unacceptable? User interviews can surface reported experiences; observation, usability testing, and product data help verify behavior.
Decide whether the evidence is sufficient
Look for patterns across the intended audience, not validation from a single enthusiastic conversation. Record conflicting evidence and remaining risks. If the problem remains uncertain, test a smaller concept before committing to a broader build.
Kiwi can help teams frame the problem, plan focused research, map a workflow, and turn supported findings into a scoped product decision.