Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Dashlane Mission Teams

939 vues

Publié le

We explain the history of our agile organization with a focus on the latest round of evolution of our Product and Engineering organization, moving from business-oriented feature teams to mission teams.

Publié dans : Logiciels
  • Identifiez-vous pour voir les commentaires

Dashlane Mission Teams

  1. 1. From Feature Factories to Mission Teams
  2. 2. My name is Frédéric Rivain, CTO of Dashlane. We build a Password Manager, to help you manage your identity and your payments in a simple and secure way everywhere.
  3. 3. A bit of context Funded in 2009 by Bernard Liautaud and 3 Centrale students 120 employees in Paris and New York • Product & Engineering in Paris • Marketing & Sales in New York • Consumer product (B2C) + Enterprise offer (B2B) • 8 “product & engineering” teams
  4. 4. An Agile Story • Iterative evolution. • Learning as we grow. • Adapting to our needs and scale. • Various states of maturity. Garage Mode 2014 Move to Agile. Scrum by the Book. Roadmap & Portfolio 2015 OKR Feature / Business Teams 2016 2017 Mission Teams2018
  5. 5. Half-Baked Agility* * As quoted from Felipe Castro
  6. 6. Half-Baked Agility* Operations Tactics Strategy Culture Agile Development Scrum, Kanban… Lean Goals / OKR 1 2 3 4 * As quoted from Felipe Castro
  7. 7. Running Agile Operations • Scrum is about operational agility. A methodology for day-to-day organization. • Wrap the Scrum cycle with a Lean process, to improve Alignement and Visibility at Company level. Formalize the Project Collaborative Specifications Development Validation Release to Production Assess results Evaluate and prioritize AGILE PRODUCTION Stakeholder Lean overall approach Agile production cycle
  8. 8. Escaping the perfect Feature Factory • Project-driven roadmaps • Tracking feature delivery • Only Agile at the Operations level. • Strategy is based on annual goals with overall top-down planning.
  9. 9. Expanding to an Agile Strategy • Goals and Performance Management driven by OKR. • Change the mindset:  driving Outcome / Maximizing Value not Output • More on OKR in Appendix if you are interested Operations Tactics Strategy Culture Agile Development Scrum, Kaban… Lean Goals / OKR 1 2 3 4
  10. 10. Looking for the right organization
  11. 11. Legacy Platform Teams • Originally, platform tech teams: • Desktop, iOs, Android, Web, Server, Semantic Engine • Works well for small teams. With one line of business. • Starts hurting as you grow the team and as you diversify: • Synchronization issues between platforms • Inconsistency in product • Technical focus > Business focus • Conway’s Law • That structure does not scale well.
  12. 12. Transitioning to Business Teams • Inspired by the Feature Teams model (a la Spotify) • Cross-functional teams including: • Product, Development, QA + Design, Analytics, Product Marketing, User Support • « Mini Startup » inside the company, with end-to-end responsibility on their scope. • Business focus • Acquisition • Conversion • Retention • 2 focused on B2B • 1 for Partnerships • 1 for our semantic engine
  13. 13. Transitioning again to Mission Teams Business Teams Mission Teams Project Teams “Increase retention” Too many ideas, no filtering lens for Product No clear sense of when to stop and do something else Lagging indicator-focused “Get more passwords” Lots of room for creativity within a boundary Success is clear Leading and lagging indicators “Build feature X” No room for ideas Success is delivery not results Leading indicator-focused
  14. 14. Scope is not business only • Include perspectives from Product, Marketing, Engineering... • Product Experience Team: • The teams create the vision, strategy and idea implementation. They are actually shaping it. • They see the whole: from the origin story all the way to the idea pushed to the customer. • Teams feel empowered.
  15. 15. Upgrading the Feature Team Organization • Cross-platform teams, with dedicated resources and skills, based on Missions • Small teams comprised of one Product Manager, 2 to 6 engineers, one UX designer. • Co-located • A double organization: • Mission Teams • « Platforms » communities of practice MISSIONS PLATFORMS Mission Team 1 Mission Team 2 Mission Team 3 … Mission Team N Product Manager x x x x Scrum Master x x x x QA x x x x Server x x iOS x xx Android x xx Windows x xx Web x xxx UX Design x x x x Analytics x x x x User Support x x x x
  16. 16. How we run it today • 3-week Cadence • 2 week Mission sprint • 1 Platform Week • Quarterly Review Meetings (Rodeos) • Progress • Mission Team review: Continue, Change, Disband • Staffing • Tools • Jira + Confluence • ProductBoard • Communication • Biweekly sprint reviews (for the teams themselves) • Sprint Dashboards • Town Hall Demos
  17. 17. Looking for value
  18. 18. Getting it “Right” versus to the “End” EndStart Right
  19. 19. Learning Drives Value Idea Right Discovery Decision Prioritize Build Learn Learn Learn Build Build Value Value Value
  20. 20. Generating Value • Each initiative must generate at least one of the below… 1. Adoption: achieving customer value 2. Learning: from the customer 3. Feedback: internal discovery from Tech, Product… 4. Risk Management: reducing risk and unknowns
  21. 21. Password Import “Brain Dumps” Easy Account Detection Area of focus (including main KPI) Reduce number of day 1 no password events by 30% Increase number of accounts storing >0 passwords on day 1 by 30% Increase number of accounts storing >0 passwords on day 1 by 30% Ideas (for how we might address area of focus) • Web history import: scan web history and curate list of likely sites where user has an account • Notes app import: build a sync connector with OneNote, Evernote, and other popular notes apps to scan and parse potential account/password pairings • Pen and paper import: customers can use their phones to SMS photos of pen and paper password docs, process with machine learning OCR (or mechanical turk) to provide same-day import • Intermittent questioning: test a program by which PC users are intermittently asked to provide passwords one at a time via a ”brain dump” request. Ideal frequency and user experience will be determined via the test. • Logos matchmaking: in OOBE, show a set of logos of popular consumer sites and have users check all that apply. Follow-up by asking users to provide credentials for them (including a bulk add feature if appropriate). • Email scan: sync with user’s email to construct a picture of all likely accounts a user will have; prompting user to verify and provide credentials. • Internet pass-through: test a feature by which Dashlane monitors the user’s internet connection for a period of time, thus creating likely account lists regardless of which browser is being used; prompt user for credentials at the end of the monitoring period Additional KPI's (used to track success) • % increase in import activity • <% bounce rate from brain dump prompt experience • % accuracy in suggested versus claimed accounts OKR: Increase desktop week 4 engagement rate from 18% to 30% by significantly increasing day 1 password adds. Mission Team Prioritization Framework example: Get More Passwords
  22. 22. Balancing 10% vs. 10x 10%
  23. 23. 10% vs. 10x 10x
  24. 24. Product Research: identifying problems to solve at three altitudes 1. Product Vision 2. Future Missions 3. Current Missions How do we jumpstart our experimentation with market and consumer insights? What missions should we prioritize next? What do we do beyond optimization? What are the big market shifts and opportunities? Who should we target and with what value proposition?
  25. 25. Solving for Both Ends of the Spectrum 10% 10x Experimentation- led Research-led Impact Certainty Access control on voice-powered assistants will need to be solved Users will want centralized control over their data There will be a Digital Identity consolidation Identity will become social; users will want to select and share access Users will want to protect themselves when on unsecure WiFi networks New users will immediately want to secure their accounts with new passwords iOS users will want to autofill passwords when using apps “Solve this problem” “How will we solve this problem?” “What is the problem we need to solve?”
  26. 26. 3 Key Take Aways 1. Trust your teams to be autonomous. Guide but do not control. Empower. 2. Experiment all the time. Small is better. Aim for learning. 3. Assess for value, not for delivery.
  27. 27. Questions
  28. 28. Appendix
  29. 29. OKR – Objective & Key Results • A framework of defining and tracking objectives and their outcomes • Created by Intel, in the 1970s • Made popular by John Doerr and Google • Adopted by most Silicon Valley companies
  30. 30. OKR Components • O = Objective: • Aspirational. • Memorable – Simpler, shorter, remarkable. • Qualitative. • KR = Key Results: • 2-5 per Objective. • Quantitative & Measurable. • Metrics (recommended) or Milestones.
  31. 31. OKR Example • Objective: Delight our customers • Key Results: • Increase average weekly visits from 3.1 to 3.3 per active user • Improve Net Promoter Score from 46% to 52%. • Increase non paid (organic) traffic from 70% to 80%. • Increase engagement (users that complete a full profile) from 60% to 75%. • Objective: Taming the Autofill Dragon • Key Results: • Achieve successful autologin on the top 50 Chinese websites • Achieve successful autologin on the top 50 Korean websites O can be fun!
  32. 32. Dashlane OKR • Yearly Company OKR – High-Level Strategy • KR can be reviewed and adapted every quarter or as needed. • But O should theoretically remain stable in time • Team Quarterly OKR – Tactical Short Term • Impacting Company OKR
  33. 33. Moving to OKR • It is hard, for everybody but especially for engineering. • Big change of mindset: • Focus on business impact and value first • Projects come second. • In theory, delivering a feature does not really count for success. • Need to be very data-driven. • Need to accelerate massively the cycle time and release process. • Need experimentation tooling such as strong A/B Test Engine and Feature- Flipping. • Need to shift to a more bottom-up process (~60% bottom-up, ~40% top-down).
  34. 34. OKR learnings • Don’t be too ambitious, else teams get frustrated with unreachable goals. Roofshots rather than Moonshots. • Have fewer O and KR rather than too many. Otherwise you loose focus. • Not all projects/initiatives are related to OKR. • Allow for different types of KR: • Learning metrics • Business metrics • Technical metrics • Time those KR based on the current progress and based on the outcome you are looking for. Learning first before optimizing and impacting business for instance.