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.

1. Available as a Recording Too A replay of the recorded webinar (for which this presentation was created) can be watched at http://www.accept360.com/resources/webinars/accept-webinar-keep-product-teams-dancing-in-step-with-corporate-strategy/

2. Scott Sehlhorst - Tyner Blain Tyner Blain since 2005 Product Management & Strategy Consulting Software since 1997 Programming, Consulting, Team Leadership Agile (since 1999) Hardware 1990 - 1997 Electro-Mechanical Controls Design Engineer

3. Keep Product Teams Dancing …in Step with Corporate Strategy Accept 360 2011-05-04 Scott Sehlhorst, Tyner Blain

4. Essence of Product Management Your Market Your Customers Have Goals Your Solution Your Product Has Capabilities

5. More Than One Product You Present One Product …but You Have Multiple “Products” You Have Multiple Teams & Multiple Product Modules

6. Poll How many teams / modules on your product? 1 2-5 6-10 More than 10

7. Smartphone Email As a Smartphone User, I want to know when I have an urgent email, so that I can respond as quickly as possible.

8. Smartphone Email

9. Smartphone Email

10. Requirements, Not Design It’s a Nice Sound-Bite But it Should Be… “DON’T FORCE DEVELOPERS (AS A REQUIREMENTS AUTHOR) TO BUILD SOMETHING THE WAY YOU WANT IT – - ALLOW THEM TO BUILD ANYTHING THAT DOES WHAT YOU NEED.

12. Email

13. Interact w/ Email Server

14. Determine email “newness”

15. Determine email “urgency”

17. Complexity Needs Orchestration Some Developers are responsible at ecosystem level Some developers are responsible at application / component / module level

18. Smartphone Email

20. Architects design systems approach

21. The approach constrains and guidesPer App Given architectural design (constraint) These are requirements for each module

22. architect Individual team view

23. Integrated View

24. In Practice (not just “In Theory”) Outside-In: Start with customer, goals for solution. Architects agree on system design. Identify requirements per module. Discover what doesn’t work. Back to (step 2) and repeat.