This is a guest post by Nicholas Mitchell, PhD.
Like many life science doctoral students, I dedicated my years in graduate school to focusing on experiments, troubleshooting technical problems, learning to write manuscripts, and marveling at how fickle biology can be. I developed a cursory appreciation for project management, but I was the only person affected by my projects. My graduate program didn’t offer any management courses, and I don’t remember any of my mentors suggesting management as a good way to go about conducting science. If nobody was even talking about project management, they certainly weren’t talking about product management.
Project management is about creating (and navigating) a well-articulated plan for what needs to be done, how long it will take, how much it will cost, and who is going to do the work. A final component, which deserves special mention, is the ability to identify potential problems that would derail the project (e.g., an unanticipated shortage of the irreplaceable fetal bovine serum required for your experiments). The application of project management in the field of science is pretty obvious. And when you consider its definition, you are likely to find it reminiscent of the typical grant structure. This, I suggest, is not a coincidence.
Product management is not to be confused with project management. In fact, although product management utilizes project management, it is something entirely unique.
Product management is about identifying a problem and working backwards to strategically design a solution for that problem. This flow from problem backwards is important, because good products solve big problems. In the business world, a product’s worth (i.e., what people are willing to pay for it) is directly related to how much the problem currently costs them. I’m writing this piece because I think this is exactly how most of us should be conducting our scientific investigations. If you’re already conducting science this way, you’ll probably stop reading. If not, what I’m about to tell you is bound to make your science more rewarding and more profitable.
Grants are products, manuscripts are products, and posters are products. I know—you saw those coming. Have you ever thought of your experiments as products, though? They are. And if you aren’t designing your experiments to move you closer to solving a problem that will yield a high-impact publication, change someone’s life, or get you funding—you’re doing the wrong experiments.
For an improved understanding of how product management works, consider its application in the following setting.
When Bank of America needs software to control their new ATMs, a software product manager from their contracted software company, say Diebold, works tirelessly with thought leaders (TLs) and consumers to understand the most important functions that the new software must deliver. Those functions are then communicated to software coders through the creation of “user stories.” A user story is a brief description of an outcome that should be short enough to fit on an index card (e.g., bank customers will be given the option to receive a receipt for each ATM transaction). The coders then write a program that prompts the customer with this option at the beginning of each transaction. The coders and the product manager determine whether the outcome has been achieved through testing. Testing involves simulation of as many as possible, and often devious, situations that might result in a circumstance where the program fails to ask the costumer if they would like a receipt. The product manager knows the coders have done a good job when the program appears to work in all conceivable scenarios. Sounds like science, doesn’t it?
I’ve included this example because the most current and effective product management practices (Agile Product Management) were developed by management leaders in the software industry to manage complex and highly unpredictable projects. It would seem that scientific research projects also fit this bill.
I discovered agile project management about two years ago when I became determined to find a better way to manage my professional life. My journey was precipitated by the recognition that one week after having—what appeared to be—a productive meeting with a research student, I realized I hadn’t made either of us accountable for doing something that moved the project forward. Worse yet, I couldn’t remember the next step we were supposed to take. I realized I was a bad manager, so I tried to be a good leader and find a solution. My research led me to agile product management, which I practice in a version that I’ve modified for science.
Are you interested in learning more about the application of project and product management to your research? For a brief primer, consult Josh Kaufman’s The Personal MBA.
I’d also love to hear your thoughts on this post and receive suggestions for further elaboration or discussion.
Nicholas Mitchell is an assistant professor of biology at St. Bonaventure University, St. Bonaventure, NY. His research interests focus on determining what value adult hippocampal neurogenesis offers the brain for the purposes of learning and memory. To promote greater organization and efficiency within his undergraduate staffed research laboratory, he adopted both project and product management practices.
Note: StemCultures facilitates posting on this blog, but the views and accounts expressed herein are those of the author(s) or interviewee(s) and not the views or accounts of StemCultures its officers or directors whose views and accounts may or may not be similar or identical. StemCultures, its officers and directors do not express any opinion regarding any product or service by virtue of reference to such product or service in this blog.