About a week ago, I took my wife’s van to the shop. The main issue was it was making a popping noise in the front end. I only observed the noise when steering sharply and the vehicle was in motion. Typically this occurred when parking. Although I was nearly certain this was an issue with a CV joint, I only told the mechanic about the symptoms we had observed.
The reason I didn’t lead the conversation to the CV joint is that I wanted the mechanic to look at the problem objectively. I knew he was the expert and I wanted him to solve the problem instead of replacing a part. In order to shift the responsibility, I needed the mechanic to diagnose the problem and create a plan of action.
Positioning IT Conversations to Solve Problems
At this point in my career, I have worked in various areas of technology. Over the years, I’ve had customers that tell me exactly what they think they need. In some cases, they’re correct. However, there are times that their solution does not fully solve the problem they are observing. On the other hand, some customers take a smarter approach and explain the problem they are trying to solve.
When a customer takes the latter approach, it forces the technology partner to take responsibility and own the problem. When I was a customer, this is exactly how I tried to structure deals. My goal was to get objective opinions and get my partners involved in the solution. This was a good way to make sure the vendor or partner was presenting a solution instead of a BOM (bill of materials).
Technology Customers might think about the following when positioning an IT conversation:
- Explain the problem, business objective, symptom or the outcome being sought
- Give very few specifics about how you expect the problem to be solved
- Give a lot of specifics about the problem itself
- Avoid product discussions in the initial conversations
Technology partners and vendors should also think about the points made above. If a customer isn’t happy with the outcome, it doesn’t really matter that they spec’d out the solution. Even if a customer specifically asked for a technology, there will be repercussions when their problems remain unresolved.
My recommendation to partners and vendors is to try to slow the conversations, listen for the problems and understand the expected outcomes. This process also provides the necessary time to gather the data and understand how success will be defined by the customer. This also opens the door to big picture conversations and provides the opportunity to steer the customer toward a better solution.
Conclusion
My role now often permits earlier entry into technology discussions. As such, I regularly get to be part of the process of defining the problem and architecting the solution. This is a much more comfortable position than responding to a request for a specific technology. It encourages the necessary interaction and provides ample opportunity to set expectations. I’m not saying that there is never a time an place to request a specific technology (or to respond to such a request). However when the solution is yet to be proven in a given context, I think its best to lead with the problem that needs solved.
Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This may or may not reflect the position of past, present or future employers.
The post Positioning an IT Conversation appeared first on PacketU.