Is Your Idea Big Enough? A Framework I Keep Coming Back To
Notes from my first ever Office Hours - and the question that kept finding me from every angle.
Last Wednesday morning I hosted my first ever Office Hours.
I was nervous. I’d put a sign-up form out into the world a couple weeks earlier, asked people to drop in their questions ahead of time, and then watched the responses pile up faster than I could read them. By the morning of, I had pages of pre-submitted questions, a Google Meet link, and absolutely no idea how this was going to go.
It went great. People showed up from six time zones. We covered a lot of ground - what the PM role looks like in 2026, how to stand out as a candidate without a traditional product background, the death of the long PRD, when to push for AI adoption inside a non-AI-first company, how to stay focused when there’s a new model release every other day. I’ll come back to some of those at the end.
But the question I want to write about today is one nobody asked directly. It just kept finding me from different angles, in different words, the entire hour.
How do you know if an idea is big enough?
Someone asked it as: how do you decide what’s worth building when you can prototype anything? Someone else asked it as: how do you balance shipping the current roadmap with rethinking it from scratch? A third person asked it as: when you look at a feature, how do you know whether to go deeper on it or pivot to something else entirely?
Same question. Different surfaces. And it’s one I’ve been sitting with for a while - long enough that I’ve developed a framework I keep reaching for when I’m trying to answer it. I’ve written about pieces of it before, but Office Hours was the first time I watched the same underlying question come at me from that many angles in an hour, and it made me want to write the whole thing down in one place.
I call it thinking in four directions.
The Framework
When I’m looking at an idea - a feature, a product area, a problem space - I try to look at it from four directions before I commit to a path. Not all at once. Not in any particular order. But I won’t feel good about a build until I’ve at least considered each one.
1. Backwards: what was the user doing right before this?
Most product thinking starts with the moment the user shows up at your front door. But there’s almost always a journey that got them there - and there’s usually a need somewhere upstream that you could also be solving. If you only solve the thing in front of you, you’re handing the pre-work to someone else. Sometimes that’s correct. Sometimes the real opportunity is to absorb a step or two of what they were doing before they ever got to you.
2. Forwards: what comes next, and after that, and after that?
If you successfully meet the need in front of the user, what’s the next thing they’re going to want? And after that? This is the part that PMs trained in the old world sometimes forget to think through. We’re so used to tightly scoping product requirements that we can skip over the part where you think about the underlying user goal, not just feature requests. Solve the feature and you’ve shipped a thing. Solve the goal and you’ve built something they’ll actually keep coming back to.
3. Deeper: how much further could you go on the thing itself?
This is the direction I think gets underused the most. Take the feature you’ve shipped and ask: am I really doing as much as I could here? Take NotebookLM’s slide generation as an example. They cracked the ability to turn a pile of source material into a real, coherent presentation - which is genuinely magical. Today you can already pick between a detailed deck and cleaner presenter slides, choose a language, set the length, and steer the style with a short prompt. That’s already a lot. But you can keep walking the vector. Could you edit an individual slide without regenerating the whole deck? Could you hand it a brand kit and have the styling actually stick? Could you riff with it on the structure before it commits to an outline? The feature isn’t a single point. It’s a direction, and you can keep going.
Important caveat: thinking deep doesn’t mean building deep on day one. You still want to scope an MVP that proves the capability is good, helpful, and wanted - and then decide to go deeper if it sticks. The point of the exercise isn’t to ship the maximum version. It’s to know how much room there is, so you don’t accidentally ship a shallow version of something that could have been a lot more, and then walk away from it because “the feature shipped.”
4. Up and out: is there a totally different way to do this now?
Every once in a while, you have to pop out of the immediate problem and look at the landscape. Has a new capability emerged that changes the shape of the answer? When NotebookLM launched cinematic video overviews, that wasn’t a deeper version of slide generation - it was a different answer to the same underlying need. The user wanted to absorb information visually. Slides were one solution. A narrated, scored, cinematic video is another. Sometimes the right move isn’t to go deeper on what you have. It’s to ask whether the thing you have is the only thing.
Why I find myself reaching for it
Three reasons.
The first is that it forces me to check whether an idea is big enough. One failure mode I see a lot right now - in my own thinking and in the PMs I talk to - isn’t picking the wrong idea. It’s picking an idea that’s too small. We’ve gotten so good at shipping that we forget to ask whether the thing we’re shipping is worth the effort it takes to ship it. Walking the four directions almost always reveals that the original framing was narrower than it needed to be.
The second is that it works on existing products, not just new ones. One of the questions I got at Office Hours was whether my advice was different for greenfield versus brownfield projects. My honest answer is: not really. Whether you’re starting from scratch or sitting on top of a product with real users and a real roadmap, the four directions still apply. They’re just applied in smaller increments. You don’t have to throw out the roadmap. You just have to keep asking, in each direction, whether you’re solving the problem as fully as you could be right now - given what’s possible right now, which is changing under your feet every few months.
The third is that it’s a check on my own laziness. It’s so easy, when you’ve been heads-down on a thing, to assume the shape of the answer is fixed. The four directions force me to look up. They force me to ask whether I’m in the right place at all.
What it doesn’t do
This framework won’t tell you which direction is the right one to walk in. That’s still on you - and that’s still where taste and judgment come in. Sometimes the right answer is to go deeper on what you have. Sometimes it’s to absorb the upstream work. Sometimes it’s to throw it all out and rebuild around a new capability. The four directions are a way of making sure you’ve at least seen the full landscape before you commit. They’re not a way of choosing for you.
I’ve also found it doesn’t replace the other thing I keep telling people, which is: just start building. The four directions are a thinking tool, but they get sharper the more you’ve actually built. You can stare at a whiteboard for hours and not see what one afternoon of prototyping will show you. Use them together.
🔒 Bonus: The Office Hours Debrief
The framework got a lot of airtime today. But every Office Hours has a second half - the part where someone asks a question that pulls the thread in a different direction and we end up somewhere I didn’t plan to go.
This one had a lot of those moments.
Welcome to the Debrief, where I share the rawer, in-progress threads from the session. These aren’t polished takes - they’re the questions I found most interesting, and where my thinking actually is right now.
