The more we build our SaaS, the less we think it's about features.
Working on Trackly has changed how I think about product development.
Early on, every new customer request felt like another feature to build.
Now, before adding anything, we ask one question:
"Does this help someone make a better decision?"
For example, instead of thinking:
❌ "Let's add another dashboard."
We ask:
✅ "What question is a manager trying to answer?"
Who's working today?
Are work hours being recorded accurately?
Where is time being lost?
What needs attention right now?
That mindset has helped us prioritize much better and avoid building features just because they sound good.
I'm curious how other SaaS founders handle this.
What's your rule for deciding whether a feature request gets built or goes into the backlog?
That shift is usually a sign of getting closer to the real business. Buyers pay for a reliable change in their workflow, so the roadmap should connect every feature to adoption, time saved, revenue created, or risk reduced.
"Does this help someone make a better decision" is a good filter, and better than most. But your own examples quietly answer a question I raised on an earlier Trackly post, and it's worth noticing: "Who's working today? Are work hours being recorded accurately?" That's not decision support, that's oversight. You've picked your buyer, and it's the manager who wants visibility, not the team that wants fewer status meetings.
That's a legitimate choice, but it should be a conscious one, because it changes everything downstream. If the manager is the buyer, per-seat pricing works, your messaging should be about accountability and accurate hours, and you're competing with Hubstaff and Time Doctor, not Geekbot. If you're still telling the team it's about killing standups while the feature set serves surveillance, the two audiences will feel the mismatch, and the team will resist adoption, which kills manager renewals.
On your actual question, the rule I'd add to yours: whose decision? "Does this help someone make a better decision" is one step short, because in a two-sided tool the same feature can help one side and hurt the other. Accurate hour tracking helps a manager decide and makes an employee feel watched. The sharper filter is "does this help my primary buyer decide, without making the daily user resent the tool." Features that fail the second half get adopted on paper and abandoned in practice.
The other rule worth having: build the request only if the person asking would churn without it. Most requests are preferences, few are conditions of staying. Asking "would you leave if we never built this" separates them fast.
That primary-buyer clarity question is what I spend my time on, I'm part of the team building Hivemind, an AI strategy copilot. If you want to pressure-test the manager-vs-team framing: https://hivemind.myosin.xyz
That's a thoughtful perspective, and I agree that "whose decision?" is an important question. One thing we've been careful about with Trackly is avoiding the surveillance mindset. Our goal isn't to monitor every action, but to reduce the manual work around attendance, payroll, and workforce coordination so managers have clarity without constantly interrupting their teams. If a feature improves visibility but creates unnecessary friction for employees, that's a tradeoff we're not interested in making. I also like your churn filter. Distinguishing between a preference and a true retention driver is something every founder should probably do more often.