A case study: Building a product without any full-time product managers "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs December 12 2021 False Building Products, Case Study, Guest Post, Product Culture, Mind the Product Mind the Product Ltd 1867 Product Management 7.468

A case study: Building a product without any full-time product managers

BY ON

Do you need a full-time Product Manager in your team? This post describes how small teams can achieve growth without the need for full-time Product Managers.

What you will learn in this post

In this post, you will learn how you can build an effective operating team of up to 30 people without the need for a full-time Product Manager. You will learn about a model of Shared Product Responsibilities (SPR) and get some examples of concrete building blocks that you can put in place with your team.

How it all started

One of the biggest risks for early-stage startups is not finding Product-Market fit and Product Managers play an important role in this pursuit traditionally. When we started our company, Kyte, all three of us co-founders were focused on doing the initial product discovery and finding Product-Market fit to de-risk the company. We all were talking to every stranger we crossed paths with, interviewed our first beta customers, and answered support phone calls to learn more about our target persona.

In short: all co-founders were doing some product work.

As we grew the team to 30 people in the next 24 months, we kept the notion of shared product responsibilities – and hence, didn’t have to hire for any full-time product manager.

As the guy with prior product management experience, I actually focused 90% of my energy on Growth Marketing. I spent only about 10% of my time on building the product, so we effectively operated without any full-time Product Manager over two years. This definitely came with some screw-ups but I would claim that the benefits overweighed. This post hopefully helps some other teams to learn from our mistakes and run even faster from the beginning.

A model of Shared Product Responsibilities

At our company, we were working in interdisciplinary teams with people in Engineering, Design, Business, and Marketing. Since we didn’t have a full-time product manager, some things were different from operating in a traditional product development setup for building tech products.

Three building blocks of SPR

We installed three building blocks:

💪 Extreme Ownership

➡️ Decentralized Product Processes

🌟 Strong North Star

1. 💪 Extreme Ownership

A high sense of ownership of every teammate was the key foundation for a successful Shared Product Responsibility culture. The more people felt ownership, the more they were thinking holistically about product decisions, not only from their view as an individual contributor but also from a customer or stakeholder perspective.

At Kyte, we’ve fuelled a sense of ownership in the following ways:

  • Set ownership as a company value: We define one of our three core values at Kyte as “It’s YOUR company.” Everyone in the company should have a feeling of ownership and take decisions as a CEO would do. (find the other values here)
  • Praise ownership continuously: Values are only worth as much as they are lived by. We’re praising any example of ownership taken among our growing team. In 1-1s, daily stand-ups, and weekly company all-hands meetings: we were (and are) giving kudos to teammates who were showing exceptional ownership in their respective areas. We also tie their impact back to the company value when praising: “It’s your company”.
Tie kudos to company values
  • Maximize customer exposure: We were striving to maximize customer touchpoints for everyone in the team. This is the key enabler for any teammates to think like a customer and to get a holistic view of the company. Everyone in the team who was based in our operating city delivered cars to customers, everyone took regular customer support shifts and came back with some feedback on things we should work on. With more scale, it is easy to slack on this (happened to us), we as a company need to get back to this mode of operation again as we scale.
  • Pull vs. push: For the first year, we didn’t work in sprints, just had a Kanban board with very limited prioritization and no effort estimates of tickets, just because there was no product manager or scrum master who would prepare sprints and priorities. We only later learned that instead of assigning tickets to single engineers, we can increase output by leaving them the choice to pick their next ticket.
  • Team goals vs. single ownership for engineers: We started out with a principle of 1 owner for 1 topic but had to learn the hard way that it is way better to split ownership from goals. A single owner of a topic makes sense but if the team has a common goal, they can work together more effectively. Especially for engineers, code reviews can be done without context switching, and pair programming is possible with one single owner per topic. So I strongly recommend starting with engineering team goals as soon as the team is big enough.

2. ➡️ Decentralized Product Processes

While processes can be burdensome when defined poorly, they can increase efficiency significantly if set up in the right way. We strove to create processes that made it very easy for everyone in the company to contribute to product work. With those processes in place, the barrier to contribute to product responsibilities was low.

Some of the core processes we deployed were:

  • Build a continuous pipeline of customer feedback. In different stages of the business, different modes of collecting feedback make sense. In the early days, we prominently positioned a Google Voice phone number on our home page, in order to maximize receiving qualitative feedback and the chance to convert every lead that had made it to our site.
    With more scale, we switched from phone to live chat as a more scalable option.
    Also, we were automating messages to existing customers, e.g. asking them for an interview with a teammate after their second trip.
Inbound funnel to generate customer interviews
  • Implement a #dogfooding channel in Slack, where everyone can post issues they find using the product, or issues customers are reporting. We made the customer perspective a team responsibility instead of the responsibility of a single product manager. If a customer complained about an unclarity on the booking flow using the support chat, this would get reported in our dogfooding channel and then put into an engineering ticket to be implemented.
  • Decentralized feeding of the product backlog. Clear instructions on how to write tickets in the onboarding flow for every new teammate. Everyone in the company should write tickets of ideas they have or bugs they find. This takes off a bunch of time of a regular product manager and can be done by any person in the company.

3. 🌟 Strong North Star

When people have a strong ownership mindset in the company, people make decisions on their own that drive the company in one direction or the other. Hence, it becomes even more important to align all the initiatives in one direction with a clear north star metric.

This metric can change as the company grows and it can be supported by product principles for example.

The main point is, if all efforts are aligned to pay into the overall company objective, the total outcome will be bigger than the sum of all the single initiatives.

When I asked Martin Eriksson, founder of Product Tank, about other companies with a similar setup, he mentioned that this setup of not having a full-time Product Manager and having Shared Product Responsibilities is quite uncommon but Stripe for example only started to hire product managers after their Series C round. They were a developer-focused company building products for other developers though, so it made sense to have developers acting as product managers. In contrast, Kyte is a classic B2C platform and I would claim that Shared Product Responsibilities without a full-time Product Manager worked up to a size of 30 people. So I hope it will also help other smaller teams to operate effectively and efficiently.

When full-time product managers make sense

For most companies, it actually makes sense to hire full-time Product Managers at some point.

By bringing a full-time Product Manager onboard compared to distributing the load of jobs-to-be-done to other individual contributors (ICs), the ICs can focus more of their time on their speciality. I agree with Martin Eriksson that good Product Managers can enable experts to “focus on what they are best in” while at the same time involving them in the key elements of the Product work.

Watch We can Build Better Things Together by Martin Eriksson 

Even in a company with full-time Product Managers, there is value in keeping Shared Product Responsibilities by a culture of extreme ownership, easy processes, and a strong north star.

Applying the Shared Product Responsibility model to bigger teams

How can product managers maintain a Shared Product Responsibilities culture across bigger teams?

  • Teresa Torres, the author of Continuous Discovery Habits, suggests the “Product Trio” being the ideal setup where a product manager works hand-in-hand with a designer and a software engineer (often a Tech Lead or Engineering Manager). All discovery activities are executed by the Product Trio while the product manager is leading the discovery process.
  • Product Trios focus on deeply understanding the customer or stakeholder. They can distil the information and loop in their teammates into key insights and key parts of the discovery process. This provides more time to focus on what they’re best at and enables them to keep an ownership mindset at the same time.
  • Similarly, Christian Idiodi, partner at Marty Cagan’s Silicon Valley Product Group, mentioned in a Product meetup: “Engineers should spend 30 min per day on Product discovery.”

While product managers are needed in most bigger teams, I encourage companies of any size to strive to instil the principles of extreme ownership, easy processes, and a clear north star in their culture.

Watch this ProductTank on Bets, Boards, Missions and North Stars by John Cutler

Full-time Product Managers can work much more efficiently if everyone in the company shares some of their responsibilities and the company achieves goals more effectively if everyone is enabled to think and act with the bigger picture and the customer in mind.

With that being said, our company Kyte is at a point where it makes sense for us to hire full-time Product Managers that continue to shape a culture of Shared Product Responsibilities. We are providing easier access to fewer cars with a ridiculously ambitious team, and searching for stellar Product Managers that embrace a collaborative approach to Product and who want to further develop this model with us as the company scales. Check out our job page if you’re interested in joining the Kyte crew!

Summary

I hope you learned a bit about how small teams can grow a product without the need for a full-time Product Manager and the three building blocks of 💪 Extreme Ownership, ➡️ Decentralized Product Processes, and a 🌟 Strong North Star help you build your own team or shape the culture in the company you’re working at.

Hit me up with any questions or if you would like to discuss any of these elements more.

Discover more case studies or engage with further insights using our Content A-Z.

Do you need a full-time Product Manager in your team? This post describes how small teams can achieve growth without the need for full-time Product Managers.

What you will learn in this post

In this post, you will learn how you can build an effective operating team of up to 30 people without the need for a full-time Product Manager. You will learn about a model of Shared Product Responsibilities (SPR) and get some examples of concrete building blocks that you can put in place with your team.

How it all started

One of the biggest risks for early-stage startups is not finding Product-Market fit and Product Managers play an important role in this pursuit traditionally. When we started our company, Kyte, all three of us co-founders were focused on doing the initial product discovery and finding Product-Market fit to de-risk the company. We all were talking to every stranger we crossed paths with, interviewed our first beta customers, and answered support phone calls to learn more about our target persona. In short: all co-founders were doing some product work. As we grew the team to 30 people in the next 24 months, we kept the notion of shared product responsibilities - and hence, didn’t have to hire for any full-time product manager. As the guy with prior product management experience, I actually focused 90% of my energy on Growth Marketing. I spent only about 10% of my time on building the product, so we effectively operated without any full-time Product Manager over two years. This definitely came with some screw-ups but I would claim that the benefits overweighed. This post hopefully helps some other teams to learn from our mistakes and run even faster from the beginning.

A model of Shared Product Responsibilities

At our company, we were working in interdisciplinary teams with people in Engineering, Design, Business, and Marketing. Since we didn’t have a full-time product manager, some things were different from operating in a traditional product development setup for building tech products. [caption id="" align="alignnone" width="584"] Three building blocks of SPR[/caption] We installed three building blocks: 💪 Extreme Ownership ➡️ Decentralized Product Processes 🌟 Strong North Star

1. 💪 Extreme Ownership

A high sense of ownership of every teammate was the key foundation for a successful Shared Product Responsibility culture. The more people felt ownership, the more they were thinking holistically about product decisions, not only from their view as an individual contributor but also from a customer or stakeholder perspective. At Kyte, we’ve fuelled a sense of ownership in the following ways:
  • Set ownership as a company value: We define one of our three core values at Kyte as “It’s YOUR company.” Everyone in the company should have a feeling of ownership and take decisions as a CEO would do. (find the other values here)
  • Praise ownership continuously: Values are only worth as much as they are lived by. We’re praising any example of ownership taken among our growing team. In 1-1s, daily stand-ups, and weekly company all-hands meetings: we were (and are) giving kudos to teammates who were showing exceptional ownership in their respective areas. We also tie their impact back to the company value when praising: “It’s your company”.
[caption id="" align="alignnone" width="1016"] Tie kudos to company values[/caption]
  • Maximize customer exposure: We were striving to maximize customer touchpoints for everyone in the team. This is the key enabler for any teammates to think like a customer and to get a holistic view of the company. Everyone in the team who was based in our operating city delivered cars to customers, everyone took regular customer support shifts and came back with some feedback on things we should work on. With more scale, it is easy to slack on this (happened to us), we as a company need to get back to this mode of operation again as we scale.
  • Pull vs. push: For the first year, we didn’t work in sprints, just had a Kanban board with very limited prioritization and no effort estimates of tickets, just because there was no product manager or scrum master who would prepare sprints and priorities. We only later learned that instead of assigning tickets to single engineers, we can increase output by leaving them the choice to pick their next ticket.
  • Team goals vs. single ownership for engineers: We started out with a principle of 1 owner for 1 topic but had to learn the hard way that it is way better to split ownership from goals. A single owner of a topic makes sense but if the team has a common goal, they can work together more effectively. Especially for engineers, code reviews can be done without context switching, and pair programming is possible with one single owner per topic. So I strongly recommend starting with engineering team goals as soon as the team is big enough.

2. ➡️ Decentralized Product Processes

While processes can be burdensome when defined poorly, they can increase efficiency significantly if set up in the right way. We strove to create processes that made it very easy for everyone in the company to contribute to product work. With those processes in place, the barrier to contribute to product responsibilities was low. Some of the core processes we deployed were:
  • Build a continuous pipeline of customer feedback. In different stages of the business, different modes of collecting feedback make sense. In the early days, we prominently positioned a Google Voice phone number on our home page, in order to maximize receiving qualitative feedback and the chance to convert every lead that had made it to our site. With more scale, we switched from phone to live chat as a more scalable option. Also, we were automating messages to existing customers, e.g. asking them for an interview with a teammate after their second trip.
[caption id="" align="alignnone" width="1125"] Inbound funnel to generate customer interviews[/caption]
  • Implement a #dogfooding channel in Slack, where everyone can post issues they find using the product, or issues customers are reporting. We made the customer perspective a team responsibility instead of the responsibility of a single product manager. If a customer complained about an unclarity on the booking flow using the support chat, this would get reported in our dogfooding channel and then put into an engineering ticket to be implemented.
  • Decentralized feeding of the product backlog. Clear instructions on how to write tickets in the onboarding flow for every new teammate. Everyone in the company should write tickets of ideas they have or bugs they find. This takes off a bunch of time of a regular product manager and can be done by any person in the company.

3. 🌟 Strong North Star

When people have a strong ownership mindset in the company, people make decisions on their own that drive the company in one direction or the other. Hence, it becomes even more important to align all the initiatives in one direction with a clear north star metric. This metric can change as the company grows and it can be supported by product principles for example. The main point is, if all efforts are aligned to pay into the overall company objective, the total outcome will be bigger than the sum of all the single initiatives. When I asked Martin Eriksson, founder of Product Tank, about other companies with a similar setup, he mentioned that this setup of not having a full-time Product Manager and having Shared Product Responsibilities is quite uncommon but Stripe for example only started to hire product managers after their Series C round. They were a developer-focused company building products for other developers though, so it made sense to have developers acting as product managers. In contrast, Kyte is a classic B2C platform and I would claim that Shared Product Responsibilities without a full-time Product Manager worked up to a size of 30 people. So I hope it will also help other smaller teams to operate effectively and efficiently.

When full-time product managers make sense

For most companies, it actually makes sense to hire full-time Product Managers at some point. By bringing a full-time Product Manager onboard compared to distributing the load of jobs-to-be-done to other individual contributors (ICs), the ICs can focus more of their time on their speciality. I agree with Martin Eriksson that good Product Managers can enable experts to “focus on what they are best in” while at the same time involving them in the key elements of the Product work.

Watch We can Build Better Things Together by Martin Eriksson 

Even in a company with full-time Product Managers, there is value in keeping Shared Product Responsibilities by a culture of extreme ownership, easy processes, and a strong north star.

Applying the Shared Product Responsibility model to bigger teams

How can product managers maintain a Shared Product Responsibilities culture across bigger teams?
  • Teresa Torres, the author of Continuous Discovery Habits, suggests the “Product Trio” being the ideal setup where a product manager works hand-in-hand with a designer and a software engineer (often a Tech Lead or Engineering Manager). All discovery activities are executed by the Product Trio while the product manager is leading the discovery process.
  • Product Trios focus on deeply understanding the customer or stakeholder. They can distil the information and loop in their teammates into key insights and key parts of the discovery process. This provides more time to focus on what they’re best at and enables them to keep an ownership mindset at the same time.
  • Similarly, Christian Idiodi, partner at Marty Cagan’s Silicon Valley Product Group, mentioned in a Product meetup: “Engineers should spend 30 min per day on Product discovery.”
While product managers are needed in most bigger teams, I encourage companies of any size to strive to instil the principles of extreme ownership, easy processes, and a clear north star in their culture.

Watch this ProductTank on Bets, Boards, Missions and North Stars by John Cutler

Full-time Product Managers can work much more efficiently if everyone in the company shares some of their responsibilities and the company achieves goals more effectively if everyone is enabled to think and act with the bigger picture and the customer in mind. With that being said, our company Kyte is at a point where it makes sense for us to hire full-time Product Managers that continue to shape a culture of Shared Product Responsibilities. We are providing easier access to fewer cars with a ridiculously ambitious team, and searching for stellar Product Managers that embrace a collaborative approach to Product and who want to further develop this model with us as the company scales. Check out our job page if you’re interested in joining the Kyte crew!

Summary

I hope you learned a bit about how small teams can grow a product without the need for a full-time Product Manager and the three building blocks of 💪 Extreme Ownership, ➡️ Decentralized Product Processes, and a 🌟 Strong North Star help you build your own team or shape the culture in the company you’re working at. Hit me up with any questions or if you would like to discuss any of these elements more.

Discover more case studies or engage with further insights using our Content A-Z.

2 thoughts on “A case study: Building a product without any full-time product managers

  1. One company I’m aware of that has been quite public about its lack of product managers is Basecamp.

    The book Shape Up: Stop Running in Circles
    and Ship Work that Matters describes how they approach work.

Leave a Reply

Your email address will not be published.