Best Practices

Beyond New Features: Three Ways to Care for Your Product

I start every morning with a list. 

When I was younger, the list was simple. Go to school, do homework, ride my bike with friends, learn a new house skill (I started doing laundry when I was eight because I thought it looked fun). Every bullet on my list was meant for self-improvement, though I didn’t realize it at the time. Had I known better, maybe there would have been fewer Saturday morning cartoons and more studying. Maybe.

Over time, the list has changed drastically. Go to the store for groceries. Work on my budget sheet. Force myself to work out. Do the laundry (not for fun anymore). I still attempt to fit in some activities aimed at personal growth, but I have a lot more to-dos on my plate now. What bills do I need to pay? How will I boost my credit for my next car purchase? And if I fit in writing a blog post, bonus!

The modern product manager has been coached to focus on one thing and one thing only: add new features to your product. In an era of fierce competition and constantly changing technologies, staying relevant in the market is critical. And increasingly, the product team is seen as leaders when it comes to innovation and forward-thinking.

However, as products mature, they will have more and more needs. Like my morning list, product’s responsibilities will expand. But no matter what, a product manager has to balance, prioritize, and care for three main product needs: application support, technical debt, and features. 

Application support

I hate paying bills. The act of visiting each website, seeing the damage, and knowing that I get to deal with it all over next month is a frustrating, never-ending experience that I’m happy to do again and again. I consider each bill to be the maintenance and support I need for my preferred quality of life. I’ve made a conscientious decision that I need these things to be comfortable and happy, so I’ll continue to pay to maintain the norm with only the occasional fuss (I feel like I’m paying for every streaming service imaginable).

For those of you not on a product team, want to hear one of our dirtiest secrets? Every single product you ever use, sell, market, or know about will always have bugs. Always, always, always. Always. And that’s okay! 

As your team adds to your product, it becomes richer and more dynamic, almost taking on a mind of its own. During the unlucky times, this can lead to a couple of issues here and there, with the critical ones turning even the best product managers into firefighters. These experiences are inevitabilities, almost like a right of passage. Want to see if someone has the stomach to work in product? Throw them a problem and tell them there’s the potential to lose millions of dollars while everything is burning down. Then see if (or how fast) they run away.

While these critical issues are generally the most memorable, they’re also rare. During every meltdown, your bug backlog will grow, fluctuate, and possibly even lead to customer dissatisfaction. Sure, your customers may really benefit from some powerful new functionality. But how do you think they feel if a reported bug goes unanswered, essentially being swept under the rug for a rainy day? The Voice of the Customer practically becomes a scream from the rooftops until they are eventually running to something else that’s shiny and promising.

You may have noticed I didn’t call this section “bugs, bugs, and more bugs.” Application support isn’t simply fixing problems for customers, but also providing solutions for your internal departments. Imagine if your sales team could have a fresh set of standard data populated with the press of a button prior to a demo. Or maybe your customer success team could have an easier and faster way to set up new accounts. Whether your company is drinking its own champagne by using your products or simply supporting you, it’s never a bad thing to listen to internal problems. Your team may be able to provide useful solutions. You’d be surprised how a simple change can improve team morale and employee retention!

Technical debt

My first car was a major taste of freedom. Music blaring, windows down, and friends laughing as I drove through hot summer nights are unforgettable memories from my young adult life. I loved my first car so much that I didn’t even realize how much it cost me. As a fresh teenager, I had no idea what or how impactful my credit score was. I paid my bills on time, which unfortunately included the precise minimum payments on my credit cards. When the dust settled and I realized I paid for a car-and-a-half, I knew I had to make some fundamental changes to never make that mistake again.

Like my credit habits, your product portfolio will eventually require foundational, architectural changes to grow and evolve. Want to build an amazing, groundbreaking feature? That’ll require the equivalent of an 800+ credit score. There will come a time when you realize that what you have built is no longer perfect, and this will lead to what we call technical debt: a backlog of refactoring work you’ll need to address. 

Whether due to tight deadlines, multiple feature releases, or customer demands, you’ll sometimes have to sacrifice quality for speed. And with that sacrifice will come technical debt. Just like you don’t know what will happen in your life a year from now, you can’t predict which areas of your product will need retooling down the road. This is inevitable yet necessary. And you have the power to manage this properly, and, if you’re lucky, proactively.

There is one word that scares me more than any other: refactor. For a new feature to work properly with the rest of the application, code needs to be redone first. Refactoring is risky and time-consuming, sometimes becoming nearly surgical in nature. It will almost always add to timelines, and possibly even result in a ripple effect throughout the entire system. 

As a product manager, you may not understand exactly what this technical debt backlog entails (there’s been an ongoing debate as to whether or not product managers should have a technical background, which I won’t attempt to argue here). Instead, I urge any PM to take three key steps with regard to technical debt: 

  1. Make sure technical debt is written up by your team so you can track it.
  2. Work with your team (architects, senior devs, etc.) to prioritize the work properly.
  3. Advocate to get the work done!

It won’t be a perfect science. You may find that your devs sound like your customers, claiming that the sky will fall if the work isn’t done immediately! Just remember this: it’s your job to patiently understand the problems and potential impacts. Maybe it’ll improve performance and stability. Perhaps it’ll make areas of the application faster. Maybe it’ll feel like it did nothing except pave the way for something new. Regardless of the outcome, it is imperative that you allow your product to fundamentally grow behind the scenes so it can “buy” that brand-new feature you’re so excited about.


I’ve wanted to write blog posts for years. Whether it was for personal reflection or professional mentoring, the desire to share my thoughts with the world was exciting and fulfilling! I eventually picked writing back up over the years, allowing me to refine my personal style and voice as I branched out to new topics and ideas. Even with all the distractions in my life, I made sure to take time for self-improvement.

Your product is never done. There will always be room for minor improvements, new additions, or even overarching changes to what already exists. As you capture bugs and technical debt, you should always be listening out for customer feedback. This can be through explicit conversations with customers or with amazing tools such as Pendo or FullStory.

Out of the three areas to care for within your product, features are where you will let your vision shine. Delivering value and delight to your customers through the beautiful combination of creative technicality and seamless design is simply one of the most incredible experiences imaginable. Being a product manager is a stressful role. Sometimes, it even leads to outward frustration and actual breakdowns. However, there is nothing like the feeling of creating something that people love. Just be sure not to let your vision shine too brightly. Otherwise, you might miss the building flaws you need to address.

Caring for your product

Your product, like your life, revolves around a series of complex requirements and needs, all of which should be addressed and supported. Depending on the maturity and lifecycle of your products, you may find that some areas require more attention than others. Nonetheless, your product needs your love and care to be the best it can be. 

If there’s anything to take away from everything here, it’s this: you’re not a feature manager. You’re a product manager. Treat your product with the respect it deserves, and you won’t be disappointed.