As a developer, architect and now Product Manager, I've spent most of my career trying to turn software ideas into reality. For many years, I worked on teams that adhered to the Way of the Functional Spec, an ancient practice whereby a product leader spends countless hours producing a document that uses text to describe the future state of software, only to see that document become useless by the time the first line of code is written. Over the years, I've experimented with all of the agile and Product Management techniques designed to help drive down uncertainty in software and foster clear, high-fidelity collaboration between product leaders, designers and engineers. Some have been useful, others not. About two years ago, a few product teams at my current company began toying with the idea of replacing our existing spec work with prototyping. Instead of working with text-based docs, a PM would work with an Interaction Design to create an interactive piece of software that conveys the vision for a product or feature. This was one of the best decisions we ever made. High-fidelity prototyping is now a critical component of our product workflow, and we've become addicted to using these assets for collaborating with customers and internal teams alike. In this session, I'll will share how one software company abandoned functional specs and PRDs for the green pastures of prototyping. Using a case study format, I'll share challenges we overcame, victories we experienced and tips for embedding a full-on Prototyping workflow in any software organization.

1. GOODBYE SPECS,
HELLO PROTOTYPES!
@BRANDONSATROM
SATROM@TELERIK.COM

2. 3 BIG IDEAS

3. V i s u a l s o f t w a r e c a n n o t
b e p r o p e r l y e x p r e s s e d
w i t h t e x t
1

4. P r o t o t y p i n g i s a n e x c e l l e n t
tool for communicat i o n
a n d v a l i d a t i o n
2

5. P r o t o t y p i n g w o r k s b e s t w h e n
d r i v e n b y g reat d e s i g n e r s ,
PMs and complimented by
g reat t o o l s .
3

6. OBLIGATORY YMMV SLIDE!
I am not a designer
6

7. ANOTHER OBLIGATORY YMMV
I am a product
manager
7

8. TEXT

9. A BRIEF HISTORY OF
SPECS
(Or, how to waste immeasurable
amounts of time not building software)

10. THE EARLY AGE OF SPECS
10

11. THE EARLY AGE OF SPECS
“Ο γραπτός λόγος είναι το πιο οπτική
όλων των μέσων, και πρέπει να είναι όλα
αυτά που η ανθρωπότητα χρειάζεται για
να δημιουργήσετε όμορφα κτίρια,
κατασκευή θαύματα και να σχεδιάσετε το
επόμενο iPhone, το οποίο άκουσα θα έρθει
σε 3 ένδοξη μεγέθη.”
- Specificitus, On Text, 136 BC
10

12. THE EARLY AGE OF SPECS
11

13. THE EARLY AGE OF SPECS
“The written word is the most visual of all
mediums, and should be all that mankind
requires in order to create beautiful buildings,
construct wonders and to design the next
iPhone, which I heard will come in 3 glorious
sizes.”
- Specificitus, On Text, 136 BC
11

14. A DIFFERENCE OF OPINION
“Προσπαθώντας να αντιπροσωπεύουν οπτικά
δημιουργίες χρησιμοποιώντας μόνο τη γλώσσα
μας μπορεί να αποδώσει μόνο ρηχά αντίγραφα του
τι οραματιζόμαστε στο μυαλό μας. Είναι μόνο μέσω
της χρήσης των εικόνων μαζί με τα λόγια μας που
μπορούμε να δημιουργήσουμε το ένδοξο
αριστουργήματα! Με αυτό το ευγενές εργαλείο στο
χέρι σίγουρα οι δρόμοι θα τρέχει κόκκινο και
βρύσες μας ξεχειλίζουν από ούζο, όταν
χρησιμοποιούμε αυτά τα σχέδια να πατάξει την
μιγάς Spartan από τη γη!”
- Prototypus, What More Than Words, 135 BC
12

15. A DIFFERENCE OF OPINION
13

16. A DIFFERENCE OF OPINION
“Attempting to represent visual creations using only our
language can only yield shallow copies of what we
envision in our minds. It is only through the use of
pictures along with our words that we can create
glorious masterpieces! With this noble tool in hand
surely the streets will run red and our fountains
overflow with ouzo when we use these designs to
smite the mongrel Spartan from the earth!”
- Prototypus, What More Than Words, 135 BC
13

17. TEXT VS. PICTURES
14

18. TEXT VS. PICTURES
14

19. SPECS IN THE
MODEN ERA
15

20. THE SPEC, AKA…
Functional Spec
Technical Spec
Product Requirements Doc
(PRD)
16

21. STRENGTHS OF SPECS
Exhaustive
Detailed
Good at being verbose and also
wrong
17

22. WEAKESSES OF SPECS
Impossible to capture everything in
advance
Hard to iterate
Rarely used during development
Often out of date
A true sign of a "waterfall" mentality
18

23. 19

24. 19

25. Also… specs are terrible for
capturing customer feedback.

26. Like, just the worst.

27. The. worst.

28. I’m not even kidding
y’all, they are terrible.

29. You want proof, do
you?

30. I HAVE JUST THE PRODUCT FOR YOU!
Immediate weight loss
Promotes cardiovascular health
Said to cure epilepsy
An affective treatment for metabolic syndrome (high
blood pressure, high blood sugar, etc.)
25

31. I HAVE JUST THE PRODUCT FOR YOU!
Immediate weight loss
Promotes cardiovascular health
Said to cure epilepsy
An affective treatment for metabolic syndrome (high
blood pressure, high blood sugar, etc.)
25

32. I HAVE JUST THE PRODUCT FOR YOU!
Immediate weight loss
Promotes cardiovascular health
Said to cure epilepsy
An affective treatment for metabolic syndrome (high
blood pressure, high blood sugar, etc.)
25

33. HOW WE FAILED WITH SPECS AT TELERIK
Attempting to build a
spec for everything
killed velocity
Too easy to specify the
“how,” which is NOT
the domain of PM & UX
We had nothing of
value to show to
customers
26

34. Specs aren’t all bad…

35. … they help engineering
build the thing right.

36. The spec, even when done well,
can’t tell you if you’re building the
right thing…

37. How do we evolve the spec into
something useful for modern,
design-focused teams?

38. A BRIEF HISTORY OF
PROTOTYPES
(Or, how to be the Alec Baldwin to the
Functional Spec’s Billy Baldwin)

39. BLUEPRINTS
32

40. MODELS
33

41. CONCEPT CARS
34

42. THE HARDWARE PROTOTYPE (AKA I
DON’T HAVE A KICKSTARTER
ADDICTION NO REALLY I DON’T)
35

43. 36
THE PPT AND PSD TWO-STEP

44. PROTOTYPING IS IMPORTANT
37

45. PROTOTYPING IS IMPORTANT
37

46. PROTOTYPING APPROACHES
Paper Prototype
Wireframe/Mockup
Pseudo-demo app
High-Fidelity
Prototype
38

47. PAPER PROTOTYPE
39

48. WIREFRAMES/MOCKUPS
40

49. DEMO APPS
41

50. HIGH-FIDELITY PROTOTYPES
42

51. HIGH-FIDELITY PROTOTYPES
1. Functional demos
2. Represent the real product
to be delivered (even if
loosely)
3. Can be manipulated by
end-users
43

52. BENEFITS OF THE PROTOTYPE
1. Visual
2.Functional
3.Collaborative
4.Dual-Purpose
44

53. 45

54. RISKS OF PROTOTYPING
Time-consuming
Creates a built-in bias
Not a replacement for
user stories and other key
details.
46

55. ARCHITECTURE AND SOFTWARE
47

56. PM & UX
Ideation and Design
HOW WE PROTOTYPE AT TELERIK
PM Team
Iteration and
refinement
Feature
Customer
Validation and
Feedback
PM, UX & Engineering
Construction &
Iteration
Engineering
Clarification and
Estimation
48

57. WHERE WE STILL HAVE WORK TO DO
STORIES
ARTICULATING
CUSTOMER PROBLEM
REQUIREMENTS MOCKUPS
CHUNKING THE WORK
CAPTURING THE
“HIDDEN DETAILS”
49

58. GETTING STARTED WITH PROTOTYPING
GET SOME
TOOLS
FIND A PM
&
DESIGNER
DO SOME
RESEARCH PROTOTYPE
50
BUILD! ITERATE VALIDATE

59. USER RESEARCH TOOLS
ANALYTICS
GOOGLE
PARSE
LOCALYTICS
METRICS CUSTOMER
ENGAGEMENT
STICKINESS
CHURN
ENGAGEMENT
INTERCOM
SURVEY MONKEY
51

60. PROTOTYPING TOOLS
Axure
Balsamiq
Bootstrap
UXPin
52

61. DON’T FORGET MOBILE!
1.InVision
2.proto.io
3.Justinmind
53

62. BEYOND THE PROTOTYPE

63. WHAT A PROTOTYPE CAN'T TELL YOU...
If the product or feature will help you
meet your goals.
If you’re solving a real customer problem
Everything engineering needs to know to
actually build this thing.
55

64. GOALS AND INITIATIVES
56

65. SOLVING REAL PROBLEMS
57

66. DECOMPOSING THE WORK
58

67. How prototyping fits into
the big picture at Telerik

68. THE PRODUCT
FUNNEL
60
Inputs
- Strategy
- Metrics
- Markets
- Customers
Work
- Ideas
- Features
- Headroom
Markets Customers
Strategy
Backlog
Story + Prototype = Estimate
Roadmap
Value / Effort
Work & Inputs - Aha!, Google Analytics,
Qualtrics, Intercom
Backlog - Aha!, UXPin & InVision
Roadmaps - Aha!
R1 R2 R3 R4

69. THE BOTTOM LINE
1. Prototyping is just a
tool in the toolbox.
2. Don't expect it to do
everything, but do
adopt it, because it
excels at many things.
61

70. 62
Thank you!
@BrandonSatrom
satrom@telerik.com