I’ve been reflecting on one of the most important lessons we’ve learned as a product team: the critical importance of using our own product. Not just testing it during development, but genuinely relying on it in our day-to-day work.
When we first built our application, it was born out of necessity. We had a team of less technical people who needed to automate complex processes without requiring specialized knowledge. The initial build solved that immediate problem.
But the real transformation in our product came from something unexpected: we kept using it ourselves.
Where Real Improvement Comes From
I was at an event recently, working through our own workflow, when I caught myself thinking, “This is taking longer than it should.” That moment of friction,that feeling of “there has to be a better way”,became our next product improvement.
Here’s why that matters: I wasn’t experiencing it as a developer looking at code. I was experiencing it as a user trying to accomplish a task. That shift in perspective makes all the difference. When you’re building, you’re thinking about how the system works. When you’re using, you’re thinking about what you’re trying to accomplish.
If you’re not using your own product, you’re missing out on the most valuable feedback loop available. You miss seeing it through your clients’ eyes. You miss understanding what’s actually broken versus what works well. You miss the small friction points that compound into major usability issues.
Living Your Values Through Product Use
One of our core values at Sardius is “best answer wins.” Living that value means constantly asking ourselves: Is this the best way to do this? Is this what our clients actually need? Is this approach serving them well?
You can’t answer those questions from a distance. You can’t answer them by looking at analytics alone. You have to put yourself in the experience, feel the friction, notice what works, and pay attention to what could be better.
This doesn’t mean you need to use every feature every day. But you should be a genuine user of your core workflows. Set up systems that require you to interact with your product regularly. Use it in real scenarios where there are real consequences if it doesn’t work well.
When your team members are actual users of what you’re building, the conversation changes. You’re not debating abstract features. You’re discussing real experiences. The best answer wins because everyone has skin in the game.
What’s one friction point you’ve discovered in your own product recently? I’d love to hear how you’re turning those insights into improvements.