The PM Mindset
As I’ve settled into my role of Product Manager at PROS, I’ve become more and more excited not only about my product, and even more excited about my customer’s problems. Even when I shop online, view a website, or any of the applications on my phone, I think about what the problem that this item or application is trying to solve in my life, and how do they present themselves in a way that makes me confident they’re able to do so.
I’d like to touch on what I’ve come to realize is the PM Mindset, and how it beneifts an organization. Here is a breakdown of how a typical PM thinks when presented with a problem, in no particular order, but I do find the order to be very relevant:
- Who are my customers?
- What is the problem being solved?
- How do I deliver this to my customer?
Who are my customers?
This is a very important question, and ultimately feeds back into the market and industry that your organization and product is in. If you’re building a mechanical product that helps farmers, but you think some feature will make the product ‘cooler’, step back and ask, ‘will farmers benefit from this feature?’ or am I just thinking this feature is cool in general. The most important type of thinking that Product Managers do is related to the customer. Product Managers are customer obsessive. I sometimes lay in bed at night and think ‘if I added this feature or build this product, how does it benefit who the customers of our platform are, and better yet, who exactly are these customers?’.
Customer or user personas help with this, and some Product Managers and UX Designers live and die by user personas.
What is a customer or user persona you say? Well here is an example:
I find the above user persona easy to understand and allows me to then group real customers into this ‘type’ of customer. It allows me some basic starting questions during customer interviews such as ‘How familiar are you with wearable technology?’…if they say ‘Nope, not much’, then they may be a good fit for this persona schema.
I want to stress though that user personas should not come from someone sitting at a desk, and going ‘what would this user look like?’…your user persona’s should be based on extensive research of your customers, and potentially through countless hours of cutomers and user research, not just some idle thought that comes to mind about what makes sense to you.
Keep in mind, if you’re in the enterprise product space, your customer and user personas may be very different, and they should be seperated out for you to understand where your product is most attractive to a buyer than a user of your product. For examples, users may not care about the data integrations of your enterprise product, but the buyer and investor in your product from your business will as that will allow faster time to value for deploying within their enterprise.
What is the problem I’m solving?
As PMs we live in the problem. Sometimes the problems that our customers face consume us night and day. Let’s take on this question using a real product: Slack. The problem being solved for customers will typically be embedded into the product’s vision, so let’s look at Slack’s. On their website, they have the product vision as:
“Make work life simpler, more pleasant and more productive. Slack is the collaboration hub that brings the right people, information, and tools together to get work done.”
From what I can understand, Slack is solving the problem of collaboration and centralization of tools and information for the purpose of workplace collaboration. Now if I were to put your product vision statement up there, then what would I learn about the problem your product is solving?
Not only should your product vision be aligned to the problem being solved with the product, but the problem has to be a real one. Many products fail because of the preconcieved idea of a problem, but when the product is brought to the marketplace, no one is in line, and excitement seems to have only been internal to the company.
Product is not a ‘Field of Dreams’ and if you build it, that doesn’t mean they will come, but if you do the research, spend the time, and determine that there is a problem users want a solution to, then you may have a great opportunity ahead of you.
How do I deliver this to my customers?
There are many ways to deliver a product or product feature, but I’m a big believer in the CI/CD of Product. When I say deliver, it’s inclusive of the what, as in what feature should be built. Will the delivered item solve the customer’s problem, and how does this item need to function so that my customers can be successful with my product?
When the feature or product is completed, then what customers will get this feature? How do I collect the right feedback so that I can make sure that it gets rolled out in the best way possible for my users with minimal disruption to how they use and benefit from my product already? These questions and many more are the ones that Product Managers are tasked at owning and helping drive answers for either through product research and leadership.
With regards to features, I strongly believe that there are three criterias a feature must conform to when being delivered:
Backwards compatibility
Will my feature break anything that my customers are currently using because of the need for newer technology or parts?
Betweenness comfortability
How comfortable will my customer be with using this new feature given the context of the overall product?
Forward causality
Will they see the benefit of this feature as an improvement to their journey in my product and how do I help them succeed?
Overall, I believe that Product Managers present a way of thinking that is greatly beneficial to any company. Whether you’re a techonology company or a clothing company, you have a product, you have customers, and the success of your customers when they use that product will be critical to the longevitiy and growth of your company.
