How do you teach engineers to think like PMs? You give them the awesome and scary responsibility of choosing their work. Our team learned how to think and prioritize strategically by collectively building an Idea Backlog where we dream up and prioritize impactful projects to tackle. Here's how it works.
Rebuilding the team with a growth engineering structure
In our last post, I told a story about how the departure of our PM led my manager and I to split the PM roles between ourselves and shield the team from the change. This led to burnout, spreading the two of us way too thin.
We decided to make a major change to the team structure with a process that would focus on individual empowerment.
Engineers would be empowered to ideate and drive projects from ideation to execution. Instead of being fed work from a PM, our engineers would be responsible for thinking of new features and projects that drive growth and seeing them through to completion through the entire software development cycle. This was bottom-up impact.
Individual Empowerment through the Idea Backlog
In this new model, the ball starts with each individual contributor. Armed with a clear vision of the goal (OKR) and the tools to measure them (metrics and analytics), the team is given leeway and authority to work on any project that can drive impact.
We do that with an Idea Backlog. Each week, we check in with the team and see if people have any new ideas for projects and experiments that can move the needle. Projects have included:
- Landing page experiments involving copy or UX tweaks
- New partnership ideas with other companies
- New product ideas that solve a specific problem in the customer journey
- New ways to gather feedback from users
People don’t just think of ideas unprompted! It’s important to encourage open-ended ideation. One way to do that is to get our engineers consistently in front of customers. For example, by manning a chat widget on one of our landing pages, I had to talk to several customers a day and learn about what they were looking for - those conversations led to product ideas that eventually became experiments!
Our Idea Backlog is really just a Kanban board of big ideas; rough and unfiltered. As they mature and get vetted in weekly discussions, they begin to take form. Product specifications get written and circulated - all by the engineer.
Idea Backlog: Product Spec 1-pagers
Each idea backlog item moves from “this is a cool idea” verbal discussion into written form as a 1-pager specification. This specification needs to have:
- A sense of the opportunity size or impact, usually measured in one of our key metrics ($ or rides).
- A discussion of how the implementation will work, usually defined as a A/B experiment that is measurable and time-bound.
- A discussion of the risks and non-goals involved.
- Any external stakeholders or teams that also need to be involved.
Yes, it’s painstaking work that often lives outside of most engineers’ comfort zones. This means oftentimes setting up meetings with different teams, other PMs, and product leaders. This means writing specs (ugh). This means getting down and dirty with data analysis, writing queries and hunting down data tables that may be poorly documented or hard to understand.
In other words, this isn’t coding, but it’s a foundational part of the exploratory analysis needed to be a product owner. And we have our engineers all go build that muscle.
How do ideas become reality?
At the beginning of each week, we evaluate our roadmap and see if there is any need to “pull” a new idea from our idea backlog into the roadmap. At this point, the team can decide together whether an idea has enough legs, definition, and impact alignment so as to actually become a project!
Idea Backlogs - a great way to get involvement from your teams
The projects that make it out of this cycle get formalized in our roadmap and worked on in upcoming sprints. Better yet - all engineers are responsible for the generation of these ideas, so the sense of ownership they feel over their idea is huge.
In our next post, we’ll discuss how we split up some shared PM responsibilities among team members and got the day-to-day work of executing and strategy development rolling among the team!