Product management didn’t start this complicated – we’ve actively worked hard to make it that way. We’ve buried it under vision decks, prioritization frameworks (RICE, WSJF, KANO, MuSCoW blah blah), vanity metrics, and process fluff.

But when you strip it all down, its simple and It has always been simple:

Why. What. How. When.

That’s it.

---

1. Why

Everything starts with the “Why”.

If you don’t know why you are building something, everything else is meaningless. It’s the hardest to get right and even harder to explain. That’s why people skip it and jump straight into features. If you have access to users, talk to them. Ask simple questions. Let them ramble. Listen to what they repeat. If you don’t, then go where the complaints live – Reddit threads, App Store reviews, Twitter rants, support tickets. Frustration always leaves a trail, find it.

Start with friction, not features.

Don’t ask “What can we build?” , instead ask →

• “Where does it hurt?”
• “What keeps happening that shouldn’t?”
• “What are people hacking because the current flow doesn’t work?”

---

2. What

“What” is the bet you’re placing to solve the problem you uncovered in “Why”.

Not how it looks, Not how it works. Just what it is – in simple human terms. It’s not a feature list, a deck, a figma flow. It’s a clear call on what you think will make the pain go away (or at-least be less). You’re not describing everything. You are drawing a starting line. Something real enough to move on, but not weighed down by detail. If it needs a deck or walkthrough – it’s not clear yet.

Don’t confuse scope with clarity.

Don’t ask “What features can I ship fast?”, instead ask →

• What’s the bet we’re making?
• What’s the simplest form this solution can take?
• What’s the one thing that, if it works will prove that we are on the right track?

---

3. How

“How” is where your idea becomes a product.

Think in flows, not features. This is where you define the flows, the designs, and make tech that brings your “what” to life. It’s where things get specific, and often messy. This is also where the scope spirals. Roadmaps stretch. Jira boards overflow. But you don’t need to solve for everything – just what proves the bet.

Build just enough, and solid enough – to learn.

Don’t ask “How much can we build?”, instead ask →

• What’s the flow we’re prioritizing?
• What the simplest end-to-end design to support it?
• What tech and data do we need to power it now – without locking us in?
• And who else needs to be ready across the org – support, ops, sales, marketing, finance, etc?

---

4. When

“When” is the pressure that keeps your “how” honest.

Without a sense of time, nothing ships. Work just lingers, and adds over-thinking, over-building and over-explaining. Deadlines should be constraints not threats, and constraints are beautiful. They help you cut scope, make trade offs and stay focused on your core bet. Without this everything starts to feel important.

“When” isn’t about being done. It’s about proving your bet, or moving on.

Don’t ask “When will it be done?”, instead Pick a time box ->

• 6 weeks?
• 12 weeks?
• A quarter?

---

To me, it’s just these four things: why it matters, what are you betting on, how you’ll build it, and when will you ship. everything else is optional.

May be it’s too simple, may be it’s too naive – but that what I’m sticking with for – at least until I change my mind again. Adios!