The document provides guidance for developing software prototypes quickly through an iterative process focused on speed. It emphasizes that the purpose of a prototype is to collect data, and that the team should focus on building the core concept rapidly through multiple iterations to gain traction. The document stresses that the product lead should ensure the team works in parallel to maximize speed, and that they focus on evolving the prototype based on analyzed feedback from each iteration rather than building unnecessary features. The goal is to tell the tale of the product's progression through traction and lessons learned.

1. Dan Rockwell
Program Manager of the
Software Prototyping Center
Ohio State Technology
Commercialization & Knowledge
Transfer Office
Co-Founder at Big Kitty Labs
28 concepts, 7 startups, 3 years
fun with SPEED and code

2. LET’S PROTOTYPE
applause now

3. We’re all delusional until we get our asses kicked.

4. ownership
vision vs product
prototype’s purpose
strategy
build it
parallel processing
speed is king
lie, cheat, steal
evolve
feedback cycle
the tale of traction

5. divvy up the roles
pick a product lead
grant them ownership
get out of their way
the product will die if no one owns it
ownership

6. Vision is timeless, unlimited budget and composed of infinite
possibilities- a product has 120 days to be real.
vision and product don’t mix
at least not right now
your mission is momentum
making something is momentum
the sales guy preaches vision, you execute it
Vision speaks to who you could be,
product is what you wake up to the next morning.
vision vs product

7. A prototype’s purpose is to get data.
purpose

8. screen strategy
think points of interaction
land/inform
user account experience
admin panel (you)
featureville
enterprise on boarding

9. rails vs php vs don’t care get’r done
be mindful of enabling tech
staples apply to everything
build it

10. the tech really doesn’t matter
build it
no devs
be 1000 times
more creative
have devs be
1000 times
more productive
you don’t need
code to get data
no money some money

11. parallel process

12. everything you do as the product lead
should be focused on going fast
build your creative execution cycle to
maximize SPEED
eliminate barriers and choke points
(rubber necking, ownership, delegating, design, ux, data collection, code, project management,
knowing what’s happening and what’s next)
be the first to forgive yourself when the
product sucks
SPEED

13. SPEED
THE PRODUCT
THE SPLASH
The first brand we’re comfortable with.
prototype, building it, accept that it is never ending
initial PR piece that tells people you’re
coming,A/B test ground for vision and
marketing messages, feature alignment
72 hours
120 days to beta
3 weeks
the brand you all eventually agree upon

14. SPEED
THE PRODUCT
discovery
just thinking product...
2 weeks
120 days to beta
iteration 1
5 days
feed cycle
3 days
iteration 2
2.5 weeks
iteration 3
2.5 weeks

15. Build what matters, not- logins, user
accounts, payment systems, social
sharing components, about us pages.
Steal from everyone.
98% of your effort should be focused
on realizing your idea.
Dressing isn’t traction. Traction is core concept
failing miserably over multiple iterations to
decent momentum.
lie, cheat, steal

16. 1st iteration is crap, barely works, looks like hell but your date
is still interested, its built in 5 days with crushing all
nighters, massive brainstorms, sweet ah ha’s and pounding
music. It is the first time the team feels alive.
It sets the pace of what’s to come.
evolve
2nd iteration is better, bit changes complete, adding
some sauce, cleaning the core. Adding little extras while
we get some feedback.
3rd iteration after decent feedback is progressive. The thing is
show-able more so than the first. Its no joke, its working.

17. Feedback is the bane and the lifeblood of the product lead.
You learn to love and hate feedback. You must collect it all,
analyze for patterns and avoid rubbernecking at all costs.
As the product lead you have authority to say no to dumb
feedback, especially if it takes you off course.
Likewise you have the authority to tell team members, not yet.
You are judged by the collective outcome of product,
traction and momentum.
feedback

18. let’s get some feedback
apprentice
aloud protocol
goal scenarios
avoid bias
let them stumble
tell me more
why

19. the worst feedback
its nice
i think other people
would love this

20. bad feedback turquoise makes me
think of my mother in
the winter
tins? who has tins?
sacla is a horrible brand
logo makes me think of
pants and my ass
icon for meat should be a cow
sainsbury, who goes there?
could be darker

21. feedback you can use i don't know if i can
click these are not, are
they buttons?
pricing should be in $
based off my account
preferences
search should capture
comments, descriptions
sainsbury doesn't stand out as much as
most popular, i’m not sure where i’m at
is that a drop down?

22. the product
feedback
collected
and heard
more often
feedback
with no
pattern
iterative
operational
feedback
20minutes
to fix
vision
orientated
feedback
you cant
address
rubberneck
ville
speed

23. build for product
build for team synergy
build is traction
traction is attractive
tale of traction
enable your story
- lessons learned
- give back
- document it

24. so let’s recap
own it
lead it- be the product not the vision
understand the prototypes purpose
what are you building
parallel process, pr vs product, you can do both
tech doesn’t matter
SPEED, SPEED, SPEED
do not build crap that doesn’t matter
evolve through iterations
get feedback, analyze, act on
the tale story of how you’re making it happen

25. thanks,
questions?
presented for Ohio University - Innovation Engine Accelerator 2013