Top 5 Ways Product Managers can help Developer’s Love them
It all comes down to influence.
The number one skill a product manager needs, above all else, is influence. Without influence, no matter how well you do your market analysis, you will utterly fail to get that product built. There are many occupations that talent can out-weigh the preverbal ‘jackass’ diva employee, especially if they can isolate you. I’ve seen a couple of them. But never have I met a kickass, jackass Product Manager (please correct me if I’m wrong). This case is simply true because those who cannot influence their team towards a common mission and goal in an ultra-positive way.
The good news is, everyone can learn the skills required to have influence. Granted, for some it will be harder than others. You will need a lot of humility and patience to grow people skills. But if you truly want to be a leader and influence people without outright authority (read fear), you will need to learn to be a humble, transparent, useful and above all, a lovable human being.
The following are the top 5 qualities I believe will get you on your way to have a development team that respects and loves you as their product manager.
I’ve heard pros and cons on both sides of the debate whether or not Product Managers should be technical enough to write code. However, let’s be clear what the product manager’s real purpose is. The product manager’s job is to determine what to build (product/market fit) and to get it built (design/development/launch).
My belief is simple. Product managers need to be involved in the development process, but they also need to know their place.
As a Product Manager you should:
- Listen to the development team
- Get the code on your computer
- Learn to read and get the gist of the code
- Walk through code snippets with developers as often as they let you (don’t annoy them)
- Follow the check-in repository and comments
- Be humble in knowing it’s the developer’s role to create the software, not yours. i.e. you are not the developer, don’t play one (even if you used to be one).
- Trust the development team and their feedback, time estimations, etc… (If you cannot trust your developers, either you have fundamental issues, or your Dev team has fundamental issues, but someone needs to go.)
- Solicit feedback on the entire product (not just development issues — i.e. business and design issues) and sincerely listen to the feedback
Developer’s want to be told what to build by you, leaving the ‘how’ up to them. The only appropriate time to provide thoughts on how is when it is a requirement specific to the product.
While it’s the developer’s job to build the software, it’s the product manager’s job to tell them what to build. Sometimes there might be a middle person between the product manager that helps in this process, who is often called a product owner. There will always be requirements discovered throughout the development process that were not anticipated, but this can be greatly reduced by thinking out and creating exceptions, edge-cases, trade-offs, etc… that the developer might not be aware of. All of these details create the ‘bowling lane bumpers’ so to speak that keep the development on-track. Development, when given details, build what you request, when details lack, their creativity ensues, and you might not like what you get back. Thus, working with development, being near them and helping them through the development process not only helps you understand what details they are looking for, but helps them ask questions keeping them on target. This is one of the reasons I highly encourage the whole product team, including development, sitting together.
Details I’ve given as a product manager:
- User Stories
- Acceptance criteria
- Documentation
While the previous point was about giving them details and helping them focus, here I’m almost saying the opposite. I want the development team to get the big picture, and a lot of product managers neglect to do this. Everyone on the product needs to understand the big picture, so that the micro-focused decisions will always be in alignment with the macro purposes. It is often the case that context can give the development team insights not only on what to build, but how to build it keeping in mind future purposes and goals.
An added benefit is this reveals the decisions the product manager makes are in alignment with the product’s future (assuming they were made correctly), and that the roadmap is truly a plan for the future. If all is done correctly, all of this evidence not only gives the development team confidence that the product manager is doing the right thing, but it also shows them informed, calm and collected, and that the product is under control in the right hands. When the crew sees the ship is going in the right direction, there are no mutinies.
Context resources I’ve given as a product manager:
- Product Map (This is a document I created, See the article I wrote on it here)
- Roadmap
- Stakeholder feedback/interviews
- Personas with ancillary info on how they were created
- User Interviews (video, audio, summaries)
- Asked them to sit-in on user research/usability testing
- User insights and utterances
- Asked them to be part of product meetings
Development does not need to use or go through all of these resources, but making them available goes a long way to the team trusting and loving you.
Let’s be honest. Developer’s, like all people, hate to do some things. It should be the goal of the product manager to remove any hinderances to the development team. This is where you can jump in and help. If there is something that is encumbering the development team, that is out of their job focus, and you can do it, or find someone to do it, do so. Whatever it is, take the pain away from the development team so they can do their job and get it done. Helping the development team helps the product. Be the development team’s advocate. Help them get what they need to get the job done. This is the job of the manager of the product, do what needs to be done to get the product made. If there isn’t an expert for the role, you become the expert. If there is an expert, get that expert.
As a product manager I’ve:
- Acquired tools and resources (books, software, etc…) the development team needed
- Cooked, made or got my team food
- Counseled them on personal matters ( sometimes pain is real pain )
- Cleaned their desk
- Dealt with other departments bugging them
- Edited writings and wrote on their behalf
This is the most important of all steps. I’ve never been a believer that work is all ‘professional’. What I mean by this is that the people you spend the majority of your time with 8+ hrs, 5 days a week, are going to be more than simply professional relationships. They are either going to be your friends, or not your friends. The dynamic you instigate is going to set the tone for the work-place environment. If you want a culture of transparency, and trust where you hear the good and the bad before it impacts you or the product, then you’re going to need to deal with personal relationships. Let’s not forget, developers are not ‘resources.’ They are not ‘assets.’ They are people. Whatever you do, do not dehumanize them or their role. People have good days, and bad days. You too will have good days and bad days. You’re going to have to learn to give and receive grace.
One of the most important skills that a product manager needs to hone is his or her ability to have empathy for their users. More often than not though, we as product managers forget that we need to have empathy for our company and for our team. This empathy will either help the product succeed or fail without it. Sometimes emergencies happen and we need to work extra hard or fast, and whether or not we have displayed empathy beforehand, will be part of the determination on how the team reacts to those emergencies.
As a product manager I have:
- Taken walks with coworkers out of the office to hear their problems with another coworker (not to gossip, but to just be that listening ear, sometimes people just need to vent and let it go)
- Taken the blunt of the frustration towards the customer, so that the developer can vent and feel heard, and the customer can be informed in a better way
- Told coworkers, go home and take the day to rest, or deal with whatever family or other problem you need to deal with
- Taken the team out to celebrate victories, whether small or large, sometimes you need to celebrate!
- Given a motivational talk when the bad news hits, sometimes an emotional reset button needs to be pressed before digging into problems.
- Thrown dinner parties and social events to help the team gel better together outside of work
- Baked cookies and brought them in for people
- Mourn with those who have lost something they loved
- Given free hugs, because sometimes, you just need to be hugged, oh yes, developers too
Being a product manager and running a product team is often described as being the CEO of a product. I couldn’t disagree more. Unlike a CEO, we have no authority. All of the product manager’s power comes through influence. Neither are we the parent of the product. It isn’t our baby. When it comes to the product itself, we are a doctor, prescribing what is best for the health of the product. But when it comes to the product team, I believe we are the mothers. I don’t know about your mother, but the mother’s I know are the framework that holds the house together. The dad might be the authoritarian, but the mother is the nurturer. She holds sway by her influence. The mother’s most powerful and natural gift is that of empathy for her children. And for that empathy she has the devout loyalty of her children. So here the metaphor ends, as developers are not your children, neither are designers, nor anyone else on your team. But like a mother, as a product manager, you need to do the things you need to do, even sacrifice, not only to get the product built, but to make sure everyone gets there successfully with the product, in an emotional healthy state.
It has been my honor all these years to lead developers, whether as their manager, CEO, or now as their product manager. I have learned if I do the above things, giving each developer the respect and dignity of being an intelligent human being, and the trust that they are going to do a great job, that they will in turn, do so while giving me the same respect, trust, and friendship. I hope you are blessed with the same developer relationships that I have had throughout the years.
Mark Stephan is an entrepreneur and product enthusiast.
Starting off as an Archeologist, Mark graduated university with 5 majors and 3 minors, and worked on his masters in History and Archeology. However, taking an abrupt turn, in 1999 he entered into the tech world by working at Trilogy Software in Austin, Texas. After the Dot Com collapse in 2001, Mark moved to Istanbul, Turkey where he taught entrepreneurism to persecuted communities and refugees. He also attended Istanbul University, learned Turkish, and on graduation started his own software company in Istanbul and ran it there for 5 years. In 2008, Mark moved back to Austin, Tx moved his company there as well and ran a consulting company helping start-ups start up. In 2012, Mark closed his consulting company and focused full-time on his new product start-up, Community Raiser, launching a crowdfunding platform for non-profits. In 2015, Mark took a short break from his start-up to work at a human-centered digital product design agency as product manager helping clients build the products of their dreams.
Today, Mark is still very involved in giving back to the community serving refugees and persecuted communities around the world. He is also working on a new product at his start-up Community Raiser, and is about ready to launch a mobile app to build generosity of thought. Afterwards, Mark is intending to work for a yet to be determined product company building the next great thing.
Want to learn more about Mark Stephan?
- Check out his LinkedIn profile.
- Check out my Twitter.
Originally published at medium.com on May 3, 2016.