Overview of my approach to product strategy and implementation

1. BWM Product Development Process Presented by 1

2. Target Process Model – Single Team Choosing, Planning, Building & Releasing Each arrow represents a scheduled Event Weekly Status meeting for each team Executives must participate in “Choose” mtg Choose Product 2 Choose Product 3 Plan Product 1 Plan Product 2 Plan Product 3 Product 1 Product 2 Product 3 Plan Sprint b Plan Sprint c Plan Sprint d Plan Sprint a Plan Sprint b Plan Sprint c Plan Sprint d Plan Sprint a Plan Sprint b Plan Sprint a Demo Sprint a Demo Sprint b Demo Sprint c Demo Sprint a Demo Sprint b Demo Sprint c Demo Sprint a Release Product 1 Release Product 2 Release Product 3 Weekly Status 2 June July August September October November Time

4. Value focus built into organizational structure (team  value stream)

6. ROI calc & deal templates

7. Deal execution

8. Deal postmortem

9. Redemption technologies

10. POS integration

11. Partner platform

12. API

13. Widgets

14. Co-branded exp

15. Portal

16. Social Media apps

17. SEO platform

18. Landing page testing platform

19. Core web exp

20. Deal exp

21. Account management

22. Offer dashboard

23. 2nd ary offer market

24. Loyalty/reten-tion programs

25. Mobile/smart-phone exp

26. Deal production platform

27. Admin platform

28. Sales support

29. CS support

30. Business Intelligence

31. Offer Science

32. Email communications4

33. Teams 5

35. Team 1 – core consumer experience

36. Team 2 – operations

37. Team 3 – merchant experience/backend

38. As we grow our team size through March …

39. Team 1 – deal merchandising, exp, & fulfillment

40. Team 2 – operations

41. Team 3 – backend

42. Team 4 – consumer exp, social, & mobile access

43. Team 5 - merchant experience

44. Teams consist of at least 1 engineer, ½ designer, ½ product manager

45. Lean, feedback driven, 2-week iteration based approach6

47. Teams are not ‘owned’ by an individual

48. Teams have the freedom to choose approaches, but not objectives.

49. Teams are accountable for the results of their choices

50. Product Management

51. (opportunity & solution identification, product performance against kpis)

52. Visual and interactive design

53. (usability analysis, solution identification & definition)

54. Software development

55. (solution definition, design, & construction)

56. Quality assurance

57. (solution definition & correctness)

58. Process facilitation

59. (process effectiveness oversight)7

61. Product release dates are refined as sprints are completed. If they are fixed, scope is managed appropriately

62. Each team will publish calendar with fixed meeting dates

63. Weekly sprint progress will be published

64. Executives will be invited to choice meetings

65. Each team will conduct demonstrations of built functionality at the end of every sprint (~2 weeks) and prior to release

66. Information published using SharePoint (or another document management system)8

68. Each product category or value stream requires a roadmap.

69. Each team requires a roadmap

70. If fewer teams than product categories, group product categories and combine roadmaps

71. Mapping teams to value streams allows the team to drive against quantifiable success criteria associated with value stream

72. e.g. visitor to subscriber conversion

73. e.g. # purchases per session per subscriber

74. e.g # of purchased *offer science* recommended deals

75. e.g. # of subscribers per API partner9

77. Maximize [ARPS ($ per sub)] per partner per unit time

79. Widgets & JavaScript/HTML objects

80. Partner tools & analytics

81. Automated Partner signup

82. Partner deal management capabilities

83. Product expert - <tbh>

84. Interactive/visual designer – <tbh>

85. Software development – <tbh>,<tbh>

86. ½ Quality assurance – <tbh>10

88. Minimize [#subscribers churn/month] ratio

89. Maximize [#purchases/subscriber] ratio

91. Community experience

92. Account management

93. Offer Dashboard

94. Secondary market

95. Product expert - <tbh>

96. Interactive/visual designer – <tbh>

97. Software development – <tbh>, <tbh>

98. Quality assurance – <tbh>11

100. Maximize [#deals/merchant] ratio

101. Maximize [commision$/deal] ratio

103. BoostYourBusiness and associated web collateral

104. Referral features

105. Conversion funnels

106. Product expert - <tbh>

107. Interactive/visual designer – <tbh>

108. Software development – <tbh>. <tbh>

109. ½ Quality assurance – <tbh>12

112. Customer Service tools

113. Financial Operations support

114. ½ Product expert - <tbh>

115. Software development – <tbh>, <tbh>

116. ½ Quality assurance – <tbh>13

118. Web analytics

119. Other internal & external data-sources relevant to our business operations

120. Database/Report development – <tbh>,<tbh>

121. Software development – <tbh>

122. Business analytics – <tbh>14

124. Maximize the value of each subscriber communication

125. Leverage email to extend base service offerings

126. Maximize [Commission $/1000 sends] ratio

127. Maximize [# clicks/1000 sends] ratio

128. Maximize [# opens/1000 sends] ratio

130. Email campaigns

131. Email management tools

132. Deliverability management tools

133. Data extraction associated with email campaigns

134. CRM expert - <tbh>

135. Visual designer – <tbh>

136. Software development – <tbh>, <tbh>

137. ½ Quality assurance – <tbh>15

139. Bug fixes & enhancements

140. Admin app support

141. Web production & publishing

142. Payment system changes

143. Product expert - <tbh>

144. Interactive/visual designer – <tbh>

145. Software development – <tbh>, <tbh>

146. ½ Quality assurance – <tbh>16

147. Choosing & defining 17

148. Choosing what to do Ideas come from everywhere Product roadmap Technology roadmap Business development Customer feedback Funnel optimization analysis Metric review Competitive research Prototyping and brainstorming How do we decide which ones are the most valuable? How do we decide which ones to do?

149. Choosing what to do Release targets are fixed and occur on a recurring basis for each team This schedule puts pressure on the ‘ideation process’ (product identification and prioritization) Each team must have a “backlog” of product ideas ready to build The process of generating, capturing, and evaluating ideas must be as disciplined and normal as the process of implementing them

150. Choice Cycle Sprint & release cycle (building) sprint 4 sprint 1 sprint 2 sprint 3 release 1 release 3 release 2 plan release 2 plan release 3 plan release 4 Identification & evaluation cycle (choosing) = concept doc

151. Identifying Teams are empowered to work with executive management in order pick the products or projects that will have the greatest impact on their value stream During a release cycle, the team’s product manager must identify and evaluate 2-5 items as candidates to be built during the next release Identification primarily involves picking opportunities to realize or problems to solve

152. Identifying Opportunities or problems to address can come from at least the following places Roadmap Internal business intelligence Business development opportunity Competitive research & analysis Market study research & analysis Customer feedback *intuition* An opportunity is identified once a ‘concept document’ has been written 1- 2 page document with an opportunity description (quantitative), an objective section, and a candidate solution (with cost) section Should provide enough information to evaluate and prioritize item

153. Choosing Choosing what to do is a critical decision process at the end of which a commitment is made to invest time and money into an endeavor with an uncertain outcome Consequently, the team must be joined by the appropriate set of executive stakeholders when choosing what items to tackle in the upcoming release Choosing and prioritization occurs at the “concept review meeting” which takes place at least 1 week prior to the end of the current release

154. Choosing In the concept review meeting the conceptual docs for the candidate initiatives are presented and discussed At the end of the concept review meeting 1 or more projects are chosen to be built in the upcoming release. If more than 1 project is chosen, a priority order is defined Multiple methods for choosing may be employed Simple ROI NPV IRR Scorecards Qualitative analysis

155. Defining Once a project has been chosen it must be ‘minimally’ elaborated before the start of the next release. Elaborating a project is known as ‘release planning’ or creating the ‘product backlog’ It is very different from creation a PRD; It is a simple list With a ‘product backlog’ the objective is not completeness Items in a product backlog are called ‘user stories’ or ‘features’

156. Defining User stories or features are simple descriptions of application behavior or user interactions They are intended to be place holders for further conversation Each must have a unique value and a time estimate Defining

157. Planning Releases Releases are divided into sprints During sprints, the team decides how many features or user stories it believes it can accomplish in a fixed amount of time During sprints, the team elaborates the features covered in the sprint Sample release plan Release (29 features) Sprint 1 (12 features) Sprint 2 (17 features) 4 weeks 4 weeks

158. Building 28

159. Process model Scrum 15 – minute daily meeting Team members respond to basics - What did you do since last meeting? - any obstacles? - What will you do before next meeting? Sprint Every 24 hours Backlog items expanded by team Backlog Features assigned to iteration 30-day sprint New Functionality is demonstrated at the end of iteration Scrum Pull next Product Backlog Priority 1 Priority 2 Priority 3 Define Build Test Evaluate Pull top item Fail

160. Sprinting/Iterating The heart beat of agile product development is the ‘sprint’ A release consists of 1 or more sprints The team delivers an integrated, release ready set of features at the end of a sprint. Features and user stories built during a sprint are taken from the ‘product backlog’ A sprint is composed of the highest priority items from the backlog that the team believes can be accomplished within the sprint time frame

161. Sprinting Sprints are always time boxed At the beginning of a sprint the team engages in ‘sprint planning’ and associates tasks (each task has ‘effort points’) with each user story or feature in the sprint The most important user stories or features are built first Features are defined, built, and tested by the team one at a time Once a sprint is fixed, only the team can add new features

162. Daily Stand-up The daily standup or ‘scrum’ is the primary vehicle for team communication The goal is for the team to remove any obstacles preventing it from succeeding in delivering the sprint Feature ambiguity or complexity Technical ambiguity or complexity Lack of critical information External distractions Momentum problems The daily standup meeting takes place every day and must be attended by all members on the team

163. Daily Stand-up Roles Scrum facilitator – facilitates scrum Product expert – defines and refines application behavior Team – realizes application behaviors Daily standup is a realization of ‘empirical process control’ Visibility – intermediate process steps are visible Inspection – intermediate results can be evaluated Adaptation - changes can be made as a result of visibility & inspection In this way the product solution can be achieved through a series of small activities, each which can be measured against objectives

164. Story Boards & Burn-down Charts Story boards and burn down charts are the ‘vehicles’ upon which the sprint and daily stand-ups rely Story boards list user stories or features on index cards and categorizes them as ‘not started’, ‘in progress’, & ‘completed’ Through the course of the sprint, index cards migrate from ‘not started’ to ‘completed’ The burn down chart captures this progress in a, hopefully downward sloping, two dimensional graph

165. Story boards Story Boards Not Started In Progress Completed Purchase flow Account History Sprint day 1 Not Started In Progress Completed Buy btn – LFM mode Purchase flow 1 trk Purchase flow >1 trk Mar com – splash pg Omniture tracking Account History Buy btn – visit mode Sprint day 22

166. Burn-down Charts Sprint 2 is a two week sprint which started with 11 features and 63 effort points. Do we have a problem?

167. Testing & releasing 37

168. Testing in Agile is Different Traditionally, test and development organizations are separate Traditionally, development hands off large amounts of theoretically working, but largely untested code to a test organization With agile, testing and development are peas in a pod With agile, tests are developed concurrently with coding and requirements generation

169. Testing in Agile is Different Features or user-stories are validated as they move from ‘not started’ to ‘completed’ The define/build/test cycle occurs on a feature by feature basis The embedding of a ‘test driven’ mentality throughout the whole ‘build’ process results in systems which are built to be verified This leads to higher overall quality

170. Agile Testing Principles All code is tested code Teams get no credit for delivering functionality that has been coded but not tested Tests are written before, or concurrently with, the code itself Testing is a team effort; testers, developers, and product experts all write tests Automation is the rule, not the exception

171. Agile testing strategy

172. Measuring Success 42

173. Success Success in a world of value stream orientation is the creation of value Each team is successful as a unit if it positively impacts its KPIs Working software products that conform to their intended purpose is the first necessary condition for success Discovering the right products through frequent release and measurement is the other necessary condition for success

174. Success Every member of the team is exposed to the performance of the products or projects they are building through a team dashboard Success is NOT Completing the step in a work order A PRD or a technical specification Adherence to internal milestone dates A wireframe A complete test plan Positive performance of products is the primary measure of success for the entire team

175. Metrics Although the primary measures of success are direct product performance metrics, other internal efficiency and effectiveness measures are valuable Project metrics allow the team to perform project kaizen (to get better at doing) There are two kinds of project metrics Sprint assessment metrics Release assessment metrics

176. Sprint assessment metrics

177. Release assessment metrics

178. Process Metrics Project metrics help individual teams improve their own performance at the project level Process metrics provide global insight into process effectiveness across six dimensions Product management capability Release planning and tracking capability Sprint planning and tracking Team effectiveness Testing practices Development practices/infrastructure

183. Sharing Information 53

184. Publication <Discuss SharePoint> <per team> <performance metrics> <competitive/market analysis & artifacts <Exploratory comps/wireframes/descriptions etc> <backlog> <release plan> <weekly sprint progress – via backlog>

185. Recurring Meetings <outline recurring meetings> <commitment meeting> <release planning meeting> <sprint planning meeting> <sprint delivery meeting> <pre-release meeting> <monthly open-forum area performance meeting>

186. Status <Define how teams bubble status to exec committee on weekly basis – pre operations meeting> <Multi-tabbed spreadsheet (ala ru)>

187. Governance 57

188. Stakeholder Involvement <characterize appropriate involvement levels> <examples of *good* involvement> <examples of *bad* involvement> <emphasize persuasion & coaxing & evangelizing as *good*> <emphasize explicit direction & imperatives as *bad*> <discuss pathologies that arise as a result of this technique>

189. Process Impediments Iterative Process People arrive late to meetings Meetings take too long. People become bored and devalue meetings Scrum master dictates design decisions or micromanages Teams are too large for daily scrum and sprint planning Teams do not report task remaining time for burn down analysis People Practices Individuals interrupted by non-sprint based work Team members isolated physically Team members not accountable for sprint commitments Individuals multiplexed across too many teams

190. Process Imediments Product Engineering Practices Resources necessary for definition/design/implementation/testing not present on team Sprints do not fully implement & test deployable increments of customer valued features Product owner not available/integral to team System integration not forced at each sprint Product owner wont split up large product backlogs Features introduced into sprints after sprints begin Organizational issues Software process police regulate to ineffective process Management assumes fixed cost, fixed scope delivery Individual rather than team behavior rewarded Rules or capitalization structures demand water-fall Teams not collocated to maximum extent feasible