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.
How Yammer Stayed Lean
Post-Acquisition
Customer Development
as Survival Strategy
I’ve worked most of
my career in startups,
but somehow I keep working
with enterprises:
So here we were at Yammer,
just working hard, y’know…
…when this happened.
We totally had an open mind.
But the precedents weren’t great…
What We Stood to Lose
• How we build product
• How we make decisions
• How we maintain culture
(Actually, keeping these be...
How We Build Product:
Problem First
• Product vision, not roadmap
• Identify problem through:
– Analytics data
– Research
...
How We Build Product:
Autonomy
• Goal: teams operate autonomously
• Goal: no unsolicited day-to-day
manager approvals, opi...
How We Build Product:
Cross-Functional Teams
• Full cross-functional representation
– Product Manager
– Designers (visual ...
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
• B...
How We Build Product:
No “Experts”
• People assigned to different
feature/product areas each time
– Prevents silo-ing
– Pr...
How We Make Decisions:
Test Everything
• All features A/B tested
• Goal is learning, not shipping
– If it doesn’t move met...
How We Make Decisions:
Maximize Impact
• What % of users will this affect?
• Can this change help people without
them need...
How We Maintain Culture:
Systems Thinking
• “95% of the variance in productivity
is due to the system, not the
individual”...
How We Maintain Culture:
Manager as Servant Leader
• Managers don’t code/design/write specs
• Remove obstacles
• Push peop...
How We Maintain Culture:
Data, Not Opinions, Wins
• Kill the HiPPO
• Quantitative data proves that a
problem exists, that ...
How We Maintain Culture:
Clarity around ‘Culture Fit’
• “Product sense”
• Ability to communicate clearly / work
openly
• P...
“Don’t pick your battles.
Fight for everything.”
- Kris Gale, VP Engineering
…though, apparently, just telling
people “You’re doing it wrong” is
not a successful strategy.
Acquisition
is a lot like
customer development!
Form hypotheses
State assumptions
Hypothesis
We believe cloud services teams are
struggling with moving fast enough
and making data-informed decisions
and w...
Assumptions
• Teams will tell us, “that’s just the way
it’s done” and not listen
• Individuals will use bureaucracy to
avo...
Find the early adopters willing to
listen to your beta arguments
Finding Early Adopters
• Posting on the MSFT Yammer
network
• Redmond casual “Lean Day” – chairs
and paper signs in an ope...
Share notes with your team
and update your assumptions
Updated Assumptions
• Individuals are reasonable, the
bureaucracy is awful.
• The person who knows X is happy to
help; the...
Stop doing
things that don’t work
No.
• Too much “systems thinking” and
theory
• “Minimum Viable Product”
• Asking GMs for
help/resources/collaboration
• As...
Celebrate successes!
Yes, more!
• “Borrow an analyst” for teams who
wanted to explore A/B testing
• Research + Analytics talks
• Dropbox integr...
Prochain SlideShare
Chargement dans…5
×

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

1 819 vues

Publié le

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

Publié dans : Internet
  • Soyez le premier à commenter

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

×