This is Part 1 of a 3-Part Series.
As product managers, we rarely have the luxury of being assigned a brand-new product or feature to manage. It's not often that a product manager has the benefit of a clean slate, starting from scratch.
The reality is that most of us take over a product or feature that's 'in progress' - mid-build - and are tasked with hitting a launch date.
As product managers, we're often picking up where another PM left off.
Sometimes we pick up a superbly organized, well-scoped product or feature with a clear vision.
And sometimes we pick up a product or feature in some state of disorganization, that lacks focus, or whose team is disillusioned.
Where should you start when you pick up a product or feature mid-build?
Here are 5 steps for Week 1: Getting a handle on things.
1 - Define the Goal
What are you launching? When? Ask everyone (individually) on the team. Does everyone have a different answer? What does your boss say? Do you have clear direction on MVP scope, or do you have some wiggle room to define MVP?
When taking over a half-baked product, you may have a very clear goal consistently communicated to you by everyone on the team. "We must launch everything on this list by July 15th." If so, this is an easy step for you.
If you're getting varied answers from everyone on the team, you'll need clarification from management as to what is expected and by when. Once you get a clear and firm answer, make sure to consistently (and often) communicate the goal to your team.
2 - Rally That Team Love
Get to know everyone on the team, and set up a 15 minute one-on-one with devs, UX folks, designers, and any other PMs or BAs that might be working with you. Get everyone's take, and get a feel for the team dynamic. Ask your team what is going well, what can be improved, and what their roadblocks are.
You should manage your team's culture and cohesion like a product in and of itself. If you read my blog, you'll know that I am a huge believer in "a happy, cohesive team builds great things."
3 - Stop Talking About the Past, Focus on the Future
When taking over an in-progress product or feature, you could be stepping into a team with some baggage. This is certainly not always the case, and I've come into teams mid-build that are forging ahead with fantastic vision and speed.
However, if there is baggage, allow everyone on the team a little catharsis at first. Then swiftly move past it. Let them air that baggage (everyone deserves to let their grievances be heard), empathize and then make it clear you're moving forward. Being stuck in a less-than-pleasant past is a barrier to creating a positive future.
4 - Gather Documentation
Is there competitive research? Do you have user stories? IS there a PRD? Is there a Confluence area where all this information is stored, or do you need to pull in documentation from disparate areas into a common area?
Here are the key pieces of documentation you'll want to hunt down:
- A PRD, or other requirements, if they exist
- Epics, user stories or headlines in JIRA
- Competitive research
- Any UX research
- A project plan, if that's something done in your company
- Any other confluence pages describing features, storing meeting notes, and other random information about the product or feature
5 - Understand the Customer Problems to Solve (the Jobs-to-be-Done)
What 'jobs' is your product doing for its customers? (If you're not familiar with JTBD, you can read here or listen to a podcast episode on the subject here.) There may be documentation on customer personas with use cases, and if so, get your hands on this documentation and understand it.
You need to understand this. If there isn't documentation on your customers' use cases or jobs-to-be-done, create some, even if it's just for you to refer to. Later on, you can incorporate this into a Product Brief, or a Product 'Sell Sheet.'
6 - BONUS TIP: Share Red Panda Photos
I once threw in a red panda photo during a presentation with my current team.
I guess it isn't for everyone.