I am involved in a lot of conversations where companies and people are trying to solve a business challenge with software. Communication is so compressed nowadays, people’s time is limited, and we are almost always communicating across multiple time zones and frequently across cultures. This makes a common understanding difficult and opens up lots of opportunity for confusion.
Normally I would agree that talking about solutions is a very good thing. Here’s what happens in almost every one of these conversations. We fail to actually define the problem, because we’re so anxious to offer our solution. Generally there isn’t a description of the challenge at all, typically we hear a proposed solution (not a problem) and are asked to comment on how to execute on it. So many IT projects are based on this flawed foundation and the results are a lot of wasted time and money.
Why is defining the challenge so important?
There are always multiple ways to solve a problem. Normally the best approach requires a combination of expertise (context over the business process, technical expertise of the systems involved, good critical thinking skills, understanding of the users involved, and knowledge of how software works in general). No one person holds all this knowledge. You have to describe the challenge to the group that can collectively come up with the best solution.
On a recent call, we were talking about integration. The customer started the conversation with how they would provide a data file out of their system for us to pick up and integrate into another system. For some time the conversation dove deep into the details of how this proposed solution would work. I then asked the question, why are you exporting to a file? The answer was “it’s just what I thought we needed to do.” This is a great example. We didn’t define the challenge; we just started discussing a potential solution offered by one person with limited context and expertise. The customer wanted bi-directional, real-time integration – exporting to a file as an intermediary step would prevent the desired results of this project, yet we spent lots of time talking about this potential solution because we didn’t take the time to define the challenge clearly.
So next time you’re getting into a conversation about how to solve a business challenge with software, hold up on the solutions and ask clarifying questions about the challenge. Test yourself, do I understand what the challenge is completely, before you start trying to solve it. Often the little details you get from asking clarifying questions will greatly influence your solution thinking and often they provide the spark to solve the challenge more elegantly.
For example:
- Can someone describe the business challenge you want to solve?
- What are the desired BUSINESS results?
- What are all the systems involved?
- Describe the users of this system?
- What is the scale of challenge?
- What is the timeframe the solution is needed in?
Does everyone involved understand the problem? It’s really easy to make assumptions here and plough forward without validating that everyone is on the same page. I’ve seen “early assumptions” cost hundreds of thousands of dollars and months of labor downstream.
Take the time to define the challenge, if nobody asks any clarifying questions – you’re probably making assumptions, rather than verifying understanding. Being smart isn’t about proposing the first potential solution, being smart is about asking the right question that expands everyone understands.
Discussion
By Jacob Aizikowitz on Oct 31, 2014
It is well known that asking the proper questions is a major part of coming with a solution; or, properly stating the problem will lead for a relevant solution. Its known in science, and it is the heart and soul of Jenn's article, which is very relevant and reflecting realities that need to be changed.
Yet, and especially in the delicate boundaries of vendor / customer (or prospect) relationships and interactions, sometimes, the customer can not ask the right questions. This is because the customer may not be knowledgeable about what the technology dimension enables.
So, sometimes, it makes sense to have a session about what the technology can provide and then have a discussion of "what is the problem" followed by whether there is a solution, and assuming there is then what are the options.
Just was reminded recently of what Henry Ford said (paraphrasing)right around the intro of the first car: "if you asked the customers what do they need then they would have said More Horses..."
So, our challenge as providers of technology / products, is to be open, listen, understand, not just dump tech on our customers and prospects, but, at the same time, sometimes, be proactive, and suggest considering a new innovation that was not asked for but in fact solves the customers' problems in way they never formulated themselves.