Kanban is a pull system. Your PO can push how much they want into a TODO column, but it's still the people doing the work that will have to pull from the top of that once they have capacity.

When work is pushed what can happen is that "too much" work is pushed. If it exceeds the capacity of those doing the work, things will start to be delayed while waiting to be worked on, or because a lot of context switching is introduced that only makes everything take longer (maybe also introducing defects because of lack of focus, defects that then need to be fixed adding even more time).

So, in Kanban you pull work based on what you know you can handle, and you also make that visible with the WIP limits which basically reflect this fact.

In your comment above you say that:

[...] sometimes the customer keeps on asking more and more features, add this, change that [...]

Well, they can do that. Kanban is Agile, which means it welcomes change. If the customer realized something, they can ask for changes to better solve their needs. Often, people see something and realize they needed something else. That's why Agile says to deliver something working frequently, so that you get feedback and validate what you are building.

Obviously, there are changes and there are changes. There needs to be a balance between puting an effort on deciding what they want before you build something, and making changes after you've built it. If you have a very large number of changes demanded after the fact, then maybe you need to sit down with the customer and find a way to make the whole process more efficient, by still responding to changes, but not so much changes as to negate the in depth thinking about what needs to be built.

Kanban is a pull system. Your PO can push how much they want into a TODO column, but it's still the people doing the work that will have to pull from the top of that column once they have capacity.

When work is pushed, what can happen is that "too much" work is pushed. If it exceeds the capacity of those doing the work, things will start to be delayed while waiting to be worked on, or because a lot of context switching is introduced that only makes everything take longer (maybe also introducing defects because of lack of focus, defects that then need to be fixed, adding even more time to completing the work).

So, in Kanban you pull work based on what you know you can handle, and you also make that visible with WIP limits.

In your comment above you say that:

[...] sometimes the customer keeps on asking more and more features, add this, change that

Well, they can do that. Kanban is Agile, which means it welcomes change. If the customer realized something, they can ask for changes to better solve their needs. Often, people see something and realize they needed something else. That's why Agile says to deliver working software frequently, so that you collect feedback and validate what you are building.

Obviously, there are changes and there are changes. There needs to be a balance between the customer putting an effort on deciding what they want before you build them something, and making changes after you've built it. If you have a very large number of changes demanded after the fact, then maybe you need to sit down with the customer and find a way to make the whole process more efficient.

You will still need to respond to changes (this is not about forcing the client to provide very detailed upfront requirements), but not so much changes as to completely ignore the fact that the customer needs to think about what they want to be built.