1) After being acquired by Microsoft, Yammer stayed lean by continuing to focus on customer development and maintaining their startup culture and processes. 2) Key aspects of Yammer's product development process included building products based on identified customer problems, autonomous cross-functional teams, and testing all features through A/B testing. 3) Yammer also focused on data-driven decision making, maintaining a supportive and empowering culture, and finding early adopters within Microsoft to socialize their approach.

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

2. I’ve worked most of
my career in startups,
but somehow I keep working
with enterprises:

3. So here we were at Yammer,
just working hard, y’know…

4. …when this happened.

5. We totally had an open mind.

6. But the precedents weren’t great…

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. How We Build Product:
Problem First
• Product vision, not roadmap
• Identify problem through:
– Analytics data
– Research
– Customer suggestions (high degree of
skepticism)

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. How We Build Product:
Cross-Functional Teams
• Full cross-functional representation
– Product Manager
– Designers (visual & interaction)
– Researcher
– Data analyst
– Tech Lead
– Engineers

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. 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. 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. 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. 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. 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. 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. 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. “Don’t pick your battles.
Fight for everything.”
- Kris Gale, VP Engineering

20. …though, apparently, just telling
people “You’re doing it wrong” is
not a successful strategy.

21. Acquisition
is a lot like
customer development!

22. Form hypotheses
State assumptions

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. 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. Find the early adopters willing to
listen to your beta arguments

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. Share notes with your team
and update your assumptions

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. Stop doing
things that don’t work

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. Celebrate successes!

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