Live data from Hacker News

When users never use the features they asked for

web.eecs.utk.edu

171–180 of 228 posts

Re: When users never use the features they asked for

#171

Earlier quoted context omitted.

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.

I think what Steve Jobs calls "market research" is mostly customer panels, polls and actual straightforward "what do you want" questions to users.

Apple did extensive research when designing their products, just not the naive/lazy kind that would be offered if they went to an established marketing firm.

This bias was also what bit them when they designed the trashcan MacPro, or the following coming to term with needing a Mac Pro at all.

Re: When users never use the features they asked for

#172
Since everyone is sharing their stories.

Back in our 2000's startup, our AOLServer like application server, had something similar to what Rails Active Record brought to the world, just in Tcl.

Basically each RDMS driver had their own lowlevel Tcl bindings, and then the infrastructure code would wrap them up in the upper layers.

So sales got a very important customer, there was a caveat though, they were using Sybase SQL Server, which we didn't had any driver support.

Given that we had to deliver no matter what, a war room project was quick started to add support for Sybase SQL Server, across all layers of the product, drivers, model generation, SQL translation, the whole package.

In the meantime, the customer got talked into using Oracle as we were getting the finish touches for delivery.

When they finally got the new version, with Sybase SQL Server, requested by them as hard requirement, they decided to just keep using Oracle instead.

Re: When users never use the features they asked for

#173
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…

Also the "feature spiral of death" when a customer's feature request is really just them trying to say "no" politely. There is no amount of features that will make them say "yes". But once they've started down this road it's very difficult for them to admit that they didn't want any of the features they're asking for, they just want you to leave them alone.

Wasting time and money on this sounds like just deserts for being too pushy with one's sales techniques.

Re: When users never use the features they asked for

#174
post #172

Since everyone is sharing their stories. Back in our 2000's startup, our AOLServer like application server, had something similar to what Rails Active Record brought to the world, just in Tcl. Basically each RDMS driver had their own lowlevel Tcl bindings, and then the infrastructure code would wrap them up in the upper layers. So sales got a very important customer, there was a caveat though, they were using Sybase…

Did you at least have use for the Sybase support at some point?

Re: When users never use the features they asked for

#175

Earlier quoted context omitted.

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?

Ask them flatout how they reward initiative and accomplishment. If they start fumbling, there's your answer. If they don't, ask them for a concrete example. If that's when they struggle, there's your answer.

Re: When users never use the features they asked for

#176
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…

> "but to figure out what they really need."

I've had a boss who was very "pragmatic". Used to come up with concrete and practical solutions all the time. "We need to add a button here" or "We need an extra tab that only X can see" and so on.

Wasn't pragmatic at all, just listened to the customers, then translated their requests into what he thought would be the simplest (cheapest, fastest) to implement. While this sounds Lean, it really is a sure way to accumulate an immense mess of complexity, legacy and clutter in no time.

What we really needed was some design sessions to translate the customers' request into something that fit the product and matched a vision (or to disregard it, it that fit is not found).

Re: When users never use the features they asked for

#177

Earlier quoted context omitted.

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?

1. "...Able to work under pressure and meet deadlines.."

PASS !

2. "I(boss) coded the first version..."

50% of the time it means:

Your solutions or design decision will never be "as good as his" and you will forever hear "I did it like this and that. It should be fast to implement xyz"

Re: When users never use the features they asked for

#178
post #172

Since everyone is sharing their stories. Back in our 2000's startup, our AOLServer like application server, had something similar to what Rails Active Record brought to the world, just in Tcl. Basically each RDMS driver had their own lowlevel Tcl bindings, and then the infrastructure code would wrap them up in the upper layers. So sales got a very important customer, there was a caveat though, they were using Sybase…

Did you at least have use for the Sybase support at some point?

Not really.

I guess the only benefit was that on later releases, we could share the infrastructure with Microsoft SQL Server.

For those that don't know, Microsoft SQL Server grew out of a partnership with Sybase, and the early versions were quite alike, just Microsoft version had better GUI tooling.

Re: When users never use the features they asked for

#179
Then you have Slack which forces everyone to use features nobody ever asked for.

AWS which ignores what people ask for until it happens to align with something AWS wants.

Microsoft which only implements what their double platinum partners program people asks for and forces everyone else to use that.

Oracle which gives people what they want and sues everyone who gets it from someplace else.

Google gives you what their algorithms determine you want. Like community support of all their products. You wanted that. They can prove that mathematically.

Re: When users never use the features they asked for

#180
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…

Since we sharing :)

One "trick/lesson" I learned from working with a "big dist system" (think scraping-jobs) with lots of clients(read unique errors) and requirements was:

Never-ever-ever do:

if(client->id=123){

//do special workaround,process,feature or magic-dance

}else{

//normal non-magic-dance,process,flow

}

The only "allowed method" for implementing such code was to add a "JobOption" to the client-config.

Thus you have:

if (client->joboptions->magic_dance){

  //magic-dance-feature-workaround
}

You'd be surprised that over time how many clients have "similar requirements" but different combinations and just being able to do a checkbox-check on their job-config (enable magic-dance) was gold for maintenance and keeping out the spaghetti code!

It was the 'greatest of sin's in our org to write "if client->id=123"

Post reply on HN