During the last months I’ve had some personal issues that required me to take some time of work and dedicate myself to my family. Things are a lot better now and I’m more or less back to normal, but sometimes my availability is unexpectedly lower. As I am a product manager, this has been a challenge for the team I’m working with.
For example, a while ago I designed a new feature for our product. This feature required both UX and functionality changes, and I had already created a deck that gave an overview of them. But then I was unavailable for some time and couldn’t discuss these changes with them, and when I came back the developers told me that they had finished the feature (cool!) but when they showed it to me, the buttons were in a completely different place than where I wanted. My first (internal) reaction was “F$^%@ developers! Couldn’t they read the spec? Why didn’t they call me??? (stupid question – I would not have answered)”. Thankfully I have learned to keep my first reaction to myself, breath, let it sink, and then react.
Was the different location that bad? Not really, it was not the best place to put it, but overall it was OK. Would customers really mind if we moved the buttons in the near future to the place I wanted? Yes, they would mind a bit. But after a while they would get used to their new location.
But what was the other possibility? The developers would have waited for me to come back, the feature would have been delayed, we would not have gotten good customer feedback that we are getting. But the buttons would be in the right place.
What would you chose? In retrospect, I think there is no question that delivering the feature sooner with the buttons in the “wrong place” is ten times better than delivering the feature weeks later. Or even more. Development (and product) agility is based on customer feedback, so the sooner we get feedback the better we can react to this feedback, and by this we are creating a better product.
And for a product manager, this means that you sometimes have to let go. If the development team is always waiting for your input, you are blocking them. They must be able to make decisions by themselves when you are not around. Maybe you are on a business trip, maybe you are on vacation, or maybe handling some personal issues. So if something comes up and you are not around, they should be able to go on. Maybe they won’t take the best decision, but most times this is much better than just sitting and waiting.
Update – One of my readers told me that it reads from this post that developers should get full specs and then develop based on them. Au Contraire! the development process is done together all of the team, product managers and developers. And when the product manager is not available, this should not block the developers at all, because if we are running a good team, they will have a good idea of what they must do, and if they make mistakes, these will be relatively small and easy to fix.
* This post was inspired by the song Let It Go which I LOVE, and this Reversim podcast episode (hebrew) where Lior talks about how business trips affect his team’s rhythm.