Hacker News Reader

Exactly these 2 points.

I as a PM for a platform may sound arrogant, however I strictly adhere to the phrase: Only what customerS need, not what they want. I also rely on numbers and classification: does this feature help one or more user? Which type? Power User(s)? Everyday normal users? Is this just emotional, a want or need? How much does a user benefit from the change? Can we do better, are we missing something (symptom vs. root cause)?

Product development is incredibly hard to get it right. However, do less as a general advice. Think about Word and its feature overload. There is a downside to customer feature wants: clutter and distraction. Users of all kind are allergic to noise. Keep that in mind. I call this "friction free".

I think in systems, as a general abstraction and modules. I classify features. For example Power Users can get a special Role and Admin area where you can abstract there needs away. Their productivity is different.

I learned as a rule of thumb, that you should talk a lot to your customers and blend that with data. Data itself (usage tracking) is highly misleading.

This is hard and I aim for general satisfaction level. People who like your products tend "get" your idea and don't fight it.

Have fun! :)

> clutter and distraction. Users of all kind are allergic to noise

It's actually worse than this - additional information and option hinders the users. It make them less able to find, understand and successfully perform otherwise easy tasks. At some point, it also make them stop use the product. Those major drawbacks are important to state to all stakeholders.

That's weird, I always thought the absence of additional information and options were what was hindering me from performing easy tasks.

Good doctors don't ask patients what medications they want, they probe about symptoms, context, desired outcomes, etc. I find this a reasonable (not perfect) analogy in my work as a consultant.

> Data itself (usage tracking) is highly misleading.

This is so true. Why is a feature unused? It could be:

* It is not needed

* Nobody can find it

* Nobody understands what it does or how it works

* The name is misleading people into thinking it's not what they want

* You left the feature flag off, the feature isn't even live

* It doesn't actually work

* It works sometimes, but frustrates users when it breaks so they don't come back

* Your data is wrong, and they do use it

* etc.

Lots of folks stop thinking at the first one.

I absolutely hate modern design that tries to get rid of all the "distractions". I have had a bunch of my favorite applications get MUCH worse due to hiding or elimination of key features in the name of making a simple slick design.

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.

I never even considered this. Given the number of times we've built some really stupid feature because a potential big client had it as a requirement, I bet at least a few were just telling us to go away.

The standard way of finding this out is to ask them to pay at least something towards developing the feature. If they're genuinely interested but genuinely need this feature, this is reasonable and they'll be agreeable. If they're not actually interested, then this doesn't make any sense for them and they'll refuse.

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

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

If they'ed rather not click the button than get you to fix the button, clearly they don't need a working button.

I would run from that product.

You would never know that this was happening.

"but to figure out what they really need."

I actually had a senior manager at a large company I once worked for tell me after we demoed a new feature that had been added for his team: "that may be what I asked for but its not what I want".

It can be hard to come up with a constructive reply to stuff like that.... :-)

This is why I always build things as iterative prototypes. Get something in front of the customer asap, so they can tell you what's wrong with it. Trying to get humans to accurately and completely describe what they want in a spec is doomed to failure.

Indeed, and if this chap hadn't seen the multiple mockups and iterations during development I might have had some sympathy.

Edit: We eventually found out it was pure office politics, nothing to do with what we had actually built.

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"

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.

Somewhat related: https://en.wikipedia.org/wiki/XY_problem

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

> "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).

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.

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.

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.

See this comment in the thread for more of the same attitude.

https://news.ycombinator.com/item?id=28704103

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.

One of my engineering bosses once said that the scariest thing in the office is to pass by a sales guy on a phone call who is vigorously nodding his head.

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.

If it's in the enterprise sales phase then sales will just say "yes, no problem". Ideally they will talk with engineering, but...

To be totally fair to sales people, it's very, very hard to say "no" when an enterprise customer is dangling a contract in front of your nose that means your company keeps the lights on for another year. But enterprise is really something you should look at if you really understand the niche, have lots of contacts, and plenty of patience and runway.

>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?™

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.

> 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/