👷 The 4 Questions That Decide if Your Idea Deserves Your Time
You're afraid. So you say yes to everything that sounds impactful. That's exactly how you end up visible for the wrong reasons.
You are better at filtering other people’s ideas than your own.
When a stakeholder comes to you with a request, you slow down. You ask what decision this changes, who will use it, what happens if you don’t build it. Most requests don’t survive those questions. You know this. It’s part of the job.
But when the idea is yours, something shifts. The filter goes quiet.
The shiny new initiative you want to take but that would pull you away from the work that matters.
The cross-functional opportunity that flatters your ego but doesn’t serve your team.
The tool you want to introduce but won’t help.
The migration that’s interesting to do but doesn’t move anything.
The architectural rewrite that’s been sitting in your brain for two years.
These feel different because they’re yours. You built the case in your head. You refined the idea in isolation, without the friction of someone else needing to fund it, sponsor it, or use it. That’s the problem.
Your Ideas Deserve the Same Scrutiny
The same questions you ask the head of sales when they come to you with a request apply to your own backlog. “What decision does this change? Who’ll use it? What happens if we don’t?“ Most of your ideas won’t survive the filter either.
The filter needs to start earlier than the idea itself.
I run bi-weekly calls with a few selected people across the org. My jov in those calls is to listen. They tell me about their plans and frustrations, what’s slowing them down, what they’re worried about heading into the next quarter. I don’t need to invent problems. People tell me about them.
This matters because the filter only works if the pain is real and externally verified. If the idea starts inside your own head and you go looking for evidence that the pain exists, you’re just looking for a confirmation.
The calls flip the sequence. The pain comes first, from the source, and then you decide whether it’s worth solving.
Once you have a real pain, run it through four gates before you commit a single hour of your team’s time.
Here’s the framework
1. Start with the pain
Describe it precisely:
Does it have a measurable cost when it goes unsolved, or is it mostly an irritant?
Is it something others in the org feel, or is it your version of the problem?
2. Research
What’s the standard outside your org?
Is this the most important pain to be solving right now, or is there something more load-bearing sitting ahead of it?
Most engineers skip this step. They feel the pain, design a solution, and ship. The research gate is where you find out whether you’re solving the right thing or the familiar thing.
3. Think of different solutions
If you go into solution mode with the one you already want to build, you’re defending an idea, not evaluating a problem. Generate at least two alternatives before committing to an approach.
4. Talk to the people it affects
What do they think about the pain?
What do they think about your solution?
Are they willing to sponsor this, or do they have other initiatives that matter more to them right now?
This last question kills the most ideas, and rightfully so. A pain that nobody will prioritize is a pain the org has decided to live with.
If all four come back green, ship.
Remember to download the complete audit at the end of the article.
