4 ms·

The solution to this problem is to solicit user feedback all the time. As in, the moment you get your code kinda sorta working you get some feedback from the ul

The solution to this problem is to solicit user feedback all the time. As in, the moment you get your code kinda sorta working you get some feedback from the ultimate end users (e.g. NOT the product manager, LOL)... "This rough implementation is how I (we) envision this feature working. What do you think?" "We've got the feature working well but it requires non-trivial back end changes. Would you be willing to wait or will you be satisfied if it works but only in a very manual way until we get the back end changes in place?" Week 2 after release: "The feature is live... What do you think? How is it working?" These are conversations the developers should be having with the end users. Regularly! It's when developers only ever talk to their boss and/or the project manager that pushes development into the anti-user zone.

gronne 8y ago
Good luck getting the customer to provide feedback on a <2 week cycle. Ime. customer feedback and/or approval is a serious dev bottleneck.
- LaGrange 8y ago
  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.
  - scarface74 8y ago
    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/GuideforRailroads.pdf 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.
    - lstamour 8y ago
      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-in-TaxCycle-Look-what-youve-done-for-TaxCycle-this-year https://www.taxcycle.com/News/Your-feedback-becomes-features...
  - adrianN 8y ago
    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.
    - WillPostForFood 8y ago
      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.
      - pjmlp 8y ago
        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".
    - LaGrange 8y ago
      > 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.
mason55 8y ago
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.
dagw 8y ago
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.

gronne 8y ago

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

LaGrange 8y ago
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.
- scarface74 8y ago
  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/GuideforRailroads.pdf 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.
  - lstamour 8y ago
    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-in-TaxCycle-Look-what-youve-done-for-TaxCycle-this-year https://www.taxcycle.com/News/Your-feedback-becomes-features...
- adrianN 8y ago
  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.
  - WillPostForFood 8y ago
    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.
    - pjmlp 8y ago
      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".
  - LaGrange 8y ago
    > 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.

mason55 8y ago

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.

dagw 8y ago

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.