The document provides tips for product managers to get engineers to build what they want in 3 main points: 1. Involve engineers as early as possible to develop a shared understanding of the problem and build relationships. 2. Work asynchronously and use tools like asynchronous messaging to discuss ideas and make decisions without blocking work. 3. Tell stories and provide context about user needs through techniques like customer interviews, but avoid giving too many implementation details, focusing on the what rather than the why.

1. SHERIF MANSOUR • PRODUCT GUY • @SHERIFMANSOUR
A PM and a Developer
walk into a bar…

2. Batman and Robin
walk into a bar…

3. Mario and Luigi
walk into a bar…

4. Captain America and The
Hulk walk into a bar…

5. 3
things
you can do to get
engineers to build
what you want

6. #1 remember:
you represent the customer

7. all these customers!
rely on you…
so don’t screw it up !

8. They are not “in the zone”…
just pretending

9. Make sure they are
clearly aware of
your importance.
“Interruptions”

10. Got their attention?
Use motivating one-liners
to earn respect

11. “Isn’t it just loops and vars?”

12. “Yeah… I used to code…”

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

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

15. “Let's take a step back”

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

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

18. “… Let’s do that in phase two”

19. NO!
mutual respect?
working well together?

20. the testbeercoffeelunch

21. Our product is an outcome of
the people we hire and the
decisions they make.
KRISTO KÄÄRMANN
TRANSFERWISE
“
”
http://bit.ly/productequalspeople

22. 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 relationsh
whole team not just one PM or one DEV - foster a relationship with the who
* This works well for our teams might work well for you

23. asynchronous
(allthethings)
report
What should the….?
decidediscuss

24. • Ask what’s
blocking?
• What’s an FYI?
• Consider rooms for
1-1s

25. • Linking for detail
• Status indicators
• Commenting for
questions

26. • Provide context
• Explore and discuss
options
• Time to think!
• Make decisions and
track actions

27. Meetings shouldn’t
block decisions

28. hire for culture,
build relationship
work asynchronously

29. #2 involve them late as
late as possible

30. </>
ideation research definition code
JAN FEB MAR APR
involve engineers here

31. </>
ideation research definition code
JAN FEB MAR NOV
involve engineers here
ship here

32. I wish engineers spent
more time coding, less
time understanding the
problem
- SAID NO ONE… EVER
“
”

33. building a
shared
understanding

34. 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?

35. 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

36. Shared understanding
over engineering velocity

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

38. make
money
user press button

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

40. (facepalm)

41. 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

42. Stories get their name from how
they should be used, not what
should be written.
JEFF PATTON
STORY MAPPING (2014)
“
”

43. your story
toolbox

44. Contextual inquiries
Customer interviews
Prototypes
Analytics
Surveys
Journey maps
Requirements docs
Story mapping
Personas
….
your story
toolbox
http://bit.ly/StoryToolbox

45. CONFUSING
UX
FEATURE x
NOT USED
BUGGY
Analytics
The what, not the why
LOW
ADOPTION
HARD TO GET
STARTED
LOST IN
FLOW
NOT
DISCOVERED
EXPECTED TO
BE LOW
DON’T USE
SERVICE
User testing
Qualitative feedback
Interviews, surveys…
Drill into the why and
actually talking to people!
SPECIFIC
BROWSERS
SCENARIOS
UPFRONT
DECISIONS
NO GUIDE
NAVIGATION
PROGRESS
TRACKING
More analytics!
Support feedback

46. Now Next Not doing
DISCOVERY
SPECIFIC
BROWSERS
NO GUIDE
NAVIGATION
PROGRESS
TRACKING
HARD TO GET
STARTED
Understanding problems
provides clarity for
roadmap planning

47. Tell stories, not requirements.
Build a toolbox of techniques.
Why?
Take engineers on the journey.
Agree on the problem.
Stop arguing about solutions.

48. SHERIF MANSOUR • PRODUCT GUY • @SHERIFMANSOUR
A PM and a Developer
walk into a bar…

49. SHERIF MANSOUR • PRODUCT GUY • @SHERIFMANSOUR
A PM and a Developer
walk into a bar…
WORK
ASYNC.
INVOLVE
EARLY
SHARED
UNDERSTANDING
TELL
STORIES
CULTURE &
RELATIONSHIPS
spot
WHY, NOT
WHAT
Thank you!