Product Thinking — Part 1: What Makes Something Worth Building
maang.io AI-Native Builder Series
What is this?
Imagine you give your brilliant-but-tasteless cook a single order: "make me dinner." The cook is fast and flawless, so two minutes later a plate appears. It's a perfectly executed dish of plain boiled cabbage. Technically food. Technically dinner. Nobody wants it. The cook did exactly what you asked — the failure wasn't the cooking, it was the order. You never said who was eating, what they were hungry for, or what would make them happy. You skipped the thinking and jumped straight to "make."
This is the single most common way software dies. Not because the code was bad — the code is easy now, the cook is fast — but because nobody stopped to ask what's actually worth making, and for whom. Product thinking is that pause. It's the work of figuring out the right dish before anyone fires up the stove. In the AI-Native Mindset topic you learned that you are the director: you bring judgment, the AI brings speed. Product thinking is where that judgment starts — the very first thing a director decides is what story is even worth telling.
The one-line idea: before you build anything, you have to know the real problem you're solving, exactly who has it, and whether the value is genuine — because the most expensive mistake in software is building the wrong thing well.
That last line is the whole topic. The cabbage was cooked perfectly. It was still the wrong dinner.
Three questions sit underneath every app worth building, and they form a kind of triangle — pull any corner out and the whole thing collapses:
We'll take these one corner at a time, then snap them back together at the end.
1. Solutions are cheap; problems are the hard part
Here's a trap almost every beginner falls into, and it feels like the opposite of a trap. You get excited about a solution — "an app with a leaderboard!", "something that uses AI to recommend stuff!", "a social network but for X" — and you start building it. The energy is real. But you've started from the wrong end.
A solution is the thing you build (an app, a feature, a button). A problem is the real difficulty a real person is having before your thing exists. Solutions are easy to dream up and, now, easy to build. Problems — genuine ones that people actually feel — are rare and valuable. The whole skill is starting from the problem.
Notice the difference. The top path might be solving a real problem — but you won't find out until after you've built it, which is the most expensive possible moment to learn you were wrong. The bottom path starts from a difficulty a real person feels, then picks the solution that fits. Same amount of building. Wildly different odds of mattering.
💡 A quick test you can run on any app idea: can you finish the sentence "This helps someone who is struggling with something specific" — with real names in both blanks? If you can only describe the thing you'd build and not the struggle it relieves, you're starting from the wrong end.
Let's apply it to our own app. StreakUp didn't start as "let's build a habit tracker with streaks." It started as a problem:
"I decide to build a habit — read every night, go for a run — and I'm great for about three days. Then I miss one day, lose all momentum, and quietly give up. I never see my own progress, so it never feels real."
That's a problem. A specific, felt, human difficulty. Only then does the solution appear: show the habit, let me check it off, and count the days in a row so the progress is visible and breaking the chain feels like something to avoid. The streak isn't the idea — it's the answer to the problem. That ordering is everything.
2. Who is "the user," really?
The fastest way to build something nobody wants is to build it for "everyone." It feels generous and ambitious. It's actually fatal. When you design for everyone, you make a thousand small choices to please an imaginary average person who doesn't exist — and you end up with something blandly okay for all and genuinely great for none. The boiled cabbage of apps.
The user is the specific person you're building for — and "specific" is the load-bearing word. Real products are built for a sharp, narrow person first, and grow outward only later.
Counterintuitively, the narrower you aim, the more people end up liking it — because sharp, confident choices feel like the app "gets" them. Instagram started as a photo app for a small set of people who cared about filters, not "a place for all human visual communication." The narrow start is a feature, not a limitation.
For StreakUp, we're not building for "people who want to be productive." We're building for someone specific:
A high-school student who keeps starting good habits and abandoning them, who has their phone constantly, and who is motivated by visible progress and not wanting to break a streak.
That sentence is going to make a hundred decisions for us later. Watch how a sharp user description quietly becomes design decisions before you've drawn anything:
We haven't designed a single screen, and the user has already started designing the app for us. That's the power of being specific. (In Part 2 we'll make this person even more concrete with a persona.)
3. What "value" really means: painkillers vs. vitamins
Okay — you've got a real problem and a specific user. The next question is the one that quietly decides whether anyone keeps using your app: how badly do they need it? There's a classic way to think about this, borrowed from medicine: is your product a painkiller or a vitamin?
- A painkiller solves a problem the user actively feels and wants gone right now. You have a headache; you take the pill; the relief is obvious and immediate. People seek painkillers out, remember them, and come back.
- A vitamin is nice for you in some vague, long-term way, but you don't feel a sharp pain without it. It's easy to mean to take it, easy to forget, and easy to stop. People drift away from vitamins.
Most apps that fail aren't badly built — they're vitamins nobody remembers to take. "An app that shows you an inspiring quote each day" is a vitamin. Pleasant, harmless, forgettable. Nobody's day is ruined without it, so nobody opens it twice.
⚠️ Here's the honest part: StreakUp is closer to a vitamin than a painkiller by default, and that's exactly the risk we have to design against. Nobody is in acute pain because they didn't track a habit. So the entire job of the product is to manufacture a small, real, felt pain — the sting of seeing your streak about to reset to zero. That sting is the painkiller mechanism. It's why the streak resets on a missed day instead of just pausing. We're deliberately turning a vitamin into something with a little bite, because a little bite is what brings people back.
💡 The painkiller-vs-vitamin lens is one you'll reuse on every feature, not just the whole app. When you're tempted to add something later — charts, reminders, friends — ask: is this relieving a felt pain, or is it a vitamin I think people should want? Vitamins are where roadmaps go to die.
This is also a perfect example of what only you can know. The AI can describe the difference between painkillers and vitamins beautifully — it has read a thousand articles about it. But the AI cannot feel the sting of breaking your own streak. It doesn't know whether your specific user actually feels that pain. Judging real human value is the director's job, and it can't be outsourced.
4. Why most apps fail: solving a non-problem
Let's put the pieces together into the single most common cause of death for new apps. It's not bad code, bad design, or even bad marketing. It's building a polished, working solution to a problem nobody actually has. A non-problem.
A non-problem is a difficulty that sounds plausible in your head but that no real person actually loses sleep over. "People don't have a single place to organize their thoughts about their houseplants." Maybe true! Also: nobody is suffering from this. You can build a gorgeous houseplant-thought-organizer and it will be a perfect, empty restaurant.
Walk down that diagram and you've got the entire toolkit from this chapter: a real problem, a specific user, and genuine, felt value. Three yes-answers, and you've earned the right to start building. A single "no" and you'd be cooking cabbage — perfectly, for nobody.
🚫 The pitfall to name out loud: it is deeply tempting to skip this chapter's questions because they feel slow and obvious, and the AI makes building feel free. But "the building is free" is exactly why product thinking matters more now, not less. When it cost months to build the wrong thing, the cost itself slowed you down. Now you can build the wrong thing in a weekend — which means the only thing standing between you and a beautiful, useless app is you, asking these three questions first.
This is the deal product thinking makes with you: spend a little judgment up front, and everything downstream — the requirements, the stories, the spec, the actual code — points at something that matters. Skip it, and the AI will help you build the wrong thing faster than anyone in history.
Key takeaways
- Start from the problem, not the solution. Solutions (apps, features, buttons) are cheap and easy to dream up; real, felt problems are rare and valuable. If you can only describe the thing you'd build and not the struggle it relieves, you're starting from the wrong end.
- Build for someone specific, not "everyone." The narrower and sharper your user, the more people end up loving the result. A vague "for everyone" produces bland choices nobody needs.
- Aim for a painkiller, not a vitamin. A painkiller relieves a felt, right-now pain and people come back; a vitamin is vaguely good-for-you and quietly forgotten. StreakUp earns its bite from the sting of a resetting streak.
- Most apps fail by solving a non-problem — building a polished solution to a difficulty no real person feels. Run every idea through three yes/no gates: real problem? specific user? genuine value?
- Only you can judge real human value. The AI can explain these ideas perfectly but can't feel whether your user actually has the pain. That judgment is the director's job — the "why" is yours.
Your turn
Open your build journal — you're about to take the first real step toward your Spec Package. For StreakUp (or, if you prefer, your own app idea):
- Write the problem in one paragraph, in a real person's voice — the actual difficulty they feel before the app exists. Don't mention any feature. (Use the StreakUp problem in Section 1 as a model.)
- Name the specific user in one sentence — as narrow and concrete as you can make it. Resist the word "everyone."
- Decide: painkiller or vitamin? Write one sentence on what felt pain your app relieves. If you can't find one, that's not a failure — it's the most useful thing you could discover right now.
In Part 2, we'll turn that specific user into a full-blown persona — a concrete imagined person you can design for — and learn the single most useful product-thinking tool there is: figuring out the job people are really hiring your app to do.