Life as a Product Manager or what it’s like to wear a PM’s shoes.

Lately I have been being asked frequently about what it’s like to be a Product Manager, and I keep drafting similar emails back to these curious minds… so I figured I would draft up something for anyone else who’s curious about the things we care about, spend our time on, and the more process driven scenarios we’re working through.

“Being a PM is like being the CEO of the Product” — Everyone

It’s kind of true. At the end of the day, a PM (especially so depending on the level the PM is at and the size of the company the PM is at) is really sort of the center of the universe. Product Managers do not typically manage any team directly (other than other PMs) but operate at the center most point of all of the different stakeholders within a company, and lead those different stakeholder groups through influence as opposed to title.

They say that true leaders are those that people will follow into any scenario, while managers are people that others will listen to because they are told to. PMs need to be strong leaders.

Depending on the size and structure of the organization you’re at, here are just some of the different groups of stakeholders you might be influencing or working directly with:

  • Sales
  • Marketing
  • Engineering
  • QA
  • Customer Service
  • Client Success
  • Release Communications
  • Growth / Insights
  • Competitive Intelligence
  • Content
  • Not to mention clients / users themselves

At the end of the day, it’s your job to make sure that anyone of the teams that you intersect with or guide knows where the product is at today, whats being released next, where there is market opportunity for the new enhancements, and whats coming down the pipeline on your roadmap. Hopefully you have these all aligned with a clear vision and goals so that everyone is pointing the ship in the same direction.

A typical day in the life

On any given day, depending on your release cycles, you might find yourself researching the market you’re playing in, doing deep dives into competitive projects, auditing workflows, looking into pricing models, writing user stories, creating a road map, building presentations, kicking off projects with your engineers, fighting for resources, wire framing, meeting with users, user testing, writing release notes, validating concepts, running design sprints, looking for growth hacks that work to increase your market exposure, jumping on sales calls to help push the wins, and the list goes on.

A single day really can be dramatically different from the next and is usually slightly dictated by the process your product organization subscribes to (and usually customizes the shit out of). If you’re an agile shop for example, you might be running weekly sprints, bi-weekly sprints, or some variation of what a sprint means. There are also shops that still run with a semblance of a waterfall approach, where you’ll be releasing products based on specs and pre-defined delivery dates. Or maybe you’ll do a combination of the two.

In my day job, we kind of do a mix of waterfall meets agile, where we have a quarterly release cycle, that we run sprints within. With my side projects, we typically look for the right process for the right timing and resources we have to work with. Which eludes to my next key point…


I’m very much a right process, right time kind of guy… but the bigger the company you work for, the more likely you’ll be in a much more defined process as the size increases.

If you’ve been exploring software development and thinking about wanting to become a PM… you’ve probably stumbled on the SDLC concept, or Software Development Life Cycle. SDLC is basically a framework for developing software at all given points of a products lifetime. I like to think of a sister to SDLC in a PDLC or Product Development Life Cycle… as the engineering component is just one lens to view the cycle from.

In my mind the PDLC can be broken out easily into a framework that I call I.D.E.A. Which to me is sort of the overarching 4 main stages of a product development life cycle. My process is defined as:

I = Ideation: Ideation is the stage in which I like to brainstorm about possible solutions, work through what exists, what needs to exist, unpacking the problems we’re trying to solve and formulating a theory around what a solution could look like. There are a lot of “How might we…?” questions happening here and resource gathering. Once we’ve articulated the problem and solution, the goal is to validate that as quickly as possible through whatever means you have at your disposal. This could include tools like Invision for prototyping or internally baked tools like our BigIdeer machine. We make our assumptions and define what success would look like.

D = Design/Develop: At this stage, we’ve now uncovered the problem, developed our hypothesis for the solution and done as much validation of that potential solution as we could. If all signs pointed to ‘continue’ we start designing the actual solution. This generally starts with the big picture and then we narrows that down to the MVP (Minimal Viable Product). I like to generally build the foundation that delivers value to the end users first, get to market so that we can further validate our assumptions, and continue layering on the features needed to drive the product and deprecating the ones that don’t.

E = Execution: Depending on the product / company etc. execution can mean a number of different things. Mostly though, this means releasing the product to the market. What (if any) change management needs to occur? Do we need to train people? Is there any documentation that needs to be released with the product to help users understand it? How do we enable marketing and sales to blow this up? How do we enable our content person(s) to talk about this and start building content related to the new product or enhancement? What channels do we want to open this up to? Is there a beta period or full release? You get the point…

A = Analyze: Now that we’ve identified the problem, validated it, designed the solution, engineered it, released it… we need to track it to see it is really solving the problem we set out to solve. What metrics are we looking at that define our success? What is the business case we set out to attack… and are we attacking it? If so… how can we do better? If not… what are we missing? Maybe it is simply that the problem we thought we were solving isn’t actually a problem… maybe it’s as simple as burying the feature to far into the navigation that no one can find it. Without having a clear picture of success, we cannot track our effectiveness… and thats crucial at the end of the day.

Okay… whats next?

Now that you have the general gist of what you can expect as a PM and how you can frame your thinking… it’s time to dig in and get some experience! In the meantime you can dig into some tools I love and use regularly like:

And you can also start educating yourself at places like:

And you can also start paying attention to the community with resources like:

And you can also read a shit load of great books like:

So cheers to you for diving into something you’re interested in. I urge you to try and find a role at a company where you believe in the mission and the product you’ll get to work on with the teams you respect. And as always… happy to chat on Twitter @rootchris

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.