Wild, Angry Bees and Why Your ITSM Vendor Needs Them

For some years now, I've been building up a resistance to kool-aid.  How?  Personally, I'm a pretty calm balanced person.  But as a software professional, I'm a wild, angry beekeeper.  I'll explain.


 


Angry is good, sometimes - A wise man once said, it is impossible to truly know the capabilities of a product unless it is used in anger.  This spoke volumes to me when I read it.  It explained so many problems, to me especially problems associated with product quality.  UI design and friendliness.  The OOBE (out-of-box experience)  KPI.   TTV (Time-To-Value).  Why it is sometimes so hard to get a non-trivial problem reproduced and fixed.


 


Wild vs. Tame - As a software professional employed by a vendor, one tends to become familiar and even attached in a geeky sort of way to the products with which one works.    From your product's perspective, you are "tame" to it, as opposed to a user, who is "wild" to it.  An example of a "wild" user is someone who has been given a tool without direct choice, someone who hasn't been "sold" on the product.  Someone who can draw objective, unbiased  conclusions about the product's suitability.


 


"Wild" users seem to frighten software vendors.  Wild angry users are more likely to seek out and verbalize defects, and are resistant to lame workarounds (we all know the smell of a lame workaound that's a poor fit, or impractical to implement.  Especially when an obviously lame feature is "working as designed".  Yes, but it was poorly designed.  WAD is a loophole designed to take the vendor off the hook .


 


And that is a very well-designed and functional loophole, don't you fall into it.  My advice for wild, angry users:



  • Get on the vendor's advisory board.

  • Be active on forums and communities where these ideas are discussed.

  • Don't give up.  Persistence will get you very far.

  • escalate if the Working-as-designed isn't

  • DOCUMENT your problem, don't just complain about it.

  • Have a positive attitude when you're working with Support, especially if you are a Wild user.

  • If you angrily tell the tech support person "Your product is broken, fix it.", while it may clearly be broken, and while it may clearly need fixing, you're going to get a lot more help more willingly if you are forthcoming with details and are just a little bit nice. 


 


Here's my hyphothesis:  If you are sufficiently "tame", "workarounds" become indistinguishable from "features".  But if you are wild, "workarounds" anger you.  Every time you have to do a "workaround", you just wasted a little of your time and your company's money trying to make a product do something which it should do (your justification for spending time on it) but doesn't (the problem wasn't anticipated or wasn't important enough to fix in the version you're using.)


 


 The lesson and challenge is for software organizations to use wild  QA and product management and (were it possible) wild marketing.  It will HELP you to find out your own problems before the paying wild customers do.  Expensive but worth it - tell me if you agree, would you pay more for a product that had wild users QA it first?    The famous physicist Richard Feynman said it best:  You first have to work at not fooling yourself - then it is easy to not fool others.  If you've never read his cargo cult science speech, it is illuminating and priceless if you care about research or technology integrity.


 


Bees - We tend to want to go after the major themes and features going into the next release, the "big game".  The relatively slow, big targets, and only dangerous if you get too close.


 


But while you're waiting for the big game to come along, you're constantly attacked by diminutive "almost-bugs"  -  bees and mosquitoes - all the small features or lack thereof which add up to either a very positive or very negative feeling about the product's usability.  It is these that will kill a product more quickly than starvation, if you don't deal with them quickly.


 


Tame users are used to the bee stings.  But wild users are not.  Bees can be big mistakes in the eyes of the "wild" users.  Anger-generating mistakes.  Anger not often understood by the vendor.    "Can't you just…" is the wrong attitude no matter what words  follow.  It's the death of a thousand bee stings to a vendor.  High TCO.  Unfriendly features.  It's not being run over by the elephant.  You can adjust your road map and invest in the new feature and do it right, recover or advance or whatever, but it's very difficult to recover from a thousand angry bees - wild users who get stung a lot tend to sabotage your product if they can in retaliation for being forced to use what they perceive as a poor choice of product.


 


This post is really an essay on software engineering.  The tie-in to Configuration Management is, I want this short post to be a mental runway from which you can fly to your own conclusions about your choice of vendor for your ITSM solutions.  For some really good  essays on Software Engineering, check out this gentleman, Mr. Fred Brooks,  and his timeless anchor-to-reality classic, The Mythical Man-Month.  Mr. Brooks is the father of much of what we know as commercial software today. 


 


Maybe you wild and angry beekeepers out there will understand a little better the tremendous opposing forces facing software vendors.  Maybe you competitors will realize how one gets so far behind GOOD software companies that understand my wild and angry allegory.  And maybe, just maybe, you can help me keep a burr under our own R&D saddle - they ride fastest that way.  With love to all my R&D friends, of course!  They really do a tremendous job given their constraints.


 


I'm very interested in what you have to say about my Wild Angry Bees.  Please comment and let us know.  Thanks!


 

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Jody Roberts is a researcher, author, and customer advocate in the Product Foundation Services (PFS) group in HP Software. Jody has worked ...


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation