Describe the overall problem you’re solving. This should be an overview, so keep it brief...
- Use numbered bullets to outline the problem. They will make it easier to reference this point in a conversation.
- Link to issue here...
Describe the overall approach to the solution. Again, keep it brief – this section is more about the “what” than the “why”.
- Use numbered bullets to outline the solution. They will make it easier to reference this point in a conversation.
If there are any nice side-effects we should expect, list them here. On one hand, positive side effects can strengthen the solution. On the other hand, they can become distractions if the team forgets they aren’t the core focus.
- Use numbered bullets to outline the positive side-effects. They will make it easier to reference this point in a conversation.
This details section is where the meat is. Show the problem as clearly and thoroughly as you can.
- Include screenshots, metrics, user feedback, etc.
- Help the team understand the severity of the problem and who is affected.
A well-shaped solution defines the domain (e.g., the screens or sections of the product you want the project team to work on). This is important for a few reasons:
-
Bets are made orthogonally. In most cases, we don’t want to assign more than one project team to the same area of the product because that inherently adds external dependencies and complicates communication.
-
A big part of shaping a solution is de-risking it. It is virtually impossible to identify boundaries and rabbit trails without being pretty firm about where the solution lives.
-
Identifying scopes requires defining the domain. The project team’s first steps should be to survey the land and get one piece done. If they also burn precious time deciding which parcel of land to survey, they are immediately at risk of not being able to get started on the first piece.
Your pitch is based on imperfect information. The project team will uncover issues you never considered, so your solution should be flexible enough to accommodate new takes on the execution.
-
Use flexible language. Directions like “consider”, “explore”, and “try” help the team to see your solution while still providing the freedom to make it their own.
-
Show your solution. Wireframes or mocks are too concrete, while paragraphs are too abstract. Combining flexible language and fat marker sketches is a great recipe for demonstrating a de-risked solution while remaining open-handed about the details.
-
The project team will likely default to your direction. People tend to talk about pictures, not paragraphs. By seeding the solution with sketches you are inherently directing their conversation.
Re-state the main kernel the team should take away from this pitch and list out boundaries you won’t want them to cross. Be firm – these boundaries should protect their autonomy and outline the rabbit trails you discovered during shaping.
Some boundaries are like fences along a path. They are aimed at helping the team stay on course.
Some boundaries are like construction lanes on a road. They protect other teams or initiatives from getting run over.
Some boundaries are cautionary. They call out dangers inherent to the domain or the execution.
- List out the means by which we will measure success
- Link to any existing dashboards
- Call out any charts or screens the team will need to create
Is it related with a goal of the road map? If so, specify which one. Otherwise, explain why you think it should still be considered.
While a reasonable solution scoped to a 6-week timeline affords some really positive dynamics, it can also make the solution feel like a band-aid to the team executing the work. In the event that you have some kind of longer term vision, summarize it here.
This helps the team better understand how this work fits into the bigger product vision. It also enables them to make smarter decisions and empowers them to provide feedback on that future vision as they uncover new information over the course of the project.