02 Apr

Do you suffer from L.E.S. (Loudest Engineer Syndrome)?

shoutGraffitti_smaller

Tell me if this sounds familiar.

You are sitting around a table in a corporate conference room with your team.  The purpose of the meeting is to decide on the features of the product so you’ve gathered together all the people that you think should have a say in this decision, which usually involves an engineer or two or three.  You talk about it.  “We need to do feature x in red” says someone.  Others disagree. “No, we need to do feature x in blue”.

The meeting circles around for a while.  Then you have someone in the room that is really opinionated.  He insists that his way is the CORRECT way.  And builds a case for it.  Loudly.  He nonchalantly brushes aside objections as being illogical, or not having data to back it up.  He puts the burden of proof of those that resist his ideas.

Finally, people end up agreeing with him.  Partly because they are just beaten down, but also because no one has any evidence to support an alternate point of view.  

What just happened here?  You just made a product decision because:

  • You wanted to avoid another painful meeting like this one
  • You are running out of time and any decision seemed better than no decision
  • You didn’t want to antagonize the loud engineer

 

Clearly, none of these are very good grounds to make product decisions.  If you find it frustrating to make decisions this way, how do you think your customers feel when they have to live with the results?

What is intriguing about this scenario is that most of the people involved in it know that it’s a bad way to make decisions, but they do it anyways.  If you were to ask them, “do you think that product decisions should be made on what brings the most value to the customer?”  No one would disagree.  So why does this happen?

Usually this comes up when the team has a poor understanding of their customer.  When a team really and truly understands who they are building a product for, these kinds of decisions become much easier.   With a definite user in mind as a guiding principle, it becomes clear whether or not feature X should be done in blue or in red.  Of maybe even that feature X doesn’t even matter than much –  so honestly, who cares what color it is?  Just pick one and move on.

Let me just say here that I love engineers (I even married one!).  Engineers are the ones that are ultimately responsible for building the thing, and they are artisans at heart.  But here is the thing about engineers.  They need to be persuaded that what they are building is being done for good reason.  If they don’t buy into it, they will pull out the “that can’t be done” card, which trumps all other cards on the table.

Also, engineers tend to be data driven, so that is just another reason why it is important that this understanding of the customer be evidence based. It can’t be cooked up in a boardroom with no connection to reality. And it certainly should not be decided after all the decisions have already been made so that you invent a hypothetical persona that happens to need all the features you want to build.

I’m not suggesting that you subject every single decision to rigorous testing. Rather, that you front-load a lot of the work by making sure that you have a strong understanding of who is using your product and why.

Here is the key point. If you find yourself making decisions based on the loudest engineer in the room, it is usually a symptom of a deeper problem. It probably means that the team does not understand the customer well enough to make decisions any other way.

(Photo credit Creative Commons Commercial License: http://bit.ly/1C6BjCz)