Product management · Product Development

Productive vs. tension-inducing collaboration?


June 19th, 2015

Creative work is undoubtedly going to produce tension among team members. It’s a product manager’s job to help make sure this tension remains healthy and productive (aka about the product) and doesn’t get personal. Where is the line between productive and “too far” when it comes to creative tension? And what are some best practices to ensure this line isn’t crossed?

Chris Carruth VP/Director. Strategy | Business Development | Operations | Product | Solutions

June 19th, 2015

Another very interesting topic. The reality is that creative tension will only be a problem if the basis for decision making is not defined upfront. For example, is engineering driving the bus or is marketing or is product. Everyone will undoubtedly "be on board" in the beginning but the moment disagreements arrive the real game begins. Even if you do the "right things" in terms of using research, and I mean good, solid, clean, data (primary and secondary) you will undoubtedly have those that believe they know the market better.

So upfront define the basis for decision making, including who has final say, and for those really tense moments an escalation path and the circumstances it will be used. I have seen, more than once, where very, very good data is nullified by sr. mgmt based on nothing other than just sheer unwillingness to understand the data. In both cases the ventures collapsed because the products produced had zero market appeal. Shocker. 

Do you define what is appealing and the likelihood to purchase or does the market? Lastly I would also throw in the matter of whose money is it? if you are funding the effort personally then by all means do what you want. If you have others money involved then you are obligated to reduce the risk and maximize the chance of success, no?


Erik Molander Executive in Residence at ITEC at Boston University

June 19th, 2015

Hi David,
Here are several things that have worked for us.  Begin by having the entire team evaluated on the effectiveness of the product in the market.  if the engineers are evaluated solely on cost and delivery date it can often undermine the effectiveness of the design.  Follow it with rigorous data collection from customers instead of opinions (this includes your own opinion).  
Sometimes, i've been the source of the team's problem.  I hate to admit it, but if I haven't spent enough time crafting the creative brief, the team struggles.  The more precision and insight I put into the creative brief, the less conflict the team has.

Mike Whitfield Sr. Software Engineer, EPAM, Google

June 19th, 2015

I hear a passive communication on an active situation.  What's going on, buddy?

What are you building, etc?  PM me.

Head butting is good my Cisco architect used to say.  Good shit happens like that.  Long-term, it's bad.  As a manager you reassign people.  If you're the grunt, you need to get your fix outside work.  I used to moonlight and then slack off during work hours.

You're a ref in a UFC fight.  Break it up before it gets nasty, but allow a great show to go on because that audience is your product.  If you're a fighter, fight hard and get nasty if you have to since it's management's job to ref it.

It's friday, forget about work.

Sam McAfee Building better technology leaders and teams

June 20th, 2015

Great thoughts so far. I've found a few specific patterns that matter most for the teams that I have worked with:
  1. Outcomes over Outputs. It is important that the team have a shared understanding of what the overall business goals are, and how those will be measured. Do not silo evaluation criteria, as I think Erik pointed out above. Everyone needs to be focused on the business goals, and contributing their specialty to get it done. Inside areas of specialization, you can have strong leaders how define excellence for engineering, design, marketing, sales, etc. But overall they should all be aligned at the company level. 
  2. Cross-functional, "T-shaped" people. This is the concept that people are broad in many areas and deep in one or two. They should be able to work on their main area, but also jump to an adjacent part of the workflow if help is needed. Cross-functional pairing is also really crucial, particularly between design and engineering. The fewer official "handoffs" between roles the better.
  3. Timing and cadence. There needs to be a process for regular check-ins and feedback. Daily stand-ups, weekly planning meetings, and monthly business reviews have worked for me in the past, but you can arrange it however you need to for your team.
  4. Finally, I would add the retrospectives are an extremely useful, and often overlooked practice, usually because the team lacks a good facilitator who can keep things focused and professional. If you're not doing them, I would start right away. People need a chance to give feedback on their own process of working together, learn to take constructive feedback, and collaboratively work to improve "relations" between specialists.

Robert Rebholz Product management and marketing leadership: innovation, strategy, acquisition, and growth.

June 20th, 2015

Good points all around. "Data" is interesting in that if everyone doesn't have it in equal measure, it can become a club used by the haves to beat up the have nots. 

Further, "data" is hard to separate from the stories we tell ourselves about it. Example: "conversion is higher when traffic comes from xxx source" -- fact. "People from xxx source are making more informed decisions, or are further down the funnel, or have dust bunnies for brains" -- fictions, faces in the clouds. Really smart and confident people get away with this all the time. Beginner's mind is better.

Also, you might consider a de Bono style "Six Hats" methodology. I've had some good experience using it to manage nay sayers, ax grinders, and true believers.