There’s nothing like the 39th anniversary of your library school graduation to cause you to reflect. I have many memories of a young, newly minted, newly married and very green librarian heading out into the big world. Ironically, my first task in those pre-Amazon days was to order a book—and I didn’t know how and was a solo librarian. Learning started fast in professional practice. What have I learned in the last 39 years, and is any of it useful?
Each of these personal insights and lessons learned that I'll share in the next three blog posts has at least one story and several failures underpinning it—and usually many. As I wrote this post I was surprised by how many little rules and insights drive my perceptions of innovation and product development. Hence, this column mushroomed into a three-parter. And, as I find to always be the case, there was some pain and some gain associated with learning these insights. I can’t guarantee that each philosophy will work as well for you as it does for me (as the kids say YMMV—“Your Mileage May Vary”) or in every situation. Also, when I look them over I see that some are attitudes more than aptitudes. That’s interesting to me. Attitude is everything. When you’re positive, positive things happen. Anyway, I have compiled this list over many years and thought I would share it with you this autumn. So here goes:
1. FAILURE
Yes, this is the big one! I need to keep reminding myself of the plethora of acronyms for ‘fail’:
- FAIL: Found Another Interesting Lesson
- FAIL: First Attempt In Learning
- FAIL: Future Always Involves Learning
- FAIL: Find Another Important Lesson
- FAIL: First Action In Learning
- FAIL: First Attempt In Learning
- FAIL: First Attempt in Life
- FAIL: Flawlessly Ascending in Life
We learn from failure. That’s something I need to remember often, and not simply as a means to forgive myself for striving and attempting to succeed. Lord knows I want to be successful without the learning but that’s just insane. I also need in my relationships (children, co-workers, volunteers, colleagues, etc.) to recognize others are also learning through the same process.
2. Iteration is everything
Closely related to the above, iteration can be viewed as multiple failures on the road to success. In this digitally and web-enabled world of information service and delivery, we are dealing with technology that is still in high school (less than fifteen years old) and many of its major players are barely out of kindergarten as they invent our future ecology. We just aren’t going to get it permanently right with a few development cycles. We are in a continuous development state and this state will likely last for eons. Indeed, the invention of the book took many centuries to standardize on what today we consider an intuitive format! So, we must focus on continuous iterative development of our interfaces, websites, content and services. And, every once in awhile, we have to be ready for that forklift upgrade. It seems that every five years one needs to rebuild and take advantage of emerging standards and new technology innovations. But, during that period until the next big thing comes along, we tweak and adjust and add new features as we iterate to achieve needed improvements.
3. Good, not perfect
Closely related to the first point too, is one that many of us have difficulty dealing with. We are after all a profession that covets the perfect catalogue record, believes that we can organize all of the world’s knowledge for universal access AND sits behind desks offering to answer all comers’ questions. Pretty nervy! It is a challenge for us to know when to release new products and services, or when to decide something is done, finished, and complete. Perfection as an attitude gets in the way of this decision. When our stock in trade was mostly uncorrectable hard copy, this served us well. Now that we spend so much time designing malleable interfaces, web products and content that is correctable and improvable on the fly, we need to decide when good enough is good enough. A valued colleague used to quote this “Good Not Perfect” aphorism in so many meetings that we had it printed for her on a t-shirt. It broke the perfectionist mindset logjam so often—and we all benefited from the real lessons derived from working with the real product instead of the ultimate product in our dreams.
4. It’s not the number of steps that cause delays in development—it’s the space between the steps
Have you ever been frustrated with how long it takes to accomplish projects? Of course you have. I have noticed that it’s not the number of steps in a project plan that determines how long the project takes. It’s when you take a breather between every step that causes delays. Now I am not saying that rushing is good, but good project management minimizes the space between the steps and stays focused on achieving the milestones and ultimate goal. I know that many websites benefit from regularly scheduled updates and improvements. Others seem to stay static and fossilized for so many years they require complete removal and rebuilding. By sticking to a pattern of innovation (see #2) and improvement, we keep things dynamic and engaging.
5. Freeze and Go!
The right metaphor for much electronic development is seasonal change—not revolution or evolution. With services delivered by humans, we can adjust and adapt as we see changes. Technology driven products and services are a different matter. Products are usually released in a somewhat fixed state. Changing them too often confuses the user, but not changing them often enough risks stagnation or even fossilization. Choosing the correct cycle is an art. If you do something revolutionary, it is often called “ahead of its time” in retrospect, but doesn’t achieve too much acceptance in the present—and the evolutionary approach can be death by a thousand cuts to sysadmins and users everywhere.Therefore, I like the seasonal metaphor where changes are collected and released on a simple schedule (quarterly, semi-annual [equinox/solstice metaphors are fun], etc.). This requires some rigor in the process where the release is defined and the specification is respected so that everything can be frozen, tested and released. Then the development team can “go!” and move on to the next step. I have seen too many websites and content projects risk failure through random tinkering, second guessing, scope creep, and poor management of good ideas for improvement. Don’t let this happen to you.
6. Prefer action over study
If you or your team are studying something to death, remember that death was not the original goal! I have been in libraries where their systems folks in the host institution were studying whether to upgrade from Windows 95 to 98 in 2005! Scary. Although we have a great core competency in research and study, we must know when to fish or cut bait. In risk-averse cultures this is particularly difficult. What needs to be learned and understood is that delay is as big a risk as poorly considered action. Pilots, betas, pre-releases, and good process reduce your risk (and provide learning opportunities too). This philosophy is closely related to the one where an enterprise values its conservative culture so much it gradually declines due to lack of adaptation to modern expectations (think Sears or Macy’s).
7. Brainstorm, Mock-Up, Build, Alpha, Rebuild, Beta, Pilot, Test, Launch, Evaluate, Re-Do
And there’s the process. It’s pretty simple but many make the mistake of trying to skip a step. I’ve rarely seen a skipped step that didn’t cause problems later. It sweeps unmade decisions under a rug creating a bump to trip over later on. Each step can be quite small and contained. You don’t need to bet the organization’s future on a single initiative—writ large in the strategic plan. You do need to have many projects at different stages of development in your funnel, by design. That way you have built innovation processes into the DNA of your culture. By building teams focused on a few key initiatives—e.g., virtual reference, federated search, social portals, and web portals—you can focus attention and run several projects in parallel. This starts to create excitement and a practical image of action over study—and gives multiple opportunities for launches and successes to celebrate.
8. Remember the rule of six (6) in usability testing
You get diminishing returns after asking the same question of similar people more than 6 times. Sometimes we think we can reduce the implementation risk of our innovative product features and functions by testing with hundreds of users. Some research (and personal experience) leads me to believe that that this volume of testing just increases your costs and delays delivery. For example, if you’ve designed a website for departmental users to share and curate content, you likely only need to test it with 6 users to learn enough to iterate an improved version before testing again. This technique will improve your product faster and you’ll learn more. You’ll also get closer to your target market’s needs and values when you work with them personally rather than reviewing hundreds of pages of click reports! For example, if you add a blog or a new library calendar to your library portal, test it with six people and integrate the what you learn from their experiences into your next iteration.
9. Remember the 15% rule
It’s extremely difficult for humans to actually see a comparative difference of less than 15%. I once read that research shows when we see the light from 100 candles, we don’t see a difference in brightness until 115 candles are lit. Interesting—I understand the same things are true of sound volume, color variation, and other matters of human perception. Indeed, in job evaluation systems, jobs are not considered sufficiently different until there is a 12.5-15% difference in the job’s points. So, what I have learned here is that innovation needs to be sufficiently different from what existed before in order for humans (users) to see the difference. Some people think that making 100 things 2% better will make a perceptible difference. This isn’t likely true, and for our purposes we should probably attempt to make a much smaller group of initiatives at least 15% better. Think content: if you increase your database by 2% more content, few will notice—they probably won’t notice until you’ve increased their hot topic with 50% more quality resources. I also think that this is why single small introductions of new features on library portals are often missed or ignored until they’re pointed out. They’re not sufficiently different to be perceived and noticed. Therefore, it might be better to make grander changes to bring attention to new services and products in our virtual space—or market them differently.
10. Use the 70/30 rule
“I agree with 70% of the plan and can live with the other 30%.” That’s the key to consensus decision-making. Lord knows the time wasted trying to achieve 100% agreement to all points and ideas. If you can lead your team to agree to this principle, you have made a major step forward in breaking the logjam of unmade decisions in ‘almost’ complete projects. Of course, major stumbling blocks that some team members can’t agree on must be worked through. Don’t let the minor ones hold up progress. Remember, the iteration rule—there’s always another season to make changes based on user experiences. Sometimes the ‘parking lot’ of ideas or decisions can be reviewed in the next version of the iterated initiative.
11. Remember the old 80/20 rule standby
No matter how few or how many users you have, 80% of your usage / revenue / statistics, etc. will come from 20% of your users. If you remove 80% of your users who aren’t delivering good user numbers, you’ll still be getting 80% of your use from 20% of your users. Don’t let some spreadsheet demon lure you into the productivity trap. In that 80% of users who are not using your product or service, a lot (or enough) are your non-users, yes, but also your future or emerging new users—users who are still getting comfortable with the product, users from other demographics where you’ll discover new products and services to create, and users who are just at a different point in the adoption curve. If you want to grow, you have to be a big tent to find all of your future users. If we only survey folks who came into the physical library, how can we be sure we’re meeting the needs of our virtual users?
12. Remember the 90/10 rule
It’s true enough that 90% of your costs in both time and money are in implementation, not development. It’s a crying shame but it’s true. Never underestimate the amount of time and effort that will be required after you have given birth to your baby product or service. Just like human babies, they require a lot of effort, expense, care and feeding, training and support to bring them up to their full potential. And as with kids, be patient; they’re marvelous when they’re all grown up!
So, there are the first twelve tips—more in future posts.
-Stephen
Stephen Abram is a popular Lucidea Webinars presenter. He is the past president of SLA, and the Canadian and Ontario Library Associations. He is the CEO of Lighthouse Consulting and the executive director of the Federation of Ontario Public Libraries. He blogs personally at Stephen’s Lighthouse. Watch for his new book from Lucidea Press on management tips for librarians, coming in autumn 2017!
