It takes a village: Scaling your vision


Published on

A talk for Eric Reis /Steve Blank's UC Berkeley class on entrepreneurship. Given by Rashmi Sinha and Jonathan Boutelle (CEO and CTO of SlideShare).

Published in: Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Hi, we're Jon and Rashmi, and we're here to talk about bulding a metrics-driven organizationI'm sure you guys have been hearing a lot about metrics in this class so far. Am I right? We're going to be talking about how to get a whole company oriented around numbers."can't manage what you don't measure" is one of the oldest management cliches in the book. But … Founders emphaized too much. TEAM is what matters.
  • . But it's likely that a startup won't start out being metrics oriented. The initial rush of a startup is often about getting v1 of the initial vision of the product out the door. Initial product development is so hard that it's hard to focus on anything else. So at least for us, we came to metrics over time and we had to re-orient our organization around metrics.
  • Metrics as way to manage remote team
  • We had cake every time we hit a new 100k unique visitors. This meant we were getting cake ALL THE TIME. It got a little unhealthy. But was good team-building, communication of the goal and our progress towards it.
  • Technology part is hard (crunching big data) UI design is hard (data visualization design) Instrumenting the app is hard(ish).
  • No one wanted to work on metrics dashboard People used to working on live site, fast feedback loop. Metrics feels like boring internal work, like busywork
  • People DON’T like being accountable to what users do when they land on the page. Can feel unfair (I did my part, why won’t the users cooperate?)
  • Expectations for web apps have risen dramatically. The UI of an internal tool is going to be fugly and slow. People (yes, even founders) will bounce off a crap user interface now, even if it contains information that would help them do their job better.
  • Vanilla analytics are based on URLs. You almost certainly don’t care about behovior on individual URLs. You care about TEMPLATES. Google Analytics events lets you create categories and events within categories. Someone (usually non-technical) needs to own the names that get associated with each event, it can quickly get confusing otherwise. This is a classic product manager task.
  • N things we are balancing (slides viewed, sharing activity, ad clicking) Each comes at expense of other (engagement vs virality)
  • Need to itereate on metrics, and need to refactor / cut out junk in your metrics as well. Otherwise you’ll drown in numbers.
  • Response time for dynamic pages (within cluster) Response time (within cluster) Response time for downloading html (in browser) Response time for downloading and rendering all assets (in browser)
  • It takes a village: Scaling your vision

    1. 1. It takes a Village: Scaling your Vision Rashmi Sinha & Jon Boutelle SlideShare
    2. 2. Began with a Vision <ul><li>Share all presentations in the world </li></ul><ul><ul><li>A free, truly useful service </li></ul></ul><ul><li>Build community around presentations </li></ul><ul><li>Use YouTube as a metaphor / design guide </li></ul><ul><ul><li>Hit the same gaming dynamics (the leaderboard game) & distribution channels (embeds drive new users to site) </li></ul></ul>
    3. 3. Driven by Design <ul><li>Founders believed in importance of user experience </li></ul><ul><li>Early engineers very UX-focused </li></ul>
    4. 4. Where Everybody knows your Name
    5. 5. What led us to Metrics <ul><li>Becoming more disciplined about how to grow </li></ul><ul><li>Hard to scale by vision as team grew </li></ul><ul><li>Define a direction so team-members can independently execute against it </li></ul><ul><li>Launch of paid features </li></ul>
    6. 7. Metrics Version 1 <ul><li>Individual devs, individual metrics. </li></ul><ul><li>Built a web-based dashboard, with charting. </li></ul><ul><li>Highly configurable, inspired by Slide. </li></ul><ul><li>Highly visual: humans great at visual processing, pattern-matching </li></ul>
    7. 10. #fail
    8. 11. #epicfail
    9. 12. Why? Metrics
    10. 13. Metrics are not sexy
    11. 14. Metrics need a Social Context <ul><li>Making sense of metrics takes time. No social process around iterating based on metrics </li></ul><ul><li>No person in team who was driving metrics </li></ul><ul><ul><li>Developers often not right for this role. May see as distraction from code </li></ul></ul><ul><li>Metrics also need iteration! </li></ul><ul><li>Developers may resist being judged by the behavior of users </li></ul>
    12. 15. We are all Spoiled now
    13. 16. Metrics Axed my Favorite Feature <ul><li>Metrics make implicit prioritizations explicit. Some people (including founders) used to making decisions based on intuition </li></ul><ul><li>Reveal that some beloved features might be useless! </li></ul>
    14. 17. Event-Tracking FTW Focus on ratios of events to page loads, NOT absolute numbers.
    15. 18. Metrics Version 2 <ul><li>Email reports on a daily basis, showing numbers for a trailing range of days. </li></ul><ul><ul><li>Everyone working on project gets in their inbox (data comes to you) </li></ul></ul><ul><li>Lots of numbers (provide context). But one number identified as one to focus on </li></ul>
    16. 19. Social Process around Metrics <ul><li>Weekly meetings for each team </li></ul><ul><li>Review what shipped, review impact / lack of impact on numbers, plan next week </li></ul><ul><li>Always one person in product manager role: i.e. deep in metrics, shallow on code </li></ul>
    17. 20. Email!
    18. 21. More Email! Edit data
    19. 22. Case Study: 4x growth of leads collected <ul><li>For newly launched business features </li></ul><ul><ul><li>One number the main focus. Other periphery numbers </li></ul></ul><ul><li>Daily email reports worked well. Weekly meetings to plan for next week </li></ul><ul><li>Change paths every few weeks </li></ul>
    20. 23. Case Study: Metrics, Clean Code & Visual Design <ul><li>Main page: Slideview page </li></ul><ul><ul><li>Complaints of clutter, page load time. </li></ul></ul><ul><ul><li>Page performed well </li></ul></ul><ul><ul><li>Code underneath the page also fugly </li></ul></ul><ul><li>Solution: periodic refactorings / design cleanups. “Clean it up without trying changing to effect numbers” </li></ul><ul><ul><li>Visual tweaks while monitoring metrics </li></ul></ul><ul><ul><li>Balance: engagement vs. virality </li></ul></ul>
    21. 24. Hitting Local Maxima <ul><li>Stable metrics. Tweaks no longer lead to growth. Growth will come new ideas, directions, vision </li></ul>
    22. 25. Why Version 2 Works <ul><li>Push rather than pull </li></ul><ul><li>One number to focus on </li></ul><ul><li>Social context and process around the metrics </li></ul><ul><li>Warning: REALLY EASY to drown in metrics </li></ul>
    23. 26. How to Frame Team Goals <ul><li>Tasks: “Move this number using copy, creative, and simple design changes” </li></ul><ul><ul><li>Use any means necessary </li></ul></ul><ul><li>Success: Moving the number OR learning something interesting </li></ul>
    24. 27. Operational Metrics: an Interlude <ul><li>Site uptime, average speed of page load </li></ul><ul><li>Conversion: Ave time for conversion for each document, ave wait time for user </li></ul><ul><li>Apdex: </li></ul><ul><ul><li>Blended read of page load time </li></ul></ul><ul><ul><li>Page load time </li></ul></ul>
    25. 30. Why not use this neat charting for real time user data?
    26. 33. Using Infrastructure as a Service
    27. 35. What Would we do Differently <ul><li>Start in same way </li></ul><ul><li>Start paid services earlier </li></ul><ul><li>Hire non-engineers (who help drive by metrics) earlier </li></ul><ul><li>Nurture metrics mindset in team earlier </li></ul>