This is Part 2 of a 3-Part series.
You're still in the first few weeks of taking over a half-built product, but you've conquered all of the steps in Part 1 of this series, and you're ready to get into the details.
You're past the first week; you now understand the goals and the timeline, you've gathered all of the relevant documentation, and your team is working well together. Now you're ready to make some progress in building the product.
Here are 5 steps for Weeks 2-4: Making Progress.
1 - Do a User Story Audit
For many of us, a user story audit means digging into JIRA, looking at all relevant user stories and epics on your board, and cleaning sh*t up.
- What stories are in progress? Are they all actually being worked on, or is dev blocked on some of them? (If they're blocked, throw them in the backlog until you un-block them!)
- Is the backlog prioritized?
- What stories are missing? (<-- This can be difficult to determine and will continue to be a work in progress as you move forward.)
- Is there anything you can close? Closing outdated or unneeded tickets is extremely satisfying.
2 - Do a (Quick) Agile Ceremonies Audit
If you're running some version of Agile, whether it be Scrum or Scrumban or Kanban or 'other', do a quick audit on what ceremonies are currently on the calendar. Then ask the following questions:
- Could you standups be more effective? (Pro tip: This question should come after answering the question: 'Are we having daily standups?')
- Are you holding retrospectives, or is there some other time set aside for talking through what went well and what didn't go well?
- Are you showing off your completed work via a sprint demo, or other medium?
Setting aside time to hold these types of meetings are positive steps for team cohesion, rallying around common goals, and (very importantly) celebrating successes and getting positive feedback.
Everyone - PMs, engineers, designers - likes to feel good about the work they're doing. Make sure you make time to tell your dev and design team(s) the awesome feedback you got during usability testing, or from recent customer interviews.
3 - Determine How Realistic Your Goals Are
This is hard to determine during Week 1, and possibly even difficult to determine during Week 2. However, by Week 4, you should have a good idea if the goals you're being asked to hit (by management) are realistic or not.
If the goals you've been given are unrealistic, be sure to gather evidence as to why this is so, and communicate it confidently and often to your boss. Have reasons and data to back up why Feature X probably isn't going to make v1.
4 - Figure Out How to Communicate Progress on High-Level Deliverables
What are the priority features? How can you communicate progress towards them?
Progress on key features should be as transparent as possible. There are lots of ways to communicate progress - This could be in the form of a burn down chart, a list of epics/ user stories in JIRA that show the relevant state (completed, open, in progress), or simply inviting your manager (and anyone else interested in progress) to sprint demos.
Pro Tip: No one wants to read a 3-page status email with a list of 83 user stories and their relevant statuses. That's what JIRA is for.
Communicating progress succinctly and often means there will be no surprises when you're ready to launch.
5 - Talk to Customers
Get a quick script together - some general questions on product usage, or just a few quick intro calls - and get to know some customers. Understand what your peeps are trying to accomplish with your product and what their pain points are. As a product manager, this is a key part of your job.
Pro tip: You'll undoubtedly hear versions of 'what the customer wants' and 'how they use they product' from others on the team, but nothing is better than hearing it directly from the customer.