Product managers are judged by the amount of impact they are able to drive for a business. Full stop.

Think about it like this:

Looking at it this way, it’s easy to see why smart, scrappy product managers are so revered: they get lots of the right stuff done with few resources.

This is, obviously, pretty hard to do! And it’s made even harder by the fact that great PMs need to be able to manage this kind of intense focus on shipping things that matter efficiently over a long period of time (think: years).

Generally, shipping things on time and on budget is “execution.”

At a specific feature or project level, this is project execution. Project managers (the other kind of “PM”) specialize in project execution.

Product managers do need to be good at project management. But project management doesn’t cover the skills of figuring out what to build and being able to continuously build toward a strategic objective over time. These skills are called product execution.

That’s a completely different ball game and the focus of this week’s newsletter.

We’ll break this down by:

1. Pre-product execution

2. During product execution

3. Post-product execution

Then we’ll look at an IA use-case for a writing exercise to anticipate risks.

Pre-execution

Good planning is the key to good execution. Being smart about what you build and getting ahead of the problems you may face is the best way to make sure your velocity doesn’t get tanked unexpectedly.

Aligning the Team on Vision, Goals, and Strategy

Before you start building a feature, it's crucial that everyone on your team is aligned. This isn't about a one-and-done meeting where you lay out the grand plan. It's about constant communication and reinforcement.

You need to make sure everyone understands:

• why that goal is important

• why this feature is important toward that goal

• how it fits into the broader product strategy

• how their individual tasks contribute to its successful implementation.

Doing this consistently prepares your team to make good decisions when unexpected situations arise.

Identifying Risks

You need to spend a fair amount of time anticipating potential challenges or obstacles that could hinder the execution process and developing contingency plans to address them.

Let’s say you're planning to integrate a third-party API into your product. Potential risks might include the API being deprecated or experiencing downtime. By identifying these risks ahead of time, you can develop contingency plans, such as having alternative APIs on standby or scheduling the integration during a period of low user activity to minimize the impact of potential downtime.

An amazing tool for identifying and planning for risks is writing what’s called a “premortem.” We’ll cover this more in the AI section at the end.

Creatively Scoping Features

Scoping features creatively is a crucial part of the pre-execution phase. It's about identifying the most critical aspects of a feature while actively avoiding scope creep. This involves understanding your product's real goals and making tough decisions about what is absolutely necessary for a feature to achieve those goals.

Imagine your team is working on a new social sharing feature for your app. The initial idea might include a wide range of options - sharing to multiple social media platforms, adding personalized messages, choosing different post formats, and so on. While these ideas might all seem valuable, trying to implement them all at once would lead to a bloated, complex feature that takes too long to develop and is difficult for users to understand.

Instead, a smart scoping approach would be to identify the most critical aspect of this feature - perhaps the ability for users to share content from your app to their social media account. You might decide to start with just one platform, like Instagram or Twitter (or… X ☹️), based on where most of your users are active. This allows your team to focus on delivering a high-quality, easy-to-use sharing feature without getting bogged down in unnecessary complexity. Once this core functionality is in place and you've gathered user feedback, you can consider adding more options in future iterations.

This approach ensures that you deliver value quickly, keeps the feature manageable, and guards against scope creep. And just to call it out, this is a clear difference from project management, which doesn’t involve changing the work itself.

During Execution

Alright, now you’re in the thick of it. This is where you get to flex your project management muscles. There’s really just one big topic to cover here.

Focusing, Protecting, and Supporting Your Team

During the execution phase, it's all about focus, coordination, and delivery. Your role is to shield your team from distractions and noise, allowing them to concentrate on their tasks and maintain momentum.

Say your team is in the thick of developing a critical feature that integrates your app with a popular third-party service. This feature is complex and requires focused effort from your engineering team. However, there are other ongoing projects and external requests that could potentially distract the team and slow down progress.

In this scenario, your role would be to act as a gatekeeper, managing external communications and ensuring that only the most critical and relevant issues reach the team. This might involve taking ownership of your team's intake process, triaging incoming requests, and dealing with any non-critical issues yourself. You might also need to manage expectations with stakeholders, communicating clearly about the team's current focus and when they will be available for other tasks.

At the same time, you would need to ensure that the team has everything they need to work effectively. This could involve regular check-ins to identify any blockers, coordinating with other teams to resolve dependencies, and providing the team with the resources and support they need to stay focused and productive.

By maintaining a laser focus and limiting distractions, you can help your team deliver high-quality results quickly and efficiently.

Post-Execution

You’ve finally done it! But you’re not done. This is an infinite game. It’s time to take your learnings, roll them into the next feature, and brace yourself to do it all over again.

Identifying Issues Post-Execution

After you’ve launched your feature, it's time to reflect. Now is your chance to identify any issues that may have affected the product's delivery so you can do them better next time.

For example, your team has just launched a new recommendation algorithm for your e-commerce platform. The feature was delivered, but it was a week late due to unforeseen complexities in the data modeling process. This delay had a knock-on effect, pushing back other planned features and causing some angry stakeholders.

You would start by conducting a personal review, analyzing the project timeline, identifying where delays occurred, and considering what could have been done differently. Perhaps the data modeling complexities could have been anticipated with a more thorough pre-execution analysis, or maybe additional data science resources could have been allocated to the project.

Next, you would discuss the project with your manager, giving them your thoughts. They might have additional insights or suggestions for how similar issues can be avoided in the future.

Finally, and most importantly, you would conduct a retrospective with your team. This is a chance for everyone to share their experiences, discuss what went well and what didn't, and suggest improvements for future projects. In this case, the team might discuss ways to better anticipate and manage complexities in future data modeling tasks, such as conducting more thorough pre-execution analyses or providing additional training for the team.

By identifying and learning from these issues, you can improve your processes and avoid similar problems in future projects, ultimately leading to more efficient and successful product execution.

Take Your Product Learnings and Apply Them to the Next Feature

Learning from what you’ve built and using those lessons to plan effectively for the next feature is the most important part of this whole process. Distill insights from your product's performance and use these insights to inform what you build next.

Analyze your feature deeply. Ask tons of questions, poke and prod, keep going until you’ve exhausted everything you and your team can think of. Imagine every insight is more valuable than a diamond. In some cases, they really are.

Then take these learnings and apply them to the next iteration of the feature, or use them to inspire other features. By continuously learning from your product's performance, you can make informed decisions about what to build next, leading to continuous improvement and long-term product success.

Pre-mortems – with AI

Back to the risk assessment portion!

Here’s a great AI megaprompt I’ve written to help you get a first draft.

Context you’ll need to provide:

• Project Description: [Provide a detailed description of the project, including its goals, team members, timeline, and any relevant constraints or challenges.]

• Key Stakeholders: [List the stakeholders involved in the project, including their roles and responsibilities.]

• Project Risks: [Describe any known risks or potential challenges that could contribute to the project's failure.]

Plug that information into this prompt, consider the results, and edit as necessary.

Persona: Imagine you are an experienced project manager and investigative journalist for The New York Times.

Action: Write a detailed premortem for a specific project, assuming it has failed, and describe the reasons why it failed.

Context:
Project Description: [Provide a detailed description of the project, including its goals, team members, timeline, and any relevant constraints or challenges.]
Key Stakeholders: [List the stakeholders involved in the project, including their roles and responsibilities.]
Project Risks: [Describe any known risks or potential challenges that could contribute to the project's failure.]

Format: Write the premortem in the style of an exposé article for The New York Times, including a headline, an engaging lead, and multiple sections describing the specific ways in which the project failed.

Example:
"The Downfall of Project [Project Name]: An In-Depth Analysis of Its Failure"
"As the once-promising Project [Project Name] comes to an abrupt and disappointing end, we delve into the myriad of reasons behind its collapse and what could have been done to prevent it."
"Lack of Clear Communication: How Misunderstandings and Ambiguity Led to Project [Project Name]'s Demise"
"Insufficient Resources: The Financial and Logistical Struggles of Project [Project Name]"
"Poor Management Decisions: The Leadership Errors That Sealed Project [Project Name]'s Fate"

Thanks for Reading!

If you enjoyed this, please spread the word! It means a ton to me.

Further reading

• 9 lessons from my 10+ years working in product (long post)

• Effective Product Manager – Execution

• Strategy vs. Execution