[bjourne]

I agree with this. The argument I have heard a million times is that technical people can't understand non-technical people's (whatever "non-technical" mean, partitioning people as either technical/hard or non-technical/soft is dumb) perspectives. Therefore, for a product to succeed, it needs to be designed by non-technical people. But the assumption is wrong and letting non-technical people design products more often than not just leads to badly designed products.

[tbrownaw]

But the assumption is wrong and letting non-technical people design products more often than not just leads to badly designed products.

Yes, just like letting the technical people do the design.

Good design uses a separate set of skills, which few people have because few people realize they're important. There is very little correlation between having this set of skills and having the usual set of "hard" technical skills.

[skybrian]

What's an example of a product that was badly designed because the product designer wasn't technical enough?

[adrianratnapala]

You have to see it from the inside to be sure that this (rather than some other pathology) is going on, so I will give an example from my own work.

I wrote a design program for [thingys] that were basically rectangles, but could have circular arcs instead of straight line edges. A user could fake a circle using two semicircles joined by zero length edges.

The PM saw this and wanted a circular [thingy] feature. He could not understand that it was only a fake circle, such that when the user started changing things, (literal!) corner cases would crop up. Over time, he kept demanding new features that implicitly relied on non-fake circles. And of course this just kept throwing up more confusing corner cases that he kept trying to paper over with new features.

This is one example of a HUGE class of problems that come down to managers just wishing away a mismatch between the way data and code actually work, and the features that they would like to have.

[u801e]

Your example reminds me of this video [1] that (humorously) goes over a similar mismatch problem.

[1] https://www.youtube.com/watch?v=BKorP55Aqvg

[adrianratnapala]

Yes this is a classic, and I think I was first introduced to it when I was going through my fake-circle trauma. As ridiculous as it seems, it describes the real (mis)behaviour of people. But I feel there should be an equal and opposite video. Perhaps one where an engineer keeps producing solutions to problems nobody has. (An astroturf mower? A robot that goes to the gym for you?)

I think if you had both those videos and a convincing explanation of how they can both be truthful, the combination would great training material for everyone on a product team.

[skybrian]

I'm sure there's more to the story but it seems like there's a missing conversation here: "why don't we replace the fake circles with real circles?"

A healthy team would have that conversation. I'm not sure the PM needs to understand so much as defer to the engineering side if they decide a change is needed.

[adrianratnapala]

We'd had that conversation [1]; and (we thought) the answer was that real circles were not worth the extra complexity, especially since common use-cases could be covered by fake circles. Or at least we thought we'd had that conversation, but it turns out moot if the PM can't retain in is mind, the difference between fake and real circles.

I don't think deference to engineers is useful in this sort of thing. There is a class of people (PMs) who have the hard job of aligning user expectations with the engineered reality. They do this by guiding both the customers and engineers, and to do that, they must understand the real landscape they are guiding people through.

[1] I don't want to imply here that everything was the fault of the PM, it wasn't. But there was definately a class bad things that happened due to this particular kind of non-technical thinking.

[nostrademons]

Yahoo? After Semel took over, they were explicitly organized as a media company, with a CEO who had deep experience in the media industry, managers coming from other media companies, and a sidelining of much of the original technical talent.

As a result, they completely missed that the continued growth of the Internet would make hand-curated approaches infeasible. And so they got their lunch eaten by Google. And then they started losing traffic on other properties to Google, who could leverage their massive technological infrastructure that Yahoo had largely copied and open-sourced but wasn't really integrating into their product design. Eventually they brought in an ex-Googler as CEO who tried to stem the tide and re-emphasize Yahoo's technical capabilities, but she was 10 years too late and fighting a whole culture by then.

[bjourne]

In this context, "not technical enough" means "not being able to accurately estimate technical costs." I posit that there is a correlation between being technical and being able to estimate technical costs:

One example I have seen a lot is the "exactly as I want it" design. What that means is foregoing using any standard web components (like Bootstrap, jqueryUI, ...) because they don't work exactly as the product designer wants, so you have to build something from scratch. Then you run out of time because building a complex web site without relying on any ready-made components is a lot of work, leaving the web site in a decidedly half-assed state.

As you can see, in my opinion "being technical" is not only about programming. It is also about YAGNI, being lazy and very much being a realistic pessimist.

[mannykannot]

I don't think we have to choose between reasons for bad design - both causes being discussed here have occurred repeatedly - but since you asked, I would suggest that there have been many products with security failures arising from designers not having sufficient skill in that area.