Talk about the problem, not the solution
katgleason.tumblr.com
Talk about the problem, not the solution
1–10 of 15 posts
Re: Talk about the problem, not the solution
#2OP, what are your motivations behind this?
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 exactly the job of a Product Designer.
Re: Talk about the problem, not the solution
#3"A&R" apparently means "artists and repertoire", which is a standard department in a record label (and analogous to a tech company's R&D department).
Re: Talk about the problem, not the solution
#4"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).
Re: Talk about the problem, not the solution
#5I 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.
Re: Talk about the problem, not the solution
#6"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…
> 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)
Re: Talk about the problem, not the solution
#7I 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 client…
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.
Re: Talk about the problem, not the solution
#8I 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.
Re: Talk about the problem, not the solution
#9Two things.
1) A clip from Moneyball: http://youtu.be/HiB9L3dG-Aw
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.
Re: Talk about the problem, not the solution
#10Client: I want to get from this side of the river to the other side.
Provider: I think this bridge design will fit your needs.