Question

How you prioritise customer facing feature with X impact on engagement vs a tech driven task like upgrading the libraries to eliminate legacy bugs which have no immediately visible impact? assumption is that this for Facebook android App

Answer 1

Depends on what the quarterly goals we've set. If we have enough bandwidth after allocating Engineering resources to the products/features we've set out to release that quarter, then we can set the remaining resources to work on tech debt. Also, assessing impact of these libraries on future releases planned for Android app will tell us if we should work on it immediately or in the subsequent quarter.

What do you guys think?

Answer 2

Both efforts can be measured against a fixed criteria like impact on user, cost in terms of the engineering effort, confidence on our ability to release the feature in time. However, if the overriding short term goal is  to increase engagement, I would want to find precedents of how fixing technical debt that have no visible impact have affected engagement v.s. the potential impact of this newly released feature would have on engagement and I would overweight engagement in my comparison.

Answer 3

A few different sets of ideas clustered together to help assess the priority: 

Trade-off analysis:

Feature Group	Competitive Offering	Overall Product Health (performance, security, efficiency)	Long Term Risk	Scoring
Customer-facing	Yes (3)	No (1)	Risk of losing user engagement (5)	9
Tech debt/architectural	Doesn't impact (1)	Yes (5)	Scalability & vulnerability issues (5)	11

Categorize tech debts in terms of value to the business & measure it in terms of the effort for the work:

Category	Effort	Value
App Performance	Medium	Doesn't yield any significant change
Security Update	Low	Allows user-profiles secure
Android OS changes (compliance)	High	App/Feature Crash, App updates
Inhibits certain modal/design toolkit changes	Medium	Allow creating modern modal design & in-app experience

Based on the first analysis, we get a score that tells us that tech debt will be expensive misses and should be prioritized.

Based on the second analysis, I can choose categories of work I want to do incrementally towards tech features so I don't completely neglect the most important ones.

Lastly, I would ask questions about what the "functional feature is and see how it impacts user engagement". I will try to map how the feature of that feature may be tied to one of these categories from the second analysis and try to find a meaningful co-relation (if one exists). Having a more digestible picture of the scenario then will help us decided what efforts to prioritize.

Answer 4

If you are a startup, its always a good to write-off certain percentage of tech bandwidth for techical debts. The reason is we need to pay the techical debt as regularly as we can even if does not have direct impact on core metrics else it will have large impact on business. Just like we have goals and metrics for product, it would be good to have similar to goals for the tech metrics as well such as performance metrics, quality metrics and have a plan to improve these. You can ask any companies about the large outages that they had becuase of code or performance issues and what they lost during that period. 

For the sake of this questio, lets make an assumption that tech team is coming up with a genuine items that will have long term impact on the code (and not fancy stuff). The question that will come is when to pick these items (to be specific which sprint or which quarter). A simple rule would be pick up the customer facing items that will impact on the certain metric first in the quarter (or sprint) and deliver it so we get enough time to get the feature to be adopted and show its results and the engineering team could use the rest of the time to pay the debt. 

There will always be exception to the rule such as 

1. The new customer facing feature would require certain technial debt to be paid to begin the work. 
2. The technical debt item may take longer than a single sprint 
3. The technical debt does not necessarily impacts the tech metric that we are trying to improve (say performance) 
4. If we do not fix the item, that it will expose us to security vulnerabilities or meet any regulatory guidelines (say PCI) 

 

 

 

 

Answer 5

1. What is your goal? 
2. How do you prioritize your backlog?
   1. I would use criteria like impact on goal, urgency, impact on user, engineering effort, and compare feature vs this tech debt and go through a score card exercise. 

Answer 6

Few questions to ask for -

1. Though the bugs don't have an immediate visible impact, how much is it impacting the velocity of the team? Will the velocity of the engineering team improve after upgrading the libraries as they don't have to deal with versioning issues

2. How long does it take upgrade the libraries?

3. Though the bugs are not impacting now but will the technical debt will go unmanageable if we wait for a while

4. Are there other engineers who can work on the upgrade?

5. What life cycle stage is the product at? If it is a very early stage product then living bugs with no immediate impact is OK. Adding value to customers through new features is of higher priority