Welcome to my monthly newsletter. I'm an experienced software engineer, a tech mentor to product managers, and the founder of Skiplevel. Every month I share:
- technical skills and knowledge you should know
- tips for working with and collaborating with dev teams
- tips for non-engineers struggling with confidence in technology
- tips for managers looking to build a more technically literate team
Ask me anything (yep, anything) and I'll cover it in an upcoming newsletter issue!
I'm hosting a webinar on Wed, May 10th @ 2pm ET / 11am PT on Mastering Technical Literacy for Product Managers (and other tech roles) and this is your official invite!
You’ll leave this webinar with a much better understanding of what it takes to be technical and immediate steps to get you started on your technical literacy journey.
I originally opened 100 spots, but decided to open it up to 200 after we reached the initial goal in just 5 hours 🤯. There's currently only 27 spots left as of this issue publishing so make sure to RSVP ASAP.
Looking forward to seeing you there!
Q: How do I build and sustain a feedback loop with internal teams (e.g. executives, engineering, design/UIUX, customer support, insights/research, data science/ML, sales)?
Asked by Product Manager @ Activision
Hey PM @ Activision,
Building a feedback loop is so important for product managers since being a PM requires you to take into consideration the perspective, needs, and insights of so many functions within your org in order to make informed decisions about product development and strategy.
It’s all about process!
Building a proper feedback loop comes down to designing proper processes before, during, and after a product lifecycle in order to effectively gather feedback and suggestions from internal team stakeholders.
And no, this doesn’t mean just having regular big meetings with every stakeholder present. Maintaining constant communication with so many teams means you have to protect everyone’s time and your energy, especially your own. Meetings inherently drain both and is often not a productive or enjoyable use of everyone’s time.
In this write-up I’ll share some actionable ways to set up processes throughout the product lifecycle that’ll reduce friction to gathering and incorporating feedback from internal teams into your product strategy and requirement documents.
Incorporate feedback from internal teams throughout the product lifecycle
It’s important for product managers to incorporate feedback and perspectives from various internal stakeholders frequently throughout the product lifecycle.
Different internal teams require different frequencies of check-in. Technical teams like engineering should be seen as a key collaborator before, during, and after the product lifecycle while perspectives from customer facing (sales, customer success) and leadership teams that don’t have an impact on implementation should be included before and after a product cycle with updates on project status during implementation.
It’s especially important to include engineering early on in the product process. Many product managers make the mistake of incorporating feedback from engineering after creating the final draft of a product strategy/roadmap/reqs. However, technical implementation affects product decisions as much as product decisions affect technical implementation. Benefits to including engineering early on and frequently throughout the product process include less frustrating back and forth about clarification in requirements as well as being a great well of ideas for creative solutions to product problems.
Use async collaboration tools in lieu of meetings
A proper feedback loop requires checking in with internal team stakeholders before and during the process of coming up with your product strategy/product roadmap/business requirements doc (BRD). This means you should be asking for insights and perspectives before your product sprint, and at any time during your product sprint when you need feedback. But this can lead to a lot of unnecessary meetings for everyone, including you.
In lieu of meetings, a more efficient way of gathering feedback and insights throughout the product lifecycle is...
Got a question? Ask me anything & I'll cover it in an upcoming issue!
This month's Tech Term you should know:
Both libraries and frameworks are pre-written packaged pieces of code that developers can use to speed up the development process. Libraries and frameworks both solve common programming problems so that developers don't have to re-invent the wheel each time.
For example, managing time in an app is a common and complex problem. Instead of coding the functionality for converting timezones (a very difficult task), developers might choose to import a popular library like moment.js into their codebase.
While libraries and frameworks are both re-useable pieces of code, they're used for different purposes.
A library is a collection of code that can be imported into a project to add specific functionality. For example, a developer building a web application may use a library to implement a calendar feature, instead of building it from scratch.
A framework provides a more comprehensive solution for building an application. It includes a set of rules, guidelines, and pre-written code that provide a structure for the entire application. They frameworks include tools for handling common tasks like database management, routing, and authentication.
Here are the key things to know about frameworks and libraries:
(1) Libraries and frameworks are re-useable, pre-packaged code that devs import into their own codebases to ease the development process
(2) Libraries add a specific functionality
(3) Frameworks create structure to a codebase
(4) A codebase can have many libraries but only 1 framework
(5) Recognize common libraries and frameworks (See below)
Hot Twitter Takes 👀
👇 Use my simple PAST-PRESENT-FUTURE framework for writing proper BRDs for better communication. See full thread!
Take a gander at this awesome thread with lots of PM's chiming in on how they manage their roadmaps. Yana's on the money–nothing in software is or should be one and done, but keep in mind how changes affect cross-functional teams, especially the dev team. Only make changes when it's absolutely necessary and then communicate the impact of those changes.
This is especially true if you're struggling with demands from upper management and customers. Limited time and resources means saying "No" to requests and protecting your cross-functional teams so they can focus & ship on the most important asks.
I need your help! How can I improve this newsletter?
I put in a lot of time and effort providing you with the best technical literacy content, and I need your help. Tell me how I can improve this newsletter.
Want to feel more confident in your technical skills?
Missed the mid-month PM & Tech Jobs Newsletter?
Looking for a new PM role? My team and I decided to create a shorter newsletter issued twice a month with a list product role job listings from senior to entry-level roles.