>>Pressing them directly on why they were not using ContractBeast to create all their contracts resulted in a lot of feature requests.<p>>> Now, talking with customers about features is tricky. Often you receive solid and useful ideas. Occasionally a customer will provide an insight that will change the way you look at your product. But most of the time, customers don’t really want the features they are asking for. At least not very badly.<p>This a thoughtful, well-rounded and obviously experienced view, but ultimately it shades toward being very pessimistic about the competence of the end-user.<p>>>When users are unhappy but can’t explain exactly why, they often express that dissatisfaction as a series of tangential, trivial feature requests.<p>Clearly, the writer had the self-reflection to realize that the product wasn't working, and for that should be applauded. On the other hand, maybe there's something a little intentionally self-blinding about the above statement. Assuming that people are just putting out meaningless feature requests because they'll never use the software anyway is, to say the least, taking things from a very negative starting point of view. Maybe something larger was actually missed in the "tangential, trivial feature requests" which if compiled would have pointed to a fixable underlying problem if one were take them seriously as a constellation of indicators pointing to a root issue.<p>This is speculative:<p>>>These aren’t necessarily bad ideas, but they had nothing to do with why they were not using ContractBeast more extensively.<p>This is indicative of burnout, where you stop seeing the value (for other reasons which are harder to quantify):<p>>>In any event, I was overwhelmingly getting these kinds of tangential, trivial feature requests.<p>And this is resignation:<p>>>It didn’t provide a significant immediate benefit. I was fighting human nature and losing.<p>If I'd been sitting around that office, I might have suggested adding a human consultant to the loop for every new client from onboarding to full use -- not a virtual pop-up box, but someone they could call on the phone. And not to sell anything but to suggest uses and help implement the changes to the customer's business ops that they would then come to rely on. Mid-sized businesses don't make drastic changes overnight but that's also a guarantee of lock-in if you can convince them to rely on your product. So you'd give each one a sort of a "guardian beast angel" if you like, who was available at all hours. The sole purpose of the employee would be to track a few dozen customers and their user experience, really understand how this worked in their business models, and find ways to improve their use of the software while filtering back some feature requests and bugs. And thus get the customers to realize the full benefits of the software, without any attempt to sell them anything. This kind of thing would be a loss leader, it would be money out of pocket, but it would be far more cost effective than any kind of advertising, and it would establish trust and good word of mouth in addition to providing a customer base that was now dependent on you. Also, it wouldn't have involved actually writing any new features if you felt that the software was already sufficient to the tasks most users would require, if they knew how to use it properly. It would also give you runway to roll out new features on your own timetable without constantly trying to please an audience, since the customer-facing "beasts" would provide workarounds for niche use cases and reassure them personally that improvements were in the pipeline.