Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How Yammer Stayed Lean Post-Acquisition: Customer Development as Survival Strategy

Yammer's product development process & how we kept it & evangelized it to more of MSFT.

  • Login to see the comments

How Yammer Stayed Lean Post-Acquisition: Customer Development as Survival Strategy

  1. 1. How Yammer Stayed Lean Post-Acquisition Customer Development as Survival Strategy
  2. 2. I’ve worked most of my career in startups, but somehow I keep working with enterprises:
  3. 3. So here we were at Yammer, just working hard, y’know…
  4. 4. …when this happened.
  5. 5. We totally had an open mind.
  6. 6. But the precedents weren’t great…
  7. 7. What We Stood to Lose • How we build product • How we make decisions • How we maintain culture (Actually, keeping these below items was part of the acquisition deal.)
  8. 8. How We Build Product: Problem First • Product vision, not roadmap • Identify problem through: – Analytics data – Research – Customer suggestions (high degree of skepticism)
  9. 9. How We Build Product: Autonomy • Goal: teams operate autonomously • Goal: no unsolicited day-to-day manager approvals, opinions • “Hire smart people, unblock obstacles, and trust them to get sh*t done”
  10. 10. How We Build Product: Cross-Functional Teams • Full cross-functional representation – Product Manager – Designers (visual & interaction) – Researcher – Data analyst – Tech Lead – Engineers
  11. 11. How We Build Product: The 2-10 Model • Scope it to 2-10 engineers, 2-10 weeks – If it’s bigger than that, it’s not MVP • Best = fastest speed to learning
  12. 12. How We Build Product: No “Experts” • People assigned to different feature/product areas each time – Prevents silo-ing – Prevents territoriality / deferral to “the search expert” or “the iOS expert”
  13. 13. How We Make Decisions: Test Everything • All features A/B tested • Goal is learning, not shipping – If it doesn’t move metrics, don’t ship it – We ship ~50% of projects; if that number gets higher, it means we’re not trying ambitious enough changes
  14. 14. How We Make Decisions: Maximize Impact • What % of users will this affect? • Can this change help people without them needing to take explicit action? • Will this change drive people to take the actions we want them to take?
  15. 15. How We Maintain Culture: Systems Thinking • “95% of the variance in productivity is due to the system, not the individual” – Deming – Is recruiting & hiring getting us the candidates we need? – Is staffing projects keeping people productive? – Is feature quality what we need? – Do people understand the mission and their part in it?
  16. 16. How We Maintain Culture: Manager as Servant Leader • Managers don’t code/design/write specs • Remove obstacles • Push people beyond their comfort zone • Advise when asked • Provide higher-up view / vision
  17. 17. How We Maintain Culture: Data, Not Opinions, Wins • Kill the HiPPO • Quantitative data proves that a problem exists, that a feature works • Qualitative data reveals problems and opportunities, shows why a feature works/doesn’t • ANYTHING can be put to a test!
  18. 18. How We Maintain Culture: Clarity around ‘Culture Fit’ • “Product sense” • Ability to communicate clearly / work openly • Problem-solving ability • Willingness to express dissent* • NOT “the best engineer” / “the best designer”
  19. 19. “Don’t pick your battles. Fight for everything.” - Kris Gale, VP Engineering
  20. 20. …though, apparently, just telling people “You’re doing it wrong” is not a successful strategy.
  21. 21. Acquisition is a lot like customer development!
  22. 22. Form hypotheses State assumptions
  23. 23. Hypothesis We believe cloud services teams are struggling with moving fast enough and making data-informed decisions and we can help them by sharing what we’ve learned.
  24. 24. Assumptions • Teams will tell us, “that’s just the way it’s done” and not listen • Individuals will use bureaucracy to avoid change • Teams are optimizing for “avoid mistakes” vs. “recover from mistakes” • PMs/Research feels threatened that Data Analytics will obsolete them • What kind of people stay at a company for 10+ years?
  25. 25. Find the early adopters willing to listen to your beta arguments
  26. 26. Finding Early Adopters • Posting on the MSFT Yammer network • Redmond casual “Lean Day” – chairs and paper signs in an open space • Visited people in their office, anyone who’d listen • Volunteered to give talks through internal training group
  27. 27. Share notes with your team and update your assumptions
  28. 28. Updated Assumptions • Individuals are reasonable, the bureaucracy is awful. • The person who knows X is happy to help; their manager will be a bottleneck • Teams are comfortable taking risks, they just need reassurance. • People know their products aren’t good enough yet (but are eager to figure out how to get better)
  29. 29. Stop doing things that don’t work
  30. 30. No. • Too much “systems thinking” and theory • “Minimum Viable Product” • Asking GMs for help/resources/collaboration • Asking for behavioral change without offering stepping stones • Long-term collaborations with “traditional” teams • Yammer North
  31. 31. Celebrate successes!
  32. 32. Yes, more! • “Borrow an analyst” for teams who wanted to explore A/B testing • Research + Analytics talks • Dropbox integration (“take that, OneDrive!”) • Spirit of the law, not letter of the law • If you can’t beat ‘em, join ‘em (and then covertly change their minds) • Yammer Redmond