First of all, what is a product manager?
A product manager is someone who bridges the gap between business and technology. They quite literally manage the product(s) that a company wants to produce and that a development team needs to build.
How that manifests in day-to-day, however, is much less clear-cut. My experience being Product Manager at Scouted, for example, hasn’t been by the book by any definition. From the way that I got into the position to my day-to-day responsibilities, my job as a product manager (PM) has always been interesting. But that’s what’s been great about it! Just like most jobs, there’s no ‘one way’ to be a PM. I’ll walk you through how I got here, how I learned to do the job well, and what you can expect in the role – you never know, Product Manager might just be the job you’re searching for!
Also on Mediabistro
How I got into Product Management
I started at Scouted as my first job out of undergrad, working as a Talent Associate to help candidates through their job search. I helped candidates optimize their profiles, worked with our Account Management team to coordinate interviews and help manage pipelines, and provided leverage to our Head of Customer Experience. My role at Scouted was always evolving as I took on more responsibilities and honed more of my analytical skills. I started using more of our insights and analytics tools to pull reports and optimize our processes, and eventually started taking on more responsibilities that required more tech and less human interaction/user support.
My slow transition into the more analytical side of things had a catalyst in March of 2018 when we had a major tech overhaul and a need for product management within our team. It was the combination of my work as a Talent Associate and my background in computer science that put me first in line out of those on my team to become a Product Manager. I had already gained an intimate knowledge of our platform and product working as a Talent Associate, from both the user perspective as well as from a backend, technical admin perspective. That experience combined with my 3 years studying computer science in undergrad put me in a position to help manage the gap between business and development, and become a technical product manager at Scouted.
How I learned to be a Product Manager
Our current CTO, who has over 20 years of experience in building tech companies, first walked me through the guidelines of my new responsibilities. We decided I’d jump right in and work 50/50 as Talent Associate & Product Manager to see how it went. Even though I knew our product basically inside and out and had experience coding and learning computer systems, this in no way made me fully equipped to start managing the product on my own. Once I got into the position, it was up to me to teach myself as much as I could, and quickly. The first and most substantial way I did this was by reading.
I read a lot of blogs when I got started. I mean a lot. Because we were in this transition period with our tech, I had to simultaneously fill in my knowledge gaps, ramp up to my new daily responsibilities, and help pick up and organize the pieces of our current tech. Blogs were my quick way to familiarize myself with the basics of product management, and I read (and still continue to read) books by established sources to work through the role and how I should structure it – one of my go-to’s is The Lean Product Playbook by Dan Olsen.
Check out some of my favorite blog sources below:
This role was not built in a day, though. Just like we iterate on our product, I iterated on my approach to this role from everything I learned in my reading. I worked with our CTO and development team to find out what worked best for all of us (and what definitely did not work), and after a few months of trial and error, created a process that was cohesive with our entire company’s existing workflows.
Additionally, our CTO put me in touch with other Product Managers to be mentored and to share experiences as we all iterate through the role. Through talking with other PMs, I got to learn that pretty much everyone has gotten into that position in different ways and comes from different backgrounds. Learning about how they manage the position has helped immensely both to overcome the learning curve and to know that other people are experiencing the same things you are and have the same questions and challenges.
Day in the life
A day in my life as a PM varies, especially since I work on another team at Scouted to keep helping out with candidates’ job searches (#startuplife), but there are definitely some common themes with any PM role.
User Input
Here at Scouted, we talk to our candidates every day – whether that’s through interview prep, resume feedback, or in my case as a product manager, hearing the problems and questions people have when using our product. We use email and ZenDesk to manage our candidate communication, with ZenDesk being my main way to hear from our users. By running our support channel, I know immediately when users need help using our product. This, along with many other monitoring tools that help us collect feedback and user behavior trends, allows me to keep a finger on the pulse of our site. We’re a small team here, but as you become a more experienced PM or if you work at a larger company, you’ll go from speaking directly with users daily and seeing their input first hand, to hearing more synthesized accounts of user feedback, and even conducting or observing user interviews to get their input in real time.
Prioritizing
If I had to pick one word to define product management, it would be Prioritization. Everyone is coming to you with things – broken things, things we need to build, things we’d like to build, dreams for the future, etc. You need to be able to decide which one should be tackled first, if at all. Fear not, as you hopefully have some groundwork to help you with these decisions. This help comes in the form of your Company Vision and a Product Roadmap – the long-term strategic plan for your company’s product. Not everyone has a fully established product roadmap, but it’s pretty safe to say that every company has a vision – aka what your company is trying to accomplish. Its end goal. The product(s) your company has and the ones you plan to build should all do their part to help accomplish that company vision as a baseline requirement.
Once you make sure every feature or idea achieves that baseline goal, I like to prioritize based on other important aspects like how many of our users it will reach, if it will help generate revenue or acquire more users, if it makes things more efficient, or if it helps build our brand. I also manage tech emergencies as they come up, and dig into things that might look like emergencies in order to get to the root of the deeper problem before they get to the development team. You have a certain amount of resources, so you not only want to make sure time is being spent on the right things first, but also that the development team can work largely uninterrupted in order to finish those prioritized items.
Once you have determined something really is a priority, then you get to write what’s called a ‘user story.’
Writing User Stories
Once you have an idea of what the users want and need, and how that aligns with the company vision, you’re ready to write a story. A story is a way of clearly defining what your development team should build when they’re ready to build it. It lays out the end goal of a feature or update from the perspective of a user. This helps guide you and the development team and allows you to look at the finished product and ask ‘Did it accomplish the original goal?’
The collection of stories is known as a backlog, and it’s your job as PM to manage that backlog and make sure everything in it is well written with all the necessary details. You might inherit a lot of stories, as was my case, but even if you’re starting from ground zero, you’ll eventually have many many stories, which you’ll constantly redefine, reevaluate, and reprioritize as company goals shift, resources grow or shrink, or emergencies come up. What all of these stories will have in common is that they’re explicit and to the point, and are fully detailed so you could, in theory, hand them over to the development team and they can start building.
In theory.
In actuality, you’ll want to meet with your developers, which brings me to my next daily task.
Meetings. Lots of meetings.
You meet with internal company stakeholders, you “meet” with users, and you meet with your development team to make sure everything is in sync and good to go. How much I meet with people depends on the day and what I’m trying to accomplish. If I need a better understanding of a feature request from a team member, I’ll make sure to meet with those who requested it.
Since my work affects a lot of people, I start with the people who are in the trenches with that product feature in order to get a foundation, then work up to meeting with teams as a whole, including the decision makers who will need to sign off on the final approach we come up with. No matter the type of day, I’ll have at least one 15-30 minute meeting with our development team to go over the progress for the day, any questions they have for me, and what they’ll be working on next. This is called a standup. They’re great for keeping everyone on the same page and keeping us moving toward our final goal of some releasable feature, bug fix, or update to the site. I’ll also sync on the priorities for the week with our founders and CTO to make sure we’re all on the same page and that I didn’t miss anything or mis-evaluate tradeoffs of long term goals.
Testing
But how do you know these approved and fully-produced things work? Testing! The last major part of my day is product testing. Once our development team finishes a sprint, and they’ve tested it internally for quality assurance (QA testing), it then gets sent over to me where I run through the typical flows of the user who will be interacting with the new feature/fix/update. This responsibility, again, comes with being a PM with a younger product but is so valuable for making sure we’re releasing things that we’re proud of. I make sure to cover all our bases in testing as a normal user, and many times recruit the stakeholders I originally met with when building the feature in order to make sure it works as we expected. Some things do slip by, in which case we’ll keep doing smaller ‘smoke tests’ when it’s live with our users to make sure everything is working like it should. This is also the benefit of having an ear in our support channel, as I’ll hear pretty quickly from users if something isn’t working as it should.
So what skills does all this take?
As I mentioned earlier, my experience as a PM has been at a small startup with a young product, so a lot of the skills I find helpful in the role come along with our company being at this stage. So while a PM at a more established company who manages just one product out of many might not need to juggle as many balls, for example, in general, you can expect to need the following skills and traits to thrive in a PM role.
Adaptability
You’re never ‘finished’ building a product. You iterate, the product backlog grows, things break, users request features, your company product goals shift, etc. You need to be ok with constant change and shifting priorities. There are two sides to this coin – you do get the satisfaction of releasing an item you’ve seen from start to finish, but the product itself is never done and dusted so to speak. Keeping a level head amongst an influx of issues from all sides of the company is essential so you can stay sane and make sure things still get done.
Listening
Your end goal is to help build and maintain products that serve your company’s purpose, which in turn is solving some need of your user. In order to effectively do this, you need to listen to the users, your internal stakeholders, your bosses, etc. You receive lots of feedback as a PM, so when users or stakeholders discuss certain aspects of your product, the ability to listen carefully and dig into what people are really getting at will help you filter through the noise and ground your priorities in your overall goals.
Clear communication
Part of keeping a level head amongst the influx of things coming at you involves a lot of communication – you and the engineering team can’t do everything that the users and stakeholders need, so be upfront about that, set expectations, and keep everyone on the same page and in sync. Great communication skills also come in handy for writing those user stories so that there’s no misinterpreting what a feature should look like or do.
Technical skills
There are technical product managers, which is the camp I fall into, as well as non-technical. You don’t have to have coding experience but I can say that it’s helped me a lot to have a general understanding of how certain technical things work with our site, especially as we were also transitioning development teams in the process.
Conclusion
No matter how you get there, product management is a great way to effect long-lasting change in a business. Your responsibilities may vary by company, industry, experience level, etc. but ultimately, you are constantly working to improve the experience for your users and drive home the purpose of the product and business. Finding a product and mission that you’re passionate about is key because there are few things more satisfying than releasing a feature that has a direct and tangible impact on your company and its users.
