It is a real thing, or so I am told. Companies actually have solutioneers. In looking at several job postings for solutioneers there is no standard job description. I mentioned in a couple of past articles that solutioneering is generally a bad idea, especially on sales calls. So what is solutioneering, and when it is a good idea?
First let’s not confuse a solutioneer with an imagineer, I don’t have the proper licensing rights to even consider writing about imagineers. For this article let’s think of a solutioneer as somebody who proposes solving a problem with a product solution or feature, but is not a designer, engineer, or product manager. They will typically engage in solutineering with an existing or potential customer.
When dealing with software products you will come across unique problems that customers are having. Oftentimes the customer has an idea of how they might like to solve that problem. Additionally, a lot of people who work on software products (regardless of industry) tend to be problem solvers by nature. So, a lot of customer interactions start with either a description of a problem or a proposed solution (or feature request) and the entire group begins trying to solve that problem.
The meeting can easily become a brainstorming session with people throwing out ideas for how to solve the problem. Most of the time the solutions involve either product changes or new features. I explained in prior post how this is a bad thing, but is it ever a good thing?
Brainstorming like this can be productive, if you set everything up correctly. First you need to make sure that you have the correct people in the meeting. If we assume that this is a sales call with a potential or existing customer, then you would want an engineer, a designer, a user researcher, the product manager, and the sales person from your organization on the call. The engineer will ground the discussion in reality and ensure that the ideas are technically possible. The designer will help think through the entire problem and ensure it is fully considered in any solutions. The user researcher will help facilitate the meeting and drive the customer to better explain the problem and why a given solution may or may not work. Of course the product manager and sales person should be there to ensure alignment to the company mission/vision and/or scope of the engagement with the customer, as well as to facilitate any discussion about pricing or effort. If any one person cannot attend the meeting, it should be delayed.
From the customer side of things you would want the decision maker and a person who is dealing with the problem that is being discussed. You don’t want a manager who has an idea of the problem. You really want somebody from the trenches that actually experiences the problem. You should consider getting people both up and downstream from this person to ensure that you are getting a full picture of the problem.
The context for brainstorming solutions is as important as the people that are present in the session. It is important that everybody understand that the brainstorming session is not an agreement to actually build anything. It is a mechanism to further understand the problem, and to get an idea of how the problem might be solved. It is also important to make sure that people focus on staying positive. I have mentioned before about how simply saying no can kill creativity. Make sure that people come to the session expecting to listen more than they talk and that before an idea is ruled out, it will be necessary to ensure that everybody is clear on what the idea is, and more importantly the intent of the idea.
It is under these conditions that it is ok for everybody to be a solutioneer, at least for a few hours. So, set the context, gather the right people, be creative, and shoot for the moon.
