I recently gave a talk at Code Fellows as a part of their Partner Power Hour series about how product managers and developers work together at Avvo. We’ve learned all of this through trial and error, so hopefully this gives you a head start as you begin your dev career.
Ready? Let’s get started.
How do agile teams work?
Every company and team do sprints a little differently (this video by Henrik Kniberg gives a great overview). Here’s what it looks like for my team:
The Team
Our team includes developers, data engineers, quality assurance (QA), user experience (interaction designers and content strategists), business analysts, and product managers.
What does the team actually do each day?
We work in two-week blocks of time called “sprints.” During each sprint, the team has goals and deliverables for features or bug fixes to deliver to our users.
- Sprint planning: We start the sprint with planning. As a product manager, I share with the team our goals for the next two weeks, and the problems we’ll solve for our users. The team figures out how to accomplish those goals and solve those problems.
- Daily standup: Every day, we have a quick 2-5 minute standup. Each teammate says what they worked on yesterday, what they’re going to work on today, and if they’re blocked (so we can take action to unblock them).
- Demo: At the end of the sprint, we demo the user value we delivered, using the Problem, Action, Result framework (more on this below).
- Retrospective: After the sprint we get together for a 30-60 minute retro. We discuss what went well and we want to keep doing, what didn’t go well and we should stop doing, ideas for next sprint, and high-fives / props to teammates.
- And then we do it all again next sprint!
Traits of Successful Developers & Product Managers
In and outside of sprints, these are these are behaviors I’ve seen from the most successful developers and product managers I’ve worked with. Together, they make for dream-team working relationships—which makes it much easier to deliver value to your users each sprint.
Behaviors of successful developers
- Focus on delivering business and user value.
- Ask lots of questions, especially if you don’t understand why you’re doing something.
- Collaborate with others. This means valuing a diversity of ideas, healthy debate, and hole-poking before the team converges on a way forward.
- For any task or request, explore the options, communicate the pros and cons of each, and recommend a direction or approach.
- Don’t spin too long. Say something if you’re blocked, slowed down, or confused.
- “Be kind and curious.” One of our dev managers, Leslie Zavisca, said this. I couldn’t agree more!
- Practice communicating technical things to non-tech folks. Pictures work well!
Behaviors of successful product managers
- Deeply understand your users and their problems and goals. This applies to your external users and your business stakeholders.
- Create a strategy and roadmap that balances these user goals, broken up into small, well-defined chunks of work. Then communicate the strategy to many people and groups, often in many formats.
- Bring the team problems to solve or goals to achieve, but not solutions—that’s the team’s job.
- Unblock and speed up the team. This includes shielding them from random requests, superfluous meetings, and anything else that unnecessarily breaks their focus.
- “Be kind and curious.” Leslie’s advice for the win!
Simple, Helpful Frameworks
These are two of the frameworks we use at Avvo when approaching new projects (for example, during sprint planning) and describing our work to others (for example, at end-of-sprint demos).
Framework #1: People Problems
We learned this framework from Julie Zhuo’s excellent talk, How a Facebook Designer Thinks. It’s super useful when applied to sprint planning.
Why: This helps you focus on real peoples’ problems that will move your business forward and avoid wasting time and money. For example, Airbnb is successful because people had a problem with hotels: hotels were expensive and non-existent in some areas people wanted to visit. Lyft is successful because people had a problem with taxis: depending on where you live, taxi cabs were hard to find, difficult to call/schedule, and expensive. Similarly, your work will be most impactful if you focus on the real people problems you’re trying to solve.
When to use it: Anytime you’re creating or working on a project. We use it on our roadmaps, when sprint planning, and in our feature and bug tickets.
How:
- What is the people problem you’re trying to solve? Who are these people/users and what are their specific problems, needs, and goals?
- How do you know it’s a real problem worth solving? Teams’ backlogs are filled with problems and ideas. What qualitative and quantitative data do you have to show this problem is big enough that you should tackle it over all the other problems out there?
- How will we know when we’ve solved it? Make sure you have a clear idea of what success looks like for your people/users, and know how you will measure when you’ve reached that point.
Framework #2: PAR (Problem, Action, Result)
When to use it: Anytime you’re talking about your own work, or the work of your team. The place we use this most is at sprint demos, when we’re showing our work to stakeholders and other teams at the end of the sprint.
Bonus: It’s also helpful to use in interviews and your resume/portfolio.
Why: It’s important to be able to tell a clear story of your work and why it matters to your users and your business.
How:
- Problem: What problem were you trying to solve for your users and/or the business?
- Action: What action did you take? What did you do to solve the problem? This can include research, design, technical work—anything you did in an effort to solve the problem.
- Result: What was the result? What value did you deliver to your users and the business? What did you learn that you can share with others? This is not limited to success—it’s often really educational (and fun) to share failed tests!
There you have it! This is a brief snapshot of how sprints work at our tech organization, and how product managers and developers work together to get things done.
Questions? Comments? Find me on LinkedIn.
Learn more! Some of my favorite videos and books that have shaped my approach to product management.
- Start with Why by Simon Sinek
- How a Facebook Designer Thinks by Julie Zhuo
- Design for Real Life by Sarah Wachter-Boettcher
- Technically Wrong by Sarah Wachter-Boettcher
- The Lean Startup by Eric Reis
- Don’t Make Me Think by Steve Krug