Feedback Loops
I’m working on a project with more people and functional areas involved than a typical team I lead. Normally I operate as the “Product Lead” and build software with a two developers. For this project, however, it requires deeper strategic and marketing work alongside development. My brain immediately started drawing arrows between all the people and functions to make sure we’re in alignment.
I was thinking in feedback loops, which are critical components of effective systems. They help conceptualize inputs, outputs, and the process required to take those inputs and convert them into the right outputs. By identifying the inputs and outputs, I know the levers I can pull. If we’re not generating the right outputs, then we need to check we’re capturing the right inputs through the right process.
The process is ephemeral and should be adjusted through experimentation. Yet experimentation only works when you know the variables to change, which is exactly what you uncover when you define feedback loops.
Structure
So what does a feedback loop look like? I define it in five key parts:
- Frequency: How often the loop occurs.
- Participants: Who is involved in the loop.
- Inputs: What information, challenges, or updates are provided.
- Processing: What happens during the loop (discussions, decisions, etc.).
- Outputs: What results, actions, or adjustments come out of the loop.
Example Feedback Loops
Here are actual feedback loops I defined for this project. While each operate independently, they inform one another to create an effective system.
Demos
Working software is the best barometer for progress, so I started with a clear weekly feedback loop to see and discuss the progress of the work with weekly demos.
- Frequency: Weekly
- Inputs: Completed work.
- Participants: Engineers, CEO, Product Lead.
- Processing: Demo presentations followed by discussion and feedback.
- Outputs: Adjustments to product direction, clear next steps.
Uphill Challenges
In order for the engineers to deliver great demos, we need to quickly surface and resolve unknowns while we’re working uphill. This is when we’re making a lot of decisions and trade-offs to build the best functionality. Raising these challenges daily keeps a tight feedback loop of iteration.
- Frequency: Daily
- Inputs: Uphill challenges.
- Participants: Engineers, Product Lead.
- Processing: Linear issues documenting uphill questions to resolve.
- Outputs: Priority and scope adjustments.
Marketing Insights
The core functionality should be guided by customer insights and fine-tuned by our product intuition. This feedback loop can come from the go-to-market learnings so product development can prioritize work each week.
- Frequency: Weekly
- Inputs: Customer insights.
- Participants: Marketing, Product Lead.
- Processing: Loom Weekly Update sharing key insights for development.
- Outputs: Feature priorities.
Statements
Statements for feedback loops are another way to express the same information. While the structure gives a detailed breakdown, the statements convert those into something like a “user story” you would use when building software.
Let’s continue with the examples from above:
Engineers provide demos of working software to the CEO with Weekly Demos to produce strategic adjustments and accountability.
Engineers provide uphill challenges to the Product Lead with daily Linear issues to surface and resolve technical challenges.
Marketing provides customer insights to the Product Lead with Weekly Loom Updates to prioritize feature development.
The format that drives these statements is as follows:
[Input Owner] provides [Inputs] to [Participant Owner] with [Process] to [Outputs].
Shorthand
Like statements, the shorthand is another way to express the same information. I like this format to quickly express the feedback loops and adjust the individual pieces to experiment with different inputs and processes.
Engineers → (Working Software) → [Weekly Demos] → CEO → (Adjustments)
Engineers → (Uphill Challenges) → [Linear Issues] → Product Lead → (Resolution)
Marketing → (Customer Insights) → [Weekly Update] → Product Lead → (Priorities)
The format that drives these statements is as follows:
[Input Owner] → [Inputs] → [Process] → [Participant Owner] → [Outputs]
Enjoying this issue? Sign up to get weekly insights in your inbox: