8 steps on how to talk about software's benefits, not features

By  

When I tell my business users about new features we have added to their software, their eyes glaze over and they don’t pay attention. This really makes me mad. What should I do so they will listen to me?

As technologists, we love technology, particularly technology that we personally create. This is often not the case for the business users that we serve, even if they are a techie-want-to-be or were involved in defining the business requirements. These business users, as they should, look at technology as a tool to perform their daily tasks. That is to say, they look at technology as a means to an end, not an end in itself.

To your question, if you would like your business users to engage with you about the software you have written on their behalf, describe what you have done based on business value, business benefits, and how the software will make their jobs easier. In effect, don’t try to bring them into your world, you should step into their world, thus describing what you have done using their terminology and perspective, not yours.

As an x-software developer by profession, I would write half a dozen lines of working code and want to show it to someone. I would do this not to brag about what I had done, I did this because I loved technology and wanted to share what I did with others. Truth be told, I’m still the same way. I’m the primary architect and developer of the eLearning platform that my company built for internal use and is now marketing as a cloud-based product. On the inside, every time I/we add a new feature to the software, I want to run out and show someone. Why, because I think it’s cool! What I have learned over the years, however, is that everyone looks at new software features from their own business/personal perspective:

• Sales people wonder if it will help them close a deal with a currently available customer.
• Marketing people try to decide if the new feature will give the product a competitive edge against the competition.
• Accounting people wonder if the feature can be charged as a separate line item and/or increase support revenues.
• Technical Support people want to know how to explain the new feature to the existing client base and are nervous that it will increase technical support calls.
• Product resellers wonder if the new feature will help them increase their business.

All of these people/organizations are correct to think of this new feature in terms of their roles within the business. As the technologists who created the feature, we must be able to talk to each of these business constituencies from their perspective. If you don’t, then very possibly, your time with that person will be unfruitful for you both. You will be disappointed with the conversation because the business person doesn’t seem to appreciate your work and doesn’t really understand what you were talking about. For the business person, he/she leaves the meeting confused and frustrated. The person is confused by not understanding what you were talking about. He/she is frustrated because of not really caring how the new feature worked, or in some cases what it does. The client just wanted to know what effect the new feature will have on their job.

As an added point, software developers must be immersed in “how” something works in order to add it into the software. Users of the software generally don’t care how the software works; they only care about what it does and how to use it. This is also a very important conceptual point on how to talk with users of your software. Don’t tell them what you did, answer their questions based on what they need to know and at the level of level of detail they are interested in hearing.

So back to your original question as to what you should do so your business users will listen to you. The answer is:

1. Try to gain an understanding of the pressures, issues, business needs, and general technology needs of your business users.
2. Use this understanding as a way to speak with your users within their world, not within yours.
3. Listen carefully to what they are asking.
4. Think about what’s important to them, not what is important to you.
5. Answer their question directly, without added technical embellishment, unless they ask for it.
6. Speak to them at the technical level that matches their understanding of technology (very technical for some, very high level for others, as appropriate).
7. If you believe that you have not effectively answered their question, because of their body language or other observations, ask them politely if you answered the question in a way that was most valuable to them.
8. Repeat steps #3 through #7 as needed.

If you have any questions about your career in IT, please email me at
eric@ManagerMechanics.com
or find me on Twitter at @EricPBloom.

Until next time, work hard, work smart, and continue to grow.

Read more of Eric Bloom's Your IT Career blog and follow the latest IT news at ITworld. Follow Eric on Twitter at @EricPBloom. For the latest IT news, analysis and how-tos, follow ITworld on Twitter and Facebook.

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

CareerWhite Papers & Webcasts

See more White Papers | Webcasts

Answers - Powered by ITworld

Ask a Question