Tech Terms that Drive Business People Crazy

Paul Dittmann, Monday, April 6, 2009 @ 5:55 am

Most designers and developers today are familiar with the concept of Personas for describing the users of a system.  In fact, you can use the same concept for how you talk to business people - the consumers of your services.  Put yourself in their shoes, and your services will be better received.

One of the things that drives business people crazy when talking to tech people are the terms they use.  Here are a few to avoid, and what might work instead:

Some terms not to use with Agile development

• Agile iteration zero - I understand why it's used.  It is the iteration before "real" development takes place.  Most business people start counting with 1 - iteration zero always leads to confusion.
• Agile backlog - call it a prioritized feature list.   To a business person, a backlog is bad - it means you're already behind schedule.
• Out of scope - never tell your client (internal or external) something is out of scope.  If you've convinced someone to use agile (often not an easy thing), nothing is "out of scope" - you need to talk about where they want to place it in the prioritized feature list.

Some phrases not to use with clients

• "You don't need that" , "Why would anyone want that", and anything similar.  In most cases the business users have a pretty good idea as to what they need and even if they don't, they will turn off communications if you start like that, thereby preventing the collaborative effort needed to reach a successful resolution.  Instead apply Dittmann Rule 1 - worry less about being right and more about being effective. Re-focus the conversation on their business goals and how that feature helps them reach their goals.   If you can help them get to their goal in a better way, they'll generally jump at the chance.
• "I don't know" - in response to why something isn't working.  In reality you probably don't, but if something isn't working (i.e the network is down and 100+ people are losing productivity) the person you're talking to is probably going to have to answer to someone up the chain - "I don't know" is not going to make them feel very comfortable or serve as an acceptable answer they can pass along.   Instead explain how you are going to go about identifying the problem so that it can be resolved (e.g. it could be the router or the firewall, to isolate the problems we are going to do x,y,z), and when you are going to update them.   "I don't know" spreads rapidly in an organization and creates ill will up and down the chain.  A plan for helping them can create sympathy.

I'm sure everyone has their own list, but the main idea is to think about how you would react to these terms and phrases if you were the consumer of services.

Related posts:

1. Are We Engineering Software or People?
2. Advice to Developers: Try Understanding the Business
3. Thinking about starting a SaaS or eCommerce business?
4. Agile 2009: A reminder of why each team needs leadership
5. Selling Git on the Business End

Comments (0)

Software Development

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment