There’s been a number of times in my career where I’ve been fortunate enough to join an established engineering team to lead their product efforts. Most often it’s that they’ve operated without a product manager for some time as the organization grew and matured or priorities shifted, but it could be that you’re joining a team that previously had a product manager with a different approach or product philosophy. Regardless of the reason for the change, you’ll quickly find yourself in issue triage mode with engineers looking towards you for guidance, clarity, and prioritization, or at the very least, you’ll be staring down a long feature backlog or list of already-in-flight efforts and find yourself responsible for ensuring that the team is building the right thing. Where do you start?
Go near
Almost without exception, there’s always certain bugs, features, chores, or tech. debt that the team knows they want to (or need to) address and that can deliver immediate value to users. Start there. Those user stories likely won’t require much user research or product thinking beyond validation, if anything, nor detailed specification, and the engineering team can start (or continue) making forward progress while you scrub in to the problem space and get up to speed. This approach also helps to allay any fears that the new product manager might take a bull-in-a-feature-shop approach, upsetting the team’s momentum or diminishing the value of their efforts to date.
At this point, you should be spending most of your time listening, reading, and asking questions. Don’t think you need to have all the answers. There’s bound to be a ton of collective wisdom and institutional knowledge embedded within the team that will take time to uncover and absorb. If something looks off or doesn’t make sense, ask why, and seek to understand rather than proposing alternatives. You’ll want to dedicate your first few weeks to getting to know your new team, how they work, and any prior product work. Depending on the state of the team, beyond one-on-ones to connect with your fellow humans as humans, this may mean going through the exercise of documenting how the team works day-to-day, and what it values, both in terms of collaboration and in terms of execution.
Go far
From there, think big. Really big. Ask typical PM questions. What’s the underlying problem we’re trying to solve? Who are we solving it for? How does it relate to other products? Where do we want the product to be in a year or two? In five? What assumptions do we need to validate before the team can move forward confidently? Begin to socialize a shared vision for where the product should be, absent technical constraints. The process will take different forms depending on the organization and culture, but the end goal should be a written and agreed upon mission/vision/north star that the team is striving to build towards from a user’s perspective.
The idea is that you should drive towards consensus both within the team and among stakeholders on the problems you’d like to solve, who you’re solving them for, and what they look like to be solved (but not necessarily how to solve them). You can think of this somewhat like a contract between your team and your users to solve a certain problem in a certain timeframe. For me, this often takes the form of “blog-driven development”, where you write the blog post you’d like to be able to publish on launch day (a press release or mock press coverage would work as well).
Meet in the middle
After that, it’s a matter of meeting in the middle. With a shared understanding of where the team is today and appreciation for where the team wants to go, how does the team get there? This is where solutions (and solution validation) first comes in. Your role is often mainly to facilitate the discovery conversation. You’ll work closely with the engineering team (and potentially other stakeholders) to define your first few milestones (prototype, MVP, etc.) to start proving out your solution, as well as setting a goal for what “launch” or “v1.0” looks like, and some of the intermediate ships necessary to get there (X core functionality, N users in a private beta, go to market, etc.).
Largely, your tasks at this stage look like typical product management. Depending on the size of the project, this can take the form of qualitative and quantitative research, solution discovery, breaking big ideas into discrete tasks, roadmapping, iterating and getting user feedback, or prioritizing and sequencing the newly fleshed out backlog of features or user stories.
Repeat
Once you have a defined path to 1.0 and work is underway, it’s already time to start thinking about subsequent ships, both early follow-ups that might fall out of scope for the initial launch, as well as more ambitious efforts that you might think of as the 2.0 or 3.0 of the product or initiative. The process is roughly the same. If you assume you’re in a post-1.0 world, what does the product look like in a year or two and how will the team get it there, all informed by what you learned during the first iteration.
One of the things I enjoy most about product management is the ability to help build things that solve problems for users, and there’s no more exciting a time than when kicking off a new project or initiative. This is my approach, and while far from perfect, helps me to structure my thinking when joining a new team.
If you take a different approach, I’d love to hear them in the comments below.