Problem Framing
"We need push notifications." "We need a chat feature." "We need a better app." Every week someone brings Meera a solution dressed up as a problem. If the team starts building from any of these, it may solve something nobody actually has, and ideas generated from a vague problem come out vague too.
The rule
Name who hurts, what hurts, and how you'll know it's fixed.
A framed problem has four parts:
- Who: a specific group, not "users". First-years in their first two weeks of term.
- What hurts: the struggle, described as behaviour you could observe, with no feature in it. They can't tell which listed books match their courses, so they buy everything new to be safe.
- Why it matters: the cost in money, time or missed outcomes, backed by evidence. About ₹5,000 each on books used for one semester; 6 of the 8 first-years we spoke to bought everything new.
- How you'll know: the signal that the problem has shrunk. A typical first-year buys at least half their list second-hand.
Put together:
First-years at our pilot campus spend about ₹5,000 each on new books in their first two weeks, because they can't tell which listings match their courses. We'll know we've helped when a typical first-year buys half their list second-hand.
Notice what is missing: any mention of apps, filters or tags. The solution comes later, and it may not be the one you first imagine.
A second tool is to ask "why?" a few times, to travel from a symptom to a cause you can act on. "Sellers don't list books." Why? "Listing takes too long." Why? "They type the title, author and edition by hand."
The shortcut
Use the feature-word test: if your problem statement contains a feature noun (chat, notification, button, dashboard, app), it is a solution in disguise. Delete the feature and ask what pain it was meant to relieve.
Delete the feature
"We need chat" becomes "buyers and sellers can't ___". Fill the blank with what they fail to do: agree where and when to meet.
Drills
Answer fast — trust the rule.
Which of these is a well-framed problem?
"Sellers need push notifications when someone saves their book." What is wrong with this as a problem statement?
A problem statement names the users and their struggle but not how you'll know it's fixed. What becomes hard later?
"Sellers don't list their books." Asking why reveals that typing the title, author and edition takes ten minutes. What has asking why done?
Remember
- Name who hurts, what hurts, why it matters, and how you'll know it's fixed.
- Feature-word test: a feature noun in the problem means a solution in disguise.
- Trap: starting ideas from a vague problem, which only produces vague ideas.