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

There’s comfort in thinking that one day the team would have some time on their hands, things won’t to be so hectic, and we will get to fix this annoying issue that is just not the highest priority right now.

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

A critical element in it is being able to articulate to ourselves why we made the decision to throw the bug into the black hole of NEVER NEVER NEVER. By doing so, we make it possible to better communicate it to our own team (Customer Success, Support, Sales…). And to partners. And clients.

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?

Most of us work for businesses. No one expects us to not have business-based priorities. I don’t expect this from other businesses where I am the client.

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

About the same time that we adopted this approach to bugs, we made a bunch of other changes that, as I see it, come from the same place of seeking more transparency.

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?

For example, our Idea Box management process includes a KPI for “Zero Unanswered Ideas”, which means we aspire to answer every single idea in under a week, and that we have a process in place to assure that.

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

It’s a painful thing about Product Management and Engineering. As much as we want everything, we have to face reality: we can’t physically implement the inspiring list of amazing ideas at its entirety. We can’t fix this horrible list of embarrassing bugs at its entirety.

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?