There are many different ways of doing product management. We all know that. One might say that there are many ways as product managers out there, and this is often the case. After all, we are all different and we have different approaches to different situations. Some PMs are more technical. Others focus on the business side of things.
Different types of products will require PMs with different skill sets. However, in my opinion, there is one key aspect that is not quite covered by the available literature. And we are not talking about the market of the industry, but if the product was formulated internally or externally.
What do I mean by that?
Well, are you building a product for yourself (your company) or an external client? This is going to determine if your practice is product-based or project-based. And believe me, they are different. Very different.
Project-based product management
Let’s start with the “project-based” way of doing product management. As you probably have guessed, they revolve around a project. A PM working in a software factory would be the perfect example of this.
Usually, the product manager has an external client that requires a digital product (although it could be any type of product) and hires the software factory to build that product for them. The job is to understand the client’s pain points and through an elicitation process come up with a series of requirements that will guide the development.
It could be the case that the primary user of the product is not your client, but your client’s employees or customers. In this case, product managers will be required to meet the client’s demands, factoring in the needs of the end-user.
For instance, creating an “ordering” app for a restaurant (the classic software product management example). The restaurant owner might have numerous requirements concerning the payment methods and the ordering process. But how the customers, or end-users in this scenario, interact with the app should be taken into consideration too.
The team has complete ownership of the “how”, but has to agree with the clients on the “when” and adjust the “what” (scope) accordingly. This is not to be mistaken for project management. Product people focus on adding value. In this case, it isn’t about doing what the client wants, but working on solutions that cover what the client actually needs to achieve his or her goals.
I don’t want to get into too many details, the key point here is that, in the stakeholder/end-user continuum, project-based practices tend to focus on the stakeholders’ satisfaction.
A product manager’ success will be determined by how well met were the client’s needs and how well managed were his expectations. This doesn’t mean that the end-user doesn’t matter. On the contrary, they play a very important role towards solving the client’s problem and have to be taken into account to figure out the best way to add value.
Product-based product management
On the other hand, we have what I would call “a product-based product management practice” (I know, kinda redundant, but bear with me). In this case, the practice is focused on the product itself, its cycle, and its sustainability in the long run. This is the case of product managers working in companies that own the product. For example, most of the product people working at FANG (Facebook, Amazon, Netflix, and Google) like companies.
What are the differences?
For starters, the requirement elicitation process is completely different. Since you don’t have “a client” but thousands and thousands of users, the approach of discovering the pain points requires different skills and tools. Identifying the opportunities that add value requires a blend of quantitative and qualitative research and analysis.
“You have to become obsessed with the user”. Well, not actually to THAT extent, but product managers need to fully understand his user and guide the development based on how the team can deliver the most value to it, fast.
Also, the way of measuring how well the product development is going is different in this case. User satisfaction, user retention, and new sign-ups are a few of the metrics that help product people to identify the right path into building a great product.
Moreover, how the product is going to be released or the “release plan” is different. Releases and deadlines are defined internally. This means that the “when” is ultimately decided by the product team based on the input provided by stakeholders. The concept of “time to market” is key here. This is why it is encouraged to release soon and often.
However, I don’t want to get carried away. Going back to the stakeholder/end-user continuum, product-based practices tend to focus on the end user’s satisfaction.
In this case, a product manager’ success will be determined by how well the product does with the users. Great products are loved by their users and are sustainable from an economic point of view.
What does all of this mean for Product Managers?
A lot. Since both types of practices approach the management of the product from different angles, product managers have to have appropriate skills and tools for each case. Moreover, the “rhythm” and the tasks performed will often be different.
This isn’t your typical “one size fits them all” and I believe that is important to know this beforehand to have the right mindset and start (or at least try to start) with the right foot.
By no means am I saying that product managers with years of experiences building project-based products cannot excel at a product-based practice, or vice-versa. Ultimately, the goal is the same: add value and build actually useful products. However, as well as there are differences associated with the industry, who you’re building the product for is a very important factor to be aware of.
