Early PM’s and their big first issue

Early PMs (Product Managers) often struggle to define and take ownership of a project's scope. Failure to do so can cause PMs to be hard on themselves and put downstream pressure on engineering and other verticals. This can create chaos with stakeholders, leading to optics issues. As an early PM, you must master the scope and define ahead of time what you want to support and what you do not want to support in a particular version or offering.

PMs often encounter problem statements and edge cases that have not been accounted for or envisioned in the first version. And that's totally normal. There is no one perfect release that can account for and support everything, as all products evolve over time. Hence, you cannot support everything in a particular release.

Navigating the route of scope and impact

Product Managers work on different product lines, and each product comes with its own unique challenges and importance for the overall company. For example, Meta (formerly Facebook) recently released Threads, a social platform intended to compete with Twitter. For a product like this, which is intended to reach the masses quickly, the scope of the offering will be large. However, this does not have to be the case for a startup or a product that is trying to disrupt a market. As the product evolves alongside the growth and engagement of the users, the scope can increase gradually.

Often, PMs try to optimize and build most of their vision/value creation in the first offering. This might be the right approach for some of the B2C (business to consumers) products if you believe the scale of engagement will be huge and you have to make the best possible impression to add the stickiness factor. However, in most cases, this is not necessary. PMs should lean on taking an iterative process in offering a product with a small to medium scope, meaning not more than 4-8 weeks of enhancements.

When the scope/impact of the project is big, i.e., multi-faceted/multi-dimensional, make sure to confine your messaging to your scope. As the product evolves, the messaging and GTM should also evolve in line with it. What I often see is that messaging/GTM content overpromises the impact where the product hasn't evolved to a given state, and this leads to more disappointment as the user's expectations with messaging haven't been met in the product.

Early PMs may not realize their success because they do not limit their radius of impact. As a PM, you may receive requests for things that you haven't built yet or that don't meet the performance expectations because you built it only for X threshold. PMs should first define the boundaries and territory for the solution they offer, which will help them focus on delivering a successful first version.

Remember, a larger scope does not necessarily mean a better impact. 🙂

Chaos from not defining scope and impact

First, let's define scope and impact. Scope refers to the features, segments of target audiences, and use cases/jobs to be addressed by the offering. Impact refers to the realization of envisioned value creation from the offering.

I often notice that PMs define either the scope or impact, but not both. This can create a tricky situation. If a PM defines the scope without defining the impact, the impact becomes arbitrary, and no one knows the goals and outcomes that the project is aiming for. This gives room for all stakeholders to think of their own definition of impact, which creates misalignments and makes the PM appear to be doing a poor job. As the PM hasn't set the right expectations, feedback and engagement from the audience creates chaos. For example, stakeholders may question why the PM hasn't built X, or why they haven't thought about a particular scenario, or why a user isn't happy about the offering.

On the other hand, if the user has defined the impact but not the scope, engineering, design, and other verticals may start building many features, scenarios, and more to create the impact. This could result in spraying and hoping for impact, as there is no well-defined connection between the scope and the desired impact. Building many different things in the hope of reaching the impact will lead to longer execution cycles and maintenance of the product for features that are actually not needed for the targeted value creation.

The ideal approach is to work backwards. First, define the impact that you want to offer to users. Then, do the backward math to determine exactly what is needed in the product to make the desired impact. Define the scope and freeze it to focus on the core objectives of the proposed impact.

A predefined scope and impact significantly simplifies the work of product managers and other stakeholders, allowing for confident decision-making and smoother execution.

Iterating to succcess

It is important to accept that customers may request features or tasks that are outside the scope of your product. While it is essential to clearly outline the scope and intended use of your offering, it is also crucial to be open to feedback and requests that may fall beyond its current capabilities and planned outcomes. Receiving feedback and requests for additional capabilities does not necessarily mean that you have done a poor job. In fact, it can be seen as an opportunity to gain insights into what the audience wants and how they perceive the product. For a product manager, receiving such attention and feedback is also a win. This information can be used to plan future improvements or adjustments.

Cheers!