Downloaded 23 times
Uploaded byAtlassian
A PM and a Developer Walk into a Bar
The document provides tips for product managers to get engineers to build what they want in 3 main points: 1. Involve engineers as early as possible to develop a shared understanding of the problem and build relationships. 2. Work asynchronously and use tools like asynchronous messaging to discuss ideas and make decisions without blocking work. 3. Tell stories and provide context about user needs through techniques like customer interviews, but avoid giving too many implementation details, focusing on the what rather than the why.
More Related Content
Similar to A PM and a Developer Walk into a Bar
![Inclusive Architecture - Introducing the PAMstack - [Refactr.tech]](https://cdn.slidesharecdn.com/ss_thumbnails/refactr-190614202717-thumbnail.jpg?width=640&height=640&fit=bounds)
A PM and a Developer Walk into a Bar
- 1. SHERIF MANSOUR •PRODUCT GUY • @SHERIFMANSOUR A PM and a Developer walk into a bar…
- 2. Batman and Robin walkinto a bar…
- 3. Mario and Luigi walkinto a bar…
- 4. Captain America andThe Hulk walk into a bar…
- 5. 3 things you can doto get engineers to build what you want
- 6. #1 remember: yourepresent the customer
- 7. all these customers! relyon you… so don’t screw it up !
- 8. They are not“in the zone”… just pretending
- 9. Make sure theyare clearly aware of your importance. “Interruptions”
- 10. Got their attention? Use motivating one-liners to earn respect
- 11. “Isn’t it justloops and vars?”
- 12. “Yeah… I usedto code…”
- 13. “I thought wehad the worlds best engineering team… that’s what they told me”
- 14. “I’ve seen Googledo it, why can’t we?”
- 15. “Let's take astep back”
- 16. “How do wetake this to the next level?”
- 17. “Maybe you shoulddo some pair programming, that might help”
- 18. “… Let’s dothat in phase two”
- 19. NO! mutual respect? working welltogether?
- 20.
- 21. Our product isan outcome of the people we hire and the decisions they make. KRISTO KÄÄRMANN TRANSFERWISE “ ” http://bit.ly/productequalspeople
- 22. asynchronous (allthethings) Why is thatimportant? * Reality of most PM and dev teams? distributed teams? * Devs preffer to work async * Interruptions? or keeping teams focused? - how can we keep the relationsh whole team not just one PM or one DEV - foster a relationship with the who * This works well for our teams might work well for you
- 23.
- 24. • Ask what’s blocking? •What’s an FYI? • Consider rooms for 1-1s
- 25. • Linking fordetail • Status indicators • Commenting for questions
- 26. • Provide context •Explore and discuss options • Time to think! • Make decisions and track actions
- 27.
- 28. hire for culture, buildrelationship work asynchronously
- 29. #2 involve themlate as late as possible
- 30. </> ideation research definitioncode JAN FEB MAR APR involve engineers here
- 31. </> ideation research definitioncode JAN FEB MAR NOV involve engineers here ship here
- 32. I wish engineersspent more time coding, less time understanding the problem - SAID NO ONE… EVER “ ”
- 33.
- 34. identify a shared understanding why? who? what? Why arewe building this? Why is it more important than everything else on roadmap? Who are we building this for? Who does what?What are we aiming for? How does this fit in the bigger picture? What are we (not) doing? What defines success?
- 35. Individuals and interactions overprocesses and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan http://agilemanifesto.org
- 36.
- 37. #3 tell themwhat, not why … with little detailBatman is the hero and Robin is the supporter
- 38. make money user pressbutton
- 39. As a user Iwant a new event button So that I can add events
- 40.
- 41. As a user Iwant a new event button So that I can add events Alana to plan a training event my team can run effectively
- 42. Stories get theirname from how they should be used, not what should be written. JEFF PATTON STORY MAPPING (2014) “ ”
- 43.
- 44. Contextual inquiries Customer interviews Prototypes Analytics Surveys Journeymaps Requirements docs Story mapping Personas …. your story toolbox http://bit.ly/StoryToolbox
- 45. CONFUSING UX FEATURE x NOT USED BUGGY Analytics The what, not the why LOW ADOPTION HARD TO GET STARTED LOST IN FLOW NOT DISCOVERED EXPECTED TO BE LOW DON’T USE SERVICE User testing Qualitative feedback Interviews, surveys… Drill into the why and actually talking to people! SPECIFIC BROWSERS SCENARIOS UPFRONT DECISIONS NO GUIDE NAVIGATION PROGRESS TRACKING More analytics! Support feedback
- 46. Now Next Notdoing DISCOVERY SPECIFIC BROWSERS NO GUIDE NAVIGATION PROGRESS TRACKING HARD TO GET STARTED Understanding problems provides clarity for roadmap planning
- 47. Tell stories, notrequirements. Build a toolbox of techniques. Why? Take engineers on the journey. Agree on the problem. Stop arguing about solutions.
- 48. SHERIF MANSOUR •PRODUCT GUY • @SHERIFMANSOUR A PM and a Developer walk into a bar…
- 49. SHERIF MANSOUR •PRODUCT GUY • @SHERIFMANSOUR A PM and a Developer walk into a bar… WORK ASYNC. INVOLVE EARLY SHARED UNDERSTANDING TELL STORIES CULTURE & RELATIONSHIPS spot WHY, NOT WHAT Thank you!