{"id":5694,"date":"2018-08-15T12:57:05","date_gmt":"2018-08-15T11:57:05","guid":{"rendered":"https:\/\/www.prodpad.com\/?p=5694"},"modified":"2023-05-04T17:16:29","modified_gmt":"2023-05-04T16:16:29","slug":"product-managers-developers","status":"publish","type":"post","link":"https:\/\/www.prodpad.com\/blog\/product-managers-developers\/","title":{"rendered":"What do Developers want from a Product Manager?"},"content":{"rendered":"\n

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 \u201cHow can a Product Manager help their developer team be more effective\u201d, as you can imagine, we all had a lot to say!

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

I\u2019m 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\u2019s important to developers, and maybe this will even help you to improve your team relationships \ud83d\ude42<\/p>\n\n\n

\n
\"The<\/figure>\n<\/div>\n\n\n

Initial Q and As<\/h2>\n\n\n\n

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?<\/h3>\n\n\n\n

A: I\u2019m 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\u2019ll ask our community if they want to be beta testers then once I\u2019ve 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!<\/p>\n\n\n\n

Q: Have you seen benefits from developers engaging directly with users? How should this be managed?<\/h3>\n\n\n\n

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\u2019t keen on their developers having direct contact with customers, but for us at ProdPad it\u2019s invaluable. It\u2019s 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\u2019m quite involved with our users because it\u2019s relevant to my role, but we were all a little divided on this one. Being \u201cshielded\u201d from customers was more important for some of the other dev\u2019s productivity and sanity! I know not every developer feels comfortable talking to customers, so don\u2019t go throwing your developers into direct customer contact without asking first.<\/p>\n\n\n\n

Q: At what stage should developers be brought into ideation?<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

Q: What role could\/should developers play in prioritizing dev work?<\/h3>\n\n\n\n

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\u2019re 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\u2019t share their reasons for prioritizing in the way they do, then developers can end up feeling that they\u2019re just churning out work and constantly fighting fires rather than understanding the importance of what they\u2019re working on.

Panel: We all talked about the need for complete (as possible) functional specifications and documentation. It\u2019s hard to get the balance of how much information should be included as documentation can date quickly, but I\u2019m 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.<\/p>\n\n\n\n

Q: How would you like to see the overlap between design and development managed?<\/h3>\n\n\n\n

A: When I worked for an agency, we would sometimes use freelance designers and their initial designs weren\u2019t 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\u2019t involved in the development process they weren\u2019t 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.<\/p>\n\n\n\n

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?<\/h3>\n\n\n\n

A: Testing phases<\/a> and bug fixing can be one of the most frustrating things for a developer (we all nod). It\u2019s so important to have a set of criteria and process when logging bug reports. If we can\u2019t replicate something, it\u2019s very difficult to fix it! Verify the bug first and add information such as steps to replicate (arguably the most important), the user\u2019s 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\u2019t 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\u2019s often distracting and unproductive to have to developer constantly switching context, so this is where prioritization is important.
It\u2019s 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\u2019s 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!<\/p>\n\n\n\n

\n

Another amazing PM tip from @Eilidh91<\/a> and I – say thank you to your devs #ProductTank<\/a> #productmanagement<\/a><\/p>— Danielle Vautier (@daniellevautier) February 2, 2018<\/a><\/blockquote>