This Week #10: Keeping designers and engineers excited about metrics + Transitioning from DS to PM 🕺
With guest contributor Lex Roman - Growth Designer, Writer, Speaker
Hello and welcome to my humble newsletter where I attempt to answer your questions about building product, driving growth, working with other humans, and anything else that’s stressing you out at the office. Send me your questions and in return, I’ll give you candid real-talk advice 🤝
If you’re returning from last week, thank you! If you’re new to this newsletter, nice to have you! 🤜🤛
This week (just two questions, an experiment):
Keeping designers and engineers excited about growth (with special guest @calexity!) 🤩
Transitioning from Data Science to Product Management 🧟♂️
On to this week’s questions…
Q: I’m finding it difficult to keep the designers and engineers on my team excited about driving metrics. We debate timelines, quality, and priorities and it’s never easy to get everyone on the same page. Any advice for getting everyone aligned around outcomes?
When I think about growth and design, I immediately think of Lex Roman. She has consistently put out some of the best content about design and growth, design and data, and design and experiments. I asked Lex to share her perspective on this question, and she kindly agreed (thank you Lex!). Enjoy.
—
This is a common challenge Product Managers face. They want to create cross-functional teams to leverage a diverse set of skills and perspectives and yet when they bring folks together from various disciplines, those differences often create tension.
There are four changes I would make to help shift your entire team towards a unified outcome:
Define metrics together
Review metrics together
Prioritize together
Reflect on releases together
1. Define metrics together
Designers and engineers are most engaged when they are involved in goal setting and goal breakdown. Sometimes product managers hesitate to “waste people’s time” in sessions about goals, but I would argue it is the most valuable time to spend together.
When you define quarterly goals, invite your whole team to participate. Use the time to reflect on how you did last quarter and consider where to focus this quarter. Here’s a sample working session agenda:
Review last quarter
Revisit goals and see how we tracked against them
Revisit major releases or experiments and how they performed according to their success criteria
Discuss what went well and what didn’t (with a focus on goals and what helped or hindered progress towards them)
Review company overall goals
Look at the company’s overall goals
Review how those goals are being measured and where
Discuss what teams are involved in each goal and where those teams focus their work
Define our next quarter
Review team mission and how the team measures success for that mission
Discuss what levers are at play that help you reach that mission metric (for example - what parts of your product are involved? What actions do you need users to take? What indicates you’re on the path to your mission metric?)**
Define where you should focus to have the biggest impact on your mission metric
(You can use the Growth Loops, HEART framework or North Star framework to help break down metrics into contributing factors.)
During these conversations, check in with your teammates. Do they seem excited and engaged? If not, try to figure out what gets them excited about working on this team.
I once worked with an extraordinary engineer who was really passionate about performance. We worked to connect the dots from performance to conversion to see if we could prove meaningful impact. Through this work, we could both stay focused on the business goals and tie into elements that mattered to engineering and design.
2. Review metrics together
One thing I see quite often is that designers and engineers do not have easy access to the metrics they are being held accountable for. Either, they don’t have access at all, or they have access but don’t really know what to look for.
You can address this by reviewing your team metrics together. And often. Show what dashboards or charts you look at and explain how they tie into your quarterly goals or company health overall. Be patient and encourage questions.
It’s also really powerful when you can connect the dots from their work to their impact. Show a recent experiment or release and explain how the work created change (or didn’t). Ask the team to reflect on why. Involve them as you plan the next steps. Celebrate big wins with the team and when things don’t go so well, take the time to have thoughtful conversations about your decisions.
When you review data with the team, you may also surface their interest in getting more into analytics. Help connect your teammates with resources or access so they too can explore their impact confidently.
3. Prioritize together
I like to start prioritization sessions by reviewing the team goals and how we are tracking against them. When you bring the goals and metrics forward each week, it helps everyone remember what we should be working on. And it makes it harder to go to bat for a low impact task.
As you prioritize projects, experiments or stories, make room for your team to voice what they think is high impact. But also, challenge them on it. Say a designer wants to work on a navigation redesign - ask them how the navigation is doing today. Ask them how they would measure success for the business, or for the user. Ask them to make a case.
Not everything will have a measurable impact, so you have to make a judgment call about what to push back on. Do so thoughtfully and carefully and without targeting any one individual. It’s important that everyone be upheld to the same standard on this--even PMs. Everyone should be able to explain why they want to prioritize something, what evidence they have for impact and how success should be evaluated. And occasionally, if someone really cares about something and it takes a couple of hours, let them do it. Respect what your teammates value and they will respect what you value.
4. Reflect on releases together
When you ship something, review how it has performed together. Talk about what was prioritized in this release and what wasn’t and whether or not that made a difference. Discuss what worked well and what didn’t.
It helps if you document how you’re measuring success in a product or experiment plan before the release. Make sure your team is clear on what success means and evaluate together whether or not something was successful. Consider what you all might do differently next time.
You can also try shipping some of the projects or improvements your engineers and designers are really fighting for. Give them a win. Define success together and review the impact together. Either they will see that they are pushing for the wrong thing or you will find out that they were right all along.
[Sponsored 🎁] This week’s featured open role comes from a company that I’ve been a fan of for many years: Scott’s Cheap Flights. Just a month ago, my wife and I flew to Mexico City solely because of an incredible deal we found through their weekly emails.
Scott’s Cheap Flights is hiring for a Head of Product — click here to learn more 👈
I asked their product team to share one tactic that they leverage internally to build great product:
“Support tickets are a gold mine of customer feedback and sentiment. Set up an automatic feed of product-related tickets in Slack to keep the entire team in the loop using an existing workflow.”
Thanks, Scott’s Cheap Flights!
Q: I am a data scientist looking to make the switch to product. What are your thoughts on internal tracks from DS/design/eng to product, and how to best leverage my data science background in modeling and experimentation when I do so? Also, I’ve heard that the transition to PM internally will potentially result in a “demotion” to the base level for PMs so it’s better off transitioning to PM in a new company. Is this true and how would you advise I approach this.
If your goal is to break into Product Management, an internal transfer program is by far THE BEST way to do it. I previously wrote about the four most common paths into PM and without question this path is the easiest, the least risky, and provides you with the most support. Some of the best PMs I’ve worked with got into PM this way.
If you know you want to get in PM and your company offers a route there, don’t squander it.
To your point about leveling, it’s very normal to move down a level when making this transition. And it makes sense – you’re doing a whole new job. However, normally you move down just one level. If you’re having to move down multiple levels, I’d push back to understand the rationale. If nothing else, get a clear sense of what your new manager will need to see in order to quickly move up a level.
In terms of how to actually land the gig, having a DS background is both a superpower and a liability. As a DS, you’re probably strong at many of the hard skills (e.g. driving impact, prioritization, execution, strategy), but less experienced with the weird soft-skills of the PM role (e.g. influence, product taste, keeping a team you aren’t managing happy and productive). My advice is to leverage your strengths, and fill in your gaps:
Read through this post and identify the skills that you believe you are weakest in. Then, find a way to develop them (starting with the links I’ve included in the post).
Talk to whoever it is that decides if you can get into this transition program, and ask them what they believe you need to demonstrate in order to qualify. Work with them on a plan.
Finally, closely observe the PMs that you work with day-to-day and identify what they do that is effective and ineffective. Then, try to model and avoid these things, respectively.
Don’t expect this process to be quick (it often takes over a year) or easy (a PM’s job is pretty terrible sometimes), but keep at it and if you really want it, you’ll get there.
That’s it for this week!
Inspirations for the week ahead 🧠
Watch: Moving Shapes [Only 2 mins, trust me] (via Tim Ferris)
Read: Momentum Isn’t Magic—Vindicating the Hot Hand with the Mathematics of Streaks [Turns out the hot hand fallacy is not a fallacy 🤷♂️]
Listen: Eric Weinstein interviewing Garry Kasparov [Two geniuses talking]
Images credits: Atul Choudhary, Forbes
If you’re finding this newsletter valuable, consider sharing it with friends!
If you’d like some advice yourself, just reply to this email. Each week, I’ll tackle a few reader questions (keeping your name and company anonymous) until you stop sending me questions 😬
Sincerely,
Lenny 👋