If there’s one thing product management teaches you quickly, it’s this: ideas are easy – clarity is hard.

People come to you with excitement, half-formed thoughts, and big visions. “Let’s add this feature!” or “Users need something like this!” or “What if we built an AI version of our tool?” Sometimes the problem isn’t even clearly stated — just a vague sense that something needs to change.

Over the years, I’ve developed a personal process for breaking down these fuzzy, messy, sometimes chaotic moments and turning them into focused plans. Not just for the sake of execution — but for the sanity of everyone involved.

In this post, I’ll walk you through how I do it. Not theory — just what’s worked for me.

Ask Stupid Questions First

When someone shares a new idea, my first instinct isn’t to validate or critique it — it’s to slow down.

I ask basic, obvious questions:

  • “What’s the problem we’re trying to solve here?”
  • “Who is this for?”
  • “Why now?”
  • “How do we know it’s actually a problem?”

It’s amazing how often those questions surface assumptions, contradictions, or hidden opportunities. And even when the idea is solid, these questions help ground it in something real — user needs, business goals, or existing constraints.

My rule of thumb: if I can’t explain the idea back in one or two clear sentences, I don’t fully understand it yet.

Frame It As a Problem, Not a Feature

One of the most useful habits I’ve picked up is shifting the conversation from “what should we build?” to “what are we solving for?”

It sounds simple, but it changes everything.

Let’s say someone says, “We need a dashboard for users.” I’ll ask, “What would success look like if we had one? What pain is it solving? What’s missing right now?”

Reframing in terms of pain points or goals helps me:

  • Stay open to multiple solutions
  • Keep user perspective front and center
  • Avoid jumping to the most visible fix

It also makes conversations way more productive. We stop talking about what looks cool and start talking about what moves the needle.

Break It Down Like a Flowchart

I’m a visual thinker, so once I understand the problem, I sketch.

It’s rarely beautiful. Sometimes it’s just boxes and arrows in a notebook. Other times, it’s a quick FigJam with rough steps like:

  1. User lands here
  2. They click this
  3. If X, they see Y
  4. If not, they go here

This helps me in a few ways:

  • I spot complexity early (e.g. branching paths, edge cases)
  • I can communicate faster with designers and developers
  • I get a clearer sense of what the MVP actually is

I’m not trying to design the thing — I’m just trying to visualize how it works. And often, when I show someone the sketch, we realize we’ve been thinking about two different versions of the same idea. Better to catch that early.

Translate Into Actionable Bits

Once the concept is clearer, I start writing things down in a format I can actually work with.

Usually something like:

  • Problem: What we’re solving
  • Users: Who it’s for
  • Goals: What we want to happen
  • Constraints: What we need to consider (tech, timeline, scope)
  • Next Steps: What we need to explore, decide, or test

I’m not writing a PRD yet — I’m just giving shape to the chaos.

Sometimes this turns into a quick user story or hypothesis statement. Other times, it becomes a series of questions for the team: “Can we reuse this component?” or “How long would this take if we skip versioning?”

The point is to move the idea from discussion to direction.

Collaborate Without Overcomplicating

Once I have a rough shape, I bring in the right people: designers, devs, stakeholders — whoever needs to weigh in.

I share context, not commandments. Instead of saying, “Here’s what we’re doing,” I say, “Here’s what I think we’re solving and why. What am I missing?”

This is where trust and clarity pay off. If you’ve done the work to frame the problem and involve the team early, the feedback is sharper — and often more creative.

One lesson I’ve learned: collaboration doesn’t mean consensus. You won’t get perfect alignment on every detail. But if people understand the “why,” they’ll rally behind the “how.”

Cut Ruthlessly, Then Start

By this point, we usually have enough to get started — but not before one final step: cutting scope.

Here’s how I approach it:

  • What can we do without and still test the core idea?
  • What’s nice-to-have, but not required right now?
  • What can be user-tested before it’s fully built?

This is where product decisions matter. It’s not just about speed — it’s about learning faster. I try to get the most insight for the least effort. Sometimes that’s a prototype. Sometimes it’s a single user journey. Sometimes it’s just a Notion mockup.

Once we’ve narrowed it down, we move. It doesn’t have to be perfect. It just has to be testable.

Working through a messy problem is part intuition, part communication, and part grit. You won’t always get it right — but having a repeatable approach helps.

Here’s mine, in short:

  1. Ask dumb questions early
  2. Frame the problem clearly
  3. Visualize flows before features
  4. Write it down in plain language
  5. Share it with your team — and listen
  6. Trim it down, then ship something real

That’s how I go from idea to impact. It’s not flashy, but it works — and it helps keep the chaos at a level I can live with.