How Yammer Stayed Lean Post-Acquisition: Customer Development as Survival Strategy
-
Upload
cindy-alvarez -
Category
Internet
-
view
705 -
download
0
Transcript of How Yammer Stayed Lean Post-Acquisition: Customer Development as Survival Strategy
How Yammer Stayed LeanPost-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 below items was part of the acquisition deal.)
How We Build Product: Problem First
• Product vision, not roadmap• Identify problem through:– Analytics data– Research– Customer suggestions (high degree
of skepticism)
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”
How We Build Product: Cross-Functional Teams
• Full cross-functional representation– Product Manager– Designers (visual & interaction)– Researcher– Data analyst– Tech Lead– Engineers
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
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”
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
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?
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?
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
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!
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”
“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.
Acquisitionis a lot like
customer development!
Form hypothesesState assumptions
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.
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?
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 open space
• Visited people in their office, anyone who’d listen
• Volunteered to give talks through internal training group
Share notes with your teamand update your
assumptions
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)
Stop doingthings that don’t work
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
Celebrate successes!
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