Part 2: Product thinking, problem statements and the Bistro case

Module 1 · Sun 12 Jul

Product thinking starts with the problem, never the feature. Ask: who is the user, what outcome do they want, and what pain stops them? A good problem statement names all three clearly enough that a designer could act on it.

Problem statement template (class): "User needs this outcome because of this insight." For a design question like "design a smartwatch for the blind" (class example), start by unpacking the key nouns - who exactly is "blind", and what must a "smartwatch" do for them - before any features.

Innovation is step by step. Balloons and zeppelins already existed before the Wright Brothers - the airplane was the better solution for the next stage. Before Uber, people could still travel. Before building, check market readiness and validate - talk to real users, not imaginary personas. The "right" solution depends on what existing options fail to do.

• Great products feel intuitive, build trust and get better with repeat use - that's what makes people come back.
• Build product sense with teardowns: study real apps and launches and ask "why did they do this?"
• Prioritisation is ongoing and business-driven; every feature needs a success metric before you build it, or you'll never know if it worked.

Class case - Bistro by Blinkit (10-minute food): people try it but don't come back. The class dug into why - is the food fresh, is the menu repetitive, are refunds painful, is it trusted? Discounts bring trial, not habit. Lesson: retention is about perceived value, freshness, trust and habit, and you need evidence, not guesses.