a pm and a developer walk into a bar

SHERIF MANSOUR • PRODUCT GUY • @SHERIFMANSOUR

A PM and a Developer walk into a bar…

Batman and Robin walk into a bar…

Mario and Luigi walk into a bar…

Captain America and The Hulk walk into a bar…

3 things

you can do to get engineers to build

what you want

#1 remember: you represent the customer

all these customers!

rely on you… so don’t screw it up !

They are not “in the zone”… just pretending

Make sure they are clearly aware of

your importance.

“Interruptions”

Got their attention? Use motivating one-liners

to earn respect

“Isn’t it just loops and vars?”

“Yeah… I used to code…”

“I thought we had the worlds best engineering team… that’s what they told me”

“I’ve seen Google do it, why can’t we?”

“Let's take a step back”

“How do we take this to the next level?”

“Maybe you should do some pair programming, that might help”

“… Let’s do that in phase two”

NO!

mutual respect?

working well together?

the testbeer coffeelunch

Our product is an outcome of the people we hire and the decisions they make.

K R I S TO K Ä Ä R M A N N T R A N S F E RW I S E

“”

http://bit.ly/productequalspeople

asynchronous (allthethings)

Why is that important?* Reality of most PM and dev teams? distributed teams?* Devs preffer to work async* Interruptions? or keeping teams focused? - how can we keep the relationships collaborative or harmonious and easier to talk to the

whole team not just one PM or one DEV - foster a relationship with the whole team * This works well for our teams might work well for you

asynchronous (allthethings)

report

What should the….?

decidediscuss

• Ask what’s blocking?

• What’s an FYI?

• Consider rooms for 1-1s

• Linking for detail

• Status indicators

• Commenting for questions

• Provide context

• Explore and discuss options

• Time to think!

• Make decisions and track actions

Meetings shouldn’t block decisions

hire for culture,

build relationshipwork asynchronously

#2 involve them late as late as possible

</>

ideation research definition code

JAN FEB MAR APR

involve engineers here

</>

ideation research definition code

JAN FEB MAR NOV

involve engineers here

ship here

I wish engineers spent more time coding, less time understanding the problem - S A I D N O O N E … E V E R

“

”

building a shared

understanding

identify a shared

understanding

why?

who?

what?

Why are we building this?

Why is it more important than everything else on roadmap? Who are we building this for?

Who does what? What are we aiming for?

How does this fit in the bigger picture?

What are we (not) doing?

What defines success?

Individuals and interactions

over processes and tools

Working software

over comprehensive documentation

Customer collaboration

over contract negotiation

Responding to change

over following a plan

http://agilemanifesto.org

Shared understanding over engineering velocity

#3 tell them what, not why… with little detailBatman is the hero and Robin is the

supporter

make money

user press button

As a user I want a new event button So that I can add events

(facepalm)

As a user I want a new event button So that I can add events

Alana

to plan a training event

my team can run effectively

Stories get their name from how they should be used, not what should be written.

J E F F PAT TO N S TO RY M A P P I N G ( 2 0 1 4 )

“”

your story toolbox

Contextual inquiries

Customer interviews

Prototypes

Analytics

Surveys

Journey maps

Requirements docs

Story mapping

Personas

….

your story toolbox

http://bit.ly/StoryToolbox

CONFUSING UX

FEATURE x NOT USED

BUGGY

AnalyticsThe what, not the why

LOW ADOPTION

HARD TO GET STARTED

LOST IN FLOW

NOT DISCOVERED

EXPECTED TO BE LOW

DON’T USE SERVICE

User testingQualitative feedback

Interviews, surveys…Drill into the why andactually talking to people!

SPECIFIC BROWSERS

SCENARIOS

UPFRONT DECISIONS

NO GUIDE

NAVIGATION

PROGRESS TRACKING

More analytics!

Support feedback

Now Next Not doing

DISCOVERY

SPECIFIC BROWSERS

NO GUIDE

NAVIGATION PROGRESS TRACKING

HARD TO GET STARTED

Understanding problems provides clarity for roadmap planning

Tell stories, not requirements.Build a toolbox of techniques.

Why? Take engineers on the journey.

Agree on the problem.Stop arguing about solutions.



WORK ASYNC.

INVOLVE EARLY

SHARED UNDERSTANDING

TELL STORIES

CULTURE & RELATIONSHIPS

spot

WHY, NOT WHAT

Thank you!

a pm and a developer walk into a bar

Software