Archivos de Categoría: English

Gerald Weinberg in his book Quality Software Management, long before that Product Managers came around, explained an anecdote on the way a number of programmers he interviewed used to set the priorities for their work: one programmer declared: “This customer is an SOB. If I solve this problem, he’ll stop calling me”. Another programmer in the same organization affirmed: “I’m solving this problem because the customer is so nice to me. The ones who get abusive on the phone, got to the bottom of my stack”.

A third programmer explained: “I do the customer work last. The jobs I have to do for the development staff come first, partly because it’s more important work, but mostly because they’re right across the hall”.

We, as Product Owners or Product Managers, are supposed to make decisions based on value, but value is usually a rather subjective term. Aren’t we really being as unpredictable as those programmers?

Many teams are constantly struggling to keep a clean and focused 15 minute daily stand-up meeting, but we cannot help asking our questions to the tech lead or senior members when an issue has been bugging us for the whole day. Others just talk too much and derail the conversation on important topics.

In such cases, you just can say “Greg, let’s allow everyone to explain their hurdles and complete the daily stand-up. We can save that for the sixteenth minute item”. After everyone talked about their impediments, we open the discussion and let them propose any matter they wanted to talk about. Make sure everyone is free to leave if the theme to be discussed is too specific to the work of other colleagues.

The Bystander effect or Bystander apathy is a well known social psychological theory that indicates that people are less likely to intervene in a crime or in a crisis if there are more witnesses of the crime. All of them seem to be thinking: “Someone else will call the police, for sure”, but nobody does.

This also applies to product management. When we trust only in documentation and processes, we all think someone else is having a look and will take charge of the hurdle, but nobody does. Meanwhile the issue grows endlessly. Focus should be on our product and not in the process (better if we got one, but it is not our main goal).

Tasks should always have someone assigned who will feel in charge of their delivery and have a clear deadline to avoid the blurring of the responsibility. Besides that, the Product Owner or Product Manager will be concerned of any difficulty we might be facing. The product is their ultimate duty.

Mercedes Benz made some surveys among their potential customers and they said they wanted smaller cars with less gas consumption per mile. They created the Smart. Meanwhile, cities were crowded with 4×4 vehicles as big as an airplane.

You don’t know what people want. They don’t know it either. You think you know but you don’t have a clue (me neither). Choose a reasonable option, test it, fail soon and fail cheaply. Learn from it and try a different thing. Keep as many options open as a small budget allows you.

But above all, avoid the Sunk Cost fallacy and insisting on a failure as “market wasn’t ready”. Nobody likes admitting they were totally wrong, but there won’t be more opportunities if you sink with the ship (or the department, the project, the product).