3 types of debt product teams need to tackle (+ solutions)
+ why I'm changing the direction of my content
Hey BPL fam,
I’m going to give it straight:
I’ve decided to micro-pivot my content direction.
The decision stems from the firm belief that B2B Product Managers own only a piece of the puzzle in product success.
To truly drive customer and business impact, PMs need to forge strong partnerships with go-to-market teams, especially Product Marketing.
Far too often, PMs and GTM teams operate in silos, missing out on the opportunity to present the right product to the right prospects/customers with a compelling narrative. This results in sub-optimal adoption and understanding of the product which in turn, act as false signals for future decisions.
In the era of AI, product features alone will not suffice. Your messaging, go-to-market strategy, and brand will be the wings that help your product soar above the noise. This is particularly crucial for 0-to-1 products navigating crowded spaces.
There are a lot of broken processes in this area which I’d love to explore moving forward. While I'll still touch upon adjacent PM / PMM topics, I’ll try to stay close to this new core.
Now that, that’s out of the way, let’s dive into this edition.
Here’s what’s in store:
Lines of 5 > hand-picked content pieces of the week.
Bonus Content > How to design a value proposition (with Pawel Huryn)
For PMs & PMMs > 3 types of debt product teams need to tackle
Lines of 5: Hand-picked content of the week
[Podcast] How to build 0-to-1 products in a company
This is probably one of the more tactical product management episodes on Lenny’s podcast. He talks to a popular PM at Figma (Mihika Kapoor) who describes in detail what it means to materialize a product vision in practice.[Case Study] How Dovetail grew
published a deep dive about Dovetail, a product-led B2B SaaS that’s been making waves in the customer insights category. The story explores how ideas go from a whiteboard to production, and how messy it can get when you roll out to the world.
Read here »[Novel take] A unique litmus test to assess Product-market fit (PMF)
talks about a different way to gauge PMF: when your case studies across customers start to look similar, it’s a good sign that you’re reliably solving one problem at scale. It’s a hot take, but one that’s going to get PMMs some food for thought.
Read here »[LinkedIn post] Difference between brand awareness & demand generation
Many product marketers conflate the two. The difference matters when you’re planning a go-to market for your product. Sam Kuehnle breaks it down in simple terms with relevant examples.
Read here »[Framework] Accelerating growth by focusing on features you already have
This piece by Ken Rudin hit home hard. The potential to grow adoption of already shipped features is an opportunity that most product teams ignore in the pursuit of more “shiny objects”. This is a must-read for all PMs and PMMs.
Read here »
Bonus: In case you missed it…
and I collaborated on a piece that is especially relevant for Product Managers and Product Marketers trying to work together. It unpacks business terms like “value proposition”, “messaging”, and “positioning” with examples in the context of taking a product to market. Must-read for products planning to make a mark in a saturated space:
3 types of debt product teams need to tackle
In the realm of product, debt is often only discussed in terms of technical debt.
However, two other types of debt can be equally detrimental to a product's success: product debt and marketing debt.
I’ll be unpacking these terms with a few examples.
Let’s take them one by one.
Technical Debt
Technical debt often refers to the work teams accumulate when they take implementation shortcuts and make sub-optimal architectural choices in the short run to meet demanding deadlines. Tech debt can also be associated with platforms built on outdated technologies that lack the power to service modern needs.
I like to use the dinner table analogy for this.
Imagine you order a dinner table from a furniture store but receive it an hour before your guests show up.
You get anxious. Instead of taking the time to assemble it as per the manual, you choose to take a hasty shortcut and set the table up with a combination of tape, glue, and nails.
The table stands upright but it's rickety.
It can't support the full advertised weight due to the rushed assembly. You can't place add-on accessories either because the table has an unstable base & slants at an angle.
But it somewhat does the job. You cover it with a nice-looking tablecloth. It works for your little dinner party.
After a few months, you plan to host a mega-party at your place. You need to place thrice the amount of food on the table as before.
The table isn’t sturdy enough in its current configuration. It can’t bear more weight.
You have a choice now.
Either you cut down on your requirements or get another table alongside it.
Or you take the brave route.
You rip out the adhesives, strip down a few parts, and re-assemble the components the way they were recommended.
This pending rework that needs to be done = technical debt.
It starts to bite when your friends wonder why you aren't inviting them to your famous dinner parties :)
I hope you got the analogy.
Tech debt creates escalating friction. It slows down development and even blocks you from developing ambitious features because the underlying way the code is structured simply won’t allow it or will become inconceivably complex to manage. The cost of technical fixes moving forward begins to rise exponentially too.
Tech debt accelerates due to a few reasons:
Pushing out releases ad-hoc and constantly firefighting bugs.
The feature suddenly takes a direction it was not designed for.
Poor software architectural practices or developer inexperience.
Temporary patches to make exacting deadlines.
Now, the common solution that’s suggested is along the lines of regular code reviews, refactoring code after every sprint, and better engineering management.
Another popular solution circulating in PM groups seems to be “allocate X% of each sprint to technical debt”.
I’m not sure if that’s how it works.
It may not be possible to break down technical debt work into granular, independent tasks that span over sprints. Sometimes, you might need a revamp of the entire module which can take a month or two. Other times, you may choose to qualify and size the debt and even de-prioritize it.
Interestingly, tech debt is seen as an engineering issue. That’s not always the case.
It can sometimes be traced back to the product team.
Overlooked edge cases, lack of clarity in PRDs, and failure to give developers visibility on the future runway can equally contribute to tech debt as well.
A quick example:
I was working on an automobile classifieds solution for the Middle East region. When preparing the specs, I instructed my engineering team that every car make and model can have multiple trims (variations in car specs). They started planning accordingly.
The 12-month roadmap had plans to roll out the website to multiple cities across the region.
Every region had a different price and car specifications for the same trim. For example, the same trim in some cities came with seat warmers while in others, it didn’t. While I knew about this, I had not shared it with the engineering team.
Luckily, my manager asked me to clarify this before work started. The engineering manager confirmed that had they not known this, the database would have had to be completely reworked when the multi-region launch came along.
Thus, we avoided work that would have accumulated later on by sharing the longer vision. And I learned a valuable lesson.
Let’s move on.
Product Debt
When a product starts to accumulate complexity that comes in the way of increased adoption, feature discovery, or understanding of the product, this is usually a sign of product debt.
Some common symptoms:
confusing information architecture (e.g. cluttered navigation bar)
outdated product copy
conflicting features that overlap each other
data hygiene issues due to a data model update
edge cases with increasing frequency of occurrence
It’s important to tackle product debt to prevent users from churning due to friction in usage or a reduction in customer satisfaction as the product footprint grows.
A modern example of this is Facebook when in the early 2010s, there were going through a series of design revamps that irked a lot of users. Those weren’t A/B tests. The sheer velocity with which they were rolling out sub-features pushed them to refactor their navigation multiple times.
I’ll also share a personal example.
I was leading product for a recruitment software a few years ago. We used to offer a module called “Evaluation Forms” which empowered recruiters to create custom forms to equip hiring managers to jot down their opinions about a candidate.
After a few discovery cycles, we realized that recruiters wanted a bit more. They wanted a way to collect candidate assessments from multiple interviewers and quantify each using a scoring rubric to make it easy to compare.
In response, we rolled out a far more advanced feature called “Candidate Scorecards”. These enabled recruiters to design custom scoresheets for hiring managers with scores and weights.
What do you think happened next?
We had two features on the navigation that essentially solved the same problem.
Why didn’t we just sunset “Evaluation Forms”?
Because:
several customers were used to evaluation forms,
the transition to “scorecards” required training and education, and
we had a massive backward compatibility issue i.e. how do we translate an evaluation form to a scorecard without affecting customer data reports?
We eventually deprecated Evaluation forms but till we did, we suffered “product debt”.
So, how do we solve for product debt?
The common proposed solutions are similar to tech debt:
Dedicate sprints to retool the information architecture
Anticipate product debt and issue tactics while writing specs
Conduct regular usability testing and file tickets to address issues surgically
They all have their merits but they don’t address the root cause at times: the product is becoming complex because we’re adding more without taking anything away.
Thus, here’s what I would suggest to do after significant releases:
Pull out feature adoption metrics (features used at least once in a 30-day cycle). Track which features are used.
For the bottom-tier of features in terms of utilization, debate within the team why they should be kept within the product. In some cases, they might be critical admin controls that, understandably, aren’t used frequently. However, in other scenarios, this exercise will surface features that are simply low-value.
Nominate them to be demoted in the information architecture, re-designed, or sunset.
“Sunsetting sprints” are rarely seen in the product world as the default mode of most teams is “additive”. However, the removal of underperforming features can reduce friction a lot without hurting activation metrics or CET/CSAT/NPS scores.
Dharmesh Shah (CTO of Hubspot) spoke about this in his episode on Lenny’s podcast too:
So every time you say yes to something, by definition you're saying no to something else, and so this goes back to the product heuristic we were using in the earlier years of our class.
Like, oh, when you put something in, you have to take something out because we want to keep the complexity roughly constant if we can.
Marketing Debt
Let me introduce this with two common situations in B2B teams:
The marketing site is inconsistent with the latest state of the product.
The sales team is unaware or not used to recent product releases.
When product managers and product marketing work in silos, information flows fairly slowly. And sometimes, there’s a complete disconnect.
Moreover, there’s a tendency to “hand off” work. Product notifies marketing about what’s been launched but then moves on to roll out the next sprint. Marketing is left to rely on what they “think” the feature does and take inspiration from competitors. This results in weak messaging and framing of value propositions.
This impacts the business in different ways.
Relevant personas may think the product isn’t for them (whereas it actually might).
Worse - irrelevant personas might opt for a demo due to the confused messaging.
Prospects might fail to find features the product actually has but isn’t advertising.
Sales collateral and demos reflect the wrong screenshots.
Emails and auto-responders described features that don’t exist anymore.
This can result in a drop in marketing qualified leads and poor feature adoption.
So, how do you resolve this?
I’ll tell you what the commonly proposed solution is first: periodic audits.
This means product marketing teams should set aside time in their calendar to sync up the marketing assets with the product in a quarterly or bi-monthly manner.
Audits help but marketing debt needs a more systemic change.
PMs and PMMs need to update their working model to operate in lockstep - from discovery to launch and beyond. This means PMMs need to be included in the problem-framing, solution design, and customer validation discussions so that they can absorb the context and remain vigilant of what’s to come.
When the feature enters the development stage, PMMs should be busy finalizing messaging and planning a launch or go-to-market (if required).
Of course, not every product release warrants a launch or even an announcement. But this model helps PMMs anticipate what they’ll need to affect shortly after a significant rollout happens.
Will that solve the problem completely?
No. Marketing debt is inevitable as there’s always a delay in updating all the collateral in time, especially when there are so many initiatives and campaigns at play. But it will keep the size of the debt in control. It moves things into a proactive mindset.
We struggled with this at vFairs (my existing employer) as well.
Eventually, we opted to build a squad consisting of PMs, PMMs, customer success managers, and marketing members to meet every week to circulate information about what’s taking priority on the roadmap.
I would also advise product managers and marketers to shadow sales reps in a couple of calls per month to understand how up-to-date the pitch is and where the gaps are. One thing that has helped us iwas to maintain a single demo environment with all the latest releases pushed to it.
Conclusion
Regardless of what kind of debt you’re suffering from, it’s important to know that the goal isn’t to eliminate it but rather, not to let it accumulate to a point it starts hurting customer or business outcomes. PMs and PMMs need to build practical models that let them address it at a time before the damage becomes exponential.
Till next time,
Aatir
Nicely articulated the different types of debt encountered by the PM. Well-structured. Thank you, Aatir!
I see that Bayt screen. 👀 Nice post