The Lean Startup: A model for Libraries
Let's say you do Library outreach and your Director wants to spend a good deal of your budget on digital signage. Or, you're a Systems Librarian and the reference group has been pining for a chat service, but your inclination is that your patrons -- who have a hard time with email -- will let the service die a cold, unnoticed death.
Libraries have to engage their customers -- in new and innovative ways. Today, that generally means building new stuff: technology, services, Where's Waldo contests, things that will bring more people through the door (so to speak).
But building services and tools takes time and effort. How do you set priorities? That's a major problem for anyone working on these projects. You certainly can't do everything, but with so many strings to tug at, how do you make sure you at least do something? More importantly, how do you politely show your boss she's off her rocker with the QR Codes idea? Or, show the director that your idea is better than, say, building a virtual reference desk in Second Life?
One very good methodology to stay atop these projects comes out of the Lean Startup, a book by Eric Ries, a superstar entrepreneur who's been affiliated (on the business side) with some hot tech firms and on the consultant side with a lot of new businesses. The book has got one foot firmly planted on the tech side, and -- as the title implies -- Ries also borrows heavily from the Lean Manufacturing model made famous by Toyota and other forward looking terrestrial companies.
There's been a bit of talk about libraries acting more like startups, and librarians acting more like entrepreneurs. Ries offers a great roadmap that is easily translatable to the world of most libraries -- and information organizations. There's a lot to cover in this book that I can't possibly touch, but I'd like to provide a few of the most important takeaways.
Solve specific problems
For one, you need to solve a specific problem. Many startups fail because they accidentally build products/services nobody wants or needs. Libraries have this problem, too. The trick is to understand when your idea isn't working out and figure out when to tweak that idea to make it more helpful to your users.
Ries' underlying argument goes like this: The faster you can build something (an app, a book club, a new reference service) and measure it correctly (and process the feedback), the quicker you'll be able to learn how to make the service/app better and more worthwhile to your users.
Secondly, you need to think of building products and services as a test. Don't say, "we'll build this app and see what happens." The only good feedback you'll get is that you've built a product. You must create a hypothesis: Product X will help our patrons do Y which will impact our Z. Build the product and release to prove (or disprove) your hypothesis. But that means you're now in the business of proving hunches, not building great big products -- at least not right away.
Make it minimally
And this comes to the third important thing: Don't start by trying to build the best product you can. Build a minimum viable product: just enough to get something out the door. If it's an app, let it do one thing well. If it's a service, give it a very limited scope. You don't want to spend too much time planning in front of the whiteboard, because that's wasted hours when you could be getting real feedback from real customers. (The firm 37 Signals also exhorts developers to make simple products that meet one specific purpose.)
The better we understand our customers, the better we'll be able to create products that meet their needs, Ries writes. Another important take away: You must provide at least half the vision of this new product; asking customers what they want is often fruitless because most people don't know what they want. Asking customers what they think of a specific product or service you've built is a better idea. (Mostly because you'll see first hand how people interact with this new service.)
Four: Find early adopters to help test it. Early adopters are generally very willing to put up with some bugs and funkiness for the trade off that they're on the cutting edge. They are also very willing to speak their mind, and you'll need all the feedback you can get. This is fundamental to building a great product: understanding what people like, don't need and how likely they're willing to use it. In the startup world, the biggest question is: Would you pay for this service? We don't ask that much in Libraries, but we can ask patrons if they'd actually use something we're building. Of course, you need to be prepared for the fact that nobody may care about your digital signs, QR Codes, or whatever.
Measure everything (worth measuring)
Five: Effectively measure your new product. To do so, you need to understand the best metrics to measure -- because looking at the wrong metrics will give you the wrong answers and could lead you down a rabbit hole. Before launching a new website, agree on specific statistics you want to count. (What, exactly, is a visit? A visitor?) If you think a new website will better showcase a particular service, make sure you agree on how to count increases or decreases in that realm. Ditto with a new service. We need to agree on what is a reference question versus a directional question.
This is important for transferring your product from early adopters (the cutting-edge gang) to more mainstream customers (and the meat and potatoes of your patron base).
Ries talks a lot about making statistics actionable -- with a clear cause & effect. How can you show a new service proves your hypothesis, like, say, bringing in more patrons? Is there another reason for the increase in patron requests, like a school holiday or the opening of a movie theatre next door?
The question you quickly need to focus on is this: Are the statistics backing up your original hypothesis? A lot of unknowns exist in the information environment, and you need to understand which parts of your strategy is working and not.
Six: Your product or service is not going to remain minimum forever. It's going to grow and become better. To aid this, you constantly need feedback -- quantitative and qualitative -- to understand which features you need to prioritize. The key is making sure the improvements matter to the customers.
You have to know when your strategy may not be working, or maybe failing. Every month you need to get your team together, look at the feedback, look at the numbers: What are they telling you? After an early increase, has web visits leveled off? Has popularity of the new service dropped off? Is your hypothesis coming true?
Remember, we need to make sure improvements matter to customers. But we also can't jerk from one customer comment to the next. Prioritize the changes, but only release them in small batches to make sure other users feel the same way. Ries spoke at length about thinking of new customers as groups or cohorts. (This seems a natural for Libraries, who can break users down by natural groups.) Ries uses cohorts to test the popularity of certain features: Give one group a new product with one set of functionality; the second group gets another set. How do their behaviors differ -- in the short term and over time?
Pivot when things get stale
Seven: If things aren't working as planned, you need to pivot: A change in your plan, direction, either in features, customer segments, platforms, etc. If your new chat service is failing, is it because it's difficult to use? (If so, make the UI simpler.) Or, are you focusing on the wrong customers? (Try a different group, like those who are used to getting questions answered online.) Or, worse yet, have you found that people don't feel they need to ask reference librarians questions. (Turn the service into answering things people do ask questions about.)
The pivot is emotionally charged for teams, Ries says, because people have invested a lot of time and energy into making the service work. They don't want their time and energy to go to waste. However, the cold blooded world of startups is you have to know when to stop wasting your time and understand when your product isn't reaching your customers as you thought it would.
As you can guess, the pivot is of particular importance to Ries' system. The bottom line is to build, learn and change (pivot) as quickly as possible. When you're moving through each phase quickly, each product or service iteration should be closer to what your patrons want. That's how you build sustainable services that will keep growing.
A disciplined team has a direction planned out -- and doesn't stray from one project to the next. The Lean Startup Method insures you're not wasting precious time guessing customer needs. It also helps you when you need to answer to a director's whims. Working with a real product or service (however stripped down at the beginning) is much more beneficial than thinking in the abstract about what patrons may or may not do..
There's a lot more that's important for Libraries -- and any other information organization -- in the Lean Startup. Organizations planning new ways to engage customers and patrons need to create methods to guarantee their hard work is paying off. The Lean Startup provides a lot of those methods that people can use right out of the box.