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