How to Work with Product Managers by Box Software Engineer
•Download as PPTX, PDF•
0 likes•309 views
The relationship between a Product Manager and an Engineer is crucial to the success of a project, team, and company. During this talk, we went in depth into this relationship from an Engineer's perspective - namely, what most Engineers would like our Product Managers to know and be aware of, why it's important for us, and how it can be learned. While every team has its own dynamic, we discussed specific examples of things that have gone well, things that have gone not so well, and how they play into general building blocks for developing more productive and successful relationships with your cross-functional peers.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to How to Work with Product Managers by Box Software Engineer
Similar to How to Work with Product Managers by Box Software Engineer (20)
More from Product School
More from Product School (20)
Recently uploaded
Recently uploaded (20)
How to Work with Product Managers by Box Software Engineer
- 1. How to Work with Product Managers by Box Software Engineer www.productschool.com
- 2. FREE INVITE Join 20,000+ Product Managers on productschool.com/slack-community
- 5. Data Analytics for Managers 2-month part-time Courses
- 6. Include @productschool and #prodmgmt at the end of your tweet Tweet to get a free ticket for our next Event!
- 7. Ittai Shay
- 8. Ittai Shay Software Engineer @ Box The Relationship Between Product & Engineering
- 9. Why do Engineers need Product Managers?
- 10. Why do Engineers need Product Managers? ● Keep us focused
- 11. Why do Engineers need Product Managers? ● Keep us focused ● Keep us informed
- 12. Why do Engineers need Product Managers? ● Keep us focused ● Keep us informed ● Keep us motivated
- 13. What do Engineers want from Product Managers?
- 14. What do Engineers want from Product Managers? ● Align goals
- 15. What do Engineers want from Product Managers? ● Align goals ● Communicate
- 16. What do Engineers want from Product Managers? ● Align goals ● Communicate ● Retrospect, learn, & improve
- 17. ● Align goals ● Communicate ● Retrospect, learn, & improve What do Engineers want from Product Managers?
- 18. Product Managers
- 20. Kobe Bryant
- 21. Eyes on the Prize
- 22. What is success?
- 23. What is success? ● Value to User
- 24. What is success? ● Value to User ● Revenue
- 25. What is success? ● Value to User ● Revenue ● Launch
- 26. What is success? ● Value to User ● Revenue ● Launch ● Landing
- 27. What is success? ● Value to User ● Revenue ● Launch ● Landing ● Morale
- 28. Empathize
- 29. Tech Debt & Code Quality
- 30. Tech Debt & Code Quality
- 32. Align Goals
- 33. LeBron James
- 36. Orchestrate
- 37. Support
- 38. Provide Feedback
- 39. Communicate
- 40. Stephen Curry
- 41. Fail Fast
- 43. MVP
- 44. Launch & Iterate
- 45. Retrospect, Learn, & Improve
- 46. What do Engineers want from Product Managers?
- 47. What do Engineers want from Product Managers? ● Align goals - Kobe
- 48. What do Engineers want from Product Managers? ● Align goals - Kobe ● Communicate - LeBron
- 49. ● Align goals - Kobe ● Communicate - LeBron ● Retrospect, learn, & improve - Steph What do Engineers want from Product Managers?
- 50. ● Align goals - Kobe ● Communicate - LeBron ● Retrospect, learn, & improve - Steph What do Engineers want from Product Managers?
- 51. Part-time Product Management Courses in San Francisco, Silicon Valley, Los Angeles, New York, Austin, Boston, Seattle, Chicago, Denver, London, Toronto www.productschool.com
Editor's Notes
- When you checked in tonight, you got an email inviting you to join our slack community In that community, we have 15k product people who have come through different companies like google, facebook, uber Sharing information about events, job offers from our partner companies, and valuable online content Please check your email and join - it’s free
- In our PM Course, we teach how to build products and how to get a job as a software product manager All our classes are 2 months, part time, and compatible with full time jobs. We have two options, Tues/Thurs in the evening and Saturdays in the morning Instructors- are senior level product managers from companies like Google, FB, Uber, etc
- In addition to our PM class, we offer our Coding for Managers class Also two months and part time tailored for professionals who don’t come from a traditional engineering background The goal of this course is not to make you a software engineer, but to give you enough technical background to build a fully functional website and pass the technical interview
- Similar to our coding course, we also offer our Data Analytics for Managers Tailored for people who don’t have a technical background but to give them enough knowledge of analytics to become product managers Also two months, compatible with full time jobs The goal of the course is not to make you a data scientist, but to make you technical enough to understand web analytics, learn SQL, and machine learning concepts
- We are also live streaming our event to our online audience If you want to share, please tweet @productschool and #prodmgmt for a free ticket to our next event
- Hi everyone! Thank you for having me, I’m very happy to be here. My name is Ittai Shay and today we’re going to talk about the relationship between product and engineering, from an engineer’s perspective. I am a software engineer at Box, building out self-serve growth and monetization flows like signup and upgrade, contributing to millions of dollars in revenue per year.
- We’re going to spend the majority of this talk discussing what makes a good product manager, so let’s first establish why engineers need product managers.
- PM’s keep us focused. Engineers like to go down rabbit holes. If you ask us to fill a small crack in the wall, given unlimited time, we’ll look for ways to rebuild the entire wall from the ground up using materials that will never crack.
- PM’s keep us informed. Many engineers spend the vast majority of their days staring at their computer and writing code. PM’s connect and align us to the rest of the company.
- PM’s keep us motivated. When we’re filling that small crack in the wall, it could feel like a mundane, boring task. When a PM tells us that wall is the foundation for a castle, we’re more driven to the get the job done.
- So, what do engineers want from product managers? From our perspective, what can you do to make this relationship successful?
- At a high level, you should aim to understand and align everyone’s goals. What do the customers want? What does leadership want? What does your team want? What do engineers want? How can our product fulfill all of these goals.
- Communicate clearly and effectively. What are we doing, and why are we doing it? Give feedback, and accept feedback.
- Retrospect, learn, & improve. Don’t be afraid to fail, but make sure you fail fast, learn from your mistakes, and move forward.
- Now, I'd like this session to be as interactive as possible. It'll make it more interesting for me, and it'll definitely make it more interesting for you. Feel free to interrupt or raise your hand at any time with any question or comment.
- I’ve been extremely fortunate to work with three different PM’s in my time at Box, and I’m gonna give you the good, the bad, and the ugly of all of them. However, to protect the innocent, I won’t use their real names. My biggest passion in life, of course, is cloud content management and enterprise file sync & share. After that, though, my biggest passion is basketball
- As I was saying, I’ve been extremely fortunate to work with three different PM’s in my time at Box: Stephen Curry, LeBron James, and Kobe Bryant, and I’m gonna give you the good, the bad, and the ugly of all of them. Let’s start with the OG, Kobe Bryant.
- Kobe's one of my biggest idols. I fell in love with basketball watching him win three championships with Shaquille O'Neal in the early 2000's, and closely followed the rest of his career since then. What particularly drew me to Kobe was his unparalleled work ethic. Everyone in the NBA always knew that no matter how hard they were working, Kobe was working even harder. One of my favorite stories of his insane work ethic comes from an old teammate of his. Kobe broke his right wrist during a preseason game many years ago. The teammate was shamefully excited because he thought that, for once, he would finally get to the gym before Kobe Bryant. When he arrived at the practice facility the next morning, he was stricken with fear when he heard a ball bouncing. There was Kobe, in a full sweat, cast on his right arm, dribbling and shooting with his left.
- This passion to succeed and be the best separated Kobe from the rest. He always had his eyes on the prize, with the prize being an NBA Championship. His work ethic inspired those around him to work harder and push themselves further. He led the Lakers to five championships, among the most in NBA history. You’re probably asking yourself, how does this relate to product? What makes Kobe Bryant a successful PM?
- Well, what is success? For Kobe, in the basketball world, success is defined by championships. The more you win, the more successful you’re considered. For a PM, success is determined by the key metrics your team defines.
- For example, does your product bring value to the user? Are they engaged? Do they come back to the product every day or every week?
- Does your product drive revenue? Do new customers buy it? Do existing customers buy more of it?
- Did the project launch on time, or did it take twice as long as originally planned?
- Was the project well-received, or did it anger your customer base?
- How did the project impact team morale? Is everyone burnt out from the effort, or are they energized by the accomplishment? All of these metrics are used by my team at Box.
- Beyond even those metrics, though, a successful PM is able to recognize that different organizations have other, more subtle definitions of success. As I mentioned earlier, Kobe and Shaq won 3 championships together, but they could have won much more. At the time, they were the two highest performing individuals in the NBA, on the same team, with the same ultimate goal of winning a championship. However, they had different approaches to reaching that goal. Kobe always believed that the only way to win was to be serious and work hard 100% of the time. Shaq, on the other hand, obviously also wanted to win, but he wanted to have fun and joke around while doing it. Kobe didn’t empathize with Shaq’s goal to have fun, and instead went to Lakers management and said “it’s either me or him. I can’t work with him anymore.” The Lakers traded Shaq away, and this single philosophical difference broke up the most dominant duo in NBA history. If Kobe were a better PM, he would have recognized that one of Shaq’s goals is to have fun, and aligned that with his own goals. In our world, the customers have their own goals, company leadership has its own goals, design has its own goals, and engineering has its own goals, and it’s crucial as a PM to understand and align all of those goals under the product initiative.
- As an example, a major success metric for engineers is technical debt & code quality. What is technical debt & code quality?
- Picture a house of cards. Notice how the first level of cards, the foundation, is wide and robust, while the highest level has only two cards. Each level in this house is supported by a bigger level below it. Breaking this pattern and stacking more cards on top without enhancing the foundation will quickly cause the house to collapse. This is exactly how a large codebase works. When you go to Box's signup page, or Facebook’s login page, or Google’s search page, all you see are some basic inputs and a couple buttons. Powering those forms behind the scenes, though, are complex pricing and discounting engines, form validation services, real-time logging and tracking integrations, and much more. All of these foundations took a long time to build and had no immediate impact on the three key metrics we discussed earlier, but putting them together resulted in incredibly simple and intuitive user experiences.
- Technical debt and code quality are inversely correlated. The more technical debt you accrue, through short-term, hacky, unscalable solutions, the worse code quality becomes, and the codebase starts to look like this - a crumbling infrastructure of dominoes struggling to support a heavy bridge, on the brink of collapse. Failing to address technical debt leads to more time spent fixing bugs, more existing features breaking, and more difficulty in building new features, all of which impact customer trust.
- As Kobe should have done with Shaq, and learned to do later in his career, align everyone’s goals. Ask yourself whether a project will generate revenue, but also ask the engineers whether it requires time to build proper infrastructure or will it result in more technical debt. Ask the customers if they’re happy. Ask leadership if they’re satisfied.
- The second PM I got to work with is LeBron James. Given how much I like Kobe, I was apprehensive of LeBron at first. Here comes the most highly touted and hyped up prospect of all time, straight out of high school, with the intention of taking the title of best basketball player in the NBA from my Kobe. He even has "The Chosen One" tattooed across his back.
- Seriously, who does this?
- I quickly gained a ton of respect for LeBron, though, because he's simply the smartest basketball player of all time. He is an incredible communicator and orchestrator. He sees situations developing before anyone else, puts his teammates in positions to succeed, and coordinates every element of the organization, even beyond the court. He has almost single-handedly led his team to seven consecutive NBA Finals, something that hadn't been done in 50 years. How does that translate to product management?
- Be the orchestrator. As a PM, you’re in the middle of everything, running from design meetings to engineering spec reviews to 1:1's, all while revising the product roadmap, planning design sprints, and coordinating happy hours. Like LeBron, or a concert orchestrator, you should see how everything plays together into the bigger picture, and put teammates in positions to succeed.
- Beyond putting your teammates in positions to succeed, be ready to support them when roadblocks arise. In this picture, LeBron is helping out teammates who made a mistake by blocking Andre Iguodala’s layup. Setting aside the fact that this block probably cost the Warriors the championship two years ago, it exemplifies LeBron’s willingness to jump in and support his team. As an engineer, there are times where my changes will require approval from other teams. Sometimes those teams like to take their sweet time getting to the approval, and sometimes they’ll provide unreasonable feedback. As a PM, it’s super helpful when you’re willing to work your political magic in times like these to unblock your engineers and keep the ball rolling.
- Provide constant, ongoing feedback. At Box, we have daily stand-ups to discuss progress updates, two-week sprints to review project milestones, and recurring one-on-ones for more sensitive feedback and discussions. Make sure you provide positive feedback as well. Telling your engineer something as simple as “good job” or “thanks for jumping on that bug” goes a long way in improving their morale. It’s a completely free, low-effort way to make sure they’re feeling appreciated and happy.
- All of this ties into communicating clearly and effectively. When you hand the engineer a product specification, make it as clear as possible, leaving nothing up for interpretation. Don’t tell the engineer "we want to roll this out with an A/B test." Instead, tell the engineer "when we roll out this feature, we want to conduct an A/B test where 50% of the users, the control bucket, will see the existing experience, and 50% of the users, the test bucket, will have access to the new feature." Be as explicit as possible. Provide feedback to your peers, and sing their praises when they do a good job.
- The third PM I’ve worked with at Box is Stephen Curry. Steph is the antithesis of LeBron. LeBron is a six foot eight inch athletic beast, built like a Ford F-150, unbreakable and unstoppable. He's the peak of human evolution. Steph, on the other hand, is only an inch or two taller than me, maybe 180 pounds, with below average quickness and athleticism relative to other NBA superstars. When LeBron was in high school, ESPN was televising his games and saying he might be the greatest player of all time. When Steph was in high school, he barely got a scholarship to Davidson College, a tiny Division-III school completely irrelevant in the basketball world. What separates Steph from the rest is his willingness to admit failure, accept setbacks, and use them as motivation to get better every single day. Those traits took a scrawny high-school kid no one noticed, carried him through debilitating injuries, doubters, and non-believers, and turned him into the most feared offensive player in NBA history.
- As a PM, be ready to fail fast. You might not have ankle injuries like Steph, but you’re almost sure to encounter projects that fail and projects that get cancelled. This is normal, and you should be prepared to address it and grow from it. If a project fails, take a closer look at your team’s morale. Are the engineers frustrated that months of effort went to nothing? Are the designers disappointed that their UI isn’t impacting customers as expected? You might need to plan a happy hour or take the team boxing to let out some steam, but then regroup and figure out how to put the failure behind you and move forward.
- Given that failures are inevitable, get ahead of the curve and plan to minimize their impact. This is a classic Venn diagram representing how projects are built. If you want a lot of high-quality features, it’s going to take more time. If you’re under a tight deadline, you need to sacrifice either quality or functionality. Balancing the three is a major challenge as a PM, but one way to do so is start with an MVP.
- Steph is a two-time NBA MVP. In his world, MVP means most valuable player. In our world, MVP means minimum viable product. When you’re planning a project, work with the engineer to identify the minimum viable product that will take the least amount of time to build but that we can use to test the effectiveness and successfulness of the feature. For example, I’m working on a project right now to introduce virality into our product, something my team hasn’t tried before. The original specification would have taken 3 months to build. A quarter of a year is a massive investment for a project that’s not guaranteed to succeed. If we went forward and built that out, and after launch determined that the feature doesn’t produce the results we expected, it would be a massive failure for the team. Instead, I worked with the PM to identify an MVP for the project that we can build in just 1 month, upon which we can later iterate and develop.
- After launching the MVP, don’t forget to iterate. One of the things Steph is known for is his incredible dribbling and hand-eye coordination. His pregame drills, pictured here, draw thousands of fans to arenas hours before tip off, just to see how he refines his skills. Steph takes his already otherworldly skill and iterates and improves it by testing and trying a variety of props, from multiple basketballs to tennis balls to blinding goggles. Similarly, as a PM, recognize where you can test and iterate and get creative with how you develop. At Box, my team has been focused a lot on admin onboarding recently. One test we conducted drove more file uploads, another test drove more file sharing, and another test drove more feature customization. We’re constantly iterating and tweaking these tests to help our users and push our metrics.
- Finally, retrospect, learn, and improve. Steph spent most of the early years of his career going through ankle injury after ankle injury. After each one, he worked with his trainers and coaches to identify what went wrong and how to prevent similar failures in the future. Over time, Steph partnered with Under Armour to develop custom shoes with revolutionary ankle support, started wearing heavy ankle braces, and even learned to fall in a way that minimizes impact on his ankles. He completely overcame his injury woes and led his team to two championships and counting. At Box, at the end of every project and accomplishment, we conduct what’s called a retrospective. The PM and engineer work to put together a document detailing what went well, what went poorly, and what key takeaways the team should keep in mind for future products. There is no ego in these retrospectives, and they’re not about assigning blame, but rather acknowledging everything that happened and figuring out how to use that knowledge to improve future projects.
- To recap, what do engineers want from product managers?
- Align everyone’s goals. What do the customers want? What does leadership want? What does your team want? What do engineers want? How can our product fulfill all of these goals. Win those championships.
- Communicate clearly and effectively. What are we doing, and why are we doing it? Give feedback, and accept feedback. Orchestrate your team.
- Retrospect, learn, & improve. Don’t be afraid to fail, but make sure you fail fast, learn from your mistakes, and move forward. Be an MVP.
- Thank you!