Find the Need Before You Build the Thing

Here is the trap. Your team gets excited about a solution before anyone checks if the problem is real. The roadmap fills up. People build. Six months later the thing ships and nobody uses it. The fix is not more meetings. It is doing the homework on what people actually need before you commit. This brief pulls together a clear way to do that.

Chase the need, not your favorite idea

The core move is simple. Study what people need, not the product you want to build. Dev Patnaik calls this Needfinding, and his point sticks: "needs last longer than any specific solution." Floppy disks died. The need to store data did not.

Think about the PalmPilot. Apple built the Newton to solve every problem of portable computing. It was too big, too slow, and it flopped. Palm studied how people used their early device and found they wanted a better organizer, not a tiny desktop. So Palm cut features and won.

The lesson for you: when your team states a need, make them state it without naming a solution. "The clerk needs the boxes on the top shelf," not "the clerk needs a ladder." That keeps every option open.

Watch what people do, not just what they say

People are bad at describing their own needs. They get used to their problems and build workarounds, so the need goes invisible. Patnaik's example is the scooter rider who tilted his bike to fuel it for years and swore he was happy, right up until Honda shipped one that did not need tilting.

This is why you go to where the work happens. Surveys and focus groups tell you what people prefer among things that already exist. They will not surface the need nobody can name yet.

So push your team toward observation. Jun Loayza frames the two questions worth asking: what patterns show up in behavior, and which need do people talk about but never act on? The gap between talk and action is where the real signal lives.

Frame the need as a job to be done

Once you see the need, write it down in a way the team can build against. The Jobs-To-Be-Done framework helps here. People hire a product to get a job done. As The Burndown puts it, borrowing Levitt, people don't want a quarter-inch drill, they want a quarter-inch hole.

The useful tool is the job statement: when this happens, I want to do this, so I can get this outcome. It names the trigger, the motivation, and the result. No feature names allowed.

The same piece nods to Einstein: given an hour, spend 55 minutes on the problem and 5 on the solution. Most teams flip that. Make the problem statement the thing your team defends before any design review starts.

Make discovery cheap and constant

Here is the good news. This does not require a budget or a quarter. Joe Salowitz shows you can run real research in a single morning: list your user types, post on social media to find them, run 10-minute chats. Pick the three questions that matter and ask those.

The trick is knowing when it is worth it. Aya Burstein and Ben Aharon make the case that not every decision needs a study, so judge before you book sessions. And for a new product, Anant Jain reports that over 40% of the startups his studio worked with died inside six months, often because founders skipped this step entirely.

Build it into the rhythm. R B Srikanth lays out a discovery process with clear intake and learning loops that run across sprints, so finding needs becomes a habit, not a one-time event.

The deep cut

Research alone will not save you. A pile of notes about user behavior is just description. It tells you what is happening, not what to do. The hard part is synthesis, turning raw observation into a sharp statement of the need.

Christina Wodtke argues a disruptive product has to be about 9x better than what exists, and you only find that gap with strong synthesis. So when your team comes back from research, do not ask "what did you hear." Ask "what is the one need, and how sure are we." If the synthesis is mushy, the build will be too.

Three questions for your team

• Which need are we solving, stated with no solution attached? If you can only describe it as a feature, you have not found the need yet.
• What do users do today that contradicts what they say? Find the workaround they stopped noticing, the way Bajaj riders tilted their scooters.
• Are we 9x better than the current option, or just a little better? If the answer is "a little," go back to the gap before you commit the roadmap.