Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Building Effective Product Teams

Building Effective Product Teams

You are probably already tired of the Agile, Scrum and Lean jargon. Maybe you think that all of this theory is a waste of time, or at least that is not having a big impact in your company or team.

As a developer that moved to a Technical Product Manager role, I’ve been working hard to declutter all the jargon and try simple ways to improve how teams work and deliver software.

We will discuss around questions like what makes a strong product team, how story mapping can help you deliver software faster, why talking is more important that writing user stories or why your team is not delivering as fast as you would like.

If you want to enjoy the GIFs from the deck, download the Keynote file: http://bit.ly/2yYhLrM

26c5bc5b88075a54b55ae54e98be2c09?s=128

Fernando Agüero

November 08, 2018
Tweet

More Decks by Fernando Agüero

Other Decks in Technology

Transcript

  1. Building effective product teams

  2. Hello! I’m Fernando Agüero.

  3. Madrid Devs I like to help communities ValenciaJS

  4. …and write about productivity

  5. Technical Product Manager I WORK AS A

  6. None
  7. Talk Objectives

  8. 1. Having awareness on the issues we may find 2.Being

    on the same page 3.Fostering discussion Talk objectives Improve as a team by:
  9. The team

  10. What is a product team?

  11. • Product manager • Product designers • Product marketing managers

    • Engineers • QA Testers • Data Analysts The team
  12. • Product manager • Product designers • Product marketing managers

    • Engineers • QA Testers • Data Analysts The team
  13. Knowing the roles

  14. Knowing the roles and premises

  15. The Product Manager

  16. Thinking that product management is the same as gathering requirements

    and documenting them for engineers. The Product Manager PREMISE
  17. The Product Manager Thinking that product management is the same

    as gathering requirements and documenting them for engineers. PREMISE
  18. The Product Manager Product managers are responsible for guiding the

    success of a product and leading the cross-functional team that is responsible for improving it.
  19. The Product Designer

  20. The product designer work is to apply the lipstick model

    to the product. The Product Manager role The Product Designer PREMISE
  21. The product designer work is to apply the lipstick model

    to the product. The Product Manager role The Product Designer PREMISE
  22. Previously focusing on The Product Designer Turning specs from the

    PM into designs
  23. The Product Designer Previously focusing on Turning specs from the

    PM into designs
  24. Modern workflow The Product Designer Collaborate from discovery to delivery

  25. The Engineers

  26. Engineers should only code The Engineers PREMISE

  27. The Engineers Engineers should only code PREMISE

  28. If you are using engineers only to code, you're only

    getting about half their value. The Engineers
  29. Engineer are typically the best single source of innovation; yet,

    they are not even invited to the party in the discovery process. The Engineers
  30. It’s crucial that engineers know about the customers, specially the

    pain. The Engineers More than coding
  31. It's a great idea for them to join meetings with

    customers. The Engineers More than coding
  32. It’s all about extreme collaboration

  33. The team Products are designed collaboratively rather than in sequence

  34. The Team Using GitHub issues to discuss and iterate a

    story We currently use Google Docs for epics or complex problems.
  35. The Team Product Manager Engineers Product Designer The team

  36. Work in parallel to discover the product that needs to

    be build (mainly PM and designer) while delivering a production-quality product (mainly engineers). The team
  37. Engineers help on discovery: source of great ideas. PMs and

    designers help on delivering: mainly to clarify intended behavior. Discover Deliver The team
  38. Don't show the prototype to engineers during sprint planning so

    they can estimate. Ensure they can contribute every day to make the product better. The team
  39. The Process

  40. The Process 5 key points

  41. 1. The Source of ideas

  42. Focusing only on your ideas Thinking you are the customer

    Using requirements from customers The source of ideas
  43. Focusing only on your ideas Thinking you are the customer

    Using requirements from customers The source of ideas
  44. Use your vision and objectives Learn from your customers struggle

    Analyze usage data The source of ideas
  45. Talk with customers Focus on them, not on your product.

    The source of ideas
  46. The source of ideas Do not just ask: What do

    you like about our product? Ask questions like: When you need to do x, how are you doing it? When was the last time you needed to do x?
  47. Talk with customers Using Intercom to help and learn from

    the customers
  48. Analyze usage Using Mixpanel to discover insights and understanding impact

    and usage of features
  49. 2. Focusing on the outcome

  50. Focusing on the outcome The more you ship... The faster

    you ship...
  51. It’s all about shipping! Focusing on the outcome Focusing on

    the outcome
  52. Burning story points doesn’t matter if you are not doing

    the right thing. Focusing on the outcome
  53. Focusing on the outcome Agile Reminder

  54. Agile Reminder Focusing on the outcome

  55. • More than following a plan, respond to change. •

    Hundred of other stuff… Focusing on the outcome
  56. It’s fine to remove a story from a Sprint or

    change the scope if it makes sense. Focusing on the outcome
  57. 3. Building less

  58. Build less. Building less

  59. Build less. For real. Building less

  60. There's always more to build than we have time or

    resources to build. Building less
  61. Organizing pipeline using three GitHub milestones 1. Current work 2.

    Next tasks 3. Future Milestones:
  62. Are you going to build all at once? If you

    keep validating it, you may go… Building less
  63. Building less • View the basic info: title, rating, director,

    etc • View the movie poster • Link to trailer Good Enough:
  64. Building less • View the basic info: title, rating, director,

    etc • View the movie poster • Link to trailer Good Enough: • Movie synopsis • User and reviewer ratings • List of actors Better:
  65. Building less • View the basic info: title, rating, director,

    etc • View the movie poster • Link to trailer Good Enough: • Movie synopsis • User and reviewer ratings • List of actors Better: • Trivia about the movie • News about the movie • Ability to participate in discussions Best:
  66. 4. Build shared understanding

  67. Build shared understanding Story

  68. Build shared understanding Story

  69. Build shared understanding Story

  70. Build shared understanding We agree! Story

  71. Build shared understanding Shared documents is not shared understanding

  72. There is no perfect way of writing stories Build shared

    understanding
  73. Build shared understanding • Stories are not specs • The

    real goal of stories is to build shared understanding Writing stories:
  74. Using Story mapping

  75. Story mapping Story mapping consists of ordering user stories along

    two independent dimensions: activities and implementation
  76. Image from manifest.co.uk

  77. Image from realtimeboard.com

  78. Story mapping Use story mapping by having conversations to build

    shared understanding.
  79. • Focus on the breadth, not depth • Follow user

    journeys/jobs • Prepare a release strategy • Prepare a development strategy Tips: Story mapping
  80. Try it with your team when designing a complex feature

    or flow. Story mapping
  81. 5. Avoid burning out

  82. Avoid burning out Another normal day at work

  83. Avoid burning out Working on the right thing with the

    right process Working harder > Better than
  84. Avoid burning out Be careful when working only on “keeping

    the lights on” activities.
  85. The Thinking Week Avoid burning out Making innovation an habit

  86. Avoid burning out Every month, we spend a week learning,

    improving workflows, and trying new things.
  87. Avoid burning out • Open sourced one of our frontend

    components • Created an internal tool • Played with Docker Swarm • Improved our build processes • Wrote two articles Some achievements we had in our first week:
  88. • Open sourced one of our frontend components • Created

    an internal tool • Played with Docker Swarm • Improved our build processes • Wrote two articles Some achievements we had in our first week: Avoid burning out
  89. References & Book Recommendations

  90. Inspired MARTY CAGAN How to create tech products customers love

  91. User Story Mapping JEFF PATTON & PETER ECONOMY Discover the

    whole story, build the right product
  92. Make Time JAKE KNAPP & JOHN ZERATSKY How to focus

    on what matter every day
  93. Thanks! @fjaguero