As a Product Manager, one of the most frustrating things is the feeling of a tug-of-war contest with developers colleagues: Developers will pull the rope towards technical debts and a robust infrastructure, while PMs will pull it back towards top notch designs and user experience.

Most of the time, the root cause for the tug-of-war contest feeling is not about the quality of the people. Rather, awesome employees tend to pull the rope because the culture of the company encourages them to do that.

In this short read, I’ll try to share from my experience working in Soluto, and demonstrate how working with a product oriented dev team can improve this dev-product relationship, and make processes more efficient, motivating and even fun.

Working in squads (Soluto’s ‘Journey Teams’)

The basics for allowing your team to be product-oriented are creating the appropriate conditions for it.

Spotify is known for developing a “product- oriented dev. culture” taking Agile methodology to the next level by optimising their scrum framework to be ‘squad’ focused.

A squad, according to Spotify’s engineering culture, is a small cross-functional, self-organized team which usually comprises of less than eight members. The team members have end-to-end responsibilities, and they work together towards their long-term mission.

Having a lot in common with these principles from Spotify, in Soluto we call our squads ‘Journey Teams’ because they focus on a chronological journey that the users experience with the product. Each Journey Team usually consists of a PM, a UX Designer, 3-4 Fullstack Developers and a Data Scientist (where relevant). We spend most of our day together in the same space, so there are almost zero meetings needed to talk about work.

The key drivers for the Journey Teams to success, as inspired by Spotify’s squads model, are:

  • Autonomy: Autonomy is motivating, and motivated people build better stuff, faster. This is because an autonomous team can take decisions locally rather than depend on managers and committees.
  • Alignment: Alignment enables autonomy. It’s important that everybody understands the company’s culture. The stronger our alignment, the more autonomy we can afford to grant. Autonomy with alignment increases motivation, quality, and again faster releases.

How to make your squad product-oriented?

Here are few concepts we use in Soluto to facilitate this culture:

  1. Arrange the teams around your product structure: Structuring the teams around customer journeys (or another equivalent structure, depending on your product) – is the first step towards a product-oriented team. When the team structure is defined by the product, the entire mindset is shaped around product goals.
  2. Define shared goals with product nature: It goes without saying that the team members should have aligned goals to avoid tug-of-war contests (alignment, remember?). The goals should be strongly coupled with the product KPIs: Conversion Rate, Feedback Rating, LifeTime Value, etc. These are usually owned by the PM, but are the responsibility of the whole team. When the entire team is measured based on the product goals, it is easier to identify when a robust backend solution is essential to reach those goals as opposed to when it is only proposed for the sake of engineering.
  3. Encourage the team members to participate in product decisions: If the team members are measured on product goals, they should have a say in the product decisions.
    Everyone is encouraged to participate in spec writing, user interviews, data analysis and in sharing their opinions on product decisions. Some developers are into it and some are less – they can choose their involvement level. This approach is great for the team’s motivation.
    Participation allows everyone to be aligned and to understand the bigger picture, and as a result – to take more informed decisions and move more independently.

What is the PM role in the product-oriented squad?

Taking all the above into consideration, many of the PM’s responsibilities are in fact the entire team’s responsibilities. There are still a few things owned exclusively by the PM:

    • Understand the product vision and make sure the team is aligned with it
    • Drive new feature initiation
    • When working on a feature – the PM is the one responsible to bring  the relevant background information to drive the discussion: Research, user testing & interviews, usability data, market trends etc.
    • Backlog prioritisation
  • Defining feature specs to details (after writing the initial structure together with the team)

To wrap up, here are the main benefits from working in a product-oriented team:

  • Higher agility: “You didn’t mention the edge cases so I can’t begin to code” – this is the voice of the developer pulling the rope in the contest. In a product-oriented team, dev & product can work in parallel. Team members have more liberty and confidence to make decisions, move fast and be agile in light of changes. Dev time might sometimes go to waste due to working in parallel, but that would be a fair tradeoff!
  • Better motivation: Everyone has the opportunity to impact the product they are working on
  • More time for learning, less explaining motivations: When the motivations are aligned and clear, the team members can spend more time on deep diving into interesting stuff
  • Less friction within the team and more fun! Working with shared goals makes it more fun to get to work every morning, and makes it easier to become real friends with your team members – which is eventually the most important thing! 🙂

By Ido Moskovitch

Senior Product Manager