This is some text inside of a div block with Cleo CTA
CTASigning up takes 2 minutes. Scan this QR code to send the app to your phone.
Fell, Tech Lead at Cleo, shares his techniques for effective problem solving.
Often when I’m solving a problem for users or my colleagues at work, I’m working out how I can lower the amount of effort required to get them the help they need. I was talking to a colleague about the prioritisation I put on various types of solution, and they suggested writing some documentation on my thought process, so here it is: my prioritisation for how to solve an issue.
It’s always desirable to move a problem down the pyramid, but I don’t think it’s always the right thing to do. It may be the case that there needs to be a human signing off on an intervention, or automation may be too costly or time consuming, or simply impossible. Each problem requires an indiviudual assessment, but the goal is always the same: Moving a problem to the bottom of the pyramid, where a human will not need to think about it until the parameters change.
For the purposes of illustration, we’re going to imagine there’s a bug in some software the team has written. For some small but not insignificant fraction of the user base, the new feature we’ve built for them does not work as intended. We’re going to look at what the different levels of problem solving would mean, from least to most desirable moving down the pyramid.
This is the worst kind of problem; something intractable goes wrong, and it’s simply not possible to recover from. The users who run into this problem will never be able to get the experience, no matter what we do. This is a bad experience for them, and bad for us too. However, if there’s something we could manually change in their data to fix things for them, then…
The user has some sort of problem the a developer could manually solve. This is time intensive and expensive, and takes away from the time that developers could be using to create new experiences for our users, or make the existing experiences better. If we’re just changing some data, maybe we could give our customer support (CS) colleagues a button to fix this…
The user has a problem, and they come into our CS channels to ask for help. This is time intensive for our colleagues in CS, and takes a lot of time for a human to make sure the right thing is being done in line with what the user wants. If what we’re doing is fixing users’ data, maybe they’d be better placed to do it…
The users has a problem, but now they can fix it themselves inside the product. This is starting to get a bit more sustainable lower down the pyramid, but asking users to make decisions and fix data on their own leads to issues, especially that this additional friction causes dropoffs in key parts of our product. If most of the time the users are doing the exact same thing, that means…
There’s an automatic, scheduled job that runs some code identifying the problem that our users are facing, and programatically fixing the data on behalf of our users, before they even know that there’s an issue. This is great, but it requires maintaining, and isn’t instantaneous. However if we put some better validations in when we’re taking the data from our users, that means…
This is the ideal state. The problem no longer exists; we have fixed the bug at its source, and our users are getting exactly the experience that we intend. Everyone is happy.
The eagle-eyed amongst you may have noticed that whilst we fixed the problem of the incorrect data completely, there’s a problem remaining: the users who try to input incorrect data are still sat on level 3 of the pyramid, being asked to fix a problem themselves by putting the right data in. This is important to acknowledge, but we’re comfortable with our solution: Not every problem can or should be brought to the bottom of the pyramid, and sometime we’ll need human intervention to fix an issue. That’s okay!
There’s other dimensions that can help us work out how much effort it’s worth investing in a problem: For example, how many users are affected, or how much time it will take to improve the experience. This isn’t a step by step approach to making all those decisions, but it is a useful thing to keep in mind when doing so.
Last year, our Heroku Postgres database was fast approaching its 3TB storage limit, the maximum size that Heroku supports at time of writing. To make sure our community of 4 million people could continue to work on their financial health with Cleo, it was essential to migrate away from Heroku as quickly and smoothly as possible.
In June, Cleo sent eight engineers to Brighton Ruby. Sachin outlines the trip.
You didn’t hear it from me, but Cleo Engineers aren’t perfect. We have bugs. We have quite a few of them. Our relentless focus at Cleo is to make it as simple and joyful as possible for our users to level up their relationship with money.
