Turn Feedback Into Action: A Method for Scoping Support Issues by Brian Levine
0 likes174 views
1. The document provides a method for support teams to scope issues by developing a priority matrix with two dimensions: Impact and Severity. 2. Impact refers to how many users are affected, while Severity refers to how the product/service is affected. Different levels such as small, medium, large are defined for each. 3. For business-to-business companies, two additional dimensions are recommended: Customer Value and Customer Severity. Customer Value refers to how important a customer is to the business, while Customer Severity refers to how a problem affects a specific customer's product/service.
Turn Feedback Into Action: A Method for Scoping Support Issues by Brian Levine
- 1. Turning Feedback Into Action A method for scoping support issues Presented by Brian Levine
- 3. Currently ● Founder Bottle Cap Technology Previously ● Aerospace engineer Department of Defense ● VP Support GitHub ● Head of Support Plaid My background
- 4. Caveats We will primarily be discussing software support and how support teams interact with engineering and product teams. The methodologies we talk about are applicable to other teams and other fields.
- 5. The Problem
- 6. Standard support process 1. Customer contacts support
- 7. Standard support process 1. Customer contacts support 2. Support investigates issue
- 8. Standard support process 1. Customer contacts support 2. Support investigates issue 3. Support opens an internal ticket
- 9. Standard support process 1. Customer contacts support 2. Support investigates issue 3. Support opens an internal ticket 4. And then...
- 10. ...and then...
- 12. From the other side Engineers and product managers need to know how to prioritize feature work, internally reported bugs, and customer-reported bugs. Without more details, teams often default to ● what they are told to work on ● what they think is important ● what seems easy/fast ● what seems fun
- 13. Add details Support teams often add details to internal tickets to help other teams scope problems. For bug reports: ● How to replicate ● How many users are affected For feature requests: ● Who wants the feature ● Why they want the feature
- 14. Details help, but are not enough for prioritization
- 17. Two dimensions Impact How many people are affected? Think in terms of end users and individual people. Severity
- 18. Two dimensions Impact How many people are affected? Think in terms of end users and individual people. Severity How is your product/service affected? How does that affect the people using your product/service?
- 21. Support priority matrix 5,001 - 10,000 users 1,001 - 5,000 users 101 - 1,000 users 1 - 100 users
- 22. Support priority matrix 5,001 - 10,000 users 1,001 - 5,000 users 101 - 1,000 users 1 - 100 users Critical High Medium Low
- 23. Support priority matrix Severity Example definitions Low: ● Cosmetic Medium: ● Non-core component not functioning High: ● Core component not functioning Critical: ● Security or privacy compromise 5,001 - 10,000 users 1,001 - 5,000 users 101 - 1,000 users 1 - 100 users Critical High Medium Low
- 24. Activity time! Create your own priority matrix
- 25. Activity time! Share them if you want
- 26. Setting priority Critical High Medium Low 1 - 100 users 101 - 1,000 users 1,001 - 5,000 users 5,001 - 10,000 users Support Priority (SP) Example definitions SP4: This is no big deal SP3: We should work on this soon SP2: Let’s do this next month SP1: This is our next project SP0: Stop everything to do this
- 27. Your team doesn’t work alone
- 28. Getting buy-in Involve other teams early in the process Everyone should agree on what is important to the customers and the business Develop the Severity and Impact scales and the Priority ranking as a group, with support leading Other teams develop a process for assigning work using the Priority scale Who you involve from those teams depends on your company and teams
- 30. Two more dimensions for B2B companies Customer Value How important is the customer to your business? This is specifically for customers whose value does not scale in proportion to their user base Customer Severity How does the problem affect the customer’s product/service? This may differ from the affect the problem has for a generic end-user.
- 31. Customer priority matrix Crit High Med Low Low Med High Critical
- 32. Customer priority matrix CriticalHighMediumLow Customer Value Example definitions Low: ● Proportional to the size of the customer’s user base Medium: ● 2x - 5x more valuable than average for their size High: ● 5x - 10x more valuable than average for their size Critical: ● More than 10x more valuable than average for their size
- 33. Customer priority matrix CriticalHighMediumLow Customer Severity Example definitions Low: ● Cosmetic effect on end user Medium: ● Affects non-core customer product/service High: ● Affects core customer product/service Critical: ● Shuts down customer’s product/service; causes security or privacy bug Low Medium High Critical
- 34. Setting Priority Customer Priority (CP) Example definitions CP4: This is no big deal CP3: We should work on this soon CP2: Let’s do this next month CP1: This is our next project CP0: Stop everything to do this
- 35. Activity time! Create a customer priority matrix
- 36. Activity time! Share them if you want
- 37. Summary
- 38. Summary Define SEVERITY and IMPACT levels for issues and feature requests Use those levels to create a PRIORITY MATRIX Work with other teams (e.g., eng and product) to define levels and ranks Assign a PRIORITY rank to every issue/ticket you create internally Track progress on each PRIORITY rank with the other teams Optional: Create CUSTOMER PRIORITY matrix for customer-specific decisions
- 40. Questions?