The document discusses lessons learned from Yammer's development of an inbox feature. It describes how Yammer did not properly implement minimum viable product techniques, instead overbuilding the initial feature. This made it difficult to determine what parts of the product were successful or not. The document recommends taking a more iterative approach, beginning with core functionality and adding layers over time to better understand impacts of changes and allow for course correction.

1. Yammer Inbox
Building MVP (Not), Listening to Customers (Too much), and
Releasing ‘Strategic’ Features (Oh no…)
Jason Shah
@jasonyogeshshah
me@jasonshah.org
Product Manager, Yammer
@jasonyogeshshah http://blog.jasonshah.org
Startup Product Summit

2. • Product prioritizes. Leverages analytics. Negotiates
MVP with engineering. Specs with design.
• 2-10 Weeks. 2-10 Engineers. Teams also include
analytics, design, product marketing.
• Big board and weeklies. Loosely agile.
• PM will be on 3-5 projects at a time.
• New ‘initiative’ model aimed to scale agile processes
@jasonyogeshshah http://blog.jasonshah.org
How Yammer Builds

3. @jasonyogeshshah http://blog.jasonshah.org
Yammer Inbox
• Vision: Yammer is the best
place for people to get work
done.
• Problem: People have a hard
time getting work done in
Yammer as threads are siloed
in groups and it’s hard to
prioritize.
• Goal: Increase engagement
(days engaged), retention (1
and 7 day retention)

4. @jasonyogeshshah http://blog.jasonshah.org
Building MVP (Not)

5. @jasonyogeshshah http://blog.jasonshah.org
To MVP or Not
How do you determine what is actually
minimum viable product and what is not?
If you overbuild, how do you know what worked
and doesn’t work in a product experiment?

6. @jasonyogeshshah http://blog.jasonshah.org
We released. We analyzed. We scratched our
heads.
Spent more than a month in analysis because
things were so entangled.
Eventually restarted the experiment. Saw gains,
but we barely knew what worked and what did
not work. So future iteration was constrained.

7. @jasonyogeshshah http://blog.jasonshah.org
What We Could Have Done
• Be more rigorous about existing data
• Build more iteratively
• Begin with threads you began
• Later add in threads you were mentioned
on or replied to
• No read-states
• No concept of following

8. @jasonyogeshshah http://blog.jasonshah.org
OK we messed up…

9. @jasonyogeshshah http://blog.jasonshah.org
Annoying, you say?

10. @jasonyogeshshah http://blog.jasonshah.org
Sorry, deal with it.

11. @jasonyogeshshah http://blog.jasonshah.org
But the customer is always right.
Not really. But we caved.
Negative feedback. Just got acquired. We didn’t
know what we did right and what we did wrong.
So…let’s give them what they want. Filters!

12. @jasonyogeshshah http://blog.jasonshah.org
Look! We’re geniuses.

13. @jasonyogeshshah http://blog.jasonshah.org
But it didn’t do anything.

14. @jasonyogeshshah http://blog.jasonshah.org
Not even for the vocal minority!

15. @jasonyogeshshah http://blog.jasonshah.org
So what?
• Build incrementally toward a guiding vision, so
you know where you went wrong and can
course-correct.
• Listening to your customers and building what
your customers prescribe are very different.
• Shipping neutral and ‘strategic’ features is how
you bloat your product and lose. Don’t lose.

16. Don’t be shy.
@jasonyogeshshah http://blog.jasonshah.org
Q&A