On Product Debt
We’re all familiar with technical debt. You may be familiar with UX debt too. But one of the biggest challenges Product Managers currently face is product debt.
What (exactly) is product debt?
It comes in 2 flavours:
‘Type 1’ is the accumulation of unnecessary features or functionality that weigh down the user experience of individual products. It refers to the design and feature hacks that are introduced from time to time but which leave the overall experience looking and feeling inconsistent.
Andrew Chen labelled this ‘Product Design Debt’ and Ben Yoskovitz wrote an excellent summary of how and why it occurs:
“Product debt comes from making rush decisions. It comes from lazy product thinking and design. It comes from the hope that adding “just one more feature” will solve all of your problems. It comes from wanting to push features as quickly as possible.”
‘Type 2’ is the discrepancy between different products in your ecosystem and the ongoing challenge of maintaining the ‘right’ feature set for each. Some prefer to call it ‘channel debt’.
Facebook was nearly killed by Type 2 Product Debt. Mark Zuckerberg acknowledged in 2012 that the company had wasted 2 years overlooking mobile (or worse: betting on HTML5 instead of apps) and needed to move fast to avoid becoming a web-only service.
Thanks to him, they did. In fact, Zuckerberg’s (in)famous decision to ban Facebook’s engineers from using the website internally is a cautionary tale about the temptation of Product Teams to obsess over micro-details whilst missing the big picture entirely.
In the early days of ‘multichannel’, best practice dictated that mobile products should be scaled-back, utilitarian versions of websites. This reflected the limitations of both device and network. It also reflected the mental model we had of consumer products at the time. Like Steve Jobs’ ‘Digital Hub’ strategy, which envisioned the Mac as the centre point in an ecosystem of interconnected devices, the desktop experience was regarded as the primary product and the most ‘complete’. Mobile and tablet products required more focussed use cases.
Fast forward to the present and things have flipped around. Benedict Evans observed last year that the smartphone is ‘now the sun and everything else is in its orbit’. Some of the most influential products right now (Snapchat, Instagram, WeChat, Whatsapp) are mobile-only. This raises specific questions for product managers:
“Do we need to solve for the ‘mobile only’ user? Should each product be capable of being used in isolation?”
The answer (of course!) is, it depends. It depends on the problem your product is solving and your customers’ context of use. Intercom’s Paul Adams:
“If you’re designing and building software to sell to employees or companies, and that includes everything from enterprise software to calendar and to-do apps, you better be thinking about big screens as well as small ones. It’s not just about mobile-first.”
Mobile only products, he points out, are rushing to build web apps for much larger screens. Some activities will never be achievable on mobile devices, especially in the workplace. You can solve for the mobile user in the first instance, but you’ll need to extend to multiple channels if you want true scale.
The need to constantly evolve products in order to remain ahead of (and differentiated from) the competition exacerbates the problem of product debt. As Facebook found out, incremental improvements around a local maximum are usually too little, too late. Containing product debt requires deep insight into the usage habits of your customers and the honesty to recognise that certain products require immediate, short-term focus in order to avoid destabilising the overall experience.
In one of the best essays (ever) on the dynamics that affect shipping, Jocelyn Goldfein examines the differing contexts of each product category. Facebook struggled to transition to mobile because the constraints of deploying within Apple’s domain challenged its entire engineering philosophy:
“As the company’s focus shifted to native mobile apps, the engineers hired for their mobile expertise insisted on heretofore unknown processes like feature and UI freeze, functional specs and QA.”
The web, by its very nature as an open standard, will always be the most friction-free channel to evolve products within. As a result, examples abound of ultra-agile engineering companies shipping product updates many times each day. Native apps, on the other hand, require 3rd party intermediaries and (in the case of iOS) approvals with significant lead times. This makes daily deployments impossible.
The need to keep apps more focussed and free of extraneous features means it’s a challenge deciding which elements to carry over from one to the other.
Paying down Product Debt
So how can Product Managers remain vigilant and contain the risk of product debt? My suggestions are:
Have a clear view of what your value proposition is — Slack’s Stewart Butterfield likes to pay tribute to Paul Buchheit’s insistence that Product Managers should always ask:
“If you’re creating a new product, what are the three (or fewer) key features that will make it so great that you can cut everything else?”
In Slack’s case, Butterfield chose to focus on what he refers to as “leave-state synchronization,” which allows users to pick up exactly where they left off, no matter which device they were working on. And Slack does this very, very well. Which leads nicely to the next suggestion…
Limit the number of products in your ecosystem — don’t spread yourself too thinly. Just as individual products should excel at a small number of things, your product ecosystem should only consist of outstanding products that interrelate perfectly.
Getting this right is much harder than it looks and is ultimately what distinguishes rookies from vets. Great product teams don’t rush release products or worry about being early to the next ‘hot’ platform (VR, anyone?). This is a mistake many marketing-lead organisations make. In fact, a lot products are really campaigns: pushed out to demonstrate relevance but left to wither on the vine when the media spotlight moves on.
Accept that the web leads — Unless you’re mobile only, it’s easier, faster and less risky to innovate and experiment with new features and design ideas on the web. You can release faster and (more importantly) roll back quickly if things go wrong. You can split-test, hack in ideas, then make them disappear at pace. You can show things to a small subset of your base. I know you can do this with apps too, but it’s more laborious and less efficient.
The constraints of shipping native products are often overlooked. As Jocelyn Goldfein points out, Product Managers need to:
“…be prepared for shipping mobile apps to have more in common with shipping operating systems than with shipping for the web.”
As a result, product debt often accumulates in native channels as development focus shifts constantly towards the path of least resistance (ie. the web).
Finally, make sure you…
Take time out to repay product debt — in the relentless pursuit of perfection, it’s inevitable that some of your products will ‘fall ‘behind’ the others. Product Managers need to make time to realign them, to pay down the debt.
Newsmart, the product I manage, is no different from any other digital ecosystem. We’re subject to constant JFDIs, demands for short-term feature hacks and have a fast-moving website where new features and design changes are trialled constantly. As a result, we periodically need to devote an entire sprint cycle to paying down product debt, especially on our mobile apps, to ensure their user experience is as rich as the web. Making time to do this is never easy but is, like all debt repayment, a crucial long-term investment.
Product Management is (and always has been) a juggling act. Product Managers need to work hard to co-ordinate competing demands for new features and design enhancements within individual products. But they also need to synchronise the development of multiple products within the broader ecosystem. To achieve this, they must ensure that each delivers on the brand’s core value proposition.
Monitoring (and managing) product debt is one of the best ways to perform this juggling act and to guarantee you are considering the experience of the ‘multichannel’ and the ‘unichannel’ user at the same time.
