Aakash Gupta is the author of the Product Growth newsletter. He has over a decade of PM experience with roles at Affirm, Google, Epic Games, thredUP and ScoutForce.
Website / LinkedIn

EC: How would you build a Product Growth team from scratch?

AG: I’ve luckily had the opportunity to do this in multiple gigs, including at two public companies: thredUP (TDUP) and Affirm (AFRM). So, I can speak from experience. 

The first thing to do is to establish the philosophy of the product growth team. There are roughly two varieties:

1. Pursue a metric or business problem, agnostic of the artifact

2. Own specific growth related artifacts

The first variety, product growth teams who pursue changes across any area of the product, generally have to do a lot of ‘farming on other’s land.’ So, it’s important as a leader to work through how the team will pursue and prioritize initiatives.

How will you prevent the teams owning a particular artifact from just picking up your good ideas? How will you work on their surface if they want to experiment at the same time? Working out the answers to those questions early is critical.

The second variety, product growth teams who own the product-led growth part of the product (in B2B, often some freemium type features; in B2C, often the top of the funnel) need to find realistic goals. What can you actually accomplish given the artifacts you can play in?

Having realistic goals based on data, not hopes, is key.

After figuring out the philosophy of the team, the next steps are to assemble the unit, begin building the backlog, and commit to your OKRs. 

• Assemble the unit: Get together a cross-functional team of leaders across engineering, analytics, and design. Work as a group to identify your product principles, operating rhythms, and ideal team below you. Then work with leadership to get the requisite folks. I think it’s especially important to have enough ICs in each discipline to do the work. 

• Begin building the backlog: Start to source ideas. Use data to prioritize business and user problems. Work with research to finesse the problems. Do design sprints to think through potential solutions. Work with analytics and engineering to size them. Then begin to take your initial prioritized initiatives to product leaders and colleagues to make sure you are the right team to do them.

• Commit to your OKRs: Now that you have a backlog, size those projects against some key metrics. Find a set of OKRs that are just slightly a stretch - slightly beyond your initial sizing. And then commit to them.

Now that you have a backlog and OKRs, it’s time to get shipping. Iterate and improve on your philosophy, unit, and work products as you go. Pay especially close attention to whether you need to change something.

You almost always will. 

EC: What makes a great Group Product Manager?

AG: Let’s begin by defining who a Group Product Manager (GPM) is and where they work. GPMs generally exist at two types of companies:

1. Mid-size product companies [1000-5000 employees] 

2. Large tech companies  [5000+ employees]

In these companies, GPMs are the ‘first layer of management.’ They manage the Individual Contributor (IC) product managers (PMs). Their role is often that of the ‘player coach.’ They do flex into some IC work, but the main job is to coach PMs and manage the program. 

Whereas individual PMs project manage features, GPMs project manage the overall program:

• Is it hitting OKRs?

• Are we shipping fast enough? 

• Is the team playing well with others? 

With these responsibilities in mind, we can define what makes a great GPM.

Strategic: A great GPM helps position the team in a business problem that matters. They understand the overall business strategy, and how a specific product area can contribute to it.

Execution-Maniacs: Great GPMs help their teams ship features that succeed in their hypotheses or advance the team towards a learning agenda. 

Great at Solving Problems: Many of the problems that come up with a team are people and organizational. The team isn’t getting enough analytics support. Another team is blocking. GPMs have to be able to go into these problem areas and solve them.

A+ Coaches: A great GPM must be able to bring the best out of each and every member of their squad. That includes not just the PMs that report to them, but each and every member of the overall Engineering - Analytics - Product - Design task force they work with. 

Upward Management Savants: While the downward elements of the above skills are important, equally, if not more important, is driving alignment with Directors and VPs. GPMs must be able to evangelize the roadmap, the work, and the impact to everyone. 

In summary, great GPMs are strategic, execution maniacs, great at solving problems, A+ Coaches, and upward management savants.  

Share

EC: What are the pitfalls of being enamored with 'Textbook' product management, and how can PMs overcome this?

AG: In textbook product management, all you need to do is be ‘empowered’ and do lots of ‘discovery.’ At least, that’s what the popular Marty Cagan and Teresa Torres books would have you believe. While these books are gold, there are a couple drawbacks from focusing solely on their approaches. 

1. Some waterfall helps you make impact & align leaders

If you fully hope to discover solutions as you go, you’re going to have some sorely misaligned leaders. They won’t know what you’re working on. Building a backlog and showcasing your solutions for feedback from leaders in a somewhat waterfall approach makes upward alignment much easier.

2. You’re going to feel dissatisfied with the differences

Every PM job I’ve had has had multiple departures from the ‘textbook’ way of doing things. If you’re enamored with how the textbooks say it, you’ll be unnecessarily unhappy in your job. Accept things as they are, do the best you can in them, and then voice your position of the alternate way of doing things. 

To overcome these problems, aspire to be zen in your work. Accept the way things are and move them towards a better future.