Dear Product Managers: Share the song, not the clapping

Alex Alexakis
5 min readFeb 15, 2017

--

Imagine for a second that you are a teacher in a kindergarten for gifted children, kids that are way smarter than average. Let’s say that your goal for the day is to make these kids clap all together following the rhythm of a popular song. This shouldn’t be too hard, right?

So, you start clapping, while following the rhythm of the song that you sing in your head. You ask the kids to follow. The result is disappointing. A few of them follow the pattern correctly, others are close, but the majority is far from decent. You are in a class of gifted children and you would expect something better than this.

You ask the kids to try once again. This time the result is slightly better, but still very disappointing. Realising your disappointment, one of the smart kids recommends that you take off your smartphone, and play the song you have in your mind on YouTube. You type “Here Comes the Bride”, and you hit Play. Surprise, surprise, all the kids start clapping in harmony, while following the rhythm of the song. Job done!

Now, imagine you are a Product Manager working with engineers and designers. On your first day at work, they told you that you are the owner of the products your team is building, that the quality of your job is estimated based on the output of your team, and by the way you have also read online that as a Product Manager, you are the CEO of the product.

So, you start investigating the problem your team is trying to solve with this new feature or product, you design a solution to this problem, and you deliver a set of requirements to the team (the “what” the team should build). The mockups, the user stories, the product requirements document, everything! You break these into smaller chunks of work that can be delivered incrementally (the “agile” way), and the team starts building what you asked for. You also have a strong opinion about all things design and engineering and you feel empowered and valuable.

This could work, but here’s another viewpoint by James Everingham, the Head of Engineering at Instagram:

“When I finally loosened my grip and let things go, I realised that my ideas were actually only right half of the time. The other half, my team’s ideas were far better than mine. I had been an idiot for 10 years of my career.”

Hence, according to the Head of Engineering at Instagram, does this mean that your team’s efficiency and creativity is at 50% due to the way you, as the Product Manager, take decisions daily about what your team should build and in what way? And if this is true and you should not focus on the output, assuming that half of the times you are wrong, what should you focus on then?

Alex Diaz, who has worked in Product roles for Yahoo and Google, has an interesting approach:

“Product Managers are not making the product, but rather the thing that makes the product.”

Therefore, taking the analogy of the product team as a machine, your focus should be on the input and the process, rather than the output. But, what does this mean for a Product Manager?

  • Bring the vision, goal setting and context to empower great decisions, set what success looks like.
  • Focus on posing the right questions rather than dictating detailed answers.
  • Set the context of the problem: market landscape, competition, examples from other domains, potential workarounds used by people currently having this problem, etc.
  • List out your non-goals: the problems you are not trying to solve. This is what your product is not meant to do.
  • Help the team wear the customer’s shoes: user interviews, user studies, customer feedback, user metrics, etc.
  • Assist the team to translate the input into the right output through a group of processes.

Hence, as a Product Manager, you set the tone for a collaborative product-building process inside the team by empowering your team to create the right output, based on the input you provide and establishing suitable processes in place.

As Marty Cagan, the author of “Inspired: How To Create Products Customers Love” points out:

“Products are defined and designed collaboratively, rather than sequentially. They have finally moved beyond the old model where a product manager defines requirements, a designer designs a solution that delivers on those requirements, and then engineering implements those requirements, with each person living with the constraints and decisions of the ones that preceded. In strong teams, product, design and engineering work side-by-side, in a give and take, to come up with technology-powered solutions that our customers love, and that work for our business.”

This notion seems to make sense if you think about the personality the people you work with inside a product team usually demonstrate:

  • Problem solvers, not requirements builders.
  • Millenials that want to have an impact on what they are building, much more than the previous generations did.
  • Creative human beings.

Nevertheless, in order to accept that the output is designed and built collaboratively, you need to first and foremost trust your team. The following are the words of Tom Preston-Werner, regarding the work he did in the past as freelancer:

“This client could have just as easily given me the task at the beginning of the day, gone and run the business, and come back in 6 hours whereupon I would have created better designs twice as fast as if he were treating me like a robot that converted his speech into Photoshop manipulations. By treating me this way, he was marginalising my design skills and wasting both money and talent.”

As you probably know, Tom then went on and created Github.

Therefore, what all these people suggest is obviously not handing your Product Manager’s hat to someone else, but rather a side-by-side collaboration, where the output is not controlled by one person; it is designed collaboratively, after feeding the team with the right input and fostering a sense of creativity and problem-solving through the appropriate processes.

Hence, instead of sharing the clapping with your engineers and designers, why don’t you try sharing the song with them, while understanding that all paths to success are still possible, including those you haven’t thought of yourself?

--

--