A Product Manager always pays his debts Feedback on how "the product team has prioritized a technical project" at Videdressing.

1. How the product team prioritized
a technical project
to optimize the business

2. Why and How
to prioritize a
refactoring
project
“A Product Manager always pays his debts”

3. Who are we?

5. Describe platform (Desktop,
MWS, IOS, Android)
Mobile Platform:
- 60% traffic,

6. Product & Tech
Organization
● 2 teams (product & tech)
working on the same floor, 1
common spirit
● Agile organization:
○

7. Why should we refactor
the code?

9. plateforme hét
Each platform had his own
payment module!

11. Statement

13. What is the scope of the
refactoring?

16. How can we prioritize?

17. Explain executive team & stakeholders we will not release
big feature for the next 9 months

18. ● Stop or report other projects
● Task force dedicated during 9 months
● Don’t solve bugs on legacy
● Decrease momentarily the quality of service to improve it
afterwards
Impact

19. Progressive activation of Means of Payment
● Depending on the business impact and the risk incurred,
we have prioritized the deployment of payment methods by platform
● Think about Feature Flipping & “feature flooring”
at the beginning of the project

20. 2016 2017
Q3 Q4 Q1 Q2 Q3 Q4
Desktop (50%)
Mobile web
(20%)
App IOS
(25%)
App Android
(5%)
CB 3X & 4X (22%) Paypal (23%) CB 1X (50%) Wallet (5%)payment
method:
Launch Roadmap

21. Results
● 95% of orders are now processed on the new system
- bug free
- easy to track/reconciliate
● Very positive impact on Customer Care contact rate
● Enabler for Mobile platforms better performance
- From 40% to 50% of mobile contribution in sales
- Allows mobile-first strategy as the platforms are now upgraded
● The user/order lifecyle is now readable from the inside, not only developers

22. Order Final State Machine

23. What we have learned?

24. ● Postponing information to board/exec team on platform state
● Take too much time to decide to launch the refactoring
● Spending too much energy to solve bugs instead rebuilding
● No unified & shared documentation on business process
(the process draw was the first “release” of the project)
and kill some old myth about our process
● Even if stakeholders were involved for project scoping,
we did not involved them enough/on a regular basis once
the project was in development
Mistakes

25. 5 rules to respect
- Involve stakeholders
- Stay Focus and protect the team
- Don’t feed the monster (Legacy)
- Evangelize new FSM (Final State Machine)
- Make Code Review

26. Q&A
@jolyjerome
jeromejoly@gmail.com
/jeromejoly1