What is a Product Management Philosophy

A Philosophy can be defined as “the study of the theoretical basis of a particular branch of knowledge or experience”. 

We can see the philosophy of product management as:

  • a theory or doctrine, or concept,
  • a way of thinking, 
  • a specific viewpoint,
  • a process,
  • a set of core competencies,
  • a set of beliefs,
  • a set of principles,
  • a set of values and attitudes.

The way the product manager views his product world will talk loud about his product philosophy. 

Different Product Management Philosophy Types

The PM philosophy changes from one organization to another. We essentially can find 3 types of PM philosophies that tell very concretely how Product Management is handled, promoted, and understood:

  1. The Product Management Philosophy guides the Engineering process,
  2. Engineering guides the Product Management Process,
  3. Engineering and Product Management find a common ground to work together on an integrated product philosophy.

Type 1- The Product Management Philosophy Directs the Engineering Process

This can serve the old-school type of companies well. Unfortunately, it does not create necessary emulation in a team and does not provide a team spirit necessary for a fast-growing organization. 

The product manager will probably act a little more as a manager and less as a vision and product leader. Often, this translates into poorly thought products as far as UX Design is concerned.

Engineering acting more or less in dependency mode, the expected product will show discrepancies between what the customer really needs and wants and what the team (or mainly PM) is offering. It will harm the communication chain with the marketing team, the stakeholders because what is being built can change too often in scope and (buildable) features.

Type 2- Engineering Directs the Product Management Process Philosophy

Obviously, tech businesses will often go this route while product managers will adapt and make sure all the decisions taken with strong tech roots origin will answer customers’ pain points.

In an ideal world, this product management tech-first mindset can work allowing technological leaps. The product manager then will build a vision, a roadmap, a set of goals after verified acceptable customers’ development assumptions. In short, they build leading to a huge tech step forward and the PM find a way to make money sustainably and scalably with it.

In a less ideal world, you could end up with often seen “features fest”: Engineering developing one more feature, testing one more practical software architecture, integrate one more new API. 

It can hurt badly in terms of time to market since the product in the making (or the prototype or the MVP) has no real opportunity to get customers’ feedback through user testing lab events.

Type 3- Engineering and Product Management find a Common Ground and Work Together on an Integrated Product Philosophy

Focusing on tech-powered, tech-first, SaaS products and related industries, we consider this philosophy as a better choice for product development success. 

Furthermore, it demonstrates a closer approach to what Product Management really is: shared product accountability with much clearer boundaries; delegation to engineering on features development; responsibility to the product manager for the vision, strategy, prioritization, and roadmap; customers’ needs guiding the product devlopment and leading the way.  

The Design Thinking process could appear sleeker, the time to market reduced grandly, and customers will respond positively since they will play with something they indirectly helped to design. 

Yes, I know, It sounds like a fairy tale. But the experience shows that it works. 

Which Product Management Philosophy Type Should We Choose 

We can’t say this or that product management philosophy is better. It all depends on the organizational culture, the technology level and integration, the industry, the market, its methodologies and tools (Waterfall, Agile, Kanban, Scrum etc…), and its development stage. 

PM Philosophy for Startup Development Stage

In this rough environment (shoestring budget if any; bootstrapping attitude first; in case there is any successfully achieved round, in some cases budget will be somewhat “guided” by investors supervision; (often) lack of experienced product leader or mentoring figure with a successful product launch track record) there is a large room for a smart and decisive product manager to thrive and the type 3 philosophy will serve him or her well. 

Startups will make or break great product managers because of the flatline aspect of this type of organization. The access to the top executives is direct with no unnecessary fluff. The product vision and the product strategy is better conveyed to the team and the company at large. The interaction between the PM and Engineering shows higher speed in product development process and reorientation, pivoting, can be managed way quicker.

We pilot a small boat, equipped with one sail. The rudder is simple to manoeuver and it does not generate any friction to move. In fact, we’d love to get some more resistance so that we can feel the power.

PM Philosophy for Fast-Growing Startup Development Stage

We used to pilot a small boat and now we need to change for another one. We hire and embark a larger crew. We map new routes to explore new destinations. We manage a way bigger engine and technical team.

This represents mainly the previous stage on steroids. The company is growing so fast that structuring it generates a whole lot of “logistics” challenges and keeping the startup spirit becomes more difficult. 

However, the teams can organize in a still streamlined way. The product manager role expands in stakes, responsibilities; and a need for structure starts to be addressed..

PM Philosophy in Already Scaled and Developed Organizations

The ship has become a large one where it is very important to move at a monitored, controlled pace; respect the chain of command; ensure global stability; approach new routes with caution; and hire a more conventional crew to manage only a part of one route at a time.

The product manager will generally only work on one aspect of a larger product that already sold well but needs better UX design, fewer unnecessary features; new key ones. The product lifecycle is well structured and maintained and shared. 

In case new product ideas need a product management team, the processes in place are more known, agile, quality assured. 

New product managers will find mentors, a training path, support, and coaching. The work is more limited in scope. The responsibilities reduced. The access to stakeholders and or the founding team almost absent.

Which Product Management Philosophy Should You Choose

As one can imagine, the distinctions I’ve made are only for better representation of the wide domain of challenges before a philosophy can be chosen over another one. 

The boundaries between which philosophy type applies to which company development stage can prove tricky. The company, societal, and local cultures will undoubtedly play a major role in choosing or “allowing” one over another.  

However, by keeping these different approaches in mind you will avoid making mistakes in choosing your first (or next) product management adventure that can pretty well define your whole career as a PM. 

It’s not so much the philosophy that counts on your learning path and future career success. It’s more the level of knowledge, skills, abilities (KSA) you want to reach that count:

  1. establish clearly where you stand now in terms of KSAs, 
  2. identify what makes a good PM, over the acceptable PM that you are (or what makes a great PM, over the PM you already are),
  3. project yourself in the skin of this ideal PM you want to model, and 
  4. list all necessary and indispensable and additional KSAs you will need to integrate into your practice to reach the next level.

Then it’s your turn to build your own KSA ship to manoeuver.

Related Articles