Photo by You X Ventures on Unsplash

Should you work in a product or services company?

To find the right fit as a Product Manager, get to know the differences between working in a product or services environment.

Not long ago I spoke at a Women in Product meetup about my experience as a Product Manager, specifically focusing on the differences between a product company and a services company. While the role has an obvious amount of overlap in each environment, there are subtle differences that set them apart. Understanding how they differ can help you determine which environment may suit you best.

Before we dive in, I want to be clear about what I mean by a product company and a services company.

• Product company: Product companies create and deliver a product or set of products and own the IP. Think Facebook, Uber, Oracle, and Wealthsimple. Product Managers, therefore, tend to work for years keeping one or more technologies/products in mind.
• Services company: Services companies provide services to a client, such as product strategy, design, and development, and are often referred to as agencies, studios, or consultancies. Product Managers typically work with a given client and manage a product for months rather than years, and the client owns the IP.

A helpful lens for analysing the differences between the two is the Product Owner Framework, created by Daisy Pilbrow and Javier Ubillos, and maintained by Pilbrow and Viktor Cessan of Spotify. They created the framework to help product owners assess their level of experience in product ownership among 8 well-divided categories. I’ll be using them to guide the discussion on the differences between product management at product and services companies.

Working with the World

Coordination

At a product company, coordination within and across teams is focused internally. Teams may be working on various parts of a larger product (e.g. infrastructure team or search team) and so coordination on ownership, priorities, and releases is a daily reality for product managers in these contexts. The other business functions needed to launch and maintain a product are also internal, such as marketing and customer success. This means maintaining strong relationships with the same groups over time.

Where a services company differs is that product managers work with their own clients on distinct projects, so coordination is largely focused between their own delivery team and the external, client teams. This means constantly flexing those critical communication skills to forge new relationships with new clients and all of their various teams.

Stakeholder relations

The very real responsibility of stakeholder relations remains constant for product managers, regardless of context. Product managers must ensure that the team and stakeholders are tightly aligned. Who those stakeholders are might be the only important difference between product and services companies (internal vs external).

Working with the Squad

Leadership

At a product company, you are typically with the same team over a long period of time. Team changes mostly occur when someone leaves or joins the company. In less common cases, it might be when the company restructures or sunsets an old feature, dissolving and reassigning your team. The up-side: a deep familiarity with each team member, their likes and dislikes, motivators and demotivators. The challenge: keeping excitement and energy up over time.

A stark difference for PMs at a services company is that the people on your team typically change with every new project. This means you are working with new designers and developers every 6–12 months. The up-side: fresh faces and a renewed sense of energy with each new team. The challenge: Getting through the forming and storming stages of Tuckman’s group development as quickly as possible to land at the norming phase.

Autonomy

Autonomy means creating an environment where people are trusted, motivated, and given the space to be creative and problem solve. I liken this dimension of autonomy to the concept of “Servant Leadership”, which means to share power, put the needs of your team first, and help people develop and perform as highly as possible. Similar to stakeholder relations, the dimension of autonomy doesn’t differ muchin either the product or services context.

Working with the Product

Visioning the product

At a product company, product managers are the domain expert. You must be intimately familiar with the market and the business case for your product. While you should be able to rally internal stakeholders around and garner buy-in for your product vision, both near and long-term, there does tend to be a widely shared understanding of the overarching problem you’re trying to solve for and a greater alignment on quarterly and annual goals.

It’s a sharp contrast to a services company, where you need to be able to dive into new verticals and domains at the drop of a hat. You need to become a temporary expert, diving deep and broad into new subjects and knowing which information is most crucial to the project at hand. A draft business case will have likely already been brought to you, and your role is to research and validate, elaborate, shift, or pivot the business case and vision accordingly. Helping client’s create organizational alignment around problems and goals is an important part of the engagement, which can be incredibly satisfying for many Product Managers.

Measuring success

Measuring progress towards goals and milestones is important to the success of any product. It involves using metrics and qualitative data to analyse whether your product is achieving what you set out to achieve. And while several of the dimensions discussed so far have important nuances between the services and product contexts, I believe this might be the dimension that differs the most. Why? Because of the nature of project engagements at service companies.

At Myplanet, our production teams are most commonly engaged to design and develop “Release 1” of a product. Once launched, the product ownership shifts back to the client’s internal teams or is taken over by our optimization team under a new contract. Our Product Strategists are responsible for creating a strategic hypothesis, stating how it will meet business goals, outlining how to measure success, and then building, launching, and eventually handing the project off to another responsible party before taking on a new project.

This is unlike the measurement process at a product company, where the Product Manager lives and breathes the success metrics daily. There is no “other product” they will be working on, which means they are responsible for ensuring the success of one product over time and how it evolves. Ultimately, this means there is a greater focus on middle- and bottom- funnel activities during your daily role at a product company: your roadmap and efforts will be more focused on ongoing revenue, retention, and referrals as opposed to top of funnel things like acquisition and activation.

Working with the Process

Agile and lean methods

This dimension refers to the methodologies and processes that you and your team adopt in order to build the product. The main difference here is not in the methodology itself, but in the alignment in process and the tools being used.

At a product company, it’s a matter of aligning the company’s processes and tools across the organization (e.g. Large Scale Scrum practices). At a services company, however, while the methodology may be determined, each individual team tends to have flexibility around their own processes and tools (e.g., running weekly or biweekly sprints, or using JIRA over Trello).

Moreover, you need to take into account the level of experience your client has with Agile. Clients can range from never having heard of Agile to running their own Agile shop, which can present different challenges. Introducing your client to agile methodologies, managing agile SOWs with the client, and working shoulder-to-shoulder with client team members in an agile fashion that works for both teams are common occurrences in the services context.

Incremental development

This refers to the product manager and team breaking down work and delivering value bit by bit. Since product managers at services companies typically work on a given product for months rather than years, they create roadmaps and milestones a lot more frequently. This means having ownership over the roadmap for a period of time, before handing it over to the client’s team at a certain point for them to foster and deliver upon steadily over time. But in a product context, incremental development is core to your work — the end game for visioning the product is to be able to make changes and evolve the product over time to better suit your user’s needs.

Conclusion

In broad strokes, the role of a Product Manager is similar wherever you practice. But aspects of the role can have significant differences in terms of day-to-day functions depending on your context.

People who like changing things up regularly, who find the challenges of becoming an expert on a topic in a short period of time exciting, and who relish the chance to test their team-building skills may prefer services jobs. Those who like to dig in on a topic and learn everything there is to know about it, who embrace stability, and who find incremental improvements gratifying may prefer product environments. One isn’t inherently better than the other — both present dynamic challenges with opportunities to grow in different dimensions — but they are different.

Even though the title is the same, the role emphasizes different skills. So think about your preferences, skills, and goals, and then seek out the jobs that make sense for you!