Learning Over “Solutioneering”
Back in the day, when I was one of the owners of Blue Flavor, a design and UX shop, we used to use the term “solutioneering” quite a bit. I don’t use it near as often today, but I still love the term. In essence:
Solutioneering is the term used to describe the act of working up a solution prior to really understanding the problem that solution is set to solve.
—Definition by me, D. Keith Robinson. :)
It’s a common practice. I’ve been guilty of it. You’ve been guilty of it. It’s not always bad, as good ideas can come from solutioneering, but you should always stop at some point and ask yourself some questions about what you’re doing.
Know why. #
This probably sounds obvious, but here it is: it’s very important to know why you’re doing something. This is particularly important with product design. You should be asking yourself (and your teammates, and your customers, etc.) why you’re building a particular product or feature. You should be asking who it’s for? Does it solve a real problem? Can you back that up? Can you defend your design with solid answers to those questions?
At Desk.com, where I currently work as a Product Designer/Manager and UX director, we have occasional speaker lunches. They have been really awesome, I suggest doing that if you can. Anyway, last week we had Hiten Shah, co-founder of KISSMetrics, and he talked a lot about their process of customer discovery and how it informs product decisions. Was a great, quick talk. Hiten is a smart dude.
He talked a bit about previous product failures he’s experienced and mentioned that he’s learned to put learning over solutions. This is no surprise, he also mentioned he was a bit fan of Lean Startup methodologies and the Learn part of Build, Measure, Learn is, obviously, a big part of that.
In essence they test rigorously (as you’d expect considering their product is all about testing and customer development) to find out the answers to the questions “why” “what” and “who for”. Their customers are deeply involved with product decisions. That is awesome and how it should be. When I started at Desk.com (then Assistly) the first thing I did was get out and talk to a mess of people using the product. I asked them why they used it, how it helped them, what they needed from us, etc. Of course, because we already had a product, I focused on current usage.
(An aside, Hiten said something that really stuck with me. Somewhat related. He was asked how, as a non-technical guy in the beginning, he was able to keep up with all the tech involved with running KISSmetrics. His answer was great, and something I’m totally down with: having a desire to understand is the most important thing. Hell yes. I feel like you can learn anything if you really want to.)
I’m currently…ah…embroiled in the process of coming up with a new product from scratch. We had some strategic direction, and an idea of our target market, but the actual product is still largely undefined. I started out with a bunch of ideas but quickly began to have a ton of questions. Would this solution solve anybody’s problems? Who would use it? Etc. Luckily my team and I had been learning a lot about Lean methodology and customer development so process was fresh in our mind. In one of our product meetings we decided to back things up and get out there and talk to people about what we thought we’re problems they were having. We were solutioneering and had we continued down that path, our MVP might have been something nobody wanted.
We got out there and asked people about their problems. We didn’t pitch a solution or feature set or product. We didn’t have anything to pitch. Just a thought that maybe we’d uncovered some problems that could use fixing. And, after talking to a whole bunch of people, those problems began to come clear. We’d learned enough that we could begin to work on a solution.
The most awesome thing about this process is that it’s repeatable—throughout the lifecycle of your product. You can go back, talk to your customers, learn from them and use those learning to inform your solutions on an ongoing basis. You should be doing that. Your designs—your products and features—aren’t meant to be static. They should evolve and be iterated on over time.
Whenever you feel yourself solutioneering, take some time to back up and do some learning. Focusing your process on continuous learning will improve your products and designs.
(By the way, if you’re an entrepreneur of pretty much any kind, and are curious, feel free to hit me up. I’d love to have more people get eyes and minds on our product idea.)