Couples Counseling for Product Development

Post on 15-Jan-2015

641 views 2 download

Tags:

description

An introduction to Non-Blocking Development and how to get your entire business, from sales to software development, aligned to ship more product more quickly.

Transcript of Couples Counseling for Product Development

Couples Counseling for Software Development

Joe Stump, CEO of Sprint.ly

• 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).

“The best products in the world start out as

features.”Kevin Systrom, CEO of Instagram

Warring Factions

Check Your Ego

EVERYONE IN YOUR COMPANY IS CAPABLE OF

HAVING A GREAT IDEA.

Managers

Quickly

Correctly Cheaply

YOU CAN’T HAVE YOUR WINE CASK FULL AND YOUR

WIFE DRUNK.

“Want to increase innovation? Lower the cost

of failure.”Joi Ito

ALLOW ENGINEERS TO INVEST IN

AUTOMATION & TESTING.

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

Makers

“You should get a CS degree. It's the only degree

that automatically makes you an expert on politics, finance, religion, and

economics.”@thejayfields

YOU ARE NOT AN EXPERT IN SALES, MARKETING, NOR

BUSINESS DEVELOPMENT.

A Sampling of Non-Technical Product TODOs• Financial model creation for

pricing

• Customer development

• Copywriting

• Marketing plan for launch

• Public relations

• Support

• Community development

• Sales training

• Managing beta testers

• Contract negotiation

• Messaging

• Documentation

• Screencasts & Videos

• Marketing materials

• Capturing requirements

• Business development

• Funnel analysis

• Market research

• Blog announcement

• Newsletter announcement

SIMPLEGEO’S PRODUCT LAUNCH CHECKLIST HAD 41 NON-ENGINEERING

ITEMS ON IT.

YOU ARE NOT A DESIGNER.

(SERIOUSLY. JUST LOOK AT THAT SHIT.)

YOU ARE NOT THE TARGET CUSTOMER. (NO, REALLY, NOBODY CARES

ABOUT KEYBOARD SHORTCUTS.)

“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

Delivering Product

Implementing vision takes time

Inception Your brain

Funding v1.0

“If you’re not embarrassed when you ship your first version you waited too

long.”Reid Hoffman, Founder of LinkedIn

Product is Trench Warfare

BE MILITANT IN YOUR MINIMALLY VIABLE PRODUCT

(MVP).

Approaching Product1. 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

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

Seriously?

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

INVOLVE ENGINEERING IN THE PRODUCT

DESIGN PROCESS.

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

Iterating the YardsaleWay™

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

Promote Ownership

Yay!

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

Process Interrupts

PRODUCTS ARE EITHER DATE-

DRIVEN OR FEATURE-DRIVEN.

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

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

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

@joestump