- Skiplevel
- Posts
- Building a feedback loop with your internal teams
Building a feedback loop with your internal teams
Irene Yu
April 26, 2023
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!
Hey everyone,
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!
Irene
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
Ask me anything & I'll answer it in an upcoming issue!
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!
💡 Tech Term You Should Know (TTYSK)
"Libraries & Frameworks"
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.
❗️What's important to know:
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!
As a dev & startup advisor, I've seen so many PRDs that are sparse & lack the necessary context for proper cross-team communication.
Instead, when writing your PRD's Executive Summary & Objective, focus on communicating PAST–PRESENT–FUTURE.
— Irene Yu (@iamireneyu)
3:01 PM • Apr 18, 2023
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.
At the very least, we revise our product roadmap every other week right before sprint planning. At this early stage, we have to be nimble and responsive to conditions, but at the same time it’s important to keep stability where we can. Always a balancing act :)
— Yana Welinder (@yanatweets)
3:06 PM • Apr 20, 2023
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.
Reminder: Saying NO unlocks YES.
Because, for me:
New ideas swirl around me daily.
Focus requires saying NO to many of them.
Focus is never without opportunity cost.
👉 But saying NO allows me to double-down on what matters.How does saying NO help you?
— Andrea Michalek 🎯 (@ThatAndreaM)
1:51 PM • Apr 21, 2023
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?
Become more technical in just 5 weeks, without learning to code. We also train teams. Find out more at skiplevel.co/teams and book a call with me to get started.