Seeking Transparency in Product Management

From Zero Bug Policy to Addressing Product Ideas

Some years ago we adopted Zero Bug Policy. The idea behind Zero Bug Policy is eliminating the typical unmanageable bug backlog every product secretly carries. Once any bug is reported, we decide if we fix it immediately (in the current or coming development cycle), or not. If we decide not to fix it immediately, the bug goes out of our backlog. The decision is archived, but the bug disappears.

We are basically saying: “We are never going to fix this”.

Never is a scary word

But if cornered, we would probably admit — it is never going to happen. We will always be busy. We will always have higher priorities. Whatever is the reason we are not fixing it this very minute (or month) will stay there until the end of time.

And if from some reason the same issue comes biting us back at some later time, the only reason to fix it then would be if something in our priorities has changed since. And when this happens, we will choose to fix it right away.

Zero Bug Policy is about being honest with ourselves, and it’s a basis for being transparent with everyone else

And yes, we make mistakes. But making clear decisions makes it more likely that we have to confront and debrief these mistakes.

Is it OK to say no?

The only expectation is for transparent communication. I am usually perfectly OK if a vendor says “You are the only one using this capability, we cannot invest in it”. If it’s a show stopper — I will escalate it. Otherwise — I will not wait for it. I think it’s much better than not getting an answer, and having to guess.

Putting things in endless backlogs means keeping things vague. And in a way — dishonest. Nothing is easier than saying “it’s in the backlog” (“…of 850 things that we know we don’t stand a chance to get to”). But this leads to unmanageable backlogs and poor expectation management.

From Zero Bug Policy To Zero Unanswered Ideas

One of the important changes was managing all internal and external product feedback through our public idea box. I presented our Idea management concepts in a meetup last week. Dan Michlin, our Director of Enterprise Product Management, wrote a comprehensive post about it back in June.

Our idea box follows similar principals:

  • Keeping the ideas backlog continuously groomed and in a manageable size
  • Being as transparent as possible about what has a chance of getting in the backlog, and what doesn’t align with our roadmap and strategy

Isn’t that quite similar to Zero Bug Policy?

We are obviously big fans of empty sets.. but also of mechanisms that force us to articulate our priorities out loud. Internally and externally.

Conclusion

But it’s also the painful thing about life — we don’t get to do everything, and we have to accept that. I think we can still feel good about it if we can explain our ever-so-subjective choices and stand behind them.

Putting energy into making sure we feel right with how we utilize our limited Product Management and Engineering resources, and transparently communicating it, may be a better use of it than maintaining really long backlogs.

What do you think? What are your practices for encouraging transparency in Product Management?

Co-founder and CEO @Chiefyteam @MayaBerLerner | chiefyteam.com