Our Decision Framework
How we decide what to build, what to skip, and when to say no. It's not about process—it's about asking the right questions.
The hardest part of building software isn't writing code. It's deciding what to build in the first place. Teams waste months building the wrong things because they never stopped to ask the right questions.
Our framework is simple: brutal honesty, clear prioritization, and a bias toward measurable outcomes.
The Five Questions
Before we commit to building anything—feature, product, or system—we ask five questions. If we can't answer them clearly, we don't build.
1. Who is this for, specifically?
"Users" is not an answer. We need a specific person with a specific problem. If we can't name them, we can't build for them.
Example: "Clinic administrators who manage 50+ patient appointments daily and struggle with no-shows"
2. What problem does this solve?
Not what feature it adds, but what pain it removes. Problems are concrete and measurable. Features are abstract.
Example: "Reduces no-show rates from 20% to under 5%, saving clinics $50K+ annually"
3. How will we measure success?
Define the metric before we build. If we can't measure it, we can't know if it works.
Example: "50% of clinics using this feature within 3 months, with average no-show reduction of 10%"
4. What's the simplest version?
Strip everything down to the core. Build the minimum that solves the problem. Add later if needed.
Example: "SMS reminders 24 hours before appointment. That's it. No customization, no fancy UI."
5. What are we NOT building?
Explicitly list what's out of scope. This prevents feature creep and keeps the team focused.
Example: "No email reminders, no custom scheduling, no patient portal integration—for now."
How We Prioritize
Once we answer the five questions, we score every feature on two dimensions: Impact and Effort. This gives us four categories:
High Impact, Low Effort
Do immediately.
These are the wins that justify themselves. Build them first.
High Impact, High Effort
Plan carefully.
Worth doing, but requires thoughtful execution and phasing.
Low Impact, Low Effort
Maybe later.
Nice to have, but don't prioritize over meaningful work.
Low Impact, High Effort
Don't build.
These are traps. No matter how cool they sound, skip them.
When to Say No
Saying no is harder than saying yes. But it's more important. Here's when we say no:
- ✗When we can't measure it. If success is subjective, we're guessing.
- ✗When it solves a theoretical problem. No real user, no real problem, no build.
- ✗When it's a "nice to have." We build must-haves first.
- ✗When it creates long-term debt. Quick wins that create permanent slowness aren't wins.
- ✗When it's a distraction. Every feature competes for focus. Choose carefully.
The Bottom Line
A good framework doesn't make decisions for you. It forces you to think clearly about what matters and why.
Most software fails not because teams built it wrong, but because they built the wrong thing. This framework helps us build the right thing.