"one of the biggest mistakes “nontechnical” people make when communicating to great hackers about product is that we try and tell them the solutions before we ever tell them the problem"
This is spot on.
I spend a bunch of my time helping ux, business and dev folk play nice together. This is definitely one of the major problems and something I babble on about to tedious extremes.
It's usually not as simple as a lack of trust though. It's more often things like people not having good ways to communicate the problem (as opposed to possible solutions). Or organisations being set up in such a way that the technical folk aren't in-play at the point where problem discovery is happening. Or the non-technical folk being assessed on "solution providing" not "problem defining".... and so on.
Trust is sometimes an issue - but it's often not the major cause.
(There is also a class of tech folk in some organisations who aren't interested in that level of problem - who want to get "the spec" and focus on the implementation problems that interest them more.... but I don't think this is the kind of tech folk the OP is talking about).
> Or organisations being set up in such a way that the technical folk aren't in-play at the point where problem discovery is happening. Or the non-technical folk being assessed on "solution providing" not "problem defining".... and so on
This is the fundamental problem and is, I think, largely due to the fact that the kinds of problems we are solving do not naturally fall into the neat specialties into which most companies categorize their workers. Specialization promotes serial thinking whereas what's needed is near simultaneous thinking and that requires deep communication (and smart people)
I think the OP is on to a pretty big theme. Most of our lives we're taught to solve problems, not to find them. The idea of an exam is that you're given a bunch of problems to solve. Most people describing themselves would (or would like to) score themselves highly on the ability to solve problems.
In an environment where everyone is smart and driven (such as SV), being a good problem solver is just not enough. Being good at finding and articulating valuable problems is much harder, and I would bet that more startups/founders fail at this. Part of this is because, most people are never trained, and never think to ask what makes a valuable problem.
I think this is why I as an a graphic and web designer don't always enjoy working on the projects of clients. Whenever they ask for a redesign they want me to visualize and build the solution for them. They don't always ask me to look at the problem and then think of the solution.
When I work on my own personal projects I get to do both, which is why the work I do for myself is miles ahead of the work I do for clients.
Over the years, I constantly remind my manager, clients, an colleagues to bring me in much sooner than they think they need to. When that happens, the problem definitions are much easier and the resulting solution works. Obvious, when you think about it. The analogy I use is that if we were constructing houses, then my role is both architect and builder.
2) I remember from a book about someone marketing in Japan. They were trying to sell a rice cooker that could also cook other foods. They couldn't understand why this convenience wouldn't sell. It seemed to solve a "problem." In many consumer interviews, a passing comment revealed the new problem they had actually created. Housewives feared that the taste of other foods would creep into the rice and ruin it. They stopped selling the cooker.
I have one of those rice cookers. It's the single best piece of cooking equipment I've ever owned. It has a Teflon pot, so flavours don't linger. We cook chilli in it, wok-style fried rice dishes, baked fish, breakfast fry ups, and a lot of boiled rice-based dishes. Awesome piece of kit.
This is also a big problem in health tech: the people that are good at identifying the problems (doctors, public health officials, etc.) don't communicate them but instead focus on convincing others to build their vision of the solution (which tend to be inadequate, or even counterproductive).
Given that the author is the founder of health tech startup (EligibleAPI.com), it's hard not to read this as being implicit in the post :)
It's more like business development rather than R&D. It's basically about finding new talented recording artists (performers) and publishers/writers who would be a good match for them.
I'm worried about the tendency to letting just "nontechnical" people "define the problem", and the general relegation of "technical" people to only build and execute a vision.
Some people have a background that deals mostly in perception and form, while others deals mostly in structure and function. If both balance strategic trade-offs of the product, both are designers. If they only execute plans, they are craftsmans and technicians.
Which one of them is better for "defining" the problem deppends on the problem. Both can learn to have holistic vision, and how to understand where their expertise and skills end.
There are creative and intuitive technical people. They are out there, as many as "artists" that can truly design products.
Anyways, this is right on the money. Finding the problem is an art in itself. It's only once we find the root problem that we can design the holistic solution, otherwise it's a whole bunch of patched held together by desperation and neediness.
Example: if it turns out poverty is related to global warming and for the past decade we've spend resources trying to rid poverty in isolation, we are all sorts of screwed.
This is spot on.
I spend a bunch of my time helping ux, business and dev folk play nice together. This is definitely one of the major problems and something I babble on about to tedious extremes.
It's usually not as simple as a lack of trust though. It's more often things like people not having good ways to communicate the problem (as opposed to possible solutions). Or organisations being set up in such a way that the technical folk aren't in-play at the point where problem discovery is happening. Or the non-technical folk being assessed on "solution providing" not "problem defining".... and so on.
Trust is sometimes an issue - but it's often not the major cause.
(There is also a class of tech folk in some organisations who aren't interested in that level of problem - who want to get "the spec" and focus on the implementation problems that interest them more.... but I don't think this is the kind of tech folk the OP is talking about).