Joe Stump is a seasoned technical leader and serial entrepreneur who has cofounded three venture-backed startups, was Lead Architect of Digg, and has invested in and advised dozens of companies. He is passionate about development processes, iterative product development, and building scalable web infrastructure.

1. Couples Counseling for
Software Development
Joe Stump, CEO of Sprint.ly

2. • Early employee at three startups ranging
from bootstrapped to venture funded.
• Angel investor in three startups.
• Advisor to seven venture funded startups.
• Cofounder of three venture funded
startups (SimpleGeo, attachments.me, &
Sprint.ly).

3. “The best products in
the world start out as
features.”
Kevin Systrom, CEO of Instagram

4. Warring Factions

5. Check Your Ego

6. EVERYONE IN YOUR
COMPANY IS
CAPABLE OF
HAVING A GREAT
IDEA.

7. Managers

8. Quickly
Correctly Cheaply

9. YOU CAN’T HAVE
YOUR WINE CASK
FULL AND YOUR
WIFE DRUNK.

10. “Want to increase
innovation? Lower the cost
of failure.”
Joi Ito

11. ALLOW ENGINEERS
TO INVEST IN
AUTOMATION &
TESTING.

12. Why?
• Iterating on your product is all about
shortening feedback loops
• Continuous deployment allows you to ship
on code commit
• Automated testing allows for aggressive
refactoring with confidence

13. Makers

14. “You should get a CS
degree. It's the only degree
that automatically makes you
an expert on politics,
finance, religion, and
economics.”
@thejayfields

15. YOU ARE NOT AN
EXPERT IN SALES,
MARKETING, NOR
BUSINESS
DEVELOPMENT.

16. A Sampling of Non-
Technical Product TODOs
• Financial model creation for
pricing
• Messaging
• Documentation
• Customer development
• Copywriting
• Screencasts & Videos
• Marketing plan for launch • Marketing materials
• Public relations • Capturing requirements
• Support • Business development
• Community development • Funnel analysis
• Sales training • Market research
• Managing beta testers • Blog announcement
• Contract negotiation • Newsletter announcement

17. SIMPLEGEO’S
PRODUCT LAUNCH
CHECKLIST HAD 41
NON-ENGINEERING
ITEMS ON IT.

21. YOU ARE NOT A
DESIGNER.
(SERIOUSLY. JUST
LOOK AT THAT SHIT.)

22. YOU ARE NOT THE
TARGET CUSTOMER. (NO,
REALLY, NOBODY CARES
ABOUT KEYBOARD
SHORTCUTS.)

23. “Focus on the problem. If
you’re only excited about the
solution, you’ll lose interest
when your solution doesn’t fix
the problem. ”
Adil Wali, CTO of ModCloth

24. Delivering Product

25. Implementing vision
takes time
Inception Your brain
Funding v1.0

26. “If you’re not embarrassed
when you ship your first
version you waited too
long.”
Reid Hoffman, Founder of LinkedIn

27. Product is Trench Warfare

28. BE MILITANT IN
YOUR MINIMALLY
VIABLE PRODUCT
(MVP).

29. Approaching Product
1. Focus on a single use case that addresses
the problem
2. Start with a minimal core set of features
3. Release and listen to your users
4. Question your initial assumptions based on
feedback
5. Rinse and repeat

30. Iterating on Your
Product
1. Have a great idea
2. Wireframe in Balsamiq (or whatever)
3. Designer creates a static mockup
4. Static mockup is thrown “over the wall” to
engineering to implement

31. Seriously?

32. Oh, whoops.
• Turns out static mockups are ... static
• Engineers implement it only to find out the
UX is terrible
• Engineering is unable to implement critical
features

33. INVOLVE
ENGINEERING IN
THE PRODUCT
DESIGN PROCESS.

34. Why would I do that?
• Nobody knows your data better than your
engineers
• You likely aren’t an expert at data
algorithms
• They are your company’s best technologists

35. Iterating the Yardsale
Way™
1. Have a great idea
2. Wireframe in Balsamiq (or whatever)
3. Engage engineering to build a vanilla prototype
(e.g. Default Bootstrap or iOS/Android UI
components)
4. Play, tweak, rinse, repeat
5. Once UX is nailed have a designer polish to
perfection

36. Promote
Ownership
Yay!

37. Why is this better?
• Designer’s time is not lost on features that
are not shippable
• Timelines will not be disrupted by
unforeseen technical hurdles
• Avoids pissing off the engineers

38. Process Interrupts

39. PRODUCTS ARE
EITHER DATE-
DRIVEN OR
FEATURE-DRIVEN.

40. Non-Blocking Development
(NBD)
1. No sprints, milestones, or dates are tracked by
engineering
2. Items are scored, velocity is tracked
3. Each developer works on an item to
completion in a feature branch
4. Pull request via GitHub for review
5. Feature deployed immediately upon approval
via continuous deployment

41. Why is this better?
• Shares reactive qualities of Kanban
• Velocity metrics allow you to do reasonable
capacity planning
• Features ship in real-time as they’re
completed

42. “You can’t ship process.”
VP of Product, Live Nation Labs

43. @joestump