As a software product manager, I spend a lot of time working with my development team in making sure that they are well aware of the customer pain points and the requirements of the solution we are trying to build. I have heard from time to time from my colleagues and also from software product managers in the community as to how development team does whatever they want without paying too much attention to the market requirements. While it is true that development does embark on some “skunk-work” or their “sandbox” projects, I have been lucky enough to have my product development teams more in tune with the market research my product management teams have done.
Here are some tips on how you can make sure your development team stays tuned in to the market needs and builds very simple, easy to use products that will delight your customers.
1) Involve the development team early – One of the common complaints I have heard from my developer friends is how their product managers do not get them the actionable information they need about customer needs. Go figure! We as software product managers think that development teams want to do whatever they want and the developers are complaining that we are not getting them the information they need. Guess how developers find solace? They start writing code. When they have written enough code to solve the customer problem they perceived to be right, you as a software product manager stepping in with market information is of no use. Here is one of my common mantras to anyone who cares to listen – “Developer resistance to a software product manager is directly proportional to the number of lines of code written.” More code they have written, less chance you have to influence them and get anything changed. And guess what ships – what was written.
So how can you mitigate this problem? Involve the development team early. Trust me there is no time called “too early” to involve your development team. Involve them even when things are fuzzy so that they can start asking you all the questions to which you have to find answers. Make it a collaborative process. Set expectations that you do not have all the answers yet. This puts their skin in the game – it builds a sense of ownership. Product ownership can do wonders. Before you realize, everyone is rowing in the same direction and everyone wants to win by building the right thing. I am yet to meet a developer who wants to create a product that will fail. Yes, there are developers who want to build the pie in the sky solution that only they will use, but you are bound to find such people in every profession including product management. There is nothing you can do to prevent the occasional “skunk work” or “sandbox” projects – but if this is the norm at the place you work, it can only be one of two things – you are not doing your job as a software product manager or you are working for the wrong company. This is because with such state of affairs, market failure can only be a corner away.
2) Be a good strategist, but more importantly be an excellent tactician – Set a good product strategy that will help your company achieve business success. But make sure you remain involved in the execution of your development process. You as a software product manager need to know exactly where the development team stands on your product on a daily basis. You need to know of every bottleneck or hurdle faced by your development team and your job should be to find a way to resolve these issues. This in my perspective is one of the greatest reasons why Agile product development methodology is so successful – every team member is on the same page every day and there are no unpleasant surprises.
Being involved at the execution level will help you build a great rapport with your development team – it has for me. It sends the message that you care about the success of the product and that you are in the trenches with the development team.
3) Be the team’s cheer leader – Being a developer is not a fun job – it is a very stressful job. I won’t be able to do it. Every product development cycle has its ups and downs. Be the cheer leader for your team during these ups and downs. This may mean that you get your team the beer of the week from the nearest micro brewery or you take them out for lunch or dinner once a quarter. Always keep the human perspective – it is not all about work.
Take every opportunity to make sure you stand up for your development team. If your executive management team wants you to give them a briefing on the progress of the development effort, team up with your development lead to do the briefing. If you are going on a customer visit or going to be on a conference call with your customers, invite your development team to accompany you or listen in if appropriate. More you bring them up to speed on the customer’s needs, less battles you have to fight on the problems the product has to solve.
Don’t try to hog the limelight – it is not all about you. It is all about the team. After all your customer really does not care who is getting the internal limelight or who came up with the solution. The only yardstick for the customer is if your company can solve his painpoint with a very elegant solution.
Thoughts? What are your key learnings on how best to work with your development teams?
If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader.
Image: Courtesy of Bealonghorn.utexas.edu
Software Product Manager by Gopal Shenoy 
Very nice tips including the comments posted from the developer’s shoes. I have taken the role of Software Product Manager recently and I am experiencing most of the issues discussed here.
nice tips
Interesting post. Let me offer some constructive criticism from a developers perspective…
“Guess how developers find solace? They start writing code.”
Developers will often start projects *on time* because they understand that if they don’t they will be the only ones held to the grindstone to make the deadline no matter who held up the process. Let’s be honest – product managers only have control of the deliverable date…sometimes. If a PM cannot get the “needed information” to the developer in time…then yes, a developer will often start and try to solve the issue as he/she understands the problem.
“Developer resistance to a software product manager is directly proportional to the number of lines of code written.”
I think this should be reworded to “Developer resistance to a software product manager is inversely proportional to the amount of time before the deadline” Time goes down, resistance goes up. It’s all about that “needed information”. If a PM continually delivers last minute information and the developer feels that the PM is putting all the responsibility on the shoulders of the developer in making the deadline…the developer will not be receptive and eventually will resent the PM for it. PM Credibility is important here…the PMs credibility will erode with each occurrence.
“3 ways software product managers can work effectively with development teams”
Define how to measure success of the project. If a developer gets frazzled meeting a deadline – and even worse under the stress points I’ve listed above – it’s very critical that a PM can measure the success of that project. If a method was not defined, developers will come up with one. They have the data at their fingertips and are generally very good at analyzing the usage of said new project, or change in data since release of said project. If it wasn’t a success – then say it wasn’t and be ready to understand why.
Another – Don’t claim victory with a project when it very clearly to a developer is not a victory. The PM delivered the ‘needed information’ at the last second which the developer implemented by putting in 48 hours during the next 24…maybe bled over the deadline by a day or two. Development is “noted” for not having met the deadline. Several weeks later the PM claims victory. The developer pulls some stats and sees that clearly all the rush, effort and carpal-tunnel were not worth it.
Another – Claim accountability. PMs should claim accountability with delivery of late information. Definitely they should “Take every opportunity to make sure [they] stand up for [the] development team” and tell Executives the deadline was missed because the PM delivered needed information late in the game – for example.
“Being a developer is not a fun job – it is a very stressful job.”
A large majority of developers enjoy development. A minute fraction are willingly masochistic. They will resist when they see the project headed in a direction that will ultimately *appear* to the organization as if they did not execute given everything they needed in a timely fashion.
Kudos to you for attempting to address a very common obstacle in product development. Hopefully my suggestions will offer more information to solving the challenges you’ve mentioned.
I’ve always had great relationships with my development partners because I view our relationship as critical. We speak daily and have regularly scheduled weekly meetings to stay in close contact about upcoming as well as current projects. I discuss projects with my developers very early in the conceptual stage, so that they can have a say in how we move forward, and they have already given some thought about how to code the work once the requirements are completed.
I really hope the PMs can do it. I am in the development team. We are so frustrated sometime while PMs just pass the pressure to the team and keep all the honors for their own.
Good tips! “It’s not about me” is something we as PMs should say to ourselves every morning when we wake up 🙂
Good insights. When I’ve been in the role of a product manager, I’ve had similar experiences in working with the development teams. We used paper prototyping to hash out designs and requirements with customers. It gave everyone a sense of ownership in the process and product.