1. You’re not managing a product. You’re managing the problem it solves.
If you’re not solving a problem, you’re not a product manager. I’ve said it before and I will say it again. The most dangerous four words from a systems librarian or a developer are “Wanna see something cool?” Nope. I wanna see something that solves a problem for me or for my customer.
I’ve had many, many meetings with librarians and library staff about features. It’s easy to fall into the product trap of being a feature-monkey, simply cranking out more and more esoteric and edge-case buttons, clicks, and drag & drops (see any Microsoft product). So we fall into a trap of saying “can you make it do x?” I always stop people right there. It’s important to start with a problem definition. Don’t tell me what you want the button to do. Don’t tell me how your old system or workflow worked. Tell me what you’re trying to accomplish. In return, I promise to fall in love with your problem.
Falling in love with the problem is easy for librarians. We’re trained to help people. It’s why librarians like mystery books and obscure trivia. Librarians and product managers have this in common. Problems are our bread and butter. As Vibha reminds us in her essay, you will always have too many feature requests and too many bugs, and not enough time to address them all. Being intimate with the problem that your product is determined to solve will help ensure that you’re prioritizing things properly.
Unlike most library service, however, managing a product means making compromises. This makes it hard to be both librarian and product person (all you systems librarians in libraries out there know what I’m talking about!). But this is why I’m sharing this not just with product managers, but with librarians as well. Know that your product manager (or systems librarian) wants to give you your feature. Whether s/he does or not, at least understand–or make sure–that your product manager has a good understanding of the problem.