What do Developers want from a Product Manager?

I recently had the pleasure of being a speaker alongside three other awesome developers on a ProductTank panel in Brighton. The theme for the evening was “How can a Product Manager help their developer team be more effective”, as you can imagine, we all had a lot to say!

On the panel was myself (a UX Developer here at ProdPad), Dan Pickford, Head of Dev at 15Gifts, Martyn Osborne, Technical Lead at 15Below and Eilidh Hendry, a Full Stack Dev from TrustedHousesitters.

I’m going to revisit some of the questions and my answers, and touch on the opinions of the other developers on the panel. My aim is that more product managers should better understand what’s important to developers, and maybe this will even help you to improve your team relationships 🙂

Initial Q and As

Q: Many product managers talk about the need to be close to users, and to understand user problems clearly. What techniques work best to convey this key information to you?

A: I’m lucky enough to have direct contact with our amazing users through our Slack community. If users have a problem, they generally tell us. When we have a new feature we want to test, we’ll ask our community if they want to be beta testers then once I’ve prototyped something our UX designer will run them through a series of user tests. The feedback we get from our users is essential for both iterating and even sometimes deciding if we should scrap a feature idea completely!

Q: Have you seen benefits from developers engaging directly with users? How should this be managed?

A: Sure, it has a direct impact on our feature prototyping, but it can also help when debugging a particular difficult issue. I know some companies aren’t keen on their developers having direct contact with customers, but for us at ProdPad it’s invaluable. It’s worth discussing the benefits you think your team and company could gain from talking directly with your everyday users.

Panel: As a UX developer, I’m quite involved with our users because it’s relevant to my role, but we were all a little divided on this one. Being “shielded” from customers was more important for some of the other dev’s productivity and sanity! I know not every developer feels comfortable talking to customers, so don’t go throwing your developers into direct customer contact without asking first.

Q: At what stage should developers be brought into ideation?

A: All developers should be involved from the beginning of ideation if you want them to feel valued! We play the Product Tree game at ProdPad, where the whole team writes down everything they feel is important to make our app a successful and engaging product. Together we place them on the tree with the idea that roots are the infrastructure, and the trunk and branches are suggestions of ideas/features that we could work on soon, right up to the tree tops which are more future features. When I get to work on a feature that I had personally suggested or contributed to, I feel like I am directly improving the product and am genuinely excited to work on it.

Panel: The others had similar processes to the Product Tree game but we all agreed that giving your developers a voice makes them feel more valued (which seemed to surprise a few people in the audience!). This is an invaluable feeling for any developer and I would highly recommend doing this for any company.

Q: What role could/should developers play in prioritizing dev work?

A: When I look at bugs (which we track via Trello), I would personally rather have them prioritized for me so that I know what exactly should take priority. When you have lots of bug reports and features coming in and you’re not sure what to work on next, without prioritization the wrong things could end up being built. When a product manager (or the person prioritizing work) doesn’t share their reasons for prioritizing in the way they do, then developers can end up feeling that they’re just churning out work and constantly fighting fires rather than understanding the importance of what they’re working on.

Panel: We all talked about the need for complete (as possible) functional specifications and documentation. It’s hard to get the balance of how much information should be included as documentation can date quickly, but I’m of the opinion that the more detailed a specification is, the better your development process will be. By having a definitive spec, there will be less ambiguity and misunderstanding around how something should work, preventing in less time spent at the QA stage, as well as that dreaded scope creep.

Q: How would you like to see the overlap between design and development managed?

A: When I worked for an agency, we would sometimes use freelance designers and their initial designs weren’t always built in a way they envisaged. This was down to a number of reasons – including designs being handed over without interaction specs or something being designed that was technically impossible. Because the designer wasn’t involved in the development process they weren’t there to work with developers to answer questions or work on technical restraints with them. Sometimes the build phase can be beneficial for tweaking designs/UX, so things work better than originally designed.

Panel: There was a complete split here. Some agreed about working directly with a designer, but others felt they just wanted to be left to build something that was fully specced out. But unless the work handed over includes a full spec, you could end up with a bit of a mish mash.

Q: How do you approach testing? What should be done by you / your peers / separate QA specialists? Do you get enough info on how testing is being done and who by?

A: Testing phases and bug fixing can be one of the most frustrating things for a developer (we all nod). It’s so important to have a set of criteria and process when logging bug reports. If we can’t replicate something, it’s very difficult to fix it! Verify the bug first and add information such as steps to replicate (arguably the most important), the user’s environment, screenshots etc. These are all helpful, and I urge you to please make sure this information is supplied to your developer before asking them to work on a bug. I promise you it will improve your relationship with any developer, they won’t have to spend time going back and forth for more information or waste time trying to replicate something that may even be reported incorrectly.

Panel: We all agreed that bug testing / QA process can be one of the most exasperating parts of our jobs. How you report a bug is vital, it’s often distracting and unproductive to have to developer constantly switching context, so this is where prioritization is important.
It’s also worth keeping in mind that while other colleagues may be recognized for the great things they do, developers are more often than not recognized when there’s an issue with some code rather than the work that goes into making something a seamless experience.

If you make one change, remember to thank your developers!

Q: How much does post-launch feedback matter to you? How does knowing (or not knowing) the impact of your work affect you?

A: I want to hear that people love what we build, but I also want to hear when they don’t. If you don’t have a good relationship with your customers, it could negatively affect your product. If you’re just churning out features, not knowing if what you’re building is any use, how can you justify what to build next. At ProdPad, our roadmap is a mixture based on our product tree sessions, our users’ feedback and business decisions, and not just because our CEO says so!

Q: Developers need solid periods of work to solve complex problems – but the rise of electronic interruptions (Slack messages, browser push notifications etc.) doesn’t help. What tips can you share that might help your Product person work better with your periods of focus?

A: If my headphones are on – I am generally focused and don’t want to be interrupted if it’s not important. You’re likely to be greeted with a grumpy developer if you’re constantly breaking their “flow”. If developers have the option to work from home when they need to get their head down that’s great, if not, being able to set themselves as busy on Slack or turn off email notifications for a couple of hours will help. But you need to make sure all team members respect the “headphones on” or “away from Slack” approach..

Panel: We all felt that solid blocks of time spent coding a particular thing was much more productive than lots of little pieces of work.

While you don’t want a developer to feel like they can’t concentrate on a complex piece of code, you also don’t want a frustrated PM to feel they can’t talk to a developer. Instead of asking lots of questions throughout the day, try and ask them in groups of questions, e.g. in a morning daily stand up, late afternoon or a single email. I also always appreciate a bulleted email rather than a rambling of paragraphs 😉

A few audience questions…

Q: As a PM, how do I treat my dev team without being condescending. I use stickers but is this silly?

A: I personally love stickers, so this wouldn’t be a problem for me! Stickers aside, I recall a time at my previous company when I’d been plugged in and coding for four hours and needed a breather so went to spend five minutes googling cat videos (as you do). I noticed my PM was hovering. He instantly questioned me, asking why I was looking at cat videos and if I’d completed something yet. Needless to say it was really frustrating for me, because I often find that tiny break helps me to clear my mind and perhaps think of a better way to implement something. Sometimes we just need to unwind for five minutes when switching between code as it’s hard to get your mind from one code base to another!

Q: How do you cope with deadlines?

A: I personally work better when I have a deadline to aim for. At ProdPad, while we don’t have dates on our roadmap, we do try to release twice a week. This continuous deployment approach gives us something to aim for and helps to keep focus.

Q: How do I talk to my developers?

A: This made me laugh, but my answer was just like you talk to anyone else!

Aftermath

At the end of the session, several people came up to us individually to ask more one on one questions and overall I think the panel topic was great, everyone, not just PMs, seemed to get a lot out of it.

In summary, I think there are some small things you can tweak to improve your product manager and developer work relationship including:

1. Listen to your developer’s ideas and include them where possible. Even if it’s just playing the Product Tree game or similar ideation approaches. You could get some great suggestions.
2. Appreciate and work around the fact that developers need solid blocks of time to focus on work. Encourage a work from home day (where possible) or use a temporary busy on Slack /offline approach.
3. Most of all, say thank you to your developers! They like to feel appreciated too. <3

Watch the AMA we hosted with our Dev team