This week, Product School hosted Nicole Munson, Senior Product Manager at American Express, for a special #AskMeAnything session. Nicole tells us her take on building user stories, stakeholder management, prioritization, and why it’s essential to get organized as a PM.
Nicole Munson is a Senior Product Manager at American Express, working within the AMEX Savings team. Before this role, she was a Senior Product Manager at Goldman Sachs. Prior to that, she shared her wealth of knowledge as a Peer Mentor, Teaching Assistant, and Research Assistant at her alma mater, Brigham Young University (BYU). She graduated from BYU with a BA, majoring in History and minoring in Business Administration. She was a top-notch student who received multiple scholarships and awards for her academic achievements.
How do you determine how prescriptive your user stories should be? There’s much regulation such that sometimes you have to spell out exactly how something is to be designed/built.
That is a great question! There is always a strong balance between spelling everything out and letting engineers be creative with their solution. I think it often depends on your team and can fluctuate, but as a general theme my requirements should clearly outline the Why and the What for engineers. The solutioning is often a partnership during refinement.
For me, anything regulatory that stakeholders have to confirm from a legal and compliance perspective are normally very clearly outlined since the PM will need to communicate that clearly to their engineering partners.
Another great read: PM Skills: User Story Mapping
When user stories get bigger, sometimes you have to create sections and headings. What sections or headings do you use?
I like to break down by effort needed and ideally only have a sprint’s worth of work in a user story. On the capability or feature level, I might provide a feature map that clearly outlines the work in the user story.
For example, if I needed to re-do the login experience on a consumer site, I’d find ways to break it down and use headings that reflect that. In this scenario, I could break it down by operating system or customer segmentation and title should reflect that.
How do you go about balancing long term goals (brand, features, revenue, corporate expectations) and short term (UX, engineering team goals, user growth) goals?
Balancing goals for Product Managers is always a hard topic and can feel painful at times. We often are faced with the challenge of short term success, platform stabilization, or innovation and it can be hard to sift through to design the roadmap.
From my perspective, every PM should have an OKR or North Star they are following in order to determine roadmapping. For example, if I want do something innovative but consumers are angry because of a platform issue and I’m losing customers, I will likely prioritize short term goals over new things. Each situation is different and pulling in data and customer research can give a strong indicator of the best path forward.
To what degree do you get in the weeds with your software engineering teammates? How do you find the right balance of understanding the technology with your other responsibilities?
Personally, I like getting into the weeds. I would never pretend to know more than my engineering partners, but I think it is important to understand how things connect, what swaggers are being used, the general architecture, etc.
I like to view my role as a Product Manager as being the communication channel between business and technology’s needs and my responsibility is to advocate for both sides and most importantly, the customer’s side. I think if you can effectively communicate for those three parties and can answer key questions on behalf of technology then you are doing your job right.
That being said, everyone has their own strengths and it is important to find the right balance for you that keeps your delivery efficient and customer satisfaction high.
How do you come up with a rollout plan for a feature? Do you use templates?
I have always worked at companies that have had clear rollout strategies. A common thread for rollout plans is having every takeaway documented and an owner assigned. If you have a task but no one owns it – does it ever get done
I have used Excel, MURAL, Confluence, and many other mediums to do this. They key is to remain organized. As a PM, my focus is always on testing and ensuring that the release actually works, as my top priority.
In terms of templates, I often just find things across Google, Product School, or even LinkedIn announcements. The key is to be creative and do what’s best for your product.
Would love to know how you communicate tradeoffs of a product decision to stakeholders?
Data! Data! Data! What is going to bring us closer to our end goal for this product? If I can construct an argument for a tradeoff based on data points from customer research, capacity constraints, forecasts, etc, then I have done my job correctly.
If you don’t have a lot of time to find each point, take the time to find 1 or 2 points that are strong or use pass knowledge to justify the tradeoff. It is also important to focus your argument to your audience and their top priorities.
What are the best practices for following up with engineers and designers?
In agile we tend to have Scrum of Scrum meetings that we use as touch points. If you are not using an agile methodology, ensuring you are having regular meetings with these groups to keep in touch and track open items.
What’s your typical process for discovery?
I love the discovery phase! The first thing I do is try to separate my bias from the item I discovering to know what my bias is and ensure it is not sending me the wrong way.
Next, I try to understand the customer need through customer research, the competitive landscape for customers, an overview of what I have to work with, and understand timing. By gathering all this information, I normally can create key features to guide engineers to creating the customer solution for delivery.
Read next: Product Discovery 101 for Product Managers
During your time at BYU when you were a TA and research assistant, when and what made you decide to pursue Product Management and ultimately land your first role as a Sr PM at Goldman Sachs?
I love being a PM. I loved research and working on a team, eventually I learned more and more about being a PM and the aspects of the job like research, understanding complex problems, solutioning, communicating with stakeholders, and eventually decided to try it out and the rest is history. I think PMs need to be from a lot of disciplines because that’s what keeps us creative and solving solutions for our customers!
Any final advice?
Final word of advice is that anyone can be a PM. We all have different experiences in our lives and look at the world differently. If you are interested in you will need to be ready to learn a multitude of skillsets like communication, problem solving, and high attention to detail. If you are willing to put in the work, anyone can do it and bring great products to our world! Thanks everyone! Was great chatting with everyone!