Mobile Voice 2012 – Evangelizing Voice: Lessons learned in design innovation
Evangelizing Your Thing (Extended Edition)
-
Upload
rex-st-john -
Category
Devices & Hardware
-
view
1.563 -
download
1
Transcript of Evangelizing Your Thing (Extended Edition)
Evangelizing Your “Thing”Lessons learned bringing hardware devices to hackathons
by Rex St. John (@rexstjohn)
Rex St. John (@rexstjohn)Internet of Things Evangelist, Intel
We brought Intel Edison to more than 30 collegiate events last year.
Many of the developers we met had never seen a Linux terminal before.
We made these developers successful.
And so can you!
Here is what you need to know.
An evangelist’s job is to maximize projects built with their technologies.
Their job is to convince developers to choose their devices and finish projects.
They are not salespeople, they are there for the good of the event.
That means helping people no matter what technology they choose.
Developers engage like this (hands on).
When developers receive a gadget, their brains turn off.
No one reads at a hackathon.
That’s why it is called a “hackathon.”
Reading is work. They came to have fun.
If you have important information to communicate, you must do it up front.
Developers will listen for a bit if they know they are getting hardware.
But you need to keep it short. (45 minutes or less ideally)
So do it in the first few hours.
The first day of a hackathon is the most
important.
85% of your work as an evangelist happens in
the first few hours.
No one knows about your “thing.”
You need to get them excited to use your
product.
On the first day, people are still forming teams.
By the second day, developers have made
their choices.
It is often “too late” for you to convince them to use “your
thing.”
(although there are always exceptions)
You are not the only company at the event
with a “cool thing”
It’s a good idea to approach folks and
asking them questions…
“So what are you thinking of building
this weekend?
“Have you built many hardware hacks
before?
“What programming languages do you
know?
“JavaScript?
“Cool, we have this cool device called “Intel Edison” that lets you program hardware using
JavaScript!
“We are doing a workshop after the keynote, stop by if you want to get a device.
“We also have a prize for best use of Edison this
weekend, hope to see you there.
You get the idea.
You must market your device at the start of the event to build interest.
You should also do a workshop.
A collegiate hackathon may have 500 – 1,600
participants.
There is only one of you.
If you hand out devices without a workshop, expect to answer the same questions dozens of times.
The average team is 4 people, 40 devices mean 120 developers
potentially interacting with your gadget.
That translates into a lot of redundant questions…
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?
You should really do a workshop to cover these questions.
You should also have an intro slide deck for the
keynote.
No more than 5-10 slides, don’t waste
people’s time.
Don’t spend 15 minutes rambling.
Developers came to build fun projects, tell them how they
can use your thing to do that.
Introduce yourself, your product, what people can do with your product and your
prize.
Then say “join me for a workshop after this to
get devices.”
The end. Keep it simple, not
boring.
Advanced evangelists often have interactive demos with
audience participation and live coding.
You are a technical resource to support the participants, even if
they have questions on other topics.
You are an ambassador on behalf of your company into the developer community.
Leave a good impression.
Why do hackathons matter?
Hackathons are now a college sport(and students are in charge)
“1,500 hackathons planned in 2014”–Vivek Ravisankar (@rvivek)
*a non-complete list of sponsors for HackGT, in it’s first year!
Competition for developer attention is intense
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)
Hardware + wearables stand outBe the first device students learn to hack on
Developers cross-pollinate + talkStudents may attend dozens of events before graduating (travel
reimbursements)
Some Lessons
Developer Success Is The Only Metric
Developer Success Is The Only MetricDeveloper Success Is The Only Metric
Developer Success Is The Only Metric
Developer Success Is The Only MetricDeveloper Success Is The Only Metric
Developer Success Is The Only Metric
Developer Success Is The Only MetricDeveloper Success Is The Only Metric
Developer Success Is The Only Metric
Developer Success Is The Only MetricDeveloper 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
The target metric is “projects built per device distributed”
If you hand out 40 devices and get 3 projects, you are
probably doing something wrong.
We averaged 50% or greater projects per device issued. Sometimes 80% or more.
These metrics can vary wildly based on the schools and participants, nature of the
hackathon.
Hardware focused hackathons at schools with strong EE
departments often did well.
Lesson #2: “Hackathon ready” is a higher standard of ready
If your product is “hackathon ready,” then it is ready.
Lesson #3: Hackathons are not a branding exercise
Looks like marketing, smells like marketing, sounds like marketing…not marketing
“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
We are not perfect, sometimes technology
doesn’t work well.
Apologize and take the blame and promise to see
that the problems are fixed.
“I am going to send an email about this now, we will make
sure this doesn’t happen again
“Can you give me your email? I will follow up with you when I
hear back about this next week
Consider sending them a “make good” item if you can do so
DXDeveloper Experience
Introducing HDXHardware Developer Experience
HDX is synonymous with strong performance at hackathons
How do you achieve HDX?
Work backwards from “hackathon conditions” to your product
8-36 hours to build a project with your hardware, no time to waste
Power on, Wi-Fi, BLE in less than 10 minutes
Expect HTML based login screens, isolation mode to be turned on
Your “thing” must handle bad Wi-Fi gracefully, be useful regardless
Tips & Tricks
Pro-Tip: Bring your own Wi-Fi routers.
Collegiate Wi-Fi tends to be terrible, infested with
HTML login screens.
This makes it really hard to build hardware projects on
most devices.
Make sure to also provide Wi-Fi at the end of the event during
project demonstrations.
You can usually find open ethernet jacks.
Pro-Tip: Load useful software onto USB sticks to
avoid large downloads.
Start developers 30-50% of the way to their goal
Sample code and prefabs for common use cases
Finished Projects = Happy Developers
This is the only marketing you need to worry about
Ration hardware (conditional loans)Hardware is for teams who are building, not stuffing in backpacks
Set up a supply tableExpect people to show up with nothing
Document, share relentlesslyDon’t let your success disappear down the “memory hole”
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.
Offer prizes.
Prizes should be geeky in nature, developers don’t want
money, they want fun toys and things to play with.
Generally we spent $450 on three prizes for a team
of up to four per event.
Prizes are important to motivate developers to use your products.
Tell stories about your productBe prepared to inspire developers with ideas
Developer Success = Your SuccessDeveloper success is the only metric
Celebrate developers.
Use social media channels to reward developers with public recognition, doing this regularly leaves a strong positive impression
on your organization.
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.