Discover more from Behind Product Lines
The #1 mistake Product Managers make with Engineers
+ 9 PM Prioritization Tips I Learnt the Hard Way
Hey BPL fam,
We’re at the cusp of the summers now. It seems the age of AI has put everything on fast forward this year.
However, before we head into the edition, I wanted to address something.
After talking to PMs & other colleagues in my network lately, I realize many are feeling jaded, scared & overwhelmed with the talk around AI. The AI FOMO train is taking a toll on many. And I admit that I’ve also contributed to this on my feeds lately.
Some advice to remember:
Everyone else is on the same boat & are actively calibrating to this firehouse of information on AI. It’s ok to learn at your own pace.
Be kind to yourself. Ignore the “You’re falling behind” fear-mongering. If you’re under duress, please take a break from all this. Your mental health comes first.
Not every AI update is important or even that useful. Some are over-exaggerated. Start distilling.
While AI will certainly have an incredible impact on how we work in the future, we need to stop thinking about it constantly from a place of fear.
Less “it’ll kill my job”. More “here’s how I can wield it to make myself stand out”.
Yes, you will still see AI updates on the newsletter, but please feel free to to skip them if you’re feeling overwhelmed.
Alright then, let’s head into this week’s edition.
What’s on my mind: The Top 10
The #1 mistake PMs make with engineers
9 tips on prioritization I learnt the hard way
What’s on my mind: The Top 10
Here are the top 10 things that are swimming in my head these days:
Kyle Polar discusses about a simple metric ( = Annual Recurring Revenue / # of Full-time employees) that reveal a lot about the unit economics of a SaaS business.
Adnan Zaman shares 11 email ideas for a product onboarding flow. This serves as a nice checklist to consider when shaping up your first mile.
Sal Khan’s unveiling of Khanmigo will transform education as we know it. This is probably the biggest impact AI will have on the next generation.
Marketers are raving about NERFs (Neural Radiance Fields) - a technique that generates 3D representations of a scene from 2D images. This can change how production houses go about creating ads & commercials.
ChatGPT Extensions are helping inject the magic of ChatGPT into our everyday browser, expanding on the usage scenarios. I particular am impressed by Wiseone - an extension that’ll help you answer questions about an article you’re reading.
Data analysis might become highly accessible for all with ChatGPT’s plugin called Code Interpreter. It has the ability to consume multiple file formats like Excel sheets & MP4s and conduct tasks like edit videos, chart out trends, recommend business strategies based on data & provide decision assistance.
Midjourney - the generative AI tool for realistic images - keeps breaking limits of creativity, especially with it’s latest version: 5.1. Check out the quality of images it’s coming up with now.
Reddit may start charging for it’s APIs. They feel that AI bots training on their data need to pay up. I feel Reddit might not be the only one. Any social knowledge base would feel the threat of AI consuming all their content & summarizing it.
I’m wondering whether these AI tools can help with someone’s job search. With the recent layoffs at LinkedIn, I feel it’s becoming important to level up on their ability to stand out.
I’m a big fan of the SaaS messaging framework that Robert Kaminski recommends. This PLG messaging guide on how to select the right message for each part of the buyer journey was super enlightening.
The #1 Mistake Product Managers make with Engineers
Product Managers & engineers have a famous love and hate relationship.
But the partnership is essential for product success. PMs that learn the trade of working better with engineers often end up with better product ideas, faster delivery cycles & most importantly, a psychologically supportive environment to operate in where the team is “on the same side”.
First, let’s understand how these differences arise.
Here are some bad habits of Product Managers that engineers dislike:
👉 Leading conversations with heavy business jargon & acronyms.
👉 Asking for an estimate but then mandating a shorter deadline because the "business demands it".
👉 Expecting bug-free builds, unit testing & scalable code while rushing sprints with unclear requirements.
👉 Resisting tradeoffs when slipping in a new user story at the back end of a sprint.
👉 Imposing a arbitrary deadline on a bug that's difficult to reproduce.
👉 Asking for an extensive feature & then pulling the plug mid-way without reason.
👉 Not including developers in cementing client commitments
👉 Not involving developers early on when drafting roadmaps & refining user stories.
👉 Signing up for a tight release without dev consent & expecting them to spend nights to achieve it.
👉 Taking all the credit when engineers pull off all-nighters to launch a feature.
👉 Burying micro-updates to a spec in an email, JIRA, Slack & Google Docs but expecting developers to implement each one of them.
👉 Not making an effort to understand tech debt.
👉 Thinking that asking developers to reverse-engineer something is perfectly equivalent to a detailed spec.
👉 Considering progress only to be = what's visible to them on the interface.
Let’s flip the script now.
Here are some developer habits that Product Managers aren't fond of:
👉 Promoting what's easier to implement rather than what's right for the customer.
👉 Talking about what "they" think should be built as opposed to empathizing with the customer's perspective.
👉 Not making enough effort towards reading the documentation & skipping finer details.
👉 Thinking of meetings as a burden as opposed to an opportunity to collaborate.
👉 Leaving bugs for the QA to identify & not committing to basic testing with variable inputs.
👉 Ignoring product copy & design aesthetics, thinking function > form.
👉 Failing to clarify or articulate key assumptions during estimations.
👉 Calling out problems with specs & then sitting at an arm's length from it until a solution is spoon-fed (little participation in collaboration on a solution).
👉 Raising concerns around technical debt & recommending code refactoring but not caring to explain it to the PM in depth.
👉 Not understanding that the customer doesn't care about the underlying technology.
Now, a number of these challenges emanate from the fact that product & engineer don’t understand each other’s core objective.
PMs are not meeting munchers or corporate spokespeople. Engineers are not support staff or a deposit machine for JIRA tickets. Both want to solve meaningful problems at scale.
This brings me to the core topic of this newsletter.
What's the #1 mistake PMs make with their engineering teams?
A: Involving them in only 1 stage of the product lifecycle i.e. Development.
Over the years, I've realized engineering units are a powerhouse of ideas but you have to reel them into your process. Sadly, most of that opportunity is lost in “us vs them” conversations & JIRA marathons.
Here’s what Gergely Orosz, a former engineer at Uber and Skype, had to say about what engineering wants from product:
Here are ideas on how PMs can involve engineers (applies to design/UX too) in their entire workflow:
(1) Goal Alignment
Ensure your tech team is aware about:
- The vision of the product. What’s the endgame here?
- The business goals that the company’s trying to achieve.
- The product metrics that matter & why.
- The product strategy - what conscious choices are we making & what opportunities are we *not* pursuing.
(1) Discovery Stage
As you're learning more about your customers & gathering evidence, keep your engineers apprised on key findings:
- Summarize & share insights from user interviews & market research.
- Bring engineering managers to a couple of your discovery sessions. Break them down with them to get diverse ideas.
- Work with them both on the problem & solution space. What is the core problem we're solving? What are potential solutions we can pursue?
(3) Definition Stage
Once you're aiming for a solution, leverage engineering insights to refine & enhance it:
- Review product specs with them to get feedback on technical feasibility.
- Give them creative freedom to suggest alternative user flows OR sniff out weak links & missed out corner cases. You'll be surprised what they can come up with.
- Expose wireframes early to see if they have any red flags.
- Work alongside them to groom the backlogs & identify technical debt.
(4) Development Stage
This is the stage that most PMs interface with the engineering team. Don't limit it to status updates via stand-ups though:
- Work with them to prioritize work items & explain why.
- Unblock them by giving them clarity on specs & managing their ad-hoc workload with the engineering manager.
- Review the staging builds with them & give them specific feedback.
(5) Release & Launch Stage
This is where PMs often go into chaos mode. Communication gets tense as the release is being stabilized:
- Conduct a pre-mortem with engineering & call out risks.
- Agree on a release strategy (partial, geo fenced, beta release etc.)
- Inform them about product launch activities - what are expectations from sales, marketing & leadership.
- When the release is done, publicly praise them & thank them for their efforts.
(6) Analysis & Iteration Stage
Engineers appreciate it when their work is creating impact:
- Share user feedback with them. Celebrate successful builds.
- Look at usage data & session replays to ideate what can be improved on.
- Hold retrospectives to discuss lessons learnt & how the process can be improved.
Wait. I have to share a couple of fair warnings here.
Warning 1: All engineers don’t have to be in every meeting.
That won’t be feasible. The idea is to have engineering representation in your workflow, not presence of every person with a tech job title. They have their own jobs to do, after all. Some meetings might just require the engineering manager. Others might need a subset of developers who worked on a specific feature. And so on.
Warning 2: Engineering teams may have different preferences. Don’t force them.
All engineers aren’t the same. They will naturally have different appetites to how much they want to be embedded in your workflow.
Thus, as a PM, you will have to have an open conversation to see what their needs are and what their bandwidth allows. You will have to sell the benefits to some (while others would be willfully ready to jump in).
Remember: The purpose is not to create information overload. It’s easy to eat up too much of their time unnecessarily if some semblance of balance is not maintained.
Here’s what John Cutler, ex-Amplitude PM & one of the most renowned subject matter experts on product, noticed:
I’ve worked with engineers who are hard-core Agile followers. They hated having high-fidelity design on a ticket. They wanted to be involved in all design and research sessions. They wanted to meet the stakeholders and gain all the context.
I then moved to a different team and the engineers in this team hated being distracted from their focused coding time. They wanted high-fidelity design even before they created the technical design. They preferred clear roadmap a quarter ahead, whilst my previous engineers already objected a rigid plan a sprint ahead.
There’s no one-size-fits-all. Within the team, you’ll also encounter some engineers who love being involved in early discussions, and some who like getting their heads down in the code. Recognising their strengths and preference rather than assuming will help you multiply their impact.
The bottom line is:
Make engineering a part of your product team. Not a mere support service to it. But collaborate with them first to gauge what extent they want to be involved in.
Another worthy read:
Thanks for reading Behind Product Lines! Consider subscribing only if you found value.
9 Prioritization Tips I Learnt the Hard Way
When Product Managers enter the field, I often see them struggling with prioritization.
Their natural tendency is to lean on “frameworks” to keep them afloat in the ocean of JIRA tickets & production fires.
Frameworks definitely have their benefits…as a starting point.
Image credit: Sprout Social
I’m not going to break down the frameworks out there as there’s already a lot of literature around that. If you’re interested to learn more, check out Pawel Huryn’s Medium article on this. (by the way, I highly recommend PMs to follow Pawel on LinkedIn for more resources)
Here are 9 lessons I learnt about prioritization the hard way in my career:
1) Prioritizing in a silo doesn’t end well
In fact, I find calling prioritization a pure "PM" activity a bit misleading. It’s a conversation that’s led by the PM but is essentially a collaborative endeavor.
PMs take pride in keeping customer feedback as their North Star and solving their problems. However, your surrounding team will provide key signals around business priorities, strategy, technical feasibility, market trends & more to help you prioritize better. If you leave out opinions of leadership, design, engineering & the likes, you’ll likely run into conflicts later on.
In practice, the nature of collaboration around prioritization can take different shapes and forms depending on the product stage & nature.
For example, Lane Shackleton, CPO at Coda, discussed on Lenny’s newsletter how such prioritization decisions are decentralized:
As teams got bigger, it made less sense to plan in a centralized way. Initially, the Product, Design, and Engineering leads centralized prioritization stack ranking. As it became more bottom-up and decentralized, we needed to plan further out. Overall, I’m a big believer in decentralized leadership and giving teams autonomy to solve problems.
In contrast, Varun Parmar cited a more top-down approach to prioritization when he broke down Miro’s prioritization process with Lenny:
First, the Product Leadership Team identifies priorities for the year (e.g. outcomes we need to achieve) and an initial list of initiatives we want to pursue
Next, the AMPED leaders come together to refine our priorities, discuss conflicts, and make tradeoff decisions. Typically, this group meets at an in-person offsite and dedicates four or five days to finalizing the product strategy.
Finally, the full 700-plus AMPED org reviews the product strategy. The product strategy document is shared with everyone; I present the strategy at an all-hands meeting, and we hold Q&A sessions where AMPED leaders (not just product leaders) answer questions.
While the directionality of prioritization varies, I see a PM can’t take prioritization decisions on their own. They need to get some buy-in on the high-level strategy from leadership & then partner with teams responsible for execution to pin down priorities.
2) Data is only one aid for prioritization
Prioritization needs input. Product metrics is just one facet. Also, basing decisions in scenarios where data is sparse or biased is really a recipe for deceiving yourself.
Pay attention to “evidence” like customer feedback, anecdotes, industry trends & competitive insights to help. Yes, “anecdotal” evidence is bad but let your intuition & rationale guide you on what feedback can be extrapolated.
3) Frameworks are limiting
When you choose a template design on Canva, you don’t publish it as is, do you?
Similarly, frameworks are boilerplates.
1- See if they fit your scenario.
2- Tailor them.
IMHO, most frameworks can be gamed because the parameters are subjective e.g. everyone will dish out a different “Impact” score in RICE.
This is not to say they are bad. It’s to highlight that it takes discipline, team alignment and some moral fiber to keep benefiting from frameworks.
4) Prioritization acumen changes with product stage
Analogy: Think about life. Your priorities in your 20s ≠ priorities in 30s.
Similarly, products evolve over time.
Early-stage obsess about PMF. Late-stage crave stability & optimization. That's why the latter might prioritize "tech debt" more than the former.
Know your stage. That will help you understand why leadership’s mental prioritization schemes change over time.
5) Debate is healthy
Prioritization is a logical discourse.
The worst prioritization sessions are when the team is passive about the sequencing. When people lobby for tickets with reasoning, it creates clarity & even ownership.
Of course, as a PM, you need to moderate this to break stalemates & get to a decision.
6) Look at frequency, not just impact
Unpopular opinion: tackling smaller, frequently-occurring issues can deliver more value than "high-impact" less frequent problems.
High frequency problems keep reminding customers why they don’t like your product. I like to award them a few priority points to stem the bleeding. Also, we PMs tend to over-estimate "high-impact".
7) Ask customers to help in prioritization
There’s no harm in asking a few customers about what they would prioritize. You don’t have to commit to their response. But they provide a perspective that carries weight. Their reasoning to prioritize something over another has surprised me in the past.
8) Stop starving long-term
It’s easy to keep prioritizing short-term gains.
While that myopic view will create a few small wins, in the larger context of the product, growth will be slow. Without protecting your long-term bets, you’ll eventually erode your moats & see competition zoom past.
You need to escape "enhancement" valley.
9) Stop shaming re-prioritization.
Life happens. Things change.
Re-prioritizing, sadly, carries a negative connotation. PMs that do this are seen as fickle.
Yes, it’s bad if you re-prioritize because you’ve been winging it. However, if the team thought through things, it’s ok (& even necessary) to change things around. Just make sure to let everyone know "the why" behind the shuffle.