4 ms·

I wonder how many of these feature requests are because the client does not understand how the software should be used? It could be that it is not designed to

I wonder how many of these feature requests are because the client does not understand how the software should be used? It could be that it is not designed to solve there problem, and having purchased it they are trying to get some utility from it. Would not be the first time that had been forced to use a system that was not suitable.

TeMPOraL 5y ago
This just shows how ass-backwards the whole industry is with its "standard practices", a lot of which I see repeated as advice in the thread. It goes like this: 1. Push a product (or these days, service) at people. Preferably a captive audience. In B2B, that may involve growing an "internal champion" at a customer company, preferably a manager that doesn't need the software themselves, that can be bamboozled by your sales people. 2. Don't explain how the product works or what it does to your sales people. That's techie stuff. Also, once you give your sales people the license to bullshit, it literally doesn't matter what the product does[0]. 3. Don't ask your users what they want or like. They don't know what they need. Rely on thorough surveillance instead, as a good "data-driven" shop you are. 4. If some users manage to somehow deliver feedback to you, ignore it. Users don't know what they want, and can't articulate solutions. 5. If the client does not understand how the software should be used, that again means they just don't know what they want. Interfaces are designed to be intuitive. No training is ever necessary. Software manuals? That's so 1990. 6. The so-called "power users" are making point 5 harder. Ignore them with extreme prejudice. After all, them being more productive doesn't earn us more money. It's a self-reinforcing pattern of industry-wide self-delusion. No wonder so many non-tech people hate technology. On the "XY problem" someone mentioned in this thread: one of the biggest problems on StackOverflow and other forums, and previously on IRC, is that quite often, the person asking for X actually wants to know X, not the Y, and they especially don't want to have their sanity or competence questioned. -- [0] - Per HG Frankfurt, bullshit is when you don't care if what you say is true or false, as the reality is orthogonal to the goal you want to accomplish.
- Cipater 5y ago
  See this comment in the thread for more of the same attitude. https://news.ycombinator.com/item?id=28704103 https://news.ycombinator.com/item?id=28704103
jillesvangurp 5y ago
No it's a failure to get the right people involved at the right time. I'm currently a CTO and I also do product management currently. So, whenever this stuff goes wrong it's actually both my problem and my fault. My solution is to listen to sales and get involved in early in the sales pipeline to figure out what it is that our customers need and manage our roadmap accordingly. After the deal is closed is too late to do anything. Two things I've noticed with this is that sales people are selling what you don't have and not selling what you do have. Whenever that happens either you have the wrong product or you need to get your sales people up to speed with what the product actually is about. The worst is having features that would solve a problem that sales is simply not aware off or misunderstanding and therefore not selling to the companies they talk to. The key thing is involving the right people throughout the sales and requirements process and closing deals that align with roadmap & product and ensuring that near future product work aligns with what our sales people need to be able to close deals. When talking to customers, it's important to realize that the person purchasing is not going to be the person using the software typically. So there's a big risk of a he said that she said that he thinks that's what our users need summarized by the sales person as "the customer needs X, when can you deliver that". Most SAAS products sell a promise to IT managers that don't actually use the stuff directly but instead manage people that manage people that actually have to use the software. With sales in between development and all that, that's four levels of indirection. Breaking, through that and getting to the core of the issues is important. Having people in the room that understand both the business and technical constraints as well as the actual domain and users is key.

TeMPOraL 5y ago

This just shows how ass-backwards the whole industry is with its "standard practices", a lot of which I see repeated as advice in the thread. It goes like this: 1. Push a product (or these days, service) at people. Preferably a captive audience. In B2B, that may involve growing an "internal champion" at a customer company, preferably a manager that doesn't need the software themselves, that can be bamboozled by your sales people. 2. Don't explain how the product works or what it does to your sales people. That's techie stuff. Also, once you give your sales people the license to bullshit, it literally doesn't matter what the product does[0]. 3. Don't ask your users what they want or like. They don't know what they need. Rely on thorough surveillance instead, as a good "data-driven" shop you are. 4. If some users manage to somehow deliver feedback to you, ignore it. Users don't know what they want, and can't articulate solutions. 5. If the client does not understand how the software should be used, that again means they just don't know what they want. Interfaces are designed to be intuitive. No training is ever necessary. Software manuals? That's so 1990. 6. The so-called "power users" are making point 5 harder. Ignore them with extreme prejudice. After all, them being more productive doesn't earn us more money. It's a self-reinforcing pattern of industry-wide self-delusion. No wonder so many non-tech people hate technology. On the "XY problem" someone mentioned in this thread: one of the biggest problems on StackOverflow and other forums, and previously on IRC, is that quite often, the person asking for X actually wants to know X, not the Y, and they especially don't want to have their sanity or competence questioned. -- [0] - Per HG Frankfurt, bullshit is when you don't care if what you say is true or false, as the reality is orthogonal to the goal you want to accomplish.

Cipater 5y ago
See this comment in the thread for more of the same attitude. https://news.ycombinator.com/item?id=28704103 https://news.ycombinator.com/item?id=28704103

jillesvangurp 5y ago

No it's a failure to get the right people involved at the right time. I'm currently a CTO and I also do product management currently. So, whenever this stuff goes wrong it's actually both my problem and my fault. My solution is to listen to sales and get involved in early in the sales pipeline to figure out what it is that our customers need and manage our roadmap accordingly. After the deal is closed is too late to do anything. Two things I've noticed with this is that sales people are selling what you don't have and not selling what you do have. Whenever that happens either you have the wrong product or you need to get your sales people up to speed with what the product actually is about. The worst is having features that would solve a problem that sales is simply not aware off or misunderstanding and therefore not selling to the companies they talk to. The key thing is involving the right people throughout the sales and requirements process and closing deals that align with roadmap & product and ensuring that near future product work aligns with what our sales people need to be able to close deals. When talking to customers, it's important to realize that the person purchasing is not going to be the person using the software typically. So there's a big risk of a he said that she said that he thinks that's what our users need summarized by the sales person as "the customer needs X, when can you deliver that". Most SAAS products sell a promise to IT managers that don't actually use the stuff directly but instead manage people that manage people that actually have to use the software. With sales in between development and all that, that's four levels of indirection. Breaking, through that and getting to the core of the issues is important. Having people in the room that understand both the business and technical constraints as well as the actual domain and users is key.