-
Notifications
You must be signed in to change notification settings - Fork 3
Product Role Description
A product lead is half strategist and half tactician as they help steward a product from ideation to reality.
They are responsible for defining a vision for a product; working with users, key stakeholders, researchers designers, and developers to understand the problem and formulate solutions.
Once the vision or roadmap has been defined, the product lead then drives the execution to ensure the right product is built the right way
Objective 1: Define a Vision for the Product
At the onset of a project, the product lead ensures that the problem statement and users' needs are well understood. To do so, a product lead develops a strategy to surface that information as efficiently as possible. They work closely with designers to facilitate workshops, conduct user research to develop a deep understanding of the problem space to be addressed.
The product lead then continues to collaborate with designers, engineers, and other subject matter experts to shape a vision for a solution for the users' unmet needs. This vision is also shared with stakeholders to get a common baseline understanding across the board of the product to be built (or bought).
To succeed in this objective, a product lead should have the following skills:
- Strategic Problem Solving
- Collaboration
- Communication
- Negotiation
Objective 2: Execution
Now that we have our end goal in mind, we need to chart our course to get there.
The product lead leverage agile methodologies to break that chart up into iterative increments.
- They work with stakeholders to prioritize the more impactful aspects of the product are created first.
- They focus the team's sprints to deliver those prioritized features in iterative increments (starting with an MVP).
- They ensure feedback cycles are ever present so that users are constantly validating the product (and make any needed course corrections).
- They continually manage risk as situations arise and work with the team to make pragmatic trade-off decisions
- They bridge the product development team and stakeholders; over-communicating so that there is a common understanding of the product and state of the project.
Objective 3: Foster Strong Teams
It is impossible to execute well without a strong team in place.
The product lead enables the team, remove obstacles, and does what is needed to keep the team moving along. They are like glue, keeping a cross functional team together and expanding their role to fill gaps when needed.
Sprints are a fundamental practice of Agile teams practicing Scrum or Scrumban. This is a timebox (many teams start with 2 weeks, some highly advanced teams scale it down to 1 week) during which the team identifies a set of functionality (user stories) that they want to deliver at the end of the sprint. Having this common goal helps the team focus their efforts for the sprint duration.
The product lead, on the other hand, has to split their time between helping the team tactically execute during the sprint as well as preparing for the next sprint or looking strategically further onwards.
The following is a description of a typical sprint for a product lead showing how they split their time.
- Sprint Planning: During this meeting, the team determines what will be delivered at the end of the sprint. Coming into the meeting, the product lead has a backlog of stories to capture the scope of the sprint. During the meeting each one of the stories is discussed in detail so that the team has a common understanding of what is being asked as well as the effort required to deliver. These discussions can often lead down a rabbit hole discussing implementation level detail. It is the product lead's responsibility to keep the team from getting stuck on a particular story. Keep in mind that the goal is that by the end of the meeting, there is agreement as to the scope of the sprint and that the scope is achievable. Note that while the product lead may be coming in with a backlog in mind, it is the team that agrees how much of that backlog can be accomplished in the sprint.
- User Story Kickoffs: As each story is picked up by a member of the team, there may be additional questions around it. The product lead and that team member can have kickoffs where those questions are discussed prior to work being done on the story.
- Daily Standups: A daily meeting the entire team attends where each member of the team discusses what they have accomplished in the previous day, their plans for the next day, and and blockers. This meeting should not be any longer than 15 minutes; detailed discussion regarding any issues should be parking lotted for follow up after the standup.
- Roadmap Prioritization Discussions/Investigation: While the team is executing on the current sprint, the product lead can use this time to sync up with stakeholders to develop the priorities for the next sprint.
- Usability testing & synthesis: Usability testing should occur early enough in the sprint such that any urgent findings can be incorporated into the next sprints's scope.
- Daily Standup: It's called daily for a reason ;)
- SoS Sync-ups: When multiple teams are working on a particular product the Scrum of Scrums is a meeting where the leads from each product team get together. They discuss any risks to dependencies they have of each other's teams for the current sprint but also discuss the targeted scope of the next sprint to identify dependencies for that script.
- Story Creation: Coming out of prioritization discussion and usability testing, the product lead can now begin to create stories that would be candidates for the next sprint.
- Daily Standup: Seeing a theme here? =P
-
Mid sprint checkpoint: But there is one special thing about this standup, other than talking about what happened for the day, the team also looks at the stories that were committed to during sprint planning and takes an assessment of where they are. A few examples of things to consider:
- Should they reduce scope on stories in flight to get to the others?
- Should some committed stories be taken out of the sprint? If so, what is the impact and who should be informed?
- Is it crunch time, do we need to dig deep and put in a few extra hours to get the stories? (use this judiciously as it can lead to team burn out)
- Story Creation: Continue authoring stories for the next sprint
- Daily Standup: Yep, you guessed it!
- Backlog Grooming: Seeing that during planning or as we execute, not all stories may have been committed to; there is undoubtedly a backlog of stories building up. Backlog grooming reviews those in conjunction with the new ones created during the sprint to understand what should be prioritized for the next sprint. In some teams, the product lead does this independently; in others there is a meeting amongst the team to discuss. The tradeoff for the latter is that on one hand, it's another meeting that takes time; but on the other, if the team is part of backlog grooming, the planning meeting can go faster.
- Daily Standup: #expertmode
- Usability testing and synthesis: While the next sprint has likely already taken shape, you can't really go wrong by having more frequent usability tests.
- Story Creation: Take feedback from the usability tests and ensure they are in the backlog.
- Demo/Release prep: Get ready for the sprint demo at the end of the sprint.
- Demo: The work done during the sprint is now demonstrated to the stakeholders (with the entire product team present). This meeting serves both as a showcase to the stakeholders as well as a celebration of the hard work the team put into the sprint. Seeing working software often is highly motivating for the team.
- Retro: To foster continuous improvement amongst the team (and not just the product), the team (just the team, no stakeholders) hosts a retro to discuss what went well and not so well during the sprint. The product lead may facilitate this meeting but should also recognize when they should bow out of the meeting if their presence may affect folks from providing open feedback. The team often agrees to 1-2 corrective actions to take in the next sprint. (Trying to tackle more than 1-2 per sprint is unadvisable as you want these corrective actions to stick). Retros are key to ensuring the team continues to learn from its past mistakes.