About · Posts · Categories · Projects · Mailing List

Product discussions can be ambiguous - especially when discussing a bug or new feature. The discussion can quickly deviate to edge cases that become the conversations focus. Instead of striving to find the best solution for the known problem, "what ifs" dominate the discussion.

What if the user does this, how will our solution hold?

These questions put the group into an unproductive and awkward state. Feelings get hurt and morale destroyed as the group debates inconclusive questions. It's like debating whether green is a better color than blue. Valid arguments can be made for both, how do you pick one? Then someone adds purple to the mix and the group falls deeper into the endless debate spiral.

The group should have one person with a comprehensive understanding of the issue (bug, feature) being discussed. This person is the mediator.

The mediator in product issue discussions must know how the product works. Not at a code level, but at a practical level. The mediator can confidently answer how the product behaves when a user does X or Y action. The goal is to get the group to a decision. The mediator should not abuse their power by pushing their agenda. Instate a culture where the best idea wins. Guide the group to find that idea.

Knowing how the product works provides the mediator with the antidote for edge cases: the work around. Edge cases can destroy momentum as a variety of resources (developers, operations, QAs, etc.) are pulled in to create a solution for a problem that a small percentage of users might experience. The work around saves time and frees up resources to work on higher value tasks. It also provides  a solution if the edge case happens. But to know the work around, the mediator must know how the product works.

The responsibility of knowing how the product works falls on the Product Manager. Knowing what happens if I push button X when setting Y is on and how that impacts feature Z. Getting that knowledge requires dedicating time to coming up with test cases, running them, and documenting findings. Such tasks (that do not have a clear owner but are necessary to move the product forward) must be taken by the Product Manager. It's the non-glamorous aspect of a Product Manager's job.

The task of testing your product under specific conditions can be tedious and time consuming. But time must be made for them. Running the test yourself is the only way to truly know how your product works. Tasking a developer with looking at the code is not enough. You are not only pulling them away from other tasks, but they may overlook a particular code block that gets invoked in a particular case you did not explicitly state.

As a Product Manager, three elements comprise your responsibility of knowing how the product works: curiosity, effort, and time. Be curious, come up with questions on what happens if I do X, Y, or Z. Put in the effort to run tests yourself. Try to "break" the product. Find the delicate balance between delegating tasks and doing the things no one else will do. And although you can't make more time, you should allocate time so that you learn how the product works.

If you don't do it, who else will?