Paper cut problems: the subtle menace that’s undermining your product and retention
The little things tend to be the ones that fall through the cracks. If you’re not careful, though, they’ll be the end of you, like the saying goes... death by 1000 paper cuts.
What exactly are Paper Cut Problems?
Well, can you think of a part of your product that you know isn’t as good as it should be? That’s hard to use? A little buggy? Difficult for the user to find?
These are what I call Paper Cut Problems. They’re the scourge of any fast-moving product team.
What exactly is a paper cut problem?
Paper cut problems are the imperfections or blemishes in your product experience. “Paper cut” since a single paper cut is annoying, yet not a big deal on its own. But, 1000 of them and you’re in big trouble.
These problems are the ones that are hard to prioritize in the “big picture.” Leadership will often continue to put them off for “next quarter” and never get around to actually working on them directly.
One of the best ways to identify paper cut problems is through talking to your users. Nothing surprising there, right? The challenge, though, is your standard approach to customer interviews may be ill-suited to surfacing these kinds of problems.
Instead, have your interviewee walk through a standard workflow in the product while narrating out loud. You’ll be looking for moments where they point out little hacks they use to get around a frustrating process or times where you can imagine they’re rolling their eyes. You’ll rarely hear an explicit, strong complaint. If you do, that’s probably an actual problem rather than a paper cut problem.
Ideally, you’ll be talking to enough users to start spotting recurring frustrations and friction. My rule of thumb is that you’ll want to speak to 6-8 different users before you feel confident you see a solid pattern.
As a product leader, you need to get your paper cut problems on the product roadmap
If you’re going to make a dent in these problems, you should be explicit, including them in your planning process.
I’d recommend two main approaches, but it will depend on your context which will be most effective.
Smaller product orgs will want to allocate a portion of each team’s time (easy to do if you’ve built a product portfolio roadmap). Larger orgs may be better off having a dedicated sub-team where they focus exclusively on this kind of work for a period (usually a quarter).
As you build your roadmap, resist the temptation always to put this work at the bottom of the list. If you’ve just had a big quarter of working on new features, it can even be a good “palette cleanser” for your team to start the quarter with this kind of work that’s more incremental in nature.
Before you try and boil the ocean, you need to prioritize which of these problems are most worthy of investment
Having zero paper cut problems isn’t realistic, so it’s all about balance and tradeoffs. Don’t solve everything at once, instead decide on a level of investment that makes sense at the macro level. Then fill that capacity with the most impactful work you can.
The pain vs. frequency mapping from the Jobs To Be Done framework is a great prioritization methodology for paper cut problems.
You’ll want to rank your work by how painful it for the user and how frequently your users experience the pain.
It’s better to solve a problem with 6/10 for pain that’s experienced daily by most users than a problem that’s 7 or 8 on the pain scale but only occasionally experienced by a handful of customers.
As always, prioritization is as much art as science, so don’t over-invest in trying to get the perfect portfolio of paper cut problems to solve. Instead, try to pick things you’re confident you can solve and have a tangible impact on the customer experience.
Not all paper cut problems are user-facing
While the end-user directly experiences most paper cut problems, there’s always plenty that are more internal and impact the end-user more indirectly. Be sure to consider these problems too.
What’s significantly hampering the productivity of a particular team or department in your organization? Could your product and engineering org build a small tool that helps automate some high-frequency aspect of their role? Could you help procure and integrate a third-party tool?
Keeping an active backlog of these problems can be helpful, but beware the downsides
I think having an extensive backlog is overrated, especially for this kind of work.
Instead, take the extra time during planning to think carefully about what issues are coming up frequently.
Organize a round of customer interviews focused on surfacing friction and frustrations.
Put your empathy hat on and put yourself in the shoes of your power users. What’s going to frustrate them? What are they longing for?
I’d bet most of you reading this will have something that comes to mind. Something frequently discussed but never gets worked on. That’s likely where you should start. How can you breakdown that big, scary problem into a solvable problem?
What’s the paper cut problem that’s been bubbling under the surface in your product? How can you and your team make a meaningful impact on it in your next planning cycle?