I asked seasoned product expert in Silicon Valley Big Tech and author Jackie Bavaro to share some insights from her experiences. You can read the more from interview with her here. I hope you find it as insightful as I did.

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 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.

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.

If you’d like to subscribe to my bi-weekly newsletter, INMA members can do so here.

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