Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Keep Product Teams Dancing...In Step With Corporate Strategy

As product managers, how we go about managing requirements for complex products - products that are made up of multiple teams and modules - is a little different.

This presentation presents a technique for decomposition of the problem, and approaches for reaching a shared understanding of goals across teams - allowing us to orchestrate concerted solutions for our customers.

  • Login to see the comments

  • Be the first to like this

Keep Product Teams Dancing...In Step With Corporate Strategy

  1. 1. Available as a Recording Too<br />A replay of the recorded webinar (for which this presentation was created) can be watched at<br /><br />
  2. 2. Scott Sehlhorst - Tyner Blain<br />Tyner Blain since 2005<br />Product Management & Strategy Consulting<br />Software since 1997<br />Programming, Consulting, Team Leadership<br />Agile (since 1999)<br />Hardware 1990 - 1997<br />Electro-Mechanical Controls Design Engineer<br />
  3. 3. Keep Product Teams Dancing …in Step with Corporate Strategy<br />Accept 360<br />2011-05-04<br />Scott Sehlhorst, Tyner Blain<br />
  4. 4. Essence of Product Management<br />Your Market<br />Your Customers Have Goals<br />Your Solution<br />Your Product Has Capabilities<br />
  5. 5. More Than One Product<br />You Present One Product<br />…but You Have Multiple “Products”<br />You Have Multiple Teams<br /> & Multiple Product Modules<br />
  6. 6. Poll<br />How many teams / modules on your product?<br />1<br />2-5<br />6-10<br />More than 10<br />
  7. 7. Smartphone Email<br />As a Smartphone User, I want to know when I have an urgent email, so that I can respond as quickly as possible.<br />
  8. 8. Smartphone Email<br />
  9. 9. Smartphone Email<br />
  10. 10. Requirements, Not Design<br />It’s a Nice Sound-Bite<br />But it Should Be…<br />“DON’T FORCE DEVELOPERS (AS A REQUIREMENTS AUTHOR) <br />TO BUILD SOMETHING THE WAY YOU WANT IT –<br />- ALLOW THEM TO BUILD ANYTHING THAT DOES WHAT YOU NEED.<br />
  11. 11. Solution Design has to happen<br /><ul><li>Radio / Comm – abstract as service that provides “TCP/IP”
  12. 12. Email
  13. 13. Interact w/ Email Server
  14. 14. Determine email “newness”
  15. 15. Determine email “urgency”
  16. 16. Notification – abstract to “alert” service</li></li></ul><li>Smartphone Email<br />
  17. 17. Complexity Needs Orchestration<br />Some Developers are responsible at ecosystem level<br />Some developers are responsible at application / component / module level<br />
  18. 18. Smartphone Email<br />
  19. 19. Requirements “Work” at Two Levels<br />Overall<br /><ul><li>Solution view is given to architects
  20. 20. Architects design systems approach
  21. 21. The approach constrains and guides</li></ul>Per App<br />Given architectural design (constraint)<br />These are requirements for each module<br />
  22. 22. architect<br />Individual team view<br />
  23. 23. Integrated View<br />
  24. 24. In Practice (not just “In Theory”)<br />Outside-In: Start with customer, goals for solution.<br />Architects agree on system design.<br />Identify requirements per module.<br />Discover what doesn’t work.<br />Back to (step 2) and repeat.<br />
  25. 25. Timing Also Matters<br />You Have To Orchestrate<br /><ul><li>Not Just Who Does What
  26. 26. But Also When Will Each Team Finish “Their” Part?</li></ul>Scrum of Scrums<br /><ul><li>Solution-Level Participation
  27. 27. Representative From Each Module/Team</li></ul>Per-Module<br /><ul><li>Ad-Hoc, Scheduled, Whatever Works</li></li></ul><li>Thank You VERY MUCH!<br />Scott Sehlhorst<br /><br />@sehlhorst (on Twitter)<br /><br /><br />