Why evangelizing is essential for Product Managers

I have never been a fan of using the word “strategy” or “strategic” because more than often they’re abused and misused by the most uninspired people in corporations – most of the time they mean “tactics”. 
 
 As product management is still evolving as a key function on organizations, companies (especially those outside of the tech industry attempting to succeed at “digital transformations”) are struggling to clearly define the role in their organizations. Long time ago, PMs were often primarily responsible for technical project management and decisions about the product were typically led by sales or marketing or engineering. 
 
But today, as companies compete on product experience and the bar is already extremely high, PMs need to go beyond understanding technical issues or managing scope creep in order to decide what to build next and effectively align the company around their decisions. Product Managers need now to focus drawing out customer insights, learning about customer behavior through experimentation, defining long-term success, and inspiring non-product teams.
 
Customer Insight Management
User feedback is very important in order to build features that solve problems, and as such it is critical to go as deep as possible into user insights in order to go beyond surface-level feedback  (“the product isn’t working”) to uncover the real actionable information that makes the product truly better (“the feature is fine but the customer doesn’t have the necessary knowledge to use it properly”). I have seen a lot of leaders (Refer to the hippo or rhino in the dangerous animals of product management here) who will push teams into building a fix right away or to build a new feature altogether without learning more and there’s a good chance they’ll push the teams to build the wrong thing. 
 
One thing that I have always suggested successfully is to build a good repository of customer insights in a single location, because insights always come into the business via many different channels like support tickers, email, slack, sales notes, and even social media. Without a central, searchable location, chances are many valuable insights will be missed and overlooked. 
 
Second, Product Managers need to know how to interview their customers (without offloading that responsibility to other teams such as “research”) – as an example, users rarely express the root cause of their problems when they give feedback. In fact, most of the time It takes multiple nested questioning techniques to drill down into the customer’s experience and find the exact source of a particular pain point. Personally I suggest to use the design thinking “five whys” technique.
 
Experimentation and Prototyping
I have seen teams forced into “velocity” making the horrible decision of moving straight from insights into rolling out features – and of course fail, as any feature can be designed in many different ways to solve the same problem while users will interact with some designs better than others. And very often, the most logical solution to a problem won’t always be the one that customers adopt, so the best way to figure this out is to experiment. 
 
There is already a school of thought and trend around a “behavioral product manager” function that blends data with psychology – understanding that humans have systematic irrationalities and as a result to not build products based on personas or ideal customer behavior, because there is always a difference between ideal customer behavior and actual customer behavior (I always tells my teams “there is a difference between what people say and what people do”).
 
And as a result, prototypes are ideal because they’re clearly the best way to align specific features with customer behavior and find a solution and design that works well. I’ve always been a big fan of hi-res prototyping by product managers using tools such as Origami Studio or Figma because they offer usage data hooks and APIs which gives a lot of flexibility to the product manager to A/B test an hypothesis.  
 
Evangelizing for long-term success
Unfortunately, and I know this is not very clear to many uninspired leaders in many industries, a  product manager’s daily activities isn’t only to ensure that all the features that the team builds perform well and measuring the success of those features:
Product managers guide a product towards a long-term goal and vision.
 
So getting sucked by your leadership in constant reactive mode of giving all priorities and attention to shipping features is way too easy, so don’t: 
 
Think outcome instead of output, that’s where the real impact is.  
And as such, it is super important to define the larger objectives of the product, and, secondly, to visualize and map out how the features being build will support those objectives. And for those who have been exposed to the “press release backwards” methodologies (I’ve posted about it last year here) a strong word of caution: objectives can’t just be lofty statements that the team writes down somewhere and doesn’t think about again. To make sure progress is being made towards objectives, every feature request and every upcoming feature needs to be organized based on the objective it supports. By mapping out the relationship between the features the teams works with day-to-day and the big picture goals for the product, product managers will be able to stay focused and to resist the pull of building feature after feature without a unified sense of direction.
 
Inspiring teams across the company
I have discussed this previously here: it is critical for the success of the product that the entire team, from engineering to design, marketing, sales, and customer success feel excited about the features they’re building. The product manager plays a critical role in motivating all team members even though there are a lot of decisions that impact the product that they don’t own. As a result, this might sound a little bit corny but Being a persuasive product manager, then, boils down to getting everyone in your company to take pride in their contributions to the product and value the vision you have for it, even though it might not match what they want from it. Here, easy wins matter, such as sharing the product roadmap so that all stakeholders can see how things fit in the bigger picture. 

---

Let me know what you think here. 
​My name's phil mora and I blog about the things I love fitness, hacking work, tech and anything holistic. 
​
Head of Product
thinker, doer, designer, coder, leader