This document provides guidance on managing product rollouts. It emphasizes that timelines and budgets may change during development. When specifying a product, it is important to define the problem being solved, target users, market opportunity, and metrics for success. Products should be tested iteratively and validated as feasible, usable, and valuable. Release management requires understanding product lifecycles and prioritizing backlog items. Estimates help determine priorities but planning will change as the product evolves. Metrics like market share and feature usage should determine how the product is refined or improved. Regular demos provide visibility into progress.

1. Managing Product Rollouts
The Founder Institute – Bogotá
June 2014

2. Lessons Learned
• Things will change along the way
• You will have to take “licenses” (many of them…)
• Timelines and budget will not be enough
• An X% of the product is what really matters

3. Specifying what to build
1. Exactly what problem will this solve?
2. For whom do we solve that problem?
3. How big is the opportunity?
4. How will we measure success?
5. What alternatives are out there now?
6. Why are we best suited to pursue this?
7. Why now?
8. How will we get this product to market?
9. What factors are critical to success?

4. Build the right product
• Flesh out product concepts and test them out
• Think about the product’s short and long term
• Be ready for a mind shift:
– From product discovery (new ideas, maleable
requirements)
– To focus on delivery an issue resolution
• Validate the product is Feasible, Usable and Valuable
• What matters most is creating a product your
customers love

5. Proof is in the pudding!

6. • You need to understand the product lifecycle (web
vs. Mobile vs. Platforms…)
• Order the list of items managed by a persona with
the ability to understand the business needs
• Capture all modification requests
• Give the delivery team work that will maximize the
business benefit of the product owner
Managing a Product Roadmap

7. Backlogs are never complete

8. Planning is not accurate
• A team plans based on its individual AND collective
experience
• Planning changes as the product refactors
• Planning poker works for where deadlines may be
negotiated
• Assign resources with an appreciation of risk
• Be sure to assess the team’s learning curve!

9. Estimates help Priorities
• Priorites give the team focus on specific product
features:
– Kano Model of Customer Satisfaction
• Like vs. Expect vs Could live with it vs. I’d dislike it
• Defines features as Exciters, Baseline, Linear, Indifferent and
Questionable
– Innovation Games
• Prune the product tree
• Buy the feature
– Relative Weight

10. What is YOUR criteria?

11. Metrics determine reactions
• Are you deploying a NEW product?
– Capture of market share
– Capture of competitor traffic
• Are you releasing a NEW feature?
– Traffic to the specific feature
– Time spent on the application
• Are you improving an EXISTING feature?
– Conversion tracking
– Increase in overall transactions

12. Your status is your lens

13. Keep in mind…
• A potentially shippable product approach will keep
stakeholders at ease
• At the closing of each implementation, a DEMO
should be available for progress to be visible
• Character needs to guide and protect the team’s
focus (milestone mobbing / swarming)
• Making progress is as much about controlling as it is
about reporting (business value vs. date pressure)

14. Sources
• Inspired – How to Create Products Customers Love –
Marty Cagan
• Scrum’s Product Backlog – Agile Requirements
Management – Marc Mansour -
http://agilebench.com/blog/the-product-backlog-
for-agile-teams
• Prioritization – Mitch Lacey -
http://msdn.microsoft.com/en-
us/library/hh765981.aspx

15. Questions or Comments?
federico.ortega@globant.com
@orteganieto