Yes, being a product teamer involves a lot of geeking out on fixing and developing your product. Diving into new requirements and adding elegant new features to meet them. In constant development mode, expanding your system’s capabilities.
That work is important, to be sure. But it’s also easy to get carried away focusing on the next big thing you’re adding, at the cost of something even more important.
That's why we say develop slow, respond fast.
Because there's another piece of the puzzle that is implicit to how this whole thing works, and that is the healthy and robust use of the system as it exists today. Specifically support and training, bug-fixing, and a general guiding philosophy over overwhelming helpfulness.
If you want your product to succeed, the road to success is not by putting every bell or whistle you could imagine onto the machine. Think first of making sure the people using your product are helped every step of the way to remove roadblocks to their use. No more arms crossed disappointed looks when they're not doing it right, despite "having got the training, twice!" We have to move to a support mentality that recognizes that if the product isn't used, it's useless. And that people need a ton of support to get to a highly effective level of adoption.
No question, there is also a critical role to be played by new features and larger expansion/integration projects. But even still, develop slow still applies. You aren't always jumping in adding a feature at someone's request. Rather, get things on the roadmap, prioritize them by leverage and lift. And execute them thoughtfully and strategically.
So build an essential function, yes, and then do everything in your power to help the people using it succeed. Everything in your power. Sit with them, be a wide open door to their frustrations and struggles, listen, see what you can do. Questions and requests may take time to handle but they are not a burden. They are a necessary and healthy symptom of success.