It is completely normal to include feature requests in a product roadmap and to be getting them developed when appropriate, that definitely isn't a problem. Things are also different when you have 1 client versus when you have 10+ clients. When you have 1-2 clients you generally do things you wouldn't and shouldn't normally do under good product management standards.
So let's assume you fall into the 10+ client category. The company should have a defined and published product roadmap that is being worked, new features should be vetted against the client demographic (e.g. it should benefit more then 50%, I usually set the bar higher early on like 80%) and if it passes that then it would be defined and put on the development schedule, but it should not disrupt the existing planned sprints on the roadmap. That means the client might have to wait to get this new feature, but the benefit is the product can be designed, kept reliable and stable and not get polluted with a bunch of make shift code and hacks. None of this has to be a crazy long process, it can be simple and quick and if sprints are 1-2 weeks, most likely many features can fit within the next 30-60-90 days at most (obviously assuming proper staffing etc).
The sales side of the business should never be in control of the development schedule, or product roadmap, it is a direct conflict of interest. Product management should be owned by an operations type person, CTO, COO but for sure a non-sales, and/or marketing focused person. This is what will make the company successful faster and help keep the product stable and on schedule. Founders when small have to wear many hats so they will be violating this all the time, but by the time they have hired a product manager, sales teams etc, the hacky crap has to stop if they want to succeed.
None of this means a client (or business) can't get a new feature turned around pretty quick, it just means that there is alignment of features to more than one client and that product stability, reliability and schedule are managed as first class problems. Startups struggle with this thinking it will slow things down, and they will lose deals, when in fact it speeds things up and makes everything more predictable. The key is requests can be done faster when the development teams can keep tech debt low and design things into the product properly. It also prevents the scrap it and rewrite it that happens when you don't plan well enough. To be fair, there is almost always 1-2 scrap code repositories early in the life of a startup, but it doesn't have to be that way, just usually works out that way because of people repeating preventable mistakes they haven't yet learned.
I do think it is important to recognize when you are first starting the company it is more free for all, scrappy and hacky, but even in those circumstances you should not be implementing features just because one client made a request.
So let's assume you fall into the 10+ client category. The company should have a defined and published product roadmap that is being worked, new features should be vetted against the client demographic (e.g. it should benefit more then 50%, I usually set the bar higher early on like 80%) and if it passes that then it would be defined and put on the development schedule, but it should not disrupt the existing planned sprints on the roadmap. That means the client might have to wait to get this new feature, but the benefit is the product can be designed, kept reliable and stable and not get polluted with a bunch of make shift code and hacks. None of this has to be a crazy long process, it can be simple and quick and if sprints are 1-2 weeks, most likely many features can fit within the next 30-60-90 days at most (obviously assuming proper staffing etc).
The sales side of the business should never be in control of the development schedule, or product roadmap, it is a direct conflict of interest. Product management should be owned by an operations type person, CTO, COO but for sure a non-sales, and/or marketing focused person. This is what will make the company successful faster and help keep the product stable and on schedule. Founders when small have to wear many hats so they will be violating this all the time, but by the time they have hired a product manager, sales teams etc, the hacky crap has to stop if they want to succeed.
None of this means a client (or business) can't get a new feature turned around pretty quick, it just means that there is alignment of features to more than one client and that product stability, reliability and schedule are managed as first class problems. Startups struggle with this thinking it will slow things down, and they will lose deals, when in fact it speeds things up and makes everything more predictable. The key is requests can be done faster when the development teams can keep tech debt low and design things into the product properly. It also prevents the scrap it and rewrite it that happens when you don't plan well enough. To be fair, there is almost always 1-2 scrap code repositories early in the life of a startup, but it doesn't have to be that way, just usually works out that way because of people repeating preventable mistakes they haven't yet learned.
I do think it is important to recognize when you are first starting the company it is more free for all, scrappy and hacky, but even in those circumstances you should not be implementing features just because one client made a request.