Tools for planning and executing product projects

Today we are talking about the skills product managers need to grow their careers.

To help us, Neha Bansal  is with us. She is the Head of Merchant Growth and Monetization for Google’s B2B ecommerce business, where she is leading efforts to build the next $1B+ B2B business for the company. Before joining Google, Neha worked as a Management Consultant at Essex Product Consulting, where she helped organizations build products. Outside of her day job, she has guided many PdMs in reaching their career goals, and consequently, has good insights about the skills they need.

Summary of some concepts discussed for product managers
[3:10] What key topics do you discuss when you mentor product managers looking to further their careers?

First, how can product managers establish processes to enable their teams to succeed? Processes include forums to sync with different members of your team and other teams, forums to get leadership alignment, ensuring high quality of deliverables, and OKR planning.

Second is setting up the right funnels for access to users. I strongly believe that as a PdM, the biggest value you bring on your team is speaking to users and having a pulse of what your customers need.

Third is setting goals. I have often spoken with PdMs who say they don’t think their team understands what they want. I help them rethink what they want in a quantitative way to determine a metric that defines success.


[6:10] Tell us more about processes to help our teams succeed.

Typically, there are two big phases in bringing a product from vision to launch: planning and execution. Planning includes the product vision, strategy, and roadmap. How do you set the vision, strategy, and roadmap? At what cadence do you do that? Who are the right stakeholders and partners to work with as you are setting your vision, strategy, and roadmap? What would be some tools to do that? Those are all important processes to be intentional about.

At Google we do annual planning early in Q3 when I think through the vision and strategy for my product. We write a document that evolves over four to six weeks during which all of the leads from different teams contribute.

First, we go out and talk to customers. I talk to our customer support team and sales team to understand what challenges they have been facing. We keep a pulse of where the industry is headed and what headwinds we expect. We tap into all of that to write the vision document.

[8:27] What do you put into the product vision statement?

Typically we create a vision for the next three to five years. We break that down to where we see the product in five years, three years, and two years, and what we need to do to deliver on that vision.

The document includes at most two pages about the vision. The portion about strategy goes into more depth. This is where we think about how will we get to our vision. We start by looking at the data to substantiate why we think we can achieve that vision. We think about  our strengths, weaknesses, and competition. The strategy document provides North Star metrics. We describe the metric we care about, the target we want to achieve, where that metric is right now, and how much growth is expected each year.

Finally we write the roadmap for year one. The roadmap provides specific projects that will help us hit our North Star metrics.

[12:31] What tools do you use for planning and whom do you involve?

As a product manager, I bring together the team to have equal ownership of the planning.

I always do a two or three day offsite where I’ll bring the team together in person. We spend time understanding each other’s areas and then think about ideas.

There are a lot of workshopping techniques you could use to help people come up with ideas. One of my favorite ones is having people take one minute and list all of the shortcomings in the product. Then we’ll have people talk through those and put them on sticky notes on a whiteboard. Then we’ll ask, “What do you think from here can actually be solved easily? And what is going to be a harder lift?” We’ll lay that down on a graph. You end up with a distribution of problems that have value in solving and can be solved right away as well as problems that have value in solving but will take more time.

You as the PdM can put the brainstormed ideas into the first draft of the vision and strategy document.

[15:34] How have you gotten product managers to spend time with customers?

I tell PdMs who are in the early stages of their careers that it’s definitely important to make sure you talk to customers. I have had engineering teams applaud that I meet with at least three customers every week, regardless of whether it’s prescheduled for a particular project or not. That gives engineers trust that whatever I am asking them to build is actually required by the market and by our users.

I cannot emphasize enough the need to continue to have a pulse of whom exactly you are building for.

We are often able to build a list of customers who have opted-in to provide feedback to the product development team. If you don’t have that feature on your product, please build it. We reach out to the users who have opted-in and ask if they would like to speak with the product development team. If they say yes, we schedule calls with them.

If you are building for an enterprise product, you’ll most likely be liaisoning with someone from the sales team. Make sure you have friends on the sales team. I provide access to launches and information to the sales teams so they can provide their clients early access to that information. Both the client and the sales teams appreciate that. I also attend sales calls and events that sales teams invite their clients to.

[19:10] Tell us more about setting goals. How do we define what success should be?

Typically, the topmost level goal for an organization is profit or revenue. That is the output metric. What you can really control as a product team are called input metrics, which cause an indirect impact on the output metrics.

Setting input metrics depends a lot on the product and the specific piece that you’re trying to launch. For my team, we have very clear North star metrics for each product.

For example, when I was head of brand management for YouTube video ads, we had three products: search lift, brand lift, and conversion lift. All of these products are used by advertisers to measure the effectiveness of their YouTube video ads. For each product, our output metric was total advertiser revenue, but for each product, the input metrics were different.

For conversion lift, we were externalizing the product from being just an in-house tool to being an external-facing tool. Our input rate was the drop-off rate at various stages as we were doing this migration. For brand lift, our metric was reducing our survey load. For search lift, our metric was adoption.

Then, we started thinking about levers that would affect each of the North Star metrics, and then we broke that down into smaller metrics.

Usually the hardest part is prioritizing instrumentation of metrics. As a PdM, you can help your team prioritize.

[23:07] Tell us more about execution.

Assuming you have your roadmap crystal clear, now it’s time to execute the projects that you’ve listed on the roadmap.

For the first project, start with writing a brief document that describes the project’s outcome. At Amazon, they call this PRFAQ. We write the PRFAQ thinking about what we’re going to say when we launch this externally. That helps drive a lot of clarity.

Next, start doing user research to validate the pain points that you came up with as a hypothesis. Once you have a certain degree of validation, write a product requirements document. This typically covers what problem we are trying to solve, why we need to solve it, why we need to solve it now, and what impact we are expecting.

Then go into more depth around the phasing of the product launch. Write about the requirements for phase zero. Requirements are like a contract with engineering and the UX team.

Once I have a first draft of this document, I immediately get my team in the room and get feedback from everyone. Your team will share things you didn’t even think about or didn’t know.

When the document is 70-80% ready, we do UX research to validate the solution we’re proposing.

Next, we go into UX designing. Developers write their backend design documents, and then you go into development mode.

Once development is completed, we all get together again to bug bash and break what we made. As a PdM, I do a lot of prioritization to figure out what is blocking the launch  and what’s not. In parallel, I do launch prep, which includes writing blog posts and help center articles, lining up road shows, and preparing comms for sales and marketing.

Finally, hopefully the day comes when you can start rollout. I’ve typically done a phase rollout. Don’t celebrate yet though. Wait for the feature to land. We track the metrics for at least two or three months post-launch, and once we see the metrics performing well, we go ahead and celebrate the launch.

[28:14] How do you help engineering understand the requirements?

I record every single user conversation and put snippets in my presentation. I start my presentation with the user describing the pain point. I always have some sense of what is bothering the engineering lead, so I use snippets to establish those points. Engineer’s objections are often around infrastructure, so it helps when you have already addressed those concerns to some extent. For example, one of my projects was privacy sensitive. I got a privacy approval from the privacy office and put a screenshot in my presentation.

Action Guide: Put the information Neha shared into action now. Click here to download the Action Guide.

Useful link:

• Check out Neha on Substack 
  

Innovation Quote

“The most dangerous phrase in the language is, ‘We’ve always done it this way.’ ” – Grace Hopper  

Thanks!

Thank you for taking the journey to product mastery and learning with me from the successes and failures of product innovators, managers, and developers. If you enjoyed the discussion, help out a fellow product manager by sharing it using the social media buttons you see below.