Defining The Attributes Of A Perfect Product Team

What are the main factors that influence the effectiveness of a product team? I will point out a few and share my experience.

Defining The Attributes Of A Perfect Product Team
Photo by Pascal Swier / Unsplash

In an interview, back in Jan 2020, I was asked a question – How would you define a perfect product team? I scratched my head, looked up at the ceiling, and scribbled on my notepad – I stumbled. Although I couldn’t clear the interview, it got me thinking. Being a product manager, I should know where I want to work. The “where” is the culture, the rituals, the people, etc. How should I imagine or reimagine it? If I were the product head, then what would my product org look like? So many questions but no ready answers.

It’s a tough one!!

To be clear, the question was not about any organization. It wasn't about product teams, that is, a team combining product managers, developers, user experience, and analytics. The question was about the product org which runs in parallel to engineering.

I am no expert, however, I have accidentally followed Sachin Rekhi’s explore and exploit algorithm. As a product manager, I have been exposed to B2C gaming products, B2B SaaS products, and enterprise platform products.

Since many factors influence the effectiveness of core product teams, I’ll focus on culture, ritual, and size.

Let’s Start with Culture

What exactly is product culture? There are numerous articles and studies on “product culture”. In short, product culture is an aspect of the broader organization that product management is responsible for. It might be an engineering-driven, data-driven, design-driven, or sales-driven product (ref: Finding Product Culture Fit). I can convincingly say that, at present, I work in an engineering-driven culture. In such a setup the first challenge is to stop yourself from wearing an engineering manager’s hat. Your dev team knows how to best implement the “how” part. Unknowingly or knowingly, it’s recommended not to go there. However, you should challenge the implementation if writing cool tech compromises business/product outcomes.

In the past, I have worked in sales-driven and data-driven companies. In a sales-driven organization, the customer success department dominated the product roadmap. Account managers had bigger say than the product leads. Integration consultants knocked product’s door for tactical fixes. The outcome - a product team primarily focussed on execution. Long-term product thinking was mostly compromised.

In the data-driven organization, the product manager’s best friend was the data analyst. UX had almost no voice. There was no balance between art and science. Although the objective of any feature investment was made super clear and measurable, PMs spent most of their time defining metrics and making A-to-Z measurable. Sometimes it felt like overkill. The product roadmap was almost always short-term. "Fast follow" was the most common strategic approach.

I haven’t yet worked in a design-driven product org. My biggest takeaway from working in these setups is that when executives drive product decisions, generally product management takes the shape of project management. In my opinion, shaping product culture is a top-down approach. The product head starts by defining the mission and values of the product teams, then seeks to cascade the changes to the product organization at large.

Moving on to Rituals

“Rituals” is one of my favorite words in the dictionary. Rituals contribute to culture. Beyond the obvious sprint rituals, stakeholders’ meetings, etc., I learned a few ceremonies from product leaders which foster collaboration and create a trusted environment. Here are my favorites:

Repeating Vision and Mission Statements in Every Meeting

In an interview, Jeff Weiner says

You have to repeat the vision. You have to repeat the mission. You have to repeat the strategies, objectives, your priorities, and take the time to define who you are and who you want to be culturally.

Only through constant repetition do people start to internalize and understand. This is a great tool to inspire your dev team and have them always speak the same product language.

Quarterly PM Celebration

This is a quarterly product managers’ half-day meeting to celebrate rituals. All PMs under a product leader would be present. We met to celebrate the triumphs and failures. We retrospect together, ate together, and enjoyed a drink together. The session helped us bond, and create a team that never hesitated to collaborate. Most importantly, the session was a welcome distraction.

Monthly PM Collab Session

As the name suggests, the idea of this session was to collaborate across products and co-create. It’s an open forum where you can grab anyone to discuss data, design, best practices, or any random product idea under the sky. I found this forum of great value because all Product Managers are usually sitting and meeting with their multidisciplinary teams and don’t get that many opportunities to sit together as product folks and brainstorm.

Ending with Size

Size matters! There is some very interesting research done on a product team’s size. The size depends on the number of products in the product portfolio and the product development team size typically an organization believes in creating. However, the research data clearly shows the smaller the core product team the more likely it is to perform effectively.

I’ve mostly been part of “one-product” teams – Dev, UX, Analysts, and PM working together on ONE product inspired by the product vision. However, I have also operated in a different setup being a part of a team that is responsible for a product portfolio.

The latter is not the ideal setup simply because the products progress in play-pause mode. I might be developing a feature for a product in a quarter but might not be touching the same product in the next quarter. This context-switching scenario harms the empowerment of the dev team. Even if you provide the engineers with the problem to solve and the strategic context, they always focus on the how part first.

If ever I was given a chance to retake the failed interview, then I am in a much better position to answer the question “How would you define a perfect product organization?”.

  • Focus on culture: Build a balance between art and science, Create a trusted environment
  • Rituals to reinforce culture: Think beyond the obvious sprint execution rituals, Forums to facilitate collaboration and innovation, Make it fun
  • Right-size teams: One team for one product, Develop empowered teams

My experience has shaped my thoughts and has given me tools to challenge the status quo. What is your take on your product team’s culture? What are you doing differently? I would love to learn.