Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When users never use the features they asked for

web.eecs.utk.edu

Post reply on HN
Print view View original

151–160 of 228 posts

Re: When users never use the features they asked for

#151

Post by camtarn »

oceanghost wrote: post #129
ducktective wrote: post #123

Earlier quoted context omitted.

So essentially your are a hardware shop. I wonder how a web service on your side fits on all this..

Yea, we were a consumer electronics company that mostly was subcontracted out to make components or complete hardware. I remember working on products for Denon, Crestron, Roku, Samsung, LG, Direct TV, Microsoft, HP, Nintendo, Sony and Audiovox (and their subsidiaries--Monster etc), and in Europe, One For All brand. It was honestly pretty exciting. Regarding web services, like I said, we had a library of these wavefor…

This is super interesting! Shame that you can't tell us more - I'm very curious what could link products from these companies.

Re: When users never use the features they asked for

#152

Post by MayeulC »

danjac wrote: post #125

I remember a conversation with an inexperienced PM, who was still in the mode "we need to add X because a customer asked for it". What I've learned - although I've never had a PM role - is not to blindly just give customers what they ask for, but to figure out what they really need. Their feature requests are often a proxy for something else they aren't able to articulate. Another thing to be careful about is adding…

> not to blindly just give customers what they ask for, but to figure out what they really need

Classically called an xy problem: https://xyproblem.info/

Re: When users never use the features they asked for

#153

Post by TheOtherHobbes »

notatoad wrote: post #73
olivierlacan wrote: post #58

Earlier quoted context omitted.

This is why changelogs and release notes are not optional or tucked away in a dark corner. And users who request features need to be notified (actively, specifically) that something they requested or a bug they hit was resolved or addressed. I know, that's a lot of work. But what's the point of fixing things if you never tell someone it's fixed.

changelogs and release notes don't get read. unless you're sending personal emails to the users who requested the feature, the experience in the essay here is the only way: make it automatic or turned on by default. and if it's not good enough to be automatic or enabled by default, then keep iterating until it is.

Changelogs are for developers, not users.

They're a bad way to communicate specifics because they're literally a long list of changes, most of which are boring/irrelevant to most people.

If you're releasing new features you need more ceremony. Maybe an email with targeted specifics, or at least a section on your website which highlights big important new features.

Re: When users never use the features they asked for

#154

Post by zhdc1 »

danjac wrote: post #125

I remember a conversation with an inexperienced PM, who was still in the mode "we need to add X because a customer asked for it". What I've learned - although I've never had a PM role - is not to blindly just give customers what they ask for, but to figure out what they really need. Their feature requests are often a proxy for something else they aren't able to articulate. Another thing to be careful about is adding…

One piece of advice I was told years ago as an intern. If a customer wants it, they have to pay for all of it, and once it's done, you have the right to provide it as a feature or service to other customers as you see fit.

Re: When users never use the features they asked for

#155

Post by Slartie »

oceanghost wrote: post #129
ducktective wrote: post #123

Earlier quoted context omitted.

So essentially your are a hardware shop. I wonder how a web service on your side fits on all this..

Yea, we were a consumer electronics company that mostly was subcontracted out to make components or complete hardware. I remember working on products for Denon, Crestron, Roku, Samsung, LG, Direct TV, Microsoft, HP, Nintendo, Sony and Audiovox (and their subsidiaries--Monster etc), and in Europe, One For All brand. It was honestly pretty exciting. Regarding web services, like I said, we had a library of these wavefor…

Ah, so I'd guess you were producing some chip that generated IR signals to control various consumer electronics devices, and the library is a library of control commands of thousands of devices of different manufacturers.

Basically what you need to build a universal remote control, or a remote control for a specific device that includes controlling capabilities for other manufacturers' devices.

Re: When users never use the features they asked for

#156

Post by bruce343434 »

inopinatus wrote: post #150
danjac wrote: post #125

I remember a conversation with an inexperienced PM, who was still in the mode "we need to add X because a customer asked for it". What I've learned - although I've never had a PM role - is not to blindly just give customers what they ask for, but to figure out what they really need. Their feature requests are often a proxy for something else they aren't able to articulate. Another thing to be careful about is adding…

One option is to implement a non-working version of the apparently unnecessary feature. In the unlikely event someone tries to use it, an exception is trapped, and the appearance is given that there's a bug inhibiting the feature use. A brief apology is issued. Then, and only then, does the development team actually implement the feature.

Real life lazy evaluation, I like it

Re: When users never use the features they asked for

#158

Post by foldr »

xyzelement wrote: post #53

I moved from engineering to product management precisely because I realized that the problem of "what should be built" is often harder than building the thing. Asking users what features they want is pretty much not fair - because most people don't have the skills to think through and answer that question, nor is it their job to do it. It's like asking a novel reader what they'd like to see in the next chapter. It's…

>It's like asking a novel reader what they'd like to see in the next chapter.

I love this analogy.

Re: When users never use the features they asked for

#159

Post by jerrre »

inopinatus wrote: post #150
danjac wrote: post #125

I remember a conversation with an inexperienced PM, who was still in the mode "we need to add X because a customer asked for it". What I've learned - although I've never had a PM role - is not to blindly just give customers what they ask for, but to figure out what they really need. Their feature requests are often a proxy for something else they aren't able to articulate. Another thing to be careful about is adding…

One option is to implement a non-working version of the apparently unnecessary feature. In the unlikely event someone tries to use it, an exception is trapped, and the appearance is given that there's a bug inhibiting the feature use. A brief apology is issued. Then, and only then, does the development team actually implement the feature.

A quick way to teach users never to click that button again, I'd say.

Re: When users never use the features they asked for

#160

Post by KronisLV »

oceanghost wrote: post #56
AmericanChopper wrote: post #44

Earlier quoted context omitted.

The worst programming experience of my life related to lost source code. I was working for a place that had a service running from a Java app that was customized for each customer, about 200 copies of roughly the same app. There was source control at some point, and when a new customer was being on boarded they’d just make the customizations they required, compile the app, and deploy it. By the time I worked there (y…

That's brutal. You were right to quit. There's a certain personality type that will never appreciate or reward hard work.

> There's a certain personality type that will never appreciate or reward hard work.

Now, how would someone figure out these personality types ahead of time? Any red flags to detect people or workplaces to avoid in a professional capacity?

Post reply on HN