The "quality of life improvement" trap and how to avoid it
On product discovery and the "QOLs vs value generators" debate you should absolutely be having
I work with a lot of SaaS companies on troubleshooting growth and identifying growth opportunities, and a common pattern I’ve noticed over the years when faced with a leaky-bucket over time (like revenue cohort retention) is just how misleading the product management process can be.
Product is a complex beast. It depends on a lot of inputs, the translation into outputs, and a meeting of reality.
For example, we talk to customers, get a bunch of feedback about what they want in the product, we build it, and then start to assume that just by building the feature, we’d keep the customer.
This cycle of product development leads to putting a lot of pressure on marketing and sales to generate as many leads as possible because the product can’t retain or expand the existing customers we’ve already got.
When we open up the product hood, the breakdown is surprisingly simple: we’ve got way too many “quality of life improvements” on the roadmap and not enough of the stuff that creates true value for customers.
Let’s break it down.
There’s “quality of life improvements” (QOLs) and there’s “value generators”.
What are quality of life improvements?
Quality of life improvements are simple: they’re slight tweaks and adjustments to features that already exist in the product. It’s taking something that’s already been built and expanding the value by a tiny bit to make it a little more usable to the customer.
Think like when Google Calendar gave us the ability to select our own custom colors for our calendar events or when it added the rolling 3-day view in addition to the weekly daily view in the mobile app.
Adding colors to events existed before, but they expanded it in some way that created marginal value. Weekly and monthly views of your calendar already existed before, but the rolling 3-day view was highly requested and new.
Note, however, that these are not to be confused with “bugs”; bugs are when the product does not complete the desired outcome as intended. Bugs have their own lane and of course also need to be addressed accordingly.
QOLs are much less riskier to build by nature, but they also often don’t have the most leverage in terms of growth. QOLs are more comfortable because you already know what the feature is about and how it needs to improve.
Examples of “quality of life improvements”:
A customer using an analytics platform wants to be able to view their reports in a monthly view in addition to a weekly view
The weekly view already exists, but it would expand the value of the existing feature if they could also have it in a monthly view
A customer is using a learning management system to serve courses to students. They can block certain students from taking certain courses, but they have to upload a list instead of just copy/pasting the list into a box
Blocking already exists as a feature, but the experience needs to be adjusted so it’s easier for the customer to manage this
A customer using a vacation rental management platform wants to be able to require a security deposit before guests book rather than after
Security deposits already existed, but the customer wants more control over when
Okay, so what about value generators?
Value generators are the opposite: whether big or small, value generators are the features that venture into new territory. They expand the value of the product by seeking and completing new “jobs” that the customer has (whether they’re aware of it or not).
Think like when Gmail finally enabled us to schedule emails after years of not being able to do so.
Or when Google Calendar launched “Tasks” and enabled us to track our tasks in the app or when you could create “Focus” blocks that would reject any other meeting invites that dared to invade your sacred time.
Value generators venture into the “net new feature” territory. It’s possible that it’s based on an existing feature, but it’s not a tweak — it’s a lateral expansion. It’s extending the value one can realize from using the product.
Value generators tend be riskier; nothing is ever 100% certain, but building what you believe to be a value generator is a bet that you’re making (and hopefully you’re making it based on quality qualitative insights). Value generators also require more resources since you’re not tweaking an existing feature, but adding to it or expanding it in some way.
Examples of “value generators”:
A customer using a translation management platform wants to be able to translate pages of their website in addition to being able to translate .DOCX files
Translating websites isn’t a feature offered today, but it can translate documents like InDesign files and Word documents. This would therefore be considered an expansion since it’s not necessary a file that gets uploaded.
A set of customers have been asking for a specific integration into JIRA that would enable them to export and import certain tasks
Value is expanded when adding the integration because it supports more of the customer's workflow
A segment of customers using vacation rental management software have been asking for reporting and dashboards
The software did not previously provide reports or dashboards, so this will be a new value expansion opportunity
QOLs: the double-edged sword
Quality of life improvements are absolutely necessary. You need to make QOLs. I don’t want to founders, product owners, and growth folks out there thinking that QOLs are trash. They’re not.
They improve the overall experience of the product and make it easier to use. It increases the perceived value of the product even though QOLs are often extremely subtle.
QOLs are also sneaky as hell and lull growth teams into a false sense of comfort. It’s easy to talk to a customer, ask them what they’d like improved, and then to go and build it.
It’s much harder to do the work of understanding the job they want to accomplish, what progress they’re actually trying to make, and move more cautiously into the solution space.
This is why QOLs can be dangerous:
If you have too many QOLs, you may not be building enough present value for customers to stick around long-term
If you have too few QOLs, you may be building an app that feels too hard to use to the average customer
QOLs also give us some hints, though, that there’s something missing in our product management process. If 90% of your product roadmap or backlog contains mainly QOLs, this tells me a few things:
There wasn’t enough UX research done for the feature the QOL is related to
The requirements list was incomplete for the feature. For example, if customers keep asking for tiny changes to a feature that’s been launched, it means we didn’t understand the full scope of that feature to begin with. When we built it, we likely made tradeoffs that we weren’t aware of in terms of the user’s expectations and how the feature would be built by engineers.
Didn’t get enough feedback from customers and active trialists — both verbal and UX feedback on actual comps before building the feature. Getting feedback on wireframes and comps can save a lot of pain and heartache before engineering ever makes a single change to the code. Good UX research will suss out any experience gaps here.
Don’t have the best design system for adding new features. Sometimes it comes down to the UI, plain and simple. If we don’t have a clear design system, it can impact the user experience in ways that would shock us if we saw how customers were really using the product.
We don’t have a clear understanding of where to contribute value to the customer through product
Taking it at face value when the customer makes a request for what feels like a feature but is actually a QOL in disguise. For example, a customer asking for a tweak to a feature may actually have a larger job they’re trying to accomplish that should be a completely separate experience. Plus, customers are notoriously bad at being product managers.
Don’t know what other “jobs” customers want to complete using the product
We likely haven’t been data-driven enough in terms of the volume of customers who have the same need
Teams great at product discovery and management leverage qualitative and quantitative insights to determine what to build next. This means surveys to help prioritize the roadmap based on the ICP and interviews that are then quantitatively analyzed.
For example, imagine being able to say that 20% of survey respondents do actually want a particular feature built and 80% of the respondents fit ICP #1.
The goal here is to strive for a balance that makes the most sense. It doesn’t have to be perfectly equal, but being aware of what balance seems to generate sustainable growth is what we’re after.
I wish I could say there was a magical number here (should we strive for 30% QOLs, 60% value generators and the rest bug fixes?), but I don’t have any data that supports this quite yet. I also think it highly depends on the product, the team, and the stage of growth.
What do I do if I’ve got a backlog or roadmap full of QOLs?
Yep! It’s time to swerve and do some deeper strategic thinking and planning.
Warning: you may need to make some tradeoffs and/or have a few hard conversations.
Here’s a few questions to ask yourself to go from QOL-thinking to arriving at some value generators:
What assumptions am I making about the QOLs my team have been tasked to build?
What’s the real value behind the QOL to the customers asking for it?
What are they actually trying to accomplish instead?
How many other customers are asking for the same QOL?
What are some other ways the customer’s problem can be solved?
What’s the primary job that customers want to achieve with my product?
What other “jobs” do my customers have?
Are there specific jobs that specific segments of customers have?
How well do I understand those jobs?
Once those jobs are completed, then what other jobs emerge?
What product opportunities present themselves?
The product conversation is a holistic one, so don’t forget to include other growth leaders in the process and to work together to collect the insights you need.
Here’s a few resources I highly recommend checking out if this type of thinking interests you:
Continuous Discovery Habits by Teresa Torres
Escaping the Build Trap by Melissa Perri
Demand-Side Sales by Bob Moesta
The Mom Test by Rob Fitzpatrick
Bottomline: QOLs don’t keep customers; VGs do
And the hardest part of the work will be figuring out what’s a QOL in disguise and what’s a true value generator, what balance you need to keep customers happy and attract new ones, and resourcing the value generators.
I promise, though, that you probably won’t look at your backlog or roadmap the same ever again!
Happy growing! ✨