At incident.io, we like to push the pace to deliver feature requests and bug fixes quickly. What's one of the things that helps us push the pace? The Product Responder role.
In this episode, we sit down with Sam Starling, Product Engineer, to talk about this crucial role and how it, ultimately, gives us an upper hand. We chat about:
- How the role came about
- What responsibilities the role has
- What Sam's week as a Product Responder looked like
...and more
Read more about the Product Responder here.
The transcript below has been generated using AI and does not match the audio. It is a highly summarized version of the conversation you'll hear.
Luis: Let's dive right in. What is a Product Responder here at incident.io?
Sam: That's a good place to start. We have around 20 engineers at incident.io now. Most of us have encountered something similar to a Product Responder in our previous roles. The way I see it is that it's one of the ways we set ourselves up to make our products great. It's a team dedicated to shipping things quickly for our customers, whether they are small features, reported bugs, or incidents. We work closely with customer success and sales, and sometimes we even ship things for customers in the sales cycle to showcase our collaborative engineering approach.
Luis: So it's a role with significant responsibility. How does the Product Responder team come together?
Sam: We operate on a weekly planning cycle. Every week, teams gather to set goals for the upcoming week. We often have multi-week projects, and more than one project may run simultaneously within a team. Part of this weekly team conversation is deciding who will be our Product Responder. It's not a fixed role; it rotates weekly. This rotation helps us collaborate across teams and strengthen relationships. It also broadens engineers' knowledge of different product areas, fostering cross-pollination of ideas.
Luis: Has the Product Responder role existed since the inception of incident.io, or is it a more recent addition?
Sam: I had to check with others since the Product Responder predates my tenure. Most of us had encountered a similar role in our previous jobs, and the decision to introduce it here was early on. We've always had a direct connection to our users, often interacting with them in shared Slack channels. As we all consider ourselves product engineers, this role was introduced to streamline customer interactions. It helps manage the situation where multiple engineers might assist a customer simultaneously, avoiding confusion. Additionally, it serves as a shield for other teams, allowing them to focus on their projects without being distracted by urgent customer issues.
Luis: Product Responder sounds akin to being on call. Why is it not the same?
Sam: There's a blurred line, but on-call and product responder roles are distinct. Product responders from our team handle the pager during office hours, separate from those covering evenings, weekends, and overnights. While on-call involves responding to alerts when something goes wrong, Product Responders also work from a backlog of tickets, addressing issues reported by customers or other teams. The focus of on-call is narrower, primarily dealing with incidents, while Product Responders handle a broader range of reactive work.
Luis: You mentioned benefits earlier. Can you elaborate on the advantages of being a Product Responder?
Sam: The main benefit is the reduction of our reaction time to issues. Having a dedicated team focused on responding to customer needs shortens the time between detecting a problem and fixing it. Product Responder act as a dedicated group bringing delight to customers, whether it's fixing bugs or implementing requested features. This close interaction with customers, paired with a swift response, creates a positive relationship. Customers experience fast issue resolution, reinforcing our commitment to providing quick solutions.
Luis: If tomorrow, Product Responder was no longer a role, do you think it would have a severe impact?
Sam: The workload wouldn't change; it's the same queries, bugs, and customer issues. The impact would be on how efficiently we manage that workload. Without Product Responder, everyone's day would be more interrupted, and the pace of projects might slow down. Communication would become challenging, and work distribution might become uneven. Maintaining the high bar of quick issue resolution would be difficult, potentially affecting the trust we've built with customers in terms of responsiveness.
Luis: It seems like Product Responders play a crucial role. How do they contribute to our work at incident.io?
Sam: Product Responder provides structure, ensuring a dedicated team is ready to respond to customer issues promptly. They offer a clear escalation path for customer success and support teams. This structure allows for efficient communication and prevents customers from feeling passed around. The dedicated team also shields other engineering teams, allowing them to focus on projects without worrying about immediate customer issues. This specialization and focus on responsiveness set the foundation for a positive customer experience.
Luis: We've discussed what Product Responders do. Is there any preparation involved beforehand?
Sam: Generally, there's no week-to-week preparation. The role rotates, and the team adapts. However, during onboarding, which spans the first three weeks as a product engineer, there's preparation. The initial focus is on shipping small features to customers, followed by training on leading product responder. This includes holding the pager during the day, triaging incidents, and learning how to manage the team effectively. The goal is to ensure engineers are prepared to take on Product Responder responsibilities when needed.
Luis: We've touched on customer interactions. In your experience, do engineers at incident.io speak to customers more than in your previous roles?
Sam: Absolutely. In previous B2C roles with a larger user base, the feedback received was often aggregated. Here, the B2B environment allows for direct communication with users interested in specific features or affected by certain incidents. The ability to reach out to users directly, share updates, and even fix issues promptly creates a more direct and meaningful relationship. The shared mission with customers in the incident management space fosters a strong connection, making customer interactions more frequent and valuable.
Luis: Reflecting on your first and most recent week as a Product Responder, what changes do you see in your approach?
Sam: Over the past year, I've shifted from a ticket-by-ticket focus to a more comprehensive view of the backlog. I now step back, identify themes, and look for more efficient ways to address multiple issues. This approach involves a bit of art, balancing priorities, and sometimes sidestepping to handle medium or low-priority items quickly. It's about spotting patterns, tackling related issues together, and considering the bigger picture. This shift allows for more strategic and impactful use of our time as Product Responders.
Luis: Could you walk me through a typical week as a Product Responder, based on your recent experience?
Sam: Our week starts with a Monday kickoff, reviewing the team composition and any weekend incidents. We discuss if we need additional staff for the week and evaluate our workload. We used to have standups on Monday, Wednesday, and Friday, but recently, we shifted to daily standups. Customer success is always involved, maintaining a strong connection. A wrap-up on Friday allows us to reflect on the week, discuss improvements, and ensure we're setting ourselves up for success. This half-hour session is crucial for refining our processes and making Product Responder more effective.
