Most product teams are asked to build new features. Fewer teams pause before the sprint begins to question whether those features actually solve a real problem. Problem-first, experiment-led product thinking lives in this pre-sprint phase. It treats features as tools, not goals, and focuses on reducing user friction and improving real outcomes. Ideas are framed as small, fast experiments, scope is kept intentionally tight, and decisions are driven by measurable signals rather than assumptions.
When a manager, customer, or any stakeholder asks for a "new feature," developing it is never the goal by itself. What actually matters is whether we reduce friction for the user and help them do their job better. If a feature doesn't move a real metric, I don't see much value in defending or polishing it.
So my first question is: what problem are we really trying to solve? Not what was requested, not what sounds reasonable, but what outcome we want to change in the real world.
Once the problem is clear, I treat every feature as an experiment. I ask whether we can test the idea quickly, with the smallest possible scope, and learn something real from it. Speed and clarity matter more to me than completeness. I'd rather ship something small, learn fast, and iterate than spend weeks building the "right" thing in theory.
This also means being strict about scope. One clear decision point, one main assumption to test, one success signal. If we add more than that too early, we slow ourselves down and reduce learning.
I also try to remove uncertainty early. Before committing to a plan, I talk to engineers and designers and ask what's unclear. If there are technical unknowns, I don't guess. I cut scope until the risk is acceptable. Reducing scope is usually cheaper than being wrong.
During execution, I keep things light. Short check-ins, quick demos, clear written summaries when needed. The goal is learning whether we're actually moving the needle.
At the end, there's always a decision. Did this improve the outcome we care about? If yes, we earn the right to expand. If not, we take the learning and move on. Killing a feature is not failure. Shipping something that doesn't help users is.
How this mindset shows up in practice
Let me make this concrete with an example.
Imagine a digital assistant product used by technicians in the field. They often come back with follow-up questions because the first answer they get feels too generic to act on. A founder, manager, developer, or customer suggests a solution: before answering, the system should ask one clarifying question and then provide more precise, step-by-step instructions.
Rather than jumping straight into building, the request is reframed. The goal is not to add a "step-by-step mode," but to reduce follow-up questions and make the first answer genuinely useful.
From there, the decisions become clearer. Can we test this in one sprint? If yes, keep it intentionally small. One clarifying question max. Only for a narrow set of high-frequency cases. No complex conversation flow.
Then I break it into buildable pieces, check technical risks early, run a lightweight sprint, and measure one thing at the end: did follow-up questions go down?
That's what problem-first, experiment-led product thinking looks like before a sprint even starts.
A clear, short, and practical way of thinking
1. First, define the real problem
The first question I ask is simple: does this request solve a real user problem, or are we just building a feature?
If it feels like "just a feature," I stop and reframe the question. What outcome are we really trying to achieve? If the outcome is not clear, I go back and redefine the problem. You cannot solve a poorly defined problem well.
2. Intentionally shrink the scope
If it is a real problem, my second question is: "can we make this small enough to test in one sprint?"
For this example, my first-sprint rules would be very strict:
- One clarifying question maximum
- No full conversational flow
- A limited set of cases, for example common error codes or top-used manuals
If that is possible, I break the work into concrete pieces:
- When and how the step-by-step mode is triggered
- The UX of how the clarifying question is asked
- Prompt or answer logic changes
- A clear success metric
If it is still too big, I step back and ask: "what is the smallest version that tests the hypothesis?" Then I break that down in the same way.
3. Kill technical uncertainty early
Before locking anything in, I talk to developers early. Is this mostly a prompt change, or does it require backend logic?
If there is technical uncertainty, I do not guess. I reduce scope instead. I would rather ship something smaller and known than gamble on assumptions.
4. Lightweight sprint execution
During the sprint, I avoid heavy process. No micromanagement and extra ceremony.
Short check-ins, early demos, and fast feedback are enough. The goal is not to ship something for the sake of shipping. The goal is to see whether follow-up questions actually go down.
5. Measure, learn, decide
At the end of the sprint, the question is very clear: did the real metric improve?
For example: are there fewer follow-up questions? Is the first answer clearer and more actionable?
If yes, we earn the right to expand. More cases, broader coverage, deeper logic.
If no, that is not a failure. We learned something. Based on that learning, we either pivot or kill the feature entirely.
The core principle
The goal is to make the user's job easier.
Small tests, clear goals, and fast learning matter more than shipping impressive-sounding features. If something does not reduce friction, I am comfortable killing it.
The same mindset, expressed as a simple flow
A new feature request comes in
|
|-- Question 1: Does this solve a real user problem?
| |
| |-- No → Reframe the request: what outcome do we want?
| | → Go back to Question 1
| |
| |-- Yes → Question 2: Can this be scoped to one sprint?
| |
| |-- Yes → Break it into concrete pieces
| | - Trigger logic
| | - UX
| | - Prompt changes
| | - Success metric
| |
| |-- No → Cut it down to the smallest hypothesis test
| → Break it into concrete pieces
|
|-- Are there technical unknowns?
| |
| |-- Yes → Talk to devs early, reduce scope
| |
| |-- No → Run the sprint with lightweight check-ins
|
|-- Ship
|
|-- Question: Did the real metric improve?
|
|-- Yes → Success, earn the right to expand
|
|-- No → Learn, pivot, or kill the feature