- Evangelizing your hardware product at hackathons requires maximizing the number of successful projects built using your technology. The key is helping developers succeed rather than focusing on marketing or sales. Workshops and documentation are important to answer questions and avoid redundant support. Success is measured by the number of projects completed per device distributed, so the product must be hackathon-ready with intuitive setup. Most outreach efforts occur in the first day, so marketing must be concise and excite developers to try your product early on. Developer success, not impressions, is the ultimate goal.

1. Evangelizing Your “Thing”
Lessons learned bringing hardware devices to hackathons
by Rex St. John (@rexstjohn)

2. Rex St. John (@rexstjohn)
Internet of Things Evangelist, Intel

3. We brought Intel Edison to more than 30
collegiate events last year.

4. Many of the developers we met had never seen
a Linux terminal before.

5. We made these
developers successful.

6. And so can you!

7. Here is what you need to
know.

8. An evangelist’s job is to maximize
projects built with their technologies.

9. Their job is to convince developers to
choose their devices and finish projects.

10. They are not salespeople, they are there
for the good of the event.

11. That means helping people no matter
what technology they choose.

12. Developers engage like this
(hands on).

13. When developers receive a gadget,
their brains turn off.

14. No one reads at a hackathon.

15. That’s why it is called a
“hackathon.”

16. Reading is work.
They came to have fun.

17. If you have important information to
communicate, you must do it up front.

18. Developers will listen for a bit if they
know they are getting hardware.

19. But you need to keep it short.
(45 minutes or less ideally)

20. So do it in the first few hours.

21. The first day of a hackathon
is the most important.

22. 85% of your work as an
evangelist happens in the
first few hours.

23. No one knows about your
“thing.”

24. You need to get them
excited to use your
product.

25. On the first day, people
are still forming teams.

26. By the second day,
developers have made
their choices.

27. It is often “too late” for
you to convince them to
use “your thing.”
(although there are always exceptions)

28. You are not the only
company at the event
with a “cool thing”

29. It’s a good idea to
approach folks and
asking them questions…

30. “So what are you thinking
of building this weekend?

31. “Have you built many
hardware hacks before?

32. “What programming
languages do you know?

33. “JavaScript?
“Cool, we have this cool device
called “Intel Edison” that lets you
program hardware using
JavaScript!

34. “We are doing a workshop
after the keynote, stop by if
you want to get a device.

35. “We also have a prize for
best use of Edison this
weekend, hope to see
you there.

36. You get the idea.

37. You must market your
device at the start of the
event to build interest.

38. You should also do a
workshop.

39. A collegiate hackathon may
have 500 – 1,600 participants.

40. There is only one of you.

41. If you hand out devices without a
workshop, expect to answer the
same questions dozens of times.

42. The average team is 4
people, 40 devices mean
120 developers potentially
interacting with your gadget.

43. That translates into a lot of
redundant questions…

44. Where are the docs? How do I
plug it in? Which USB do I need to
plug in? Where are the docs?
Which USB do I need to plug in?
How do I get it online? Which
USB do I need to plug in? How do
I get it online? How do I get it
online? Which USB do I need to
plug in? How do I get it online?

45. You should really do a
workshop to cover these
questions.

46. You should also have an
intro slide deck for the
keynote.

47. No more than 5-10 slides,
don’t waste people’s time.

48. Don’t spend 15 minutes
rambling.

49. Developers came to build
fun projects, tell them how
they can use your thing to
do that.

50. Introduce yourself, your
product, what people can
do with your product and
your prize.

51. Then say “join me for a
workshop after this to get
devices.”

52. The end.
Keep it simple, not boring.

53. Advanced evangelists often
have interactive demos with
audience participation and
live coding.

54. You are a technical
resource to support the
participants, even if they
have questions on other
topics.

55. You are an ambassador on
behalf of your company into
the developer community.

56. Leave a good
impression.

57. Why do hackathons
matter?

58. Hackathons are now a college sport
(and students are in charge)

59. “1,500 hackathons planned in 2014”
–Vivek Ravisankar (@rvivek)

60. *a non-complete list of sponsors for HackGT, in it’s first year!
Competition for developer attention is
intense

61. Attendence Total Prize Value
MHacks ~1,300 ~$31,000
PennApps X ~1,300 ~$30,000
CalHacks ~1,200 ???
HackGT ~700 ~$60,000+
HackRU ~700 ~$10,000+
DubHacks ~500 (capped) ~$10,000+
HackTX ~500 ???
Attendance is taking off
(a few events we attended this year)

62. Hardware + wearables stand out
Be the first device students learn to hack on

63. Developers cross-pollinate + talk
Students may attend dozens of events before graduating (travel reimbursements)

64. Some Lessons

65. Developer Success Is The Only Metric
Developer Success Is The Only Metric
Developer Success Is The Only Metric
Developer Success Is The Only Metric
Developer Success Is The Only Metric
Developer Success Is The Only Metric
Developer Success Is The Only Metric
Developer Success Is The Only Metric
Developer Success Is The Only Metric
Developer Success Is The Only Metric
Developer Success Is The Only Metric
Developer Success Is The Only Metric
Developer Success Is The Only Metric
Lesson #1: Developer Success Is The Only
Thing That Matters
Not impressions, conversions, devices distributed etc

66. The target metric is
“projects built per device
distributed”

67. If you hand out 40 devices
and get 3 projects, you are
probably doing something
wrong.

68. We averaged 50% or greater
projects per device issued.
Sometimes 80% or more.

69. These metrics can vary wildly
based on the schools and
participants, nature of the
hackathon.

70. Hardware focused hackathons
at schools with strong EE
departments often did well.

71. Lesson #2: “Hackathon ready” is a higher
standard of ready
If your product is “hackathon ready,” then it is ready.

72. Lesson #3: Hackathons are not a branding
exercise
Looks like marketing, smells like marketing, sounds like marketing…not marketing

73. “We traveled 2,000 miles to be here and spent 72 hours for nothing because of you”
Lesson #4: Your device can ruin a team’s
entire event

74. We are not perfect, sometimes
technology doesn’t work well.

75. Apologize and take the blame
and promise to see that the
problems are fixed.

76. “I am going to send an email
about this now, we will make
sure this doesn’t happen again

77. “Can you give me your email?
I will follow up with you when I
hear back about this next week

78. Consider sending them a
“make good” item if you
can do so

79. DX
Developer Experience

80. Introducing HDX
Hardware Developer Experience
HDX is synonymous with strong performance at hackathons

81. How do you achieve
HDX?

82. Work backwards from “hackathon
conditions” to your product

83. 8-36 hours to build a project with your
hardware, no time to waste

84. Power on, Wi-Fi, BLE in less than 10
minutes

85. Expect HTML based login screens, isolation mode to be turned on
Your “thing” must handle bad Wi-Fi
gracefully, be useful regardless

86. Tips & Tricks

87. Pro-Tip: Bring your
own Wi-Fi routers.

88. Collegiate Wi-Fi tends to
be terrible, infested with
HTML login screens.

89. This makes it really hard
to build hardware projects
on most devices.

90. Make sure to also provide
Wi-Fi at the end of the
event during project
demonstrations.

91. You can usually find
open ethernet jacks.

92. Pro-Tip: Load useful
software onto USB sticks
to avoid large downloads.

93. Start developers 30-50% of the
way to their goal
Sample code and prefabs for common use cases

94. Finished Projects = Happy
Developers
This is the only marketing you need to worry about

95. Ration hardware (conditional loans)
Hardware is for teams who are building, not stuffing in backpacks

96. Set up a supply table
Expect people to show up with nothing

97. Document, share relentlessly
Don’t let your success disappear down the “memory hole”

98. If it isn’t documented, it
didn’t happen.
Collect team names, take pictures of *every* project built with your technology,
save links to projects posted online. Hackathon success is ephemeral, you
need to keep a record of what happened or it will disappear.

99. Offer prizes.

100. Prizes should be geeky in
nature, developers don’t
want money, they want
fun toys and things to
play with.

101. Generally we spent $450
on three prizes for a team
of up to four per event.

102. Prizes are important to
motivate developers to
use your products.

103. Tell stories about your product
Be prepared to inspire developers with ideas

104. Developer Success = Your Success
Developer success is the only metric

105. Celebrate developers.
Use social media channels to reward developers with public recognition, doing
this regularly leaves a strong positive impression on your organization.

106. Learn.
Ask developers to share their code, chances are solutions built by one
developer will be needed by other developers at other events. Be proactive
about documenting solutions to common problems.

107. Forketing
And read this.