Good luck getting the customer to provide feedback on a <2 week cycle. Ime. customer feedback and/or approval is a serious dev bottleneck.

That is also feedback. Having unresponsive customers is a bad sign, often suggesting that maybe they're not as interested in the product as the smiles the hyper-gregarious sales team receives would suggest.

It’s not always about customer feedback when implementing functionality. For instance, take the rules governing rail car maintenance.

https://www.railinc.com/rportal/documents/18/260641/Guidefor...

The software for it has to work. There will be months of work implementing the rules engine before you have anything to show the customer besides a mock-up..

You won’t really need two week sprints to get feedback from customers. It either implements all of the rules or it doesn’t. I can imagine the same happening for tax software.

That’s taking a strictly algorithmic approach, and assumes the rules are equally understood by all parties and have no inconsistencies or undefined states. And as an example, I happen to know TaxCycle is unusually responsive to customer feedback on releases and offers early previews. Here’s a list of improvements from 2017 feedback: https://www.taxcycle.com/News/Your-feedback-becomes-features...

Your customer might not have the manpower to test your product all the time. They're presumably already spending a lot of money on you, they might not want to spend an extra headcount just for testing your work. They might feel that that's your job.

Happens all the time, and usually ends up in disaster. Not willing to test means that don't know or care, and you are throwing darts blindfolded hoping to luck into what they imagine they want. I've been on projects customer would say, "I don't need to see it, I know you're going to blow us away!" You do your best but it never ended well.

The best is when the team delivers 100% what was specified on the Jira items, do the demo after several failed attempts to get feedback and then they state that "it is nice but not really what we want".

> They might feel that that's your job.

If a customer isn't committed to the project, then I'd worry about committing to it as well. Even if the contract guaranteed I'll get paid, there are few things as demoralising as a project falling over because, once push came to shove, the customer didn't even have the manpower to deploy your product. Those are usually the same people who would do the evaluation, so with my experience, as an employee, if they're not there, I'm going to look for a project where they are — regardless of how confident sales might be.

You must have much better end users than I have. My users seem completely incapable of looking at a half finished, sort of working proof of concept and not get bogged down focusing on everything that obviously doesn't work. I definitely agree that you should talk to your end users all the time, and ideally observe them working and using your product (or your competitors product) to the extent it's possible, but I've never had much luck discussing rickety proof of concepts with them.

The problem with all the devs talking to users is that many of them are bad at it and have no desire to do it or improve at it. So that means you are either very, very limited in who you hire or you have to have some devs that don’t talk to the users.