The Sweet Spot
On software development, engineering leadership, machine learning and all things shiny.

PM-less Engineering Teams: Part 2 - The Idea Backlog

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 Part 1, 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!

Getting an idea out there: from execution to launch

The ideas that get their wings as features oftentimes are:

  • Defined well enough so that they are actionable to one or two weeks’ of effort.
  • Backed by clear metrics (or are designed with the right data instrumentation in mind to be able to retrieve clear metrics)
  • Launchable easily with minimal dependencies

This usually means that the kinds of ideas that get wings are quick tests - for example, we want to test the listing on the App Store. Or we want to test a quick JSON-LD rich snippet change on a web page that might cause our Google search index rank to rise. Or we deploy an alpha prototype to a small group of trusted prerelease customers.

Measuring success

And finally, the hallmark of an idea is that there are clear metrics for success - or failure. From this, we take a page from the playbook of the Lean Startup manual. If it doesn’t work - roll it back. Learn quickly. Talk to customers, even, if you can.

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 Part 3, 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!