This week’s Ask Me Anything session featured Lauren Peterson, Senior Product Manager at Nava. We talked about the rise to Senior PM from PM, how to prioritize tasks, and the fine art of product management!
Lauren is a seasoned Product Manager who is passionate about healthcare and brings over 7 years of professional experience to her position. She currently leads the company’s work with the Department of Veterans Affairs at Nava, a public benefit corporation dedicated to making government simple, effective, and accessible for everyone. For over the past two years at Nava, she has been building tools to improve how the Department of Veterans Affairs processes appeals. After holding multiple leadership positions, she first broke into Product as a Product Analyst at The Advisory Board Company, helping health care executives work better.
She graduated from the University of Virginia with a Bachelor of Arts in Foreign Affairs and a minor in Bioethics. Outside of her day job routine, she loves live music, ice cream, and the golden hour. Lauren has spoken about product management at a variety of tech and government conferences. She continues to develop her professional and personal skills in Data Analysis and Community Outreach.
“What are your strengths and weaknesses as a Senior PM?”
I think being reflective about your personal and professional growth is extremely important, as an employee, and as a product manager. Personally, I’ve identified one of my strengths as being able to context switch and engage in a variety of conversations throughout the day. And, I want to further develop my delegation skills which is so important as a PM, because we have so much on our plates!
“How have your day to day tasks changed since you became Senior PM? Are there differences between a PM and Senior PM?”
As I’ve grown in my career as a product manager, the scope of my role has also grown. As a product analyst, I owned and launched small features as a part of a larger product. As I started PM’ing on my own, I owned and launched products, then a suite of products. As a Senior PM, I’m still owning and launching a suite of products, but also have people management and leadership responsibilities on my team and at my organization.
“What do you feel is a reasonable ramp up time for a new product manager?”
This is such a good question! And one that doesn’t have an easy answer. This can completely depend on the space that your product is in, as well as your product’s complexity. For any job, I try to set goals for myself at the 3 month mark first, and collaborate on those with my manager. I rarely expect to feel like I’ve got a full handle on my role before 6-8 months. I think it’s important to have patience with yourself, and remember that product managers wear a lot of hats, have to learn a lot, and that takes time!
“What do you think is different as PM in healthcare and what is the most important thing you’ve learned that made you a better PM?”
To answer the second part of your question, I HIGHLY recommend the book ‘Product Management in Practice’ by Matt Lemay. It was HUGE for me, to appreciate not only the practices of product management (roadmaps, requirements, user stories, etc.) but also the principles and theories behind those practices (why agile, what does it really mean, what about product vision and goal setting, etc.)
As for being a PM in healthcare, – as well as with the Department of Veterans Affairs, – the main difference seems to be the level of complexity you have to wrap your head around, and potentially, the intricacies of working with legacy systems (some 30-40+ years old!)
“What are the tools your team loves using in order to keep organized and keep track of progress on a day-to-day basis?”
One of my ABSOLUTE favorite tools is Mural. It allows our distributed team to collaboratively sticky note/whiteboard, and brainstorm ideas with basically a blank slate. It seems to support multiple working styles, too. Some who need a blank canvas to popcorn ideas around, and others who need to bring those varied ideas into order. Highly recommend!
“How important is company culture or work culture for growth as a PM?”
I think company/work culture is extremely important for product managers. We have intense jobs! We have lots of accountability, without leading other disciplines on our team (design, eng, project management, etc.), and with that can come a lot of stress. One thing I look for in work culture is an appreciation for work sustainability, investments in people management/mentoring, and especially how the company respects working hours/time off. My current company offers unlimited mental health days too, which I absolutely appreciate.
“I’d be interested to find out if you have had any experience implementing Agile/Scrum methodologies with a small team of developers if so, what the biggest challenge was, how you motivated your team, how you asserted yourself when required and most importantly how you managed developers who were resistant to change?”
The biggest challenges I’ve faced are when teams follow process for process’ sake, rather than reminding ourselves why those processes were implemented in the first place. I would caution against implementing agile/scrum methods/rituals without first coming together as a team and defining what principles your team agrees on.
For example, the agile manifesto states “Responding to change over following a plan”. If your team (or your stakeholders) are harping on having specific rituals just because agile says so, try to remind them that iteration and flexibility is actually better for the end state of the product, and it’s ok if we have an asynchronous standup on a given day! Or something like that.
Make the process work for your team, vs. adhering to an out of the box agile/scrum one size fits all perspective.
“How do you prioritize between adding value for the buyer vs add value for the end user? Because the end user’s value may not directly be visible to the buyer.”
Oh my goodness. This is one of the hardest things as a product manager, especially if you are on the hook for revenue from your product, and what the buyers are asking for aren’t what the users actually need. One thing I’ve done in the past is try to explain to the buyers what the users need, using the buyer’s language.
An example might be – buyers are asking for a dashboard of data so they can see their progress to a specific metric. But they’re not going to use the product because of their position in the company, their direct reports/other users are. At the same time, users need some usability improvements to even get to that dashboard. Show the buyer that without those users’ usability improvements, they won’t even use the dashboard, to get that buyer their answers.
Look for ways to help the buyers find empathy with their own colleagues who are using the product.
“What are the most painful aspects of working with the development?”
I wouldn’t call working with development painful. I see developers as members of my team, and we are highly collaborative. I think there are some pain points working on a team in general, that come down to the fact that humans are complex creatures!
Communication – in terms of making sure you’re all speaking the same language/using the same terms – can be difficult sometimes, especially when your stakeholders use one word to mean the same thing developers refer to as another thing in the code.
I think it’s important to get to know your teammates as people – what drives them, what motivates them – and open the lines of communication, so that you can work well together.
“How are you aligning your day to day work to Organization’s bigger objectives? How do you quantify/determine if your daily work is impacting Product Org’s or the whole company’s Key Results?”
Each year, we set high level company goals. Each quarter, we define more specific indicators that align with those company goals. Also each quarter, we ask each discipline (product, eng, design, etc.) to set their own indicators that further those company goals and indicators. This helps all disciplines at Nava, who all work on different projects, to stay aligned with company priorities.
On my work with VA, I work with my stakeholders to set goals and priorities quarterly, so that each product manager on my team has guidance on what to prioritize and focus their scrum team on.
“What techniques do you use when you have to tell internal/external customers when requests are rejected?”
Ah. The art of product management! Explaining why is key here. Why was their request rejected? Was it because there was another feature that would have a higher impact to more users so the company prioritized it? Was there a tricky deadline? Is there tech debt that needs to be prioritized to make way for bigger bang product improvements down the line?
If you can disclose a little bit of your decision making process / your justifications and reasoning, your customers might gain understanding and empathy with you and your job as product manager, and see where this decision was coming from.
“What do you wish existed for a PM or their team?”
Infinite time! (and coffee! ) Something crucial that needs to be in place, I think, is an appreciation for iteration, an understanding that mistakes will happen, and a team that will collaborate and problem solve together. Problem solving is a team sport. I wish every PM could go to a peer engineer, designer, or other team member, with a problem, say something like “I think I’m on the right track with this, but can your riff on this with me?”
“What is your favorite prioritization technique?”
I find Impact vs. Effort very reliable. I often change “Effort” to be “Complexity”, as defined by the amount of unknowns. This helps non-technical folks contribute to the prioritization. They can easily understand if there are still open questions about the problem to solve, then it’s going to be more complex, with more moving pieces, to work on that project or feature.
“What are some of the performance metrics that you have seen Product Managers ignore but are of great value?”
If I’m understanding your question right, I might shout out my engineering team here. I don’t always monitor response times for certain pages/endpoints or asynchronous job queues as much as they do. But when they monitor them, they can get ahead of support tickets before our users report them!
“How do you structure your PRDs and Roadmaps?”
A quick note on this one – I don’t use dates with external folks. Now, Near, Future are my main headings! I typically include higher level projects/epics grouped into themes. And, especially for external folks, I include activities like “discovery”, “user research“, etc. so they know those are part of the process!
“Say if you were managing internal tools like the one used by Customer support teams, what features are a must build for you?”
I would first start talking with those customer support teams, conduct user research to understand how they were currently using the tools, where they see opportunities to improve their workflow, etc. Most of the time, your users have the answers for you!
“What’s the best lesson you’ve learned from developing products for the government?”
One of Nava’s values is that progress takes work (and time!) and that really rings true for me. Also, it’s important to ask why before immediately saying yes to something. Sometimes, folks are thinking about “the way things have always been” vs. what they can and cannot do from a legislation, regulations, or policy perspective. Asking why keeps options open for problem solving. But of course, it’s also important to show respect and deference to your civil servant coworkers!
“I work as a senior PM and nurture 2 young APMs. I report into my co founders. What advice do you have for me to help train and nurture my APMs well, while progressing in my career?”
Great to hear! People management and coaching is very rewarding. A few things – as you coach, try not to tell your APMs the answer. Believe that they have the answer within them, and ask open ended questions to help them get there. Show/lead by example. Give outlines and examples of the work you’d like them to do, and overall guidelines. But try not to be too prescriptive (unless they specifically ask for that)! Last, listening is KEY! Silence in 1:1s (I do mine weekly) is ok – it helps them come up with the answers themselves.
“So, how do you prioritize for internal products? Like if you have a feature A that could help your main product customer base by a little vs a feature B that helps your support teams by major. Which do you choose first?”
Prioritization is always tricky. One thing to think of that could help you with this – frame the internal feature B in a way that helps other empathize with your support team. There are X numbers of support tickets that deal with this feature, and feature B will help us reduce that by Y%. Or, if we build feature B, we will increase customer support productivity by Z. Customer support productivity is also a benefit to your main product customer base.
And then compare that with the impact that feature A will have for the customer base.
This role and career may look different depending on your company, prior experiences, or situation – and that’s ok! That helps us grow together.
Making space for and inspiring your team is a bigger part of product management than I had realized (back when I thought product management was just roadmaps ). Tie your work and what you ask of your team back to goals, so they aren’t working blind.
And, recognize that a diverse and inclusive team builds better products! Make space for all types of thinkers and learners.