“Product management is an exercise in synthesizing ambiguity, while requiring an incurable curiosity, passionate user empathy and walking the line between data-driven decisions and trusting your intuition on what the data cannot tell you”. – Matt Holihan
Ready for more insights from a leading Product Manager? Read on to see what Matt Holihan said in our latest #AskMeAnything session on Slack! Prepare your questions and you can join us live at our next Product School Live Chat #AMA.
Matt is a dedicated product and e-commerce leader, specializing in personalization, internal tools and scalability for enterprise-level products. At Trunk Club, Matt is the Product Manager responsible for the shopping platform and its personalization roadmap. Prior to Trunk Club, Matt worked at Peapod, where he led full-scale responsive re-designs for five grocery chain websites, focusing on personalization and improvement of the overall user experience. Matt found his way into product management while at Groupon, where he oversaw Groupon Goods‘ first order management platform integration. Outside of work, you can find Matt playing soccer, finding the perfect coffee shop to work from, or making funny faces at his daughter.
Why do you do what you do? What do you love most about what you do?
I took an accidental path to Product Management, but I think what led me here as a north star (without me knowing it at the time early on), was my desire to see things work better. Whether I’m playing a sport, playing guitar, or seeing how lights work at an intersection, my brain instantly jumps to “how could this be improved?” My obsession with how crosswalks work in my youth, unbeknownst to me, was an introduction into Product Management. How can we, as Product Managers, improve the interactions customers have with our products? How can we provide value? What I love most about what I do is being able to see the impact of our work. When we’re able to bring delight to a customer, and have a measurable positive impact… I leave the day with the biggest smile.
Given your wide experience with user personalization, how would you break down your approach to improve it (what research, what data would you want to see, etc.)?
My first piece of advice would be that there is no one model to rule them all! Personalization is hard and you need to give yourself a lot of arrows in your quiver to really understand what is working. If you try to give “the best possible recommendation” and assume you can give the very best one at all times, you may, to begin with, be focusing too much on the hardest problem. So many variables! It can be too hard to improve. Instead, I suggest focusing on tying some models to what you’re trying to achieve and matching it to the customer journey. “If a customer is interacting with us here…what are they looking for? What signal brought them here? Do we have something that can index on that specifically?”
Multiple lightweight models can bring you faster and clearer results. Be clear about what goals you are trying to achieve. Is it interaction? Is it purchase? Is it correlation? The measurement can muddy the waters. Lastly, no one is going to get it right from the jump. Set expectations with your team that this is an iterative process.
What are the major differences between developing internal tools vs. developing front-end client-facing products? Did you have to argue for prioritization of features over client-facing revenue-generating features?
The major difference between internal and customer-facing products to me are the changes to some of your units of measurement and where you can take risks.
For example: when working on an interface that your internal sales team works with, I do not have to worry about the bounce rate. I am looking at “time spent”, but in a much different way than how I am measuring it for a customer-facing site. For example, at Trunk Club, we worry a lot about efficiency of time for our internal tools, whereas our customer-facing features, we want to encourage a rich experience.
Internal tools give you the opportunity to be much closer to your users and you should use that as an advantage. It is much easier to conduct user interviews, usability sessions, etc. You have to walk the line of what internal employees want and that may not always be what is best for the company. As a PM, it’s your responsibility to toe the line of “what is best for my user and what is best for the company?” and ultimately…the end customer.
Developing those shopping / personalized platforms, you need to be much tighter in your delivery, rollout and release planning. A 500 millisecond load time may be a big issue here, but less so in a CRM platform.
Ultimately, as a PM, you’re trying to balance the total needs of the customer, the product, tech debt, and the business in all your prioritization. When you feel it’s important to prioritize something that may not be “revenue generating”, I find that its invaluable to make that case/argument in terms that make sense to the powers that be. Will this result in a cost reduction? Measurement in CSAT? Etc.
What technical skills are a must for PMs?
I do not have a technical background! I actually went to college to produce and direct television. So I don’t think coding is a must to be a PM (maybe I’m saying that because I wouldn’t be a PM otherwise).
I think it’s important to be able to speak the language of your engineering team and really understand the process flows of what their work will deliver. If I can understand and speak to “how we get to point A from point B”, whether we are talking about an API, a front-end script, it kind of doesn’t matter…because I understand how the input impacts the output.
I think understanding the language and what things mean is paramount, though. Not only will this accelerate your learnings, but your engineering team will respect your opinions and view you as an equal partner much more. All that being said, I’m looking forward to taking a basic coding class this fall!
Currently in my first job our of college as a PM – we usually solve problems together on the spot and I am expected to ask questions there and then, instead of coming back with a list of well-thought comments. What’s your advice on this from your experience?
I find that sometimes there can be a bit of an adjustment for those coming straight from academia transitioning into tech roles. The pace, the flow of work, can be so different. So I think collaboration and team-based problem solving are good things, so the fact that your team wants to unpack problems together and cares that much is great! That passion is important.
It’s OK to admit that you “don’t know what you don’t know”. Be honest with your team about that. While there is value in time-boxing problem-solving, some problems need more time and thought to go into a plan of attack. We use “spikes” as a method to assign when someone on our team needs to dedicate sprint or time resources towards “coming up with a plan”.
Knowing when to do this vs. trying to move nimbly is a bit of an art, as well as a science, but also trust that you aren’t always expected to come up with a perfect answer right away. Are you walking away with something that is “better than today?” Is it not increasing any tech debt? Can you move forward with some short-term improvements while also allowing yourself or your team, to, in parallel, focus on the bigger problem?
I don’t think you have to fix anything about your personality, just be open to some new methods, and maybe try and introduce some to your team as well!
How often do you do user-testing for new features? Do you have any tips for conducting user interviews?
As a general strategy rule, you should always include user testing for your new features! How much you choose to invest in this, and the various methods, should really be driven by how much risk there is to the features you’re developing.
Is this feature an evolution of something existing? A newer version? Is this a wild departure from your product? The more change you’re introducing, the more testing you may want to do.
As far as tips, there are a lot great resources on conducting user interviews, but first and foremost, if you have a Product Designer or Design team, utilize them here! They will be more unbiased and knowledged in the methodology of conducting these sessions (I have to constantly remind myself not to interject during these sessions, my passion becomes a detriment).
In lieu of that, remember that you never want to bias the results by leading your users into answers that you’re already looking for. It’s easy to fall into this trap, but it defeats the purpose of testing if you’re forcing the results into the direction you want.
Do you have any thoughts on leading teams and creating a culture within a team of people that each have different incentives (analytics, engineering, design, marketing, sales, etc)?
Working in larger companies will entail more layers of stakeholders and teams that will inevitably get involved. Alignment becomes paramount and to your point, when it goes wrong, it gets bad…
To me, transparency on objectives, goals, and ensuring alignment on “what problem we are trying to solve” is so key. Your marketing team is responsible for something very different than a data scientist, than legal, business analyst, etc. As a PM it’s important for you to understand each player’s role enough to understand “what matters to this person?” You can then tailor your conversations with these parties to how what you are working on 1- impacts them, and 2- how your project or product is tied to a larger goal.
We talk all the time about PMs exuding “empathy for our users”. Applying that same mindset to your stakeholders will go so far.
Lastly, more tactically, use the tools your company has at your disposal for communication. On cross-functional projects I will create Slack channels where anyone can come in and learn about the initiative. I keep myself honest of sharing updates there and stick to a semi-regular meeting schedule. You can always cancel these if not needed, but the accountability that everyone is part of this, and not just “all on you” helps as well.
I am from a hardware engineering background trying to move to PM. I have not seen many people move from my background. How difficult do you think it is and what skills are needed?
Whether you build hardware, software, cars, or inflatable pools, I think the practices of a Product Manager remain the same. Focus on the problem you are trying to solve and leverage the team and the methods you have at your company, whether that’s hardware, software, etc, to solve that problem for your user.
You may need to get up to speed a bit on software practices, but I’m sure you’ll be able to do that.
Any final advice?
My final advice is be curious, be accountable and be open to and okay with being wrong. Product Management isn’t easy. No one will tell you that. The tone that you set as a PM will permeate through your team, and impact the culture at your company, whether you realize it or not.
As you break into Product Management, try to think through use cases at your own company, at companies you admire, problems you encounter as a user yourself, start to give yourself challenges as to “How would I solve this? How would we solve this? Does this align with our company’s value proposition?”
Fortune favors the bold and if you’re trying to break into a PM team, share your thoughts with that team and the company. Showing that you put the time and consideration into that problem solving will go far, for your own education and job prospects.