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

141–150 of 228 posts

Re: When users never use the features they asked for

#141

Post by hulitu »

oceanghost wrote: post #118
danbolt wrote: post #109

Earlier quoted context omitted.

Thanks for updating! I was a little confused since Heroku wasn’t around before the 2005 launch of the Xbox 360, but figured it was shorthand for something else. Given the Xbox One SOC had a lot more security in mind, I could see how Microsoft was more cautious about these things. [1] [1] https://m.youtube.com/watch?v=U7VwtOrwceo&feature=emb_title

Just a lapse of memory and thanks for the benefit of the doubt. Another commenter mentioned turbolinks and I was like "whoooaaaa yes I used that and this timeline doesn't line up at all." This lead to a long internal discussion about when exactly did I play Bioshock and does that line up with my memories :-) I guess I don't mind talking about it so much-- we made a sub $1 component that could compress certain specifi…

You just described how music is compressed on youtube.

Re: When users never use the features they asked for

#142

Post by Someone »

gridspy wrote: post #103
pram wrote: post #78

Earlier quoted context omitted.

Hilarious. Why didn't you refactor the customizations into a config file, and just deploy a single jar though? If you went through the effort of rewriting the entire thing!

The OP wasn't re-writing them. Instead the OP fed the old version into a tool (Disassembler) which spat out terrible source code, worse than the original with no comments and bad variable names. This was the only way to get source at all. Then they made the disassembled source compile in a really nice way. Finally the boss asked them to make huge changes to this horrible source with time pressure.

Textually comparing disassembled code variants can be complicated because the disassembler might/will generate different names for locals.

Because of that, a better approach might be to compare the byte codes of the variants first to find out in what classes the variants differ.

Then treat the different class files as source code until you need to change any of them (so, variant 1 has foo1.class, bar.class, and baz.class, variant 2 has foo.class, bar2.class and baz.class, etc). Don’t immediately try to clean up their code, but ‘just’ try to figure out what they are doing (for many of them, that, hopefully, can be done from function names)

Re: When users never use the features they asked for

#143

Post by jillesvangurp »

duckmysick wrote: post #137
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…

Customers are good at communicating there's a problem. They are bad at identifying a solution.

They are actually bad at both. They usually start by telling you an imagined solution to the problem they think they have. Then you need to pick that apart to figure out what the real problem is that they have and convince them of a solution that will actually solve their issue.

Sales people, depending on their experience, are not a whole lot better. They'll happily sell solutions that don't yet exists for problems that the customer insists they have and then confront their company with requirements that don't make sense. Closes the deal but sets everyone up for failure.

Re: When users never use the features they asked for

#144

Post by kzzzznot »

dehrmann wrote: post #135
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.

I wish software did something more like video games. Well-designed video games will notice that there's a skill you're not using when you should be and show hints on-screen about using it, e.g. press L1 to change weapons, R2 to take cover.

I’m not so sure. It’s mildly irritating getting numerous pop ups of “hey, look over here at this thing we added” even when permanently dismissible. Tracking a user and letting them know that we know they haven’t ever used feature X is likely to just give them the creeps. In video games you are in “play” mode, and very aware you’re being tracked, judged, awarded points etc. In software that’s often less clear and (from certain behemoths) deliberately so. You’re also likely trying to achieve a task, rather than have fun. I personally would find it irritating if not downright invasive if I hadn’t explicitly agreed to something clearer and more explicit than a cookie warning.

Re: When users never use the features they asked for

#145

Post by rm445 »

pjerem wrote: post #126

I once had to develop a full application with really hard problem solving in a really complex domain that I had hard time to understand. This was for a big national phone operator. We delivered it under a lot of pressure from the sales team (I was in a shitty company, with few employees) and the contract was in multiple millions euros. That was literally one of our 2 or 3 customer. We delivered. One day we eventually…

That's a crazy story. My guess would have been, not that the product never worked, but that the delivered version was hacked together in the last 24 hours before delivery and never made it into source control. You know the technical details - do you think something like that could have happened, or really no one tried to use the product even once?

Re: When users never use the features they asked for

#146

Post by mwcremer »

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…

>Their feature requests are often a proxy for something else they aren't able to articulate.

Our usual answer for this is: What are you trying to do?™

Re: When users never use the features they asked for

#147

Post by globular-toast »

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…

Agree wholeheartedly on both points. My product owner needs to understand this.

One of the difficulties is the users don't really know what's possible, so they'll come up with ideas based on the current solution. Often if you listen to them you'll realise they're actually battling against the current solution anyway and adding more features won't help with that.

Re: When users never use the features they asked for

#148

Post by zw123456 »

makeitdouble wrote: post #95
zw123456 wrote: post #81

“Some people say, "Give the customers what they want." But that's not my approach. Our job is to figure out what they're going to want before they do. I think Henry Ford once said, "If I'd asked customers what they wanted, they would have told me, 'A faster horse!'" People don't know what they want until you show it to them. That's why I never rely on market research. Our task is to read things that are not yet on th…

This flies pretty opposite to what the lessons the author got from their experience ("Keep your users in the loop, always. Do not go build in isolation.", "If you make assumptions about your users, they will find a way to surprise you.") I kind of feel your view is a variation on "if you built it they will come", which is true in some cases, and will wield spectacular failures in ton of other cases.

It's a Steve Jobs Quote. Sorry should have put that there but it's so well known I guess I didn't think to. But I think it is a little of both. To much of the Jobs approach can lead you down errant paths, but if you never anticipate what the customer wants you could miss great opportunities.

Re: When users never use the features they asked for

#149

Post by Cthulhu_ »

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…

I'm in this exact situation. We run a niche software product in the telecoms industry, and we have one major customer who is also the most opinionated on how it should work. They keep sending in feature requests (for the old, poorly written application), 'we' (i.e. the boss) keeps saying yes. I'm still here and there working on features that we apparently agreed to build for them over two years ago. At least the boss is learning to say no more.

Re: When users never use the features they asked for

#150

Post by inopinatus »

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.

Post reply on HN