I spoke to students at Ada Developer Academy in Seattle, WA about how product managers and software engineers work together. In the presentation I cover: what's an agile team and how do they work; case studies of real work by my agile product development team; advice about behaviors that create successful product manager and developer working relationships; and other career/life advice for students starting their careers as software engineers.

1. Working Together
Agile Teams & Product Managers & Engineers
Danielle Martin, Product Manager
Ada Developer Academy | July 2018

2. Danielle Martin
Product Manager
LinkedIn: /daniellempost/
I’d love your feedback:
http://bit.ly/Ada-Feedback

3. Projectm
anager
Marketing
contentstrategyProduct-UX
contentstrategy
Productm
anager

4. Projectm
anager
Marketing
contentstrategyProduct
contentstrategy

5. Today I hope you learn...
● What’s an agile team and how do they work
● What does a Product Manager do on an agile team
● Successful Engineer < > Product Manager relationships
● Life/career hacks
● Case studies
● Q&A
I will share
slides!

6. First, what about you?

7. Background
What’s Avvo?

8. Mission:
To get people the legal
help they deserve

9. For my users (attorneys):
We help you grow your
practice by connecting
you with consumers
looking for legal help.

10. How?
2-sided marketplace
Consumers
Attorneys
Avvo

11. What’s an agile team?
(my team at Avvo)

12. “Agile is the fastest way to
deliver value to customers.”
- Kevin Goldsmith, former CTO, Avvo

13. My team

14. My team

15. Teammate roles
Product manager: Set and drive strategy based on user goals, business
goals, and the fastest way to deliver value.
User experience (UX): For us, interaction design and content strategy.
What info, when, and how - to achieve user goals and business goals.
Quality Assurance (QA): First and last line of defense. Repro bugs, triage
work, test new features.
Engineers / Developers: Deliver business value via engineering. On my
team, we have data engineers, full-stack developers, front-end engineers.
Business analyst: Uses data to find problems and communicate impact.

16. Team
Backlog
Idea or pain point
from users or
business
Learn
Build
Measure
Prioritized
Get
feedback
Team will
discuss, Q&A,
estimate work
Get
feedback
How we work

17. Customers
& Business
All the
teammates

18. “Agile is the fastest way to
deliver value to customers.”
- Kevin Goldsmith, former CTO, Avvo

19. A “sprint”
in the life
(2 weeks)

20. Backlog grooming
Who: Team
Goal: Shared understanding
How: Review requests/work,
ask questions, discuss
options (pros/cons/tradeoffs),
estimate work

21. Sprint planning
Who: Team
Goal: Shared understanding:
what we’re doing, why, how
How:
● Sprint goals
● Break up work, Q&A
● Commit to work (not dates)
and get goin’

22. Daily standup
Who: Team
Goal: Communication &
surface blockers
How:
● Yesterday I did...
● Today I’m doing…
● Blockers? Yes/No.
● Parking lot (discussion)

23. Demo
Who: Team
Goal: Share! Value delivered
and lessons learned
How: PAR
● Problem
● Action
● Result

24. Retrospective
Who: Team
Goal: Learn & improve
How: Discuss
● Keep doing
● Stop doing
● Ideas
● Props!

25. Questions?

26. What’s a Product
Manager (PM)?
(at Avvo)

27. Words*…
Product manager (PM): Owns end-to-end product experience and
is responsible for delivering user/biz value.
Product owner (PO): Agile lingo. Same as product manager.
Project manager (PM): Manages a defined project; usually not
responsible for strategy.
Program manager (PM): Manages a defined program; usually not
responsible for strategy.
*Words mean different things at different places, just ask them what they do.

28. Attorney user journey

30. Some things I care about a lot
● Solving real “people problems” for real humans, often in
stress (Julie Zhuo & Sarah Wachter-Boettcher)
● Making sure everyone on my team knows why (Start with Why)
● Test & Learn, and share what you learned! (Agile, UX; If a tree falls…)
● Progress not perfection. Get value to users as fast as
possible #impact (The Lean Startup)
● Protecting my team from confusion and randomization -
often with a lil’ process to speed them up (Don’t Make Me Think)

31. If you’re going to
build things that
affect people's’
lives (you are),
read these!!
These are all
linked

32. Questions?

33. Successful Dev < > PM
relationships

34. Behaviors of
successful
product
managers
● Understand users’ problems/goals
● Understand business’ problems/goals
● Balance the 2 to create strategy
● Clearly communicate strategy to
many people, in many formats
● Bring the team problems to solve,
expecting tradeoff discussions
● Break up work into small, clearly
scoped chunks/goals.
● Unblock & speed up the team -
including shielding them from noise.
● “Be kind and curious” - Leslie Zavisca
● Push to deliver value and #GSD

35. Behaviors of
successful
developers
● Ask questions (especially if you don’t
understand why)
● Collaborate with others - diversity of
ideas, healthy debate, hole-poking,
before converging on path
● Explore options, contribute pros/cons
to tradeoff discussions
● Practice communicating to non-tech
folks (pictures!)
● Don’t spin too long - raise hand if
slowed, confused, randomized
● “Be kind and curious” - Leslie Z.
● Push to deliver value and #GSD

36. Example: PM will often say to you...
● Our goal/job is to deliver user value as fast as possible
● What’s the impact? (to user, to business, to developers)
● Is there a simpler way? Is there a faster way?
● Is there a benefit to doing this now vs. later?
● Draw me a picture
● Pros and cons? Tradoffs (fast, good, cheap)? Recommendations?
● Are you blocked / slowed?
● Tell [stakeholder] to talk to me instead

37. Example
Draw a
Picture

38. Example
Written
communication
(teammates are not
mind readers!)

39. Example: What did Yana do?
● Estimated the work (1-2 points)
● Reminded me of background “we did this once before”
● Shared code / approach for dev teammates
● Gave multiple options & recommendation
● Asked a clarifying question
● Re-estimated based on my answer (2 points)
So that her PM and Dev teammates do not have
to read minds or waste time.

40. Life/career hacks
(Things I wish I knew sooner)

41. Framework: People problem
When: Someone brings you a problem or goal.
Why: Don’t waste time/work/money.
How:
1. What is the people problem?
2. How do we know it’s a real problem? (qualitative and
quantitative data)
3. How will we know when we’ve solved it?
Watch Julie Zhuo

42. Framework: Problem action result (PAR)
When: Anytime you’re talking about your work.
Why: Tell the story of your work and why it matters.
How:
1. Problem - what were you trying to solve?
2. Action - what action did you take?
3. Result - what was the result / impact?

43. Templates: Bug

44. Templates: Story / request

45. Templates: Tech debt

46. Feeling yucky is part
of the process!

47. Questions?

48. Real life!!
Case studies

49. Small

50. Problem to solve: As Avvo Marketing, I want attorneys to
announce our attorney conference on the site.
Action: PM/UX decides where it should go, Marketing delivers
the asset, developers build it with an on/off switch - so we can
ship it now, anyone can turn on later.
Result: Built and shipped. PM flipped it on day-of email.

53. Medium

54. Problem to solve: As a consumer, I want a fast answer to my
question. But as an attorney, it’s hard to add Q&A subscriptions.
Action: UX talks to Sales/Support to understand the problem.
UX & Developer design new interaction based on best-in-class
models and our UI toolkit capabilities.
Result: Much easier to add subscriptions. Oops - but now it’s
hard to unsubscribe! + some other fit n’ finish issues.
Action: Iterate over 2 sprints.

56. New progressive
reveal; checkboxes
make it easy to
add multiple
counties

57. New “select all”
makes it easy to
unsubscribe after
accidents

58. X-Large
Cautionary tale

59. Problem to solve: As Avvo, we want a new product that has 3
features (of an existing 20+ feature product)
Action: We took a route with some theoretical future side
benefits. Then we hit surprises. Then we under-resourced the
team. Then we hit more surprises. And we just...kept….going….
Result: We lost sight of business value, our pivots weren’t
dramatic enough, people felt burned out. When we ultimately
shipped, we broke the website - for a while. We shipped
again, successfully. We learned some valuable lessons!

60. Retro
to get to
learnings

61. Our learnings (more life/career hacks)
1. Never lose sight of user / business value - say it early and often.
2. Build habit of pivot or persevere discussions - if estimates change, and
at each sprint planning. “Still a priority? New info?”
3. Bring any change in scope to team and PM asap
4. Ship each sprint – good for user/biz value and for morale.
5. Mentoring is great for mentees and mentors and teams!
6. Rotate teammates off of projects - promotes shared understanding,
shared ownership over big decisions, and avoids burnout.
7. Legacy code was full of surprises and caused slowdowns (in
momentum and morale). Try a tech debt template.

62. Templates: Tech debt Benefits:
● Helps communicate
problem and impact.
● Helps break up the
work so it feels less
daunting

63. I hope you learned...
● What’s an agile team and how do they work
● What does a Product Manager do on an agile team
● Successful Engineer < > Product Manager relationships
● Life/career hacks
● Case studies
● Answers to your questions

64. Danielle Martin
LinkedIn: /daniellempost/
Q&A
I’d love your feedback:
http://bit.ly/Ada-Feedback