Feature requests are really prone to this. Customers will only ask for features they can imagine, not the ones that really solve their problem. A significant chunk of the time the customer is better served by a different feature that takes less work.

This is why i don't like tender-based software projects. The tender already describes the features needed, and they must be built even if they are suboptimal for the problem domain.

One of our Business Partners suggested a pop up box with Yes No Cancel, and then went on to describe the behaviors of each button. Absolutely no imagination. It's like people have been broken by years of limited choices.

With some types of people, I've just stopped trying to get them to back up and describe the underlying pain point they are trying to relieve. Because as far as I can tell, some people just can not do that. Instead, I let them describe their implementation and listen/ask/listen/ask/listen to understand what they're actually trying to fix.

And then once we have the problem figured out, we as a dev/design team go back and work forward again to design a proposed solution. And then we present that. Often enough, they're happy to accept it. The trick is that some egomaniacs just get fixated on their own proposed solution, and won't let go. And then you just give them their Homermobile: http://www.wired.com/wp-content/uploads/2014/06/the-homer-in...

If I had a dollar for every time a customer finally confessed that they actually wanted a different feature but thought it would be too expensive...

Nothing like blowing $40,000 on a $1000 feature.

Could you give an example of what you mean by "tender-based software projects"?

The client writes spec and solicits a bid, instead of soliciting design partners.

I usually ask, "What problem are you trying to solve?", to anyone who brings me a solution instead of a problem, but it comes down to the same thing. I guess I don't even really know which question would be more efficient at getting the real answer.

I wonder how that sits with "Don't bring me problems—bring me solutions" that I occasionally hear from non-technical managers...

There is a need for both approaches. If you have the expertise to be able to diagnose the problem, asking for the problem to be solved is the right approach. When dealing with non-technical issues, where the person coming to the manager is familiar with the process, it makes sense to ask them to bring solutions (as a first step) instead of imposing something on them.

Extremely well.

Stakeholders are supposed to present problems to engineers, and engineers are supposed to propose solutions to stakeholders.

The underlying meta-rule is that problems should be solved by the person with the most expertise.

One of my best managers ever was non-technical. His line was, "you're smart enough to fix this, so do it, do it right, and don't let it happen again." He did a great job getting the resources to back it up, too, while shielding his team from company politics. Right up until the point where he lost at company politics, anyway.

I guess the trick is to be an expert in Machiavellian games and intrigue without truly holding the values that typically drive such expertise.

I had a very similar experince with a similar boss, and similar conclusion.

But yes, best manager I've had.

I appreciate when they bring me a problem with a suggested solution. It's often quite helpful in determining the best possible solution, and so far as I remember, they quite often got that solution implemented.

But before I started asking that, and just implemented their solutions, I got a lot of kickback for it not actually solving their problem, which is how I learned to ask it in the first place.

A problem without a suggested solution is a complaint. If your people only bring you complaints, it is a drain on everyone; it breeds discontent in the workforce and contempt in management.

I feel that some people are very good at seeing problems, and some people are very good at finding solutions to problems.

I don't see any reason that the same skills should be present in any given individual, so you always need both types.

To me its part of the taxonomy of becoming a more experienced developer:

- First you can implement solutions (jr level) - Then you can design solutions (mid level, sometimes senior - most of time is spent here) - Then you can find problems that need solutions (senior, management)

I understand what you are saying. How does someone who is good at seeing problems communicate those problems and not come off as whiny and complaining?

I often hear "Ugh, it's tiring you telling us what all the problems are, why can't you tell us the solution?".

But I get "Man, I'm so glad you saw that problem way back at the design stage. We really dodged a bullet there." about 3-4 times as often.

What I generally don't hear is, "OMFG, our project is about to fail. Why did no one see that this issue was coming and do something about it!".

The assumption that anyone noting a problem is just whining and complaining is a good way to tank a project. I've seen that type of thinking prevail, and it sucks for everyone.

The client bring the problem, the vendor brings the solution

The problem they think they need to solve is usually not the problem that needs to be solved. Hence the 5X (or more) to reveal the actual problem to solve.

I think this really old article addresses it better. It's self-explanatory.

Managing Complex Design Projects (1995) http://www.dubberly.com/articles/managing-complex-design-pro...

I just read through that. Asking questions and planning up front? Documentation before code? Thats so waterfall. (And it works quite well for some projects). Certainly having a problem that isn't clearly defined is a good way build something that doesn't solve the problem well.

A blind drunk man was jaywalking and was hit by a distracted and inexperienced driver and died. Why did he die? There likely isn't a singular root cause. There are 5 potential singular root causes, but they are a subset of the 5-factorial potential combinatorial root causes.

I agree that solutions before problems is bad, but the five whys is problematic simply because it promotes the idea of singular root cause which is almost inevitably a fallacy when analyzing complex systems. There are often conceivably millions of overlapping and/or interacting causes to an observable problem. Sometimes, trying to boil causality down to a single item is merely missing the point, but very often it is much more problematic. Unintended consequences from solutions derived from improperly attributed singular root causes can be terrifying.

This seems like an overly simplistic interpretation.

The answer to "why" can be three different things. So you ask why to each of those. Repeat.

The five whys is only "problematic" if you expect it to give you the answer. It's only a means by which it can be easier for you to arrive at one or more of the many possible answers.

I agree.

Relevant: http://web.mit.edu/2.75/resources/random/How%20Complex%20Sys...

My experience is that asking five whys can help you manage or mitigate some of the root causes. You probably won't get them all on this pass, but if this is important, it'll come up again and you'll try some other root causes. However, if you think you've found the root cause, you're probably wrong. I dunno about "terrifying", but accumulating scar tissue can definitely create more problems than it solves.

The point of 5 whys is NOT to assign proper blame for each problem. It is to give you a way in a complex system for identifying pain points that are causing you repeated problems.

I've tried forcing it 5x and found that the fifth Why is exactly the point where they get annoyed and stop talking to you. So there may be a magic insight at the fifth Why but you'll never hear it :)

The magic insight is always this: "Because I want to feel good." When someone doesn't want to put this in words, they get annoyed and stop talking to you.

You're so right... but you can substitute "powerful", " secure", etc for "good"; and also sometimes "because of secret reasons".

Sometimes it's, "Because I don't want a repeat of this crappy thing that happened to me."

Often software is used as a means for one group inside a company to control another group.

Part of the idea is that if it takes more than 3 or 4 "why"s to get to some really fundamental business goal (i.e. "Because I want to make more money"), then it might not be a problem worth solving in the first place

What if you told them ahead of time what you were doing, so they would happily cooperate knowing there would only be 5? Otherwise, by the fifth most people will think "man, this never ends..."

I'd probably ask "Why 5 times?" and then it would be game on.

By six, you're usually at something like "because that makes me happy". By seven, you're into metaphysics and cognitive science.

Of course, some issues are genuinely simple, and you're off in unhelpful territory halfway through. I suspect five why's is a decent estimate, but not necessarily more accurate than four.

There's a really good Louis CK routine about this, involving his young daughter.

"Diminishing returns."

> people tend to talk about solutions and not the problems

Hard to make this any clearer. To expand a bit on this, most of the times the solutions they talk about are of course expressed in terms of what they already know, which makes communication that much harder. It's a key aspect to keep in mind, and one that ideally both parties, but at least the one that's taking the job, needs to be aware of.

Otherwise it's like visiting a physician and telling them the diagnosis instead of the symptoms.

On the other hand, it's frustrating to call up the ISP help line to get a bad router replaced and get treated like a troglodyte.

Likewise, I'm probably qualified to diagnose when my laceration needs stitches. A conversation about problems and not solutions are frustrating at that point.

Which is what makes this comic so powerful: https://xkcd.com/806/

The people asking the questions are trying to defend against false confidence, but drive the people with justified confidence crazy. Being able to filter for "I know you're competent, we can skip ahead a bit" is really powerful.

Yes, this!

As someone who likes to fundamentally understand processes and underlying reasons. It does take some practise though to get at the heart of the matter and propose alternative solutions that work without being abrupt or like "c'mon, etc?". People higher up tend to be rather attached to their solutions even though after chatting for a bit it becomes increasingly obvious a different approach would get them what they want and often reduce human error factors and/or make effeicent :)

I'm figuring this out slowly, getting "it" though.

"My problem is that I need an app to x, y, z."

No, no, no!

why don't you force it 5x?

I just don't think there's a magical number that works for me. Dealing with users/clients is really just dealing with people so I guess it ends up like being in a light therapy session, asking questions until you get a good understanding of the real problem. I'm not good reading people but I think I'm good understanding their issues. Empathy gets you a long way. That's probably half of it, the other half being dealing with their expectations.