Product agency vs. in-house: What’s the difference for a Product Manager?
August 27, 2020
What exactly is the difference between product management and product management consulting? It’s a question I’ve seen countless times while I’ve been lurking away on a variety of product focused forums.
For this article, I interviewed a variety of Product Managers from a diverse range of backgrounds and experience levels – from individual contributors to VPs, with backgrounds from engineering to M&A. Doing this has helped me understand that difference more clearly and debunk some of the myths that have arisen.
The reason I took on this piece is because I’ve straddled both sides of the debate across my career. In my current role at Connected, I work within the consultancy model, and in my previous role at Points, I managed payments and integrations of the actual product. This cross-industry perspective helps shape how I view product building and how I deliver product impact for our clients today.
Myth 1: You have more ownership at a product company.
I hate to say it but… “it depends”. I believe ownership is more a function of a company’s culture, versus whether they are an agency or a product company. I’ve seen plenty of projects at Connected where there was a real sense of trust and ownership on the team to own the outcome and deliver on it. I’ve also heard of experiences of PMs at product companies (and agencies) who have experienced the dreaded “feature factory” experience with a lot of top-down decision making and prioritization.
Generally speaking you will feel more ownership at a product company. As a consultant you have less skin in the game, you are typically brought in to help solve a particular problem area for a finite amount of time. That is not to say you care less, it’s just that the lens of impact might be different from traditional lenses. For example, at Connected, our guiding values are focused on Product, Client, Connector, and Category impact (in that order). There’s an explicit understanding that without product impact, we cannot have any of the rest.
As an in house PM you’ll need to consider all aspects of the product, from marketing to legal to support. This is also important as a consultant, but you will often have client counterparts who you can rely on to handle a lot of those internal discussions and who you can lean on for support.
Myth 2: Product management consulting is all about sales.
Yes it is! But that’s just what being a PM is all about. As a PM regardless of where you work, you are always selling. This could be selling a vision, selling an approach, or sometimes selling yourself. As consultants interface with clients so frequently, this is amplified even more. You’re now not only selling all of the above, but you will also need to sell to the client engineers, client PMs, client executives, etc. You will also be new to many of the industries, project types, and stakeholders, which means you will be simultaneously learning about the product and organization while also building trust and crafting and communicating your vision. In essence, it’s like building the plane as you fly it.
As a consultant there is more emphasis in the upfront work of clarifying and “pitching” the approach and methodologies on how we would tackle a problem (after all, this is one of the key reasons why you were brought in, to share best practices). This is less of an expectation at product companies as there is (typically) an existing process for clarifying or tackling work.
In addition, consultancies grow when: they get more projects, or when existing projects grow bigger. As such, there’s always going to be growth of your project and practice in the back of your mind. What’s important to note is that successful consultancies exist to help clients meet the users’ desired outcomes, not just their clients. This can sometimes mean invalidating or advising clients to not pursue further work if we believe that it will result in negative outcomes or leads to wasted efforts—even if this at the cost of growing an account.
Myth 3: Product management consulting prioritizes different skill sets than in house product management.
The traditional expectations of a Product Manager are some experience or skills in: the domain (e.g. they run a fashion blog and applied for a fashion startup), design, engineering, and/or “business”.
I believe in-house product companies will typically weigh and prioritize certain areas differently than consultancies, depending of course on the organization and industry. In contrast, because an important part of consulting is the ability to pick things up quickly and jump into different situations, consultancies are more willing (and I’d say desire) to hire generalists. This means a greater priority on skills such as communication, influence, handling ambiguity, problem solving, and stakeholder management.
Difference 1: Soft skills are doubly important in consulting
Consulting can be adversarial. Consultants can send a message that “you just aren’t good enough to work on this” to the team on the client side (of course the flip side is true, where the juiciest problems won’t be given to outsiders). In addition to this, you’re being paid a lot of money to deliver value and solve problems and have no context, history, or relationships.
All of these challenges mean that a consultant must develop a strong set of soft skills to be able to navigate these waters successfully. Skills such as presentation skills (the ability to sell an approach and tell a story), communication (from pushing back with senior client executives to working out how to collaborate with client engineers, designers, PMs), and being able to quickly build trust and relationships in sometimes challenging and hostile environments. These are incredibly important for both roles, but even more so in consulting due to the nature of handling client relationships.
Difference 2: You will get incredible breadth and acceleration in your learning opportunities.
As a consultant you are going to be exposed to a vastly bigger set of problems and products across a variety of industries. At Connected for example, we’ve worked in areas that range from developing hardware to help connect families around the world, to prototyping and exploring the opportunities around micromobility!
As a result, your pace of learning is faster. Because you are thrown into products across different industries, with different stakeholders and personalities, and different tech stacks, you become adept at dealing with ambiguity and very quickly ramping up on different problem spaces.
Difference 3: Consultants are generalists who leverage learnings from different fields.
A consultant’s job is to be modern, to understand best new practices, and to share those practices and enable clients and teams on the “How”. A big part of the value is bringing what works across different industries (from a sports mobile app to health products) and applying them to different problem spaces and industries.
When you spend a lot of time within an organization, there is a level of overhead that burdens individuals. You become accustomed to the process or way things are done and it can create difficult inertia to overcome. By nature of being outside that organization, consultants have the benefit of being able to question why certain things are the way they are and open up opportunities to develop better practices for product development.
Difference 4: Do you like fantasy sports? Resourcing and allocations are an important aspect of consulting.
Ever trade pokemon cards when you were younger? Some pokemon would have advantageous types, some would have multiple abilities. Depending on the situation, you’d have to think about what’s the best pokemon on your roster you should play.
One of the most interesting parts of working at a services company is resourcing. With most agencies, there will always be a “bench” or reserve of staff who are not billable on projects. This is necessary to quickly staff and jump on work opportunities—if you waited to have the contract and then tried to hire the right people, you’d never start a project.
This creates a variety of challenges. At an organizational level, how many people can you keep in reserve? What are the skills and capabilities that you currently have? What are the skills and capabilities that are being asked for? What do staff on your reserves want to achieve professionally and personally?
At an individual level, how do you handle situations where you need to have people pulled off your project to win or start new opportunities? How do you understand who’s well suited for certain projects or who might be looking to be rotated off? How do you align incentives? How do you communicate those sudden changes to your team and client?
The nature of these challenges will differ significantly depending on your seniority and scope of project. Larger projects will mean a lot more change in terms of people rotating in and out of your project, leaving the company and so forth. If you’re a manager or director responsible for allocations, you will have significantly more attention you’ll need to dedicate to not just allocations, but also the sensitivity of how information might be delivered to individuals and teams.
Consulting as a product manager is a worthwhile experience that provides you with incredible learning opportunities. By virtue of being an outsider, you sharpen your problem solving and analytical capabilities as you jump into different situations and problems—whether they’re product, industry, or people problems. You supercharge your soft skills and also get to focus deeply on the product craft—sometimes a lot more so than you would at a product organization. Ultimately, there is no better or worse scale for a PM, the difference ultimately comes down to how and where you want to drive impact.
Thu Dec 1
Global Day of Coderetreat Toronto 2022
Earlier this month, we hosted Global Day of Coderetreat (GDCR) at our Toronto office. After a three-year hiatus, we wanted to re-awaken some of the community enthusiasm when we hosted the event for the first time back in 2019. This year we planned for a larger event which turned out to be a really good thing as we nearly doubled our attendance. And in case you were wodering, this is how we did it.
Tue Nov 29
Art of Controlled Burn in Engineering Management
The idea of a Controlled Burn is simple; create a small fire that you fully control. The assumption is that were you to do nothing, a much larger disaster would occur. In agile, no team likes disruptions; rather, everyone prefers to work like well-oiled machines. This begs the question - can we apply a strategy that looks very similar to firefighters and utilizes controlled disruptions rather than waiting for a full-blown disaster to occur?