This post was contributed by guest blogger, Rachel Rubinstein, a field-based software product manager at Oxford Nanopore Technologies.
If the first thing you hear when someone says they’re a software product manager is “project manager,” you’re not alone. A few years ago when I started my career transition from bench science to software product management, I confess that I had no idea what software product management was either. Coming from a strong background of undergraduate research straight to a lab career at a biotech company, I always assumed I’d work one or two years at the company and then go to grad school.
However, about a year and a half into my role, I realized that actually, I didn’t want to go to grad school. But, I didn’t know what else to do. Fortunately, the head of software product management at my company was open to meeting with me and explaining more of her role, which eventually led me to transfer to her team and begin my product management (PM) career. Had I known about product management earlier on in my career, I’d have realized it was a great fit for my skillset and interests. As such, I want to be able to share more about this nontraditional career path for others who love science, but realize that the bench isn’t where they will be happiest.
What is software product management, and how does it relate to science?
In the simplest of terms, a software product manager helps ensure that the company or software group is building the software tools for the right people at the right time. To explain a bit further, a software product manager works with internal or external stakeholders to learn more about their needs and any problems that they are trying to solve. After learning more about the stakeholders, the product managers collate and organize that information and form it into a roadmap--a plan for future features, programs, or tools to build. After organizing the information, a software product manager works with software developers to help implement solutions for the stakeholders. Finally, software product managers test the solutions with the users, gather more feedback, and start the cycle over again to refine the solution, or to come up with a new solution.
Now, you may be wondering how this all fits in with science. Well, I’ll give you an example. At my previous company, Ginkgo Bioworks, our software development team was working on lab operations software for next-gen sequencing (NGS), and high-throughput screening. While some developers had science backgrounds, most did not. It was my job to translate complex lab operations workflows into a format the developers could understand, so they could code the best operations software possible. Similarly, when the developers needed to know information from the lab folks, it was my job to get it into a format that helped the developers work in a streamlined manner. Now, in my current role at Oxford Nanopore Technologies, I work with our customers in the US to learn where the gaps are in their sequencing workflows, any problems they’re having with our software or devices, and anything they may need to help improve their work. Then, I distill and translate that valuable information back to the rest of my team in Oxford (UK) to help solve those problems.
What type of person goes into software product management?
I always tell people the best part of my job is getting to talk to so many different people! I communicate with customers, software developers, as well as team members in automation, sales, marketing, and more! This role is a good fit for you if you are energized from interacting with others, and have strong communication skills to tailor your message to any type of audience. Additionally, in order to keep everything running smoothly, you’ll want to be really organized. Often, product managers will have three or more concurrent projects in varying stages, which can get messy if you’re not on top of it. In a science-based software PM role, having a good understanding of the science for which you’re building software will help you be a valuable asset to the scientists as well as the developers. Lastly, you’re going to need to be a problem-solver. A lot of the time, the problem to solve is clear, but the solution is more complicated. You’ll need to be creative to be able to work with others to come up with a great solution.
How to get into software product management?
Depending on the stage in your career, there are many paths to software product management.
Early in your career:
- Try to get software product management internships, preferably on teams that run within the agile framework
- If you can’t find internships at science companies, try to find internships with translatable skills: working with data, working with people, working with complex processes
- Arm yourself with knowledge of software development so you can pick up the jargon and know the concepts as soon as possible
Later in your career:
- Show demonstrated skill of people and/or project management
- Bolster your skills in strong relationship-building and influence. You’ll need a large deal of influence and strong relationship-building in order to rally many stakeholders behind a common vision.
- Use your network to your advantage
As the profession gains more traction in the sciences, I believe that more and more people will have the opportunity to explore a career in product management.
A day in the life
Now that you know a bit about what a software product manager does, you might be wondering what the day to day looks like. Check out the infographic for an outline of my day or find the text version below.
- 8:00 AM--Log on! My team in the UK is five hours ahead, so I’m always catching up in the morning!
- 9:00 AM--Technical implementation review. The developers discuss which front-end and back-end coding frameworks to use. I mostly sit and listen to stay informed on the details, but the developers have it under control.
- 9:30 AM--Back-to-back meetings. Meet with my boss and coworkers, discuss current and future features being built for the analysis software program, and meet with the automation team to discuss automated protocols.
- 12:00 PM--Catch up. Finish any communications with my UK team members before they log off for the day.
- 1:45 PM--Write final report. Work on a final report for a user research project I led. It’s divided into the key takeaway themes and customer pain points we’ve identified. I can’t wait to send it out.
- 4:00 PM--Respond to customer help tickets. Catch up on customer help tickets, and respond when I have solutions. We use these to help us know what to work on next to help alleviate any customer pain points.
Many thanks to our guest blogger Rachel Rubinstein!
Rachel Rubinstein is currently a Field-based Product Manager at Oxford Nanopore Technologies for the North America region. She is particularly interested in DNA sequencing tech, and the intersection of technology, software, and science. She loves to advocate for the customer and help build software and technology tools with the customer in mind. You can follow her on twitter @rgrubinstein.
Additional resources on the Addgene blog
Leave a Comment