STOP MAKING EXCUSES START DELIVERING VALUEA CULTURE FIRST APPROACH TO PRODUCT CENTRICITY

2

OUR AGENDA_ Introduction _ Story Time _ What I mean by Lean Product Design _ Culture First _ The Playbook _ The End

LET’S GET STARTED

3

“CDAF”“CDAF”

4

WHO ARE YOU?! WHY SHOULD I LISTEN TO YOU?!-A Reasonable Skeptic

5

JORDAN COURTLAND BROWNHe / Him / His

6 Years in Nonprofit Strategy

2.5 Years at ThoughtWorks

Lean Product Transformation / Product Strategy / Product Management

STORY TIME

6

7

http://www.adweek.com/digital/facebook-now-makes-84-of-its-advertising-revenue-from-mobile/https://techcrunch.com/2011/12/08/corporate-reorganization/

FACEBOOK ?2011

$0.00MOBILE

0%AD REVENUE

2012$390m

MOBILE$1.8b

MOBILE

2015

84%AD REVENUE

MOBILE ADS UNIFIED USER EXPERIENCE

PROMISE OF

VALUE

What are we doing next that delivers value?

POD 1 POD 2 POD 3 POD 4How much are we investing?

GROWTH + SUSTAINABILITY STRATEGIC GOAL STRATEGIC GOAL

What does the organization need to achieve to realize the Vision?

WHEREVER WHENEVER

MOBILE DESKTOPWhat’s our strategy for achieving that Goal?

ADVERTISING PLATFORM

$$$ Users+

Advertisers+

Mobile+Ad $$Ads +

Mobile Ads +M. Imp +M. Eng +

VISIONWhat is our destination as an organization?

“People use Facebook to stay connected with friends and family, to discover what’s going on in the world, and to share and express what matters to them.”

8

HOW DID THEY DO IT ?9

10

PRODUCT CENTRICITY IS A

CULTURE OF DESIGN

11

Building the Right Things

Building the Things Right

IMAGINE

LEARN DESIGN

TESTCu

stom

er N

eed Tactical Action

CULTURENORMS

VALUESBEHAVIORS

COMMUNICATION

ORGANIZATION

POLITICS

CULTURE OF DESIGN

😭😭

Another Day!

12

CULTUREPRINCIPLES

CULTURE OF DESIGN

PRACTICESTECHNIQUES

VS

OPEN ENDED QUESTIONS, MANY POSSIBLE ANSWERS.

Given a Principle…How do we approach this now?

Could we be better?

What would good look like?

This month? In six months?

How will we know we’re getting better?

TERMINAL QUESTIONS, YES OR NO ANSWERS.

Given a Practice / Technique…Do we or don’t we?

Are we or aren’t we?

Best practice or not?

N/A, we checked the box or didn’t.

N/A, we checked the box or didn’t.13

“We have a truncated process that inhibits our ability to work

holistically within an overall Vision.”

“We have identified areas of short-term capability

growth and improvement .”

“We are beginning to blend areas of the business around a

product strategy.”

“We have become an organization designed for purpose, delivering value

understood and owned by all.”

CULTURE OF DESIGN

EVOLUTION OF DESIGN CULTURE

14

HOW CAN WE START AN EVOLUTION IN OUR CULTURE?

15

PLAYBOOK FOR A DESIGN CULTURE

16

17

VALUESWHY > WHAT + HOW

OUTCOMES > OUTPUTS

BOUNDARIES > CONSTRAINTS

We need to implement Paypal checkout! Do we know what our customers are hoping to accomplish? How’s that going?

X✔

Our Velocity went up! We completed 10 more stories than last week! We delivered this business value, and average cart value went up 10%

X✔

All stories need to be written, in Jira, in this format… We have both a physical and digital backlog, Devs understand stories, and Cycle Time is low

X✔

BETTER > PERFECTWe can’t do User Testing—we don’t have external access to staging set-up and that’ll take… Marketing got us in contact with 5 user’s and we’re doing screen share over Skype

X✔

Low Checkout Conversion?

What Did We Accomplish This Sprint?

Are We Working Effectively?

Will We Validate This With Real Users?

18

BEHAVIORSDISCOVER Researching customer needs

PRIORITIZE Selecting the best place to invest

PROTOTYPE Iterating & user testing solution ideas

MEASURE Identifying a minimum viable product (MVP)

SCALE Grow successful MVPs into products

? ? ?? ? ?

! ! !

MVP

2 3

4 5 6 7

1

MVP+

SPRINT RETROS

TEAM WORKFLOW

REMOTE COLLABORATION

A FEATURE

PRODUCT METRICS

19

NORMSNOTHING IS ABSOLUTE—EVERYTHING IS NEGOTIABLEThis is a HYPOTHESIS DRIVEN model—we discover new truths, things change, and so do we. We try new things. If something stops being useful, it’s gone. Everything in service of the OUTCOMES. Nothing for it’s own sake.

EVERYONE A PRODUCT OWNER—EVERYONE A DESIGNER

DESIGN WITH THE USER

MEASURE EVERYTHING

AUTONOMOUS + ACCOUNTABLEWe own the outcome—the WHY, and AMAIRAP the what and how of that is totally up to us (Boundaries vs Constraints). That said, WE are accountable for our choices—they’re made intentionally, backed by reason, logged, and transparent.

Who Tests the Product? Who meets with Stakeholders? Who participates in User Testing? Who Buys Snacks? Who can sketch a Prototype? Who writes a Story? Who does the 3am Release? Whose fault is this?

As much as is reasonable and possible, the continuous design of the product will be a COLLABORATIVE endeavor. AMAIRAP the user (internal too) is involved—or the best proxy we can muster. Everyone takes part in ‘How might we…’

Are our Retros useful? Is this Feature valuable? What’s most painful about Dev to Release? How well are we dealing with Tech Debt? What do our users REALLY care about? How’s team morale? Does this make sense? Can we KNOW?

20

COMMUNICATION

TEAM

TEAM

ORG USER

WHO COMMUNICATES

METHOD

VALUE

EMAILPHONE

CHAT

TELEPRESENCE

FACE-TO-FACE

HOW THEY DO IT

LET’S LEAVE IT AT THIS…

21

HOW’D I DO?Be ruthless.

JBrown@thoughtworks.com

@jordancourtland

EMAIL

TWITTER

@jordancourtlandLINKEDIN

APPENDIXKey Documents

23

AGILE

LEAN PRODUCT

CONTINUOUS DELIVERY

24

CONTINUOUS DELIVERY

LEAN PRODUCT

AGILE

WHAT? HOW?

25

AGILE

CONTINUOUS DELIVERY

WHY?LEAN PROUDCT

26

CONTINUOUS DELIVERY

BUILD TEST RELEASE

CI PIPELINE

INFRASTRUCTURE

Unit Deploy to CI Env

Component

Tests

Contract Tests

Deploy to QA

SmokeE2E

Tests

Manual or Automatic Step Manual Step

Deploy to

Staging

The component tests should live in the same repository as the production code

Contract tests are defined by the consumer but should be in repo and pipeline of the provider.

The code should be refactored and documented in the same way you would production code, both QAs and developers are responsible for the health of it.

Avoid the ‘Broken windows’ theory keep the build always green

Smoke E2E

Tests

Manual Step

Deploy to

Prod

Smoke E2E

Tests

For mature teams cross functional testing can be part of the pipeline. Initially focus on making them automated and easily runnable.

28

LEAN PRODUCT

Building the Right Things

Building the Things Right

IMAGINE

LEARN DESIGN

TESTCu

stom

er N

eed Tactical Action

29

DESIRABILITY

FEASIBILITY VIABILITY

What people need + want

What is technically + organizationally feasible

What is capable based on our finances/resources

LEAN PRODUCT

INNOVATION

DESIGN THINKING

30

KNOWING WHERE TO START

VALUE TO MARKET + CUSTOMERS

CAPABILITY THE VALUETO PROVIDE

PRODUCT / SERVICE

31

KNOWING WHERE TO START

VISION

STRATEGIC GOAL

STRATEGIC BET

STRATEGIC BET

POD 1 POD 2 POD 3

PROMISE OF

VALUE

STRATEGIC GOALSTRATEGIC GOAL

STRATEGIC BET

STRATEGIC BET

STRATEGIC BET

POD 4

PROMISE OF

VALUE

PROMISE OF

VALUE

PROMISE OF

VALUE

PROMISE OF

VALUE

POD 5 POD 6 POD 7 POD 8

VALUE YOU PROVIDE

CAPABILITY TO PROVIDE VALUE

?

32

ROOT CAUSE

Lack of Engaged Change Management

RESULTING EFFECTS

BUSINESS IMPACT

Preference for comfort zone of role

Internalized Delivery Date

Pressure

Very Limited Delivery + Enablement Timeframe (48 Days)

Siloed roles stifling

collaboration

Knowledge silos

Dev+ QA + UAT Silos

Learning curve of new

stack

Prioritization of features vs. quality

Low maturity in defect

management + QA comms

Informal Tech Debt

ManagementLack of Tech Leadership

for Code Standards

Expanding Tech Debt

Trail

Time to Team Alignment on

Quality

Code Quality

Devs Not Writing Tests

Early

Some unit tests but limited

coverageChange was (is) painful

Inflexibility of Old vs. New

Practices

Constraining SOX

Interpretation

Heavy Reliance on Org Process (Waterfall) VSTS

Challenges

Incredibly slow access

process

VSTS Limits CI Possibilities

Lack of shared CI

Ownership

No Mature Build

Radiator

Frequency of Broken Builds

Lack of functional tests in CI

Slow to start with

Automated Testing

Devs not owning

functional test @ start

Less frequent integration in

Higher Environments

Functional Tests failing

Longer Build > Promotion

Cycles

Time developing

new technical patterns

Unfamiliarity of front-end framework

Knowledge sharing of

dev practices

Long refactoring

Longer Dev Cycles

Reduced Reliability

Higher Complexity

Less Features Delivered

High Complexity in

Handoff + Onboarding

Time Spent Configuring

Visible + Functional

Backlog

Laborious + Manual Project

Reporting BA/Product capacity drain

Competition b/w Role work and Practice

Stewardship

Challenge to cross-

functional analysisAddress the possibility vs tax

of ecosystem w/ cause and effects

33

BUSINESS DECISION

Clearly Prioritized Product Roadmap

RESULTING EFFECTS

BUSINESS IMPACT

Evolved IT + Business Capability

Scalability with other products and teams—

friendly dependency

Justification of Investment in

Capability Growth

Continuous scaling of

increased Product value

Clear direction for prioritization

IT + Business Alignment

Meandering delivery pathNo Alignment

between Business + IT on value

Team is Product-Focused and not

Maintenance / BAU

Ineffective Teams

Less motivated Developers

Frustrated Users

Evolution stagnates into

crushing Maintenance

Broken + Disliked Product

Attrition of High Performing

Talent

Delivery against Top Level

Business Goals

Inability to Attract Quality

Talent

Business Validation Churn

Prioritization Churn

Features always trump tech debt

Feature rabbit holes to empty

value

Disjointed and painful User

Experience with Product

Ballooning tech debt

Valuable Features released slowly

Cross functional ownership of

Product

Visible horizons of product lifecycle

Collaborative analysis and

delivery process

Quality baked in early through test-

first culture

Constant small design iteration w/

Business

Highly knowledgeable + motivated team

Continuous learning