Why That Product

Four formats, one habit: ask why.

Here is what each one looks like, with a small taste you can poke at.

Teardowns

One product, taken apart

I pick a product you probably use, slow down on one screen, and ask why for every choice on it. Then I tell you what I think they were solving for, and what I'd check to be sure.

  1. The hookA question you've never asked about something you use daily.
  2. The screenOne screen, slowed down, with each choice pointed out.
  3. The whyMy honest guess at the decision behind it, marked as a guess.
  4. The testWhat I'd measure to find out if the guess is right.

Hooks I like:

Everyone uses this app. Almost nobody asks why it works.
This feature looks small. The reason behind it isn't.
This product failed, and it wasn't the idea. Here's why.
Would They Pay?

A verdict on real demand

Founders hear "that's a great idea" all the time. It costs the speaker nothing. In this format I look at an idea and ask what kind of evidence would show that someone would actually pay. Try the ladder below.

The idea: a monthly box with one new snack from a different state each time.

Weak evidence.

Someone says it sounds nice. Saying yes costs nothing, so I treat it as politeness until something else backs it up.

Discovery diaries

Learning to talk to users, in public

User discovery is a skill, and I'm practicing it where you can see. These are notes from real conversations: the first calls that felt awkward, the questions that went nowhere, and the answer that changed the idea. The biggest lesson so far is how a question gets asked.

Questions that flop, and what I ask now:

Would you use this?
Tell me about the last time you had this problem.
Do you think this is a good idea?
What did you do the last time you needed this?
Would you pay for this?
What are you paying, in time or money, to solve it today?
Interview prep

Answer in two minutes, without a framework

Product sense questions feel scary until you notice the pattern. Pick any app, and an interviewer wants to hear you reason, not recite. Most answers get better when you ask these three whys, in this order.

  1. Why who?Why this user, and not another one? Name the person you're building for.
  2. Why this?Why is this their real problem? Say what they do today instead.
  3. Why that fix?Why this change first, and how would you know it worked?

Questions I practice with:

Pick any app. How would you improve it?
Why did you build this feature?

Want one of these about your product?

Tell me what you use, build, or can't stop wondering about, and it might become the next one.

Request a teardown See how it's going