Product Planning & Processes Saturday 22 March, 2014

1. Product Planning & ProcessesSaturday 22 March, 2014 Dublin Institute of Technology Post-Graduate Diploma in Product Management

2. Schedule

3. Innovation / Uncertainty Framework • Portfolio of projects • An intentional mix of investments • Process suitability

4. Portfolio of Projects • Applies to a single product* • For each customer problem… • How much uncertainty is there… • …About the market viability of a solution approach? • …About your team’s ability to implement? • *You can use this approach for any portfolio of investments

5. Understand Investments vs. Risk

6. Strategy Aligns w/ Risk Profile

7. 2011 Ecommerce Roadmap (v1)

8. 2011 Ecommerce Roadmap (v2)

9. Some of Your Projects • From each table… • Pick a “high” priority item in each of your current products • Where is it • in the layout? • What can we do • to reduce risk?

10. Will any Process Work?

11. Will any Process Work?

12. The Iron Triangle • Fixed Scope + • Fixed Schedule + • Fixed Resources = • Sacrificed Quality • You Can Have… • …Cheap • …Fast • …Good • Pick Two

13. Timeboxes & Units of Work • Definition: • Timebox = • Cost x Time = Capacity • Definition: • Unit of Work = • Function + Quality

14. It Always Happens

15. What Actions Can We Take?

16. Options (in Theory) • Add People to the Team • Delay the Release / Sprint

17. Options (in Theory) • Sacrifice Quality • Delay Less-Important Stuff

18. Options (In Practice)

19. Options (In Practice): Delay for Some

20. Options (In Practice): Satisficing

21. Process

22. Process • What’s good about it? • Hint: reason it exists • What’s bad about it? • Hint: unintended consequences

23. Process is Good • Pros • Prevents the most egregious mistakes • Enables you to empower lower-skilled people • Tells you what to do next • Peppered with good ideas

24. Process is Bad • Cons • Slows things down • Adds cost • Constrains innovative teams • Prevents you from changing “the plan”* • Full of bad ideas

25. Big Corp™ Big Processes • Planning • Project Definition • Engineering • Implementation • Production • Audit • Vision & Objectives • Prioritization • Sizing • Portfolio Funding • Program Management • Functional Requirements • Development • Acceptance & Deployment

26. Rational Unified Process (RUP) • “Given today’s sophisticated software systems, it is not possible to sequentially first define the entire problem, design the entire solution, build the software and then test the product at the end. • An iterative approach is required that allows an increasing understanding of the problem through successive refinements, and to incrementally grow an effective solution over multiple iterations.”

27. Rational Unified Process (RUP for System Z) • Inception • Generate Idea • Define Requirements • Proof of Concept • Elaboration • Refine Requirements • Define Architecture • Design, Create, & Test • Construction • Refine Requirements • Design, Create, & Test • Beta Release • Transition • Create & Test • Run Acceptance Tests • Generally Available (GA) Release

28. Waterfall View

29. Same Thing, Different View • What are the problems with this process?

30. Same Thing, Different View • This is better.

31. Same Thing, Different View • If this is better, why doesn’t everyone do it?

32. Big Corp ™ Big Processes • Resource Planning & Chartering • Envisioning • Planning • Development • Stabilization

33. SDLC Overview

34. Business Stakeholder View

35. Product Management View

36. Development View

37. QA Team View

38. Big Picture Process • Even at “agile” companies, the big picture process is still “waterfall” and will be for quite a while. • *excluding startups which are willing (and able) to pivot, I don’t know of a business which achieves business agility

39. Strategy Drives (Product) Vision

40. Vision Drives a Business Case

41. Vision Initiates Requirements Work

42. And a Revision of the Business Case

43. Business View of Project Initiation

44. New Team Works on the Details

45. “Design” is a Matter of Perspective(a slight segue)

46. Development& QA

47. Coffee (assuming we’re still on time)

48. Big ProcessExample • If this is the process… • Where do errors get introduced into the system? • Each Table

49. Big ProcessExample • A real example from a process-assessment & recommendation project • Each “e” is a place where errors were being introduced into their products

50. WaterfallExample • Where in the • process do we (or • can we) catch the • errors that are • introduced?