The Cult of Simplicity - Part II

I left off in my last post discussing how the good folks at Adobe have provided us with an amazing example of bloatware in the form of Acrobat. I decided to sit for a few minutes today and really look at Acrobat for the first time in a while. I’ve been dutifully installing their new versions and various patches every other week for years now (at least it seems that way), but it has been ages since I have done anything beyond doubleclick on a .PDF file and pray that I don’t get forced to install an update before I can actually read my document.

What kind of interesting stuff do we find once we start poking around the bowels of the version 7.0.8 menu structure? Below are some of my favorite memories from an Acrobat treasure hunt.

• Find > PrintMe Internet Printing – Opens up a page from the support section of some service called PrintMe. Describes how I can print documents anywhere in the world from my Blackberry or other device. Seems cool. How do I use it? Hmmm…here’s a link labeled “Find a Printer.” More instructions…and yet…none of them have anything apparent to do with Acrobat. None of the links from this page give any clue whatsoever of how I might go about using this service.
• Edit > Preferences – I want to change the way my documents display on the screen - this should be straightforward. But wait…there are 20 different preference categories to choose from. What might be the difference between “Measuring” and “Units”? What does the 3D category look like? Uh-oh…choosing the 3D category just made my screen go absolutely black for a good 15 seconds. I wonder what that just did behind the scenes…
• View > Wireframe – I’m really curious about this feature because the word has a particular meaning to me. I click the menu item and it appears to be a toggle switch because a checkmark appears and remains. I look around…nothing seems to have happened. Let’s look in the help system. No index entry for Wireframe. Let’s search for it – “The complete help was searched and no matching topic was found.” Great…

All of these provide great examples of issues that often occur when lots of additional functionality gets piled onto an application. Acrobat has an interface to an external system that seems to be a dead end. It has tremendous complexity that obscures what are probably more common/important features. It has prominently displayed features that are totally absent from the system documentation. Yikes!

Someone out there must have version 3.x of Acrobat Reader that they can share. I am talking about the one that was really stable and took less than a few seconds to download and install. Wouldn't you just love to have that back again? I bet that you would never miss any of the advanced features like "managing trusted identities." 95% of you are nodding your heads vigorously in agreement. But what happens if for some reason you ever find yourself reading a document with a trusted identity that might need managing? Aha! That is where the real magic could come into play. Wouldn't it be great if the application realized that you were attempting to open this type of document and offered to download a plug-in? Sure it was an extra step, and sure it caused a little hassle, but isn't a minor inconvenience for a small subset of the user population worth the superbly simple user experience that the vast majority of us were able to enjoy?

Benefits

• Smaller software footprint and a simpler initial install
  
• Less complexity to obscure core functionality
• Straightforward user experience

Costs

• Some minor degree of user friction
• Additional effort to manage plug-in infrastructure
  
• Product Manager must work hard to understand what is really needed for core features
  

This is only one approach. Another one that comes to mind is to create multiple versions of the application. Maybe Adobe could offer a “home/lite” version as well as a “corporate/advanced” version. Let’s allow my grandfather to read his bank statement without all of this other extraneous stuff tempting him to get lost in the software while still allowing corporate users with fancy digital IDs to read their supersecret documents.

Of course, I am quite willing to admit that I may be dead wrong about my understanding of the Acrobat user community. For the purposes of this blog post I am certainly guilty of a Product Manager cardinal sin by assuming that all users are like me. Perhaps I am part of a tiny group that doesn’t understand and use the Wireframe feature every day – me and some small primitive tribe in the Amazon basin. I don’t think this is true, but it is possible. Unfortunately, I think it is far more likely that I am part of a much larger community that only wants a simple document reader that loads quickly, works reliably, and doesn’t get in my face on a too regular basis demanding that I pay some attention to it. That probably won’t happen anytime soon given the dozens of patents that Adobe proudly displays on the About Acrobat page, but a boy can dream.

Why won't they help themselves?

It's a requirements analyst's worst nightmare. You've been assigned to capture requirements for an insanely complex system. Your customer is suffering with their existing system. You're excited, because you know you're going to make a big difference in the next generation of the customer's software.
And then you hit the wall: the users.
You'd think that a user base would be excited to be able to tell you what they want in a piece of software. You'd think they'd feel empowered by getting a chance to feed their requirements and pet peeves into the replacement for the system that they hate. They've been living with work-arounds and limitations for years, and you're going to set them free.
But instead, the users are distracted and resentful.
Why would this be? There are actually a number of reasons why users may be reluctant or disillusioned with the requirements process:
1. They have real jobs to do.
Users may have been told to go meet with you, but many of them have "real jobs" to do. They have deadlines, work backed up, and a family waiting at home that they are going to see less of this week because of you.
2. They've been through this before.
Think you're the first guy to come through and ask them about use cases? Many companies have made efforts over the years to collect requirements. They've burned a lot of user cycles on this effort, and some users may be remembering the last guy who came through to ask them "What's the first thing you do in the morning?" If that exercise wasn't worthwhile, why would they expect yours to be?
3. Cynicism says that user input is secondary to business concerns
One statement I've heard frequently from users is basically: "I know you mean well, but our opinions don't really matter. The management is going to buy/build whatever piece of software they get suckered into paying for. Our input isn't going to matter."
None of these problems are insurmountable, but we need to address each of them separately, and probably in a different blog post!

Good news for BA's

In a recent article in CIO Insight 38% of CIO's of large companies ($1B+) responded indicating that they would be increasing the number of business analysts. Read the article and research here http://www.cioinsight.com/article2/0,1540,2004045,00.asp

Time is Money

I’ve recently had many opportunities to think about software adoption and the many factors that affect it, from both the product management side and the end-user side.
In all cases, the most important thing to keep in mind when considering adoption of a new piece of software is that time is money.
Think of every user as having a bank account full of time. Your software can either increase or decrease the balance of their account and this directly affects whether or not the software will be used.
An application can have every function provided by the current process or system and still not be adopted by the user community. People don’t want to spend time to learn a new process. Minimizing the change to existing processes can help speed up adoption by the community.
This is where use case analysis can be crucial. Even when replacing a manual process with an automated tool, you should carefully examine what tasks are being performed and how they are done today. If you have too many disparate steps between old and new, you are putting yourself at risk for low adoption rates.
Every step that deviates from the standard process takes ‘money’ out of the bank. Change too many steps, and you’re bound to go bankrupt.
Even worse is when a new tool performs the same function in more time than the existing tool. Nothing angers an end-user like having to learn a new process on a new tool and having it take twice as long as it did on their old mainframe application.
Of course, there wouldn’t be much point in adopting new software if it didn’t provide some benefit to the company as a whole. You have to keep in mind, however, that if it doesn’t benefit the individual end-users in some way, you run to risk of low adoption (assuming the end-users have a choice of tools).
The key is to put some money back in the bank whenever you can.
The tool has to have features that save the user’s time or allow them to perform functions that they couldn’t do at all in the past. New features are not nearly as important as speeding up existing tasks. People enjoy the ‘Gee Whiz!’ factor for the new features, but the end-users still have a job to do and they want to do it as quickly as possible.
Every feature should be analyzed against the overall business needs but also against the job of the end-user to ensure it will be needed and used. Performance requirements can then be written to ensure the new application performs at least as well as the existing process or software.
In the end, implementation of a new tool is a balancing act.
Here’s a pseudo-scientific formula to help illustrate the points above: Adoption Rate = [ (Time Savings) + 1/10 * (New Features) ] - [ (New Process) + 10 * (Time Costs) ]You may not get exactly 1/10th the benefit out of a new feature vs. a time savings, but the factor gives a good approximation.
The more process changes you introduce, the more time savings and new features you need to come up with to compensate for the loss in time. The more time savings your tool will provide, the greater the changes you can make and still keep the users happy.
It all boils down to simple budgeting – don’t spend more of your user’s time than you save them or you will be in the red before you know it.

Attention to Detail, Who Cares?

I do. And I’m well aware that I get some eye rolls from people who don’t agree – or just don’t have the attention to detail to understand. But really, why DOES it matter?
Honestly, I would not harp on this to the extent that I do if I did not think there is a link between attention to detail and ability to capture the right requirements.
Gathering the Details When gathering requirements, it’s important to hear the intricacies of what the group is saying. Are there assumptions that are unstated and possibly wrong? Are they contradicting themselves? Are there details that are being glossed over?
Typically unstated assumptions and contradictions are not going to be glaringly obvious. It takes someone who is tuned into the finer level of detail in the conversation to recognize such issues. This type of person will ask about 101 tiny details in those conversations, and maybe only 11 of them will turn out to be relevant. But those few that were relevant will lead to complete requirements, and in turn result in more successful projects.
Writing the Details When writing requirements, details absolutely matter. The obvious reason is that you have to actually write all the requirements you gathered – with all of the details so that they can be developed and tested correctly.
However, the attention to detail in the style and accuracy of writing also matters, such that the documentation is clean for ease of reading.
You need to use the same terminology throughout. If you don’t, the audience will not be able to make the connections that you have made in your mind. For example, if your users use the words “contract” and “SOW” loosely to mean the same thing in their business, then in the documentation you should pick one of the two words and use it throughout. In a glossary, you can define the word and include other common interchangeable words. But by doing so, you save the rest of your audience (maybe an offshore dev team) from having to learn the same connection you made between the two words.
Paying attention to proper grammar and spelling also is important. Without it, the audience will have to spend energy parsing instead of reading the real meaning. If I write a sentence like this one right hear now, can you understand what I’m trying to saying or did you have to slow down to understand the werds and turn them into a sentence before you could really get the actual gist of what I was tyring to convay?
Finally, the audience is also often detail oriented. If you aren’t paying attention to details in writing the documentation, they will be annoyed and need you to fix it.
Reviewing the Details Attention to detail is extremely important when reviewing requirements. It is important that a reviewer be able to identify any missing requirements in a set of requirements. Similarly, a reviewer needs to be able to find any inconsistencies in requirements that contradict each other. This means that when reviewing requirements, you need to be able to look beyond the surface level words on paper and understand if there are non-obvious issues. It’s much like in gathering requirements, looking for unstated assumptions and contradictions.
Managing the Details In managing a requirements effort overall, you also must have great attention to detail. From the beginning you should have a detailed plan to make sure you cover all parts of the system – a framework will help this. But you must also have the detailed personality that can follow a plan. So many people create the plan in the first week and never revisit it.
And finally, as you work through requirements, there will be many open issues that need to be resolved. Some of them will be small. The key is that you need to not lose sight of any open issues, no matter how small. Let’s say you are in a requirements session, and there is an open issue around whether a user really needs to be able to search using punctuation. The group realizes it’s time to move on, that it’s a small issue that can be decided later. Your job is to track that open issue all the way through to ensure it is closed. They won’t ask you to, but the detail oriented will automatically write it down and track it to completion.
Attention to Detail Matters In the end, I believe attention to detail is one of the most critical characteristics of a good product manager. When I see those that are lacking this attention to detail, I worry about what requirements they may miss. For such individuals, I would definitely pair them up with someone that does have a good attention to detail.