4 Pillars of a Well-Oiled Product

A simple thought process for thinking about tickets and priorities.

Whether you’re a PM or a developer you’re unable to escape the reality that is competing priorities. You’ll be working on a P0 (highest priority) urgent feature one day and the next, there will be a fire that customer support needs you to put out right now. Every ticket is P0 to the person that created it, but what nobody admits publicly is that baring production outages or security breaches, nothing is as urgent as it seems. how do you rationalize what you’ll work on this sprint?

These 4 pillars: Features, Bugs, SRE, and Tech Debt will help you get the most out of your backlog by helping you rationalize and prioritize the different types of work based on how they impact your product. You’ll also have another data point to leverage when assessing the overall health of your product and team that you can communicate to your stakeholders and maximize your impact as a PM or Engineering Manager.

Memes… for the kids

4 Pillars — Features, Bugs, SRE, and Tech Debt

If you think about building and maintaining your product like you build and maintain a car, you’ll see a lot of parallels. Cars can have different features but all of them have a core feature set that gets a job done (getting from A to B). They can also break down (have bugs) and in some cases need critical updates (software updates, hardware recalls, etc). Cars also require periodic maintenance to ensure smooth operation and easy maintainability.

Here’s how I rationalize these 4 categories and how you can think about each type of work item in your next sprint planning.


These are typically prioritized by evaluating opportunity cost and how they fit with strategic initiatives. There may be a million dollar deal riding on some features or simply implementing them unlocks a sizeable amount of annual recurring revenue. Each product has a core set that must be built (the car must start and have gas and brake pedals) and a delighter set to differentiate it in the market (some cars have auto parking or 360 cameras).

Talking to customers, looking at market needs or conducting a cost/benefit or using Kano or MoSCoW analysis will help prioritize these.

Kano Model [Source]


Obviously bugs that make your product unusable (like a wheel falling off) are highest priority whereas bugs that slow down the user experience may take a backseat (like the backseat literally missing). Putting off those lower priority bugs contributes to churn however so be mindful of just how annoying that refresh glitch is when talking to customers.

Triage your bugs according to how impactful they are to a customer. Blocking bugs should be addressed first, while bugs that are minor inconveniences may be de-prioritized for something else. New bugs and post-release regressions should also get preference to older bugs.

This is obviously a P0 Bug

SRE — Site Reliability

These are tasks that typically come from your platform or security team. You’ll often hear to them referred to as non-functional requirements since there’s no externally facing change. You might view these with a risk assessment. There may not be an immediate need to build out a multi-region failover, or add monitoring & alerting infrastructure right now, but putting it off too long exposes you to a higher probability of a catastrophic failure. If your car gets a recall notice for the seat belt, you might want to get that looked at, but if there’s a recall on a faulty cup holder, there might not be a rush there.

Barring an onslaught of urgent features, seriously consider tackling some SRE tickets each sprint, especially if they’re low effort like installing security patches or updating a dependency. Consult a risk matrix for priority assignment.

Example Risk Matrix

Tech Debt

When your lead dev comes to you asking to re-write the platform and that you leave her alone for 2 months, its usually because of a mountain of tech debt that has crippled developer velocity. Think of this like an oil change. You could punt it, but eventually it will catch up to you and the sludge buildup will eventually cause your engine to seize.

Listen to your developers on this one. Punting these tickets generally don’t hurt but ignoring it for too long will cost you agility in future sprints or when a critical bug fix is required ASAP.

Credit: Aaron Huber Unsplash

Stacking Your Next Sprint

You prioritized these tickets in their respective contexts, now how do you prioritize them relative to other contexts? Stack your sprint deck in accordance to your company’s goals. Here’s what I typically do and recommend.

Start with bugs. Anything that makes the product unusable gets to the top of the list.

Then look at the proportions of your 4 buckets. Lets take an example where the backlog is mostly be features (about 60%) followed by Bugs (10%) SRE (20%) and Tech Debt (10%). When you look at what you want to accomplish for the week, and there are no constraints, you could stack each developer with a 60–10–20–10 spread, or mostly feature work with one bug, one SRE and one Tech Debt ticket. It all depends on what you’re up against and how you want to stack your deck.

You may find yourself working on a huge multi-million dollar deal contingent on the existence of some new feature set. You may need to punt the outstanding UI bug and risky SRE work to get that feature set done, to get more runway. This isn’t the best spot to be in, but the upshot is now you have a better idea of what your post-release plan is.

Splitting your work like this also helps communicate to your board, or executive team why your priorities change. Fore example, Tech Debt typically correlates to developer frustration and slower delivery, so you can use this system to communicate the fact that you sympathize with your engineering team and are prioritizing quality maintainable code. This also gets you another data point in ticket sizing, i.e. more Tech Debt would inform longer estimates.

Tying the Room Together

So there you have it, my take on how I look at the tasks that come in and make decisions around what to expedite and what to punt and how to justify those decisions. Grouping tickets like this gives a great insight to the health of your product and helps you forecast your delivery timelines with more accuracy while understanding the nuances of the technology that backs your product.

Software Engineer | Product Leader