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


Published on

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.

Published in: Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

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 />
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.