Support Driven Design

1519587b1a0febb658c36c94f6272b0d?s=47 Kevin Hale
May 02, 2012

Support Driven Design

At Wufoo, everyone has to wear multiple hats in the company and that includes manning the inbox and doing customer support every single week. One of the interesting side effects of having a company where designers, developers and even the accountant has to answer support emails, is that everyone has a stake in making sure application is as easy to use as possible. We've called this approach to creating software Support Driven Development and in this talk I'll share how this model transformed every member of their company to be dedicated to the principles of clarity and simplicity.

1519587b1a0febb658c36c94f6272b0d?s=128

Kevin Hale

May 02, 2012
Tweet

Transcript

  1. Support Driven Design Kevin Hale

  2. @ilikevests

  3. None
  4. None
  5. 60+ Languages

  6. Individuals, Developers, Designers, Non-Profits, Teachers, Students, Universities, Research, Real Estate,

    Marketing, Healthcare, Banks, SMBs
  7. None
  8. None
  9. None
  10. 676% 29,561% $25.3 M Average Startup $118K Wufoo

  11. The Secret?

  12. None
  13. None
  14. We are fanatical about creating meaningful relationships with our users.

  15. New Users :: Dating Existing Users :: Marriage

  16. New Users :: Dating

  17. Homepage Landing Pages Plans / Pricing Login Signup

  18. First Email Account Creation Blank / Starting Interface Login Link

    Ad Link First Support
  19. None
  20. None
  21. None
  22. None
  23. None
  24. Existing Users :: Marriage

  25. Dr. John Gottman

  26. Everyone fights.

  27. Cost / Billing Users’ Users Performance Roadmap Others Money Kids

    Sex Time Others
  28. 10% 100% 9% Website Visitors Signup to Trial Login to

    Account 1% 5% .5% Active Users Paying Users Staying Users
  29. 10% 100% 9% Website Visitors Signup to Trial Login to

    Account 1% 5% .5% Active Users Paying Users Staying Users
  30. Support Driven Design

  31. Software engineers and designers are often divorced from the consequences

    of their actions.
  32. Before Launch: 100% development After Launch: 33% dev, 33% bug

    fix, 33% support
  33. Responsibility Accountability Humility

  34. Golden Rule

  35. Do to others as you wish others to do to

    you.
  36. Create for others as if you have to support it.

  37. Creators = Supporters

  38. None
  39. None
  40. None
  41. None
  42. None
  43. None
  44. We make everyone do customer support.

  45. Support Responsible Developers and Designers Give the Best Support

  46. +500,000 users ~5 million people ~400 issues +800 emails 7

    -12 minutes
  47. 0 100 200 300 400 4 6 8 10 12

    14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 2 4 6 Weekly Totals 0 100 200 300 400 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 2 4 6 Daily Support Sunday Monday Tuesday Wednesday Thursday Friday Saturday 2008 2009 2010
  48. None
  49. None
  50. None
  51. None
  52. Support Responsible Developers and Designers Create Better Software

  53. None
  54. None
  55. None
  56. What happens when you make everyone responsible for creating remarkable

    supportevery single week?
  57. 0 75,000 150,000 225,000 300,000 Jun-06 Dec-06 Jun-07 Dec-07 Jun-08

    Dec-08 Jun-09 Dec-09 0 100 200 300 400 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 2 4 6 Users Support
  58. Scaling Support

  59. None
  60. None
  61. None
  62. Engineering Management Share 93 From late 2006 to early 2009,

    I was privileged to hold a variety of management positions in Facebook Engineering, ranging from manager of various teams to director of engineering. During that time, the engineering department grew from about 30 to around 200 engineers. It was an era that roughly spanned the launch of News Feed, Facebook Platform (the first F8 conference), the launch of our self-serve advertising system (now a major contributor to our positive cash-flow), internationalization of the site, and Facebook Connect. We went from being a niche college social network with less than 10M users in 2006 to a global phenomenon with over 250M users by early 2009. It was a period of time during which the company grew from being a small startup (under 100 employees) to a medium-sized company (800+ employees). Coming to Facebook, it was clear that the company was likely to expand rapidly, and a great hope of mine was to play a part in influencing key developmental decisions during this critical period so that far into the future, Facebook and its engineering department would be a vibrant and enduring institution. From my time at other technology companies which had gone through this period of hyper- growth, I had formed ideas about key cultural and organizational factors that I felt contributed to creating a strong engineering environment, one that the best people would want to work in and which maximize innovation and rapid execution. Today I have returned to being a hands-on engineer, and the other day when I reflected upon how I found it quite pleasant that I was now getting to enjoy working in such a productive engineering environment, the person I was with asked me, "Well, what ARE the Yishan tenets of growing a great engineering organization?" I had never quite thought about my ideas in such a doctrinaire way (and indeed it is dangerous to do so, lest they become unnecessarily enshrined), but I'll indulge anyway and see if I can marshal them into a numbered list, so here they are: 1. Hiring is number one 2. Let process be implemented by those who practice it 3. Promotion from within 4. Tools are top priority 5. Technical Leaders Note: these do not include various "obvious" Silicon Valley ideas about how to create a good technology startup like "hire the best people" or "have an environment that ensures open communication." There is a list of about a dozen of these that everyone knows; my list is a set of more (I consider) non-obvious things, things that rapidly growing technology organizations don't find it obvious to do easily. I believe that organizations which successfully integrate these ideas into their culture and habits end up becoming stronger, enduring, and self-renewing, while those which don't eventually weaken and spiral off into mediocrity. Over the next five days, I'll write a post about each one of these, elaborating what I mean by them and why I think each is important. To those who've worked with me over the last few years, now you get to see my playbook and why I did the things I did. I hope people find this useful and fun!
  63. growing a great engineering organization?" I had never quite thought

    about my dangerous to do so, lest they become unnecessarily enshrined), but I'll indulge a list, so here they are: 1. Hiring is number one 2. Let process be implemented by those who practice it 3. Promotion from within 4. Tools are top priority 5. Technical Leaders Note: these do not include various "obvious" Silicon Valley ideas about how to people" or "have an environment that ensures open communication." There is a list is a set of more (I consider) non-obvious things, things that rapidly growing easily. I believe that organizations which successfully integrate these ideas into t enduring, and self-renewing, while those which don't eventually weaken and spi
  64. None
  65. None
  66. None
  67. None
  68. Gmail GreaseMonkey Plugin

  69. We make everyone say thank you.

  70. None
  71. None
  72. None
  73. None
  74. None
  75. None
  76. None
  77. Best Price Best Product Best Overall Solution

  78. Thanks!