I agree that this is what I drew out of it. You can't hand wave away some pieces of the product as 'minimal' if they are directly applicable to the basic use case. I've been the audience that has to say 'great but the fact that this doesn't allow more than 20 things is a complete non-starter' constantly. You then wait for the next iteration and these critical changes aren't even talked about, and so you just give up on them and start working with the next vendor. Another variant I see often too is something that 'creates a job title' at the customer where their product is so much of a ongoing headache that you end up needing a FTE or department just to manage the thing. It is often quite apparent from the visible product where you ask about things like 'how does the system alert if there is a problem' or 'how do we know your agents are connecting' is a TODO item that says 'we defer to YOUR infrastructure' instead of having a plan that works through the whole system well.

I don't mind that people try to setup a minimal product or have people to be self-inserted to do the work that is planned to be automated later on the service company's side, but if your answer to the question 'if we use this product we'll have 1000 artifacts to configure, how do we do this efficiently' is 'you have to go one by one and we'll implement it later' on a product/service that clearly is going to have 1000's of things is just junky and not minimal at all.

EDIT: also don't be that person who says 'well you can do that with the API!' when you in fact can't do it through the API and/or it is the exact same level of clunkiness as the UI.