When users never use the features they asked for

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.

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.

I once spent 6+ month working on a feature that was to be one of the flagship features of our next major release. We'd talked to several major customers about it and gotten lots of positive feedback. Once released, virtually no one used it and no one cared.

On the flip side the by far most impactful feature I've ever added to any software in any point in my career came a couple of years later when working at the same company. It was inspired by an offhand comment by someone in a meeting, and it wasn't anything anyone had ever asked for or even really solving a problem customers claimed to be having. I'd 'coded' the feature on a piece of paper by the end of the meeting and implemented it 2 days later, mostly just to see if it would work. I quietly added it in a minor point release with only a 1 line mention in the update doc.

That feature went on to become an everyday part of most of our customers workflow, and transform how they used and interacted with our app. Nobody, least of all me, had any idea how useful our customers would find that feature.

I work mainly in BI. Data mangling, Dashboards for the simple minded, pretty reports, such things. I somewhat like the more informal atmosphere of SMBs and normaly I'm regarded as some strange kind of Wizard (of Oz of course). Thank god, seldom I have to face a Dorothy. More often cowardly lions and Tin Mans. So, I more or less do what I want. And what's right of course. That means, I monitor the user behaviour meticulously and remove unused features without feedback from time to time. In the past I always asked before, but that meant to impose some decision on them and they don't like that. It awakens their bureaucratic white collar sub instinct. Some of them can't even remember such features were requested by them or even used one or two years ago. The timespan I use as a rule of thumb after I make a feature disappear. They can be outright indignant I imply they don't know anymore, what they did or knew.

I even had the chutzpah to suggest the feature again some time later. Never had a problem.

This isn't somewhat related - it's the root cause :-)