Hi there.

This week, I asked seasoned product expert in Silicon Valley Big Tech and author Jackie Bavaro to share some insights from her experiences. Within the interview, she talks about the product mindset, working to company goals, product methodology, and gives us some practical tips. This is good for both product leaders and their teams. I hope you find it as insightful as I did.

Q&A with Jackie Bavaro

Jackie Bavaro has over 15 years of product management experience, most recently as head of product management at Asana, a team project management platform. During her tenure, she grew the PM team to over 20 people, helped Asana go from zero to more than US$100 million in annual recurring revenue, and launched Asana’s associate product manager programme. She has also worked as a product manager for Google and Microsoft in a diverse set of product roles including consumer, B2B, platform, mobile, and growth. She has written two books: Cracking the PM Interview and Cracking the PM Career, which can be found on Twitter at @jackiebo. 

You talk about the product manager mindset. How do you define that?

Product management is a relatively new role, and it requires a special mindset. We need product managers who focus on problems, goals, and real people’s needs. 

Product mindset is the habitual approach of connecting all work to those goals and needs. It’s remembering to always ask: “What problem are we trying to solve?” and “What problem should we solve?” People with a product mindset notice problems everywhere, and they connect those problems to bigger goals to explain why those problems matter. They consistently think about what their goals should be and prioritise based on those goals.

To really understand product mindset, it can help to consider the alternatives: project manager mindset and enthusiast mindset. People with a project manager mindset are execution focused. They don’t question the goals — they optimise delivering on those goals. People with an enthusiast mindset are solution focused. They get very excited about a solution or technology and want to get it out to the world, but they haven’t thought about what problem it solves or if that problem is really important.

Product mindset is important for product managers because PMs make many decisions each day. If they’re missing the habit of thinking about goals, it’s easy for them and their team’s work to drift off track.

In the INMA Product Initiative, we’ve talked a lot about the importance of goals and understanding how product work fits into these. How can a product manager navigate this if it’s not clear?

I like to think of a company’s goals and strategies as a pyramid. At the top of the pyramid is the company mission and high-level company strategy. Below that, each department might have a strategy that connects to the higher level strategy. And below that, each team might have a strategy that connects to the departmental strategy. 

When the goals are clear and well-connected, someone working on an e-mail alerts setting page could see how their work supports the team goal of increasing the number of articles read, which supports the departmental goal of retaining subscribers, which supports the company goal of increasing readership. In an organisation like this, each person can feel confident that their work is valuable and valued.

If the goals aren’t clear, the best place to start is looking at broad communication from senior leadership. The leaders might share the company’s top priorities at quarterly all-hands, annual kick-offs, or earnings calls. They might share strategy docs or have recordings of presentations that you can watch. Depending on the size of your organisation, you might repeat this at the company and departmental level.

Once you’ve caught up on the available strategic materials, have a conversation with your manager about how your team’s work fits into the larger strategy. Your manager is often privy to more details about the strategy, including any recent changes or nuance. Depending on your company culture, you might also discuss goals and strategy with more senior leaders, such as your skip-level manager, with questions such as: “How are you feeling about the company goals?” or “Which part of the strategy do you think is most important to focus on now?”

When a product manager is handed a new idea that seems to fit with the company goals, what method(s) should they use to validate the idea?

It’s important to always validate product ideas, even when they’re handed directly to you. 

First, try to reverse engineer the underlying problems and goals. Talk to real people to make sure the problems really resonate with them and are high priority for them. Ask them to tell you about specific times they’ve run into the problem in the past and how they tried to solve it. Be a bit skeptical and look for ways that you might be wrong about the problem. Remember that people are overly optimistic and will answer any question of “Would you like something that did…” with “yes,” even if practically speaking they would never use it.

After you’ve validated the problem, you might want to explore multiple potential solutions, and validate those concepts with real people. Find out which direction resonates with them more and why. A common approach is to have users walk through a prototype of a new feature and “think aloud” as they go. Another great approach is co-design: Your designer fills in the role of sketch artist while the user describes their ideal experience.

After the concepts, you can usability test the actual design with a prototype or working code. If you don’t have the time to run a formal usability test, you can sometimes learn a lot by informally showing designs to anyone who isn’t as familiar with your product, for example someone in a different department or your roommate.

Lastly, you can validate the success of the product you built with an A/B test or a beta programme. A/B tests are good for seeing how real users behave at scale, but they’re mostly good for high traffic, consumer-facing parts of the product. Beta programmes are great for getting high-quality feedback on new features from a smaller set of friendly customers or advertisers. Ask participants, “How disappointed would you be if you could no longer use this feature?” to measure the success.

How do you build out the product vision and strategy?

There are three parts to a strategy:

1. Vision

2. Strategic framework

3. Roadmap. 

You can get started with whichever one calls to you.

To get started with a vision, sketch out a storyboard of your future customers using your future product and highlight how much better their lives are compared to the status quo. I like to model my product vision after an infomercial, spending a while to explain just how painful things are today. Make sure to include a few strategic insights or bets so that the vision feels believable.

To get started with a strategic framework, write down your target market, their pain points, and the strategic bets or differentiators that you believe will win that market. Write down some alternative approaches and lay out your frameworks for why you believe your approach is better.

To get started with the roadmap, write down a rough plan for the next few year’s worth of work, ideally grouped into strategic themes. Once you have the roadmap, imagine someone asking “why?” about each part of it. Your answers to that question will form the beginning of your strategic framework.

Your plan will change as you learn new information, but starting with a strategy helps you make better moves now. Block off three to six hours on your calendar for drafting a strategy now!

How much interaction should a product manager have with customers? What are the ways in which they can source feedback?

As a rule of thumb, I like to meet at least 10 customers when I’m new to a product, and add five to 10 new customer meetings for each new project I work on. This quantity helps me notice patterns and truly become the expert on our customers. These meetings could be exploratory customer visits, sales calls, user research sessions, or any other live meeting where I have a chance to ask questions and learn about people’s concerns and motivations. 

This kind of qualitative research is especially important when building business software. But even when working on consumer software, I found that meeting with real users helped me gain empathy for people who weren’t exactly the same me. It’s hard to recognise our own assumptions until we’re faced with people who are different.

Beyond one-on-one meetings, I love gathering customer feedback from a variety of sources. Just be careful to account for the bias inherent in each source. The people who yell at you on Twitter tend to be very different from the people who write into customer support or the people who fill out a survey on your site. I find it very worthwhile to skim through 100 pieces of verbatim written feedback rather than just relying on summaries of the top topics.

In the news industry, the content is arguably the product, so stakeholders — particularly in editorial — are really important. What are your top tips for working with stakeholders ?

The best way to work with stakeholders is to invest time in really understanding them. What are their goals? What are their concerns? What does success look like for them? Stakeholders aren’t alway great at articulating their concerns, so you might need to dig deep and follow up on any confusing statements to understand what’s really going on.

For example, someone might be embarrassed to say that a certain change will make more work for them or that they’re too short staffed to implement your proposal. Relationship building and forming mutual respect can go a long way here.

Once you understand your stakeholders, you can frame your proposals in terms of their goals and concerns. Show them how your proposal will help them with problems that they care about. Show them that you take their concerns seriously.

When you have a conflict, consider whether the conflict is because you have different (1) information, (2) assumptions, or (3) values.

The first two are easy. When the information is different you can share information. When the assumptions are different you can gather data or run a small experiment.

When you have a difference of values, you really have a difference of strategy. Reframe the discussion around the strategic question — for example, is it more important to invest in growth or revenue right now? Once you highlight the strategic question, it might become apparent that you need other senior leaders in the room to resolve the question.

Looking back at your career as a successful product manager, what’s one thing you would do differently if you could do it all again?

I’m incredibly happy with my career, but I think it took me longer than necessary to understand my responsibility for product strategy and learn what it meant to be strategic. 

I now encourage even junior PMs to understand the strategy behind their work and see their work as a step towards a larger vision. Teams can have a lot more impact by setting an ambitious vision and planning the steps to get there rather than by looking for incremental improvements from where the product currently is.

What are the most important skills a product leader should look for when hiring a product team? 

The most important thing to look for is mindset, since that can’t be taught. In addition to product mindset, I look for people who have good product intuition, show customer empathy, have good design taste (even if their design skills aren’t strong), communicate effectively, can add structure to ambiguous problems, and show intellectual humility.

When hiring experienced PMs, I like to see a track record of success and will dive deep to understand how they contributed to that success.

Do you have favourite tools that you use for product management? 

I’m a huge fan of Asana, which I sometimes describe as a project management tool for people who don’t like project management. The grid view was designed to be as fast to use as Notepad. The timeline view in Asana was inspired by the way product managers would ignore all official tools and instead draw boxes on a white board. PMs like to have as little friction as possible to go from idea to artifact, and Asana supports that.

INMA Global Media Awards case studies: NZ Herald 

The INMA Global Media Awards have highlighted some excellent case studies (archived here). I have picked out a few I think will resonate with the Product Initiative Community. This week, we are looking at New Zealand Herald’s app relaunch. 

Dates for the diary

The INMA World Congress of News Media is coming up in May with 7 sessions over two weeks. Be sure to sign up, at least to the Product session on May 25 where we have an exceptional line up of speakers. More here. 

About this newsletter 

Today’s newsletter is written by Jodie Hopperton, based in Los Angeles and lead for the INMA Product Initiative. Jodie will share research, case studies, and thought leadership on the topic of global news media product.

This newsletter is a public face of the Product Initiative by INMA, outlined here. E-mail Jodie at jodie.hopperton@inma.org with thoughts, suggestions, and questions. Sign up to our Slack channel.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .