Service Design Could’ve Prevented Heroku’s Free Tier Closure
The news that Heroku is shutting down its free tier marked a sad passing. Heroku was the first Platform-as-a-Service (PaaS) to offer a quick and simple deployment method with a free tier. This started many a student or skunkworks project, and I’ve suggested them indirectly in a few posts. Indeed, Heroku’s “free tier” ethos drove a lot of my enthusiasm for tech that you can try out immediately.
Today there are plenty of alternative platforms to Heroku, although I would argue they are not so simple to use. Plus these alternatives do little to align themselves with the spirit of the tinkering user.
Usually, we see the bigger corporates buy up better-known startups in an attempt to import some of their innovative sparkle, even if there is a limited vision of the outcome. The hundreds of inactive Heroku user apps that will be culled may or may not be a loss to mankind. This is like wondering how much rainforest you can afford to lose before a species of rare aardvark is at risk. Just to make it clear, Salesforce (which now owns Heroku) has absolutely no moral commitment or responsibility to maintain free services or inactive servers if no claims were made to this effect. We all know by now what “free” means in these contexts.
But there is something behind the explanation that does need further investigation. It is the idea that the service was massively inconvenienced by “scam” users. In this case, Heroku blamed cryptocurrency miners:
“Our product, engineering, and security teams are spending an extraordinary amount of effort to manage fraud and abuse of the Heroku free product plans.”
This is an odd statement. The free plan is there to entice the type of user who might migrate to a paid plan. Historically, Heroku’s offering was unique and respected for its directness. And clearly, crypto miners are just looking for free computing to sate their habit. But this is blaming your guests for a bad party. The cynical may well conclude that this is a post-justification, but that is not what I’m focusing on in this post. I suspect there has been a confusion between the product and the service.
The Evolution of Service Design
The term service design means designing a business path that is suitable and attractive to your intended audience, while keeping out the unintended consequences. That second bit may be said sotto voce, but it is still part of the intentional business design. The humble doorstep is a barrier to many unwelcome crawling animals, while also marking out an entrance for humans.
Service designers themselves like to point out that while a car is a product, Uber is a typical service that uses the product — thus underlining the distance between the two. So perhaps we can say that any statement that sounds like “our users are plotting against us” is a problem within the service design domain.
If I remember the foment around that 2000’s period, the imperative of speed to market and making a direct offering may have been to the detriment of the softer considerations, such as user experience (UX) design and customer experience (CX) design. It is quite likely that none of those things even got considered. But today’s world is a little more complex, with wiser customers and better-armed attackers.
The first consideration, which is just standard network operation, is monitoring network traffic and applying white lists and black lists to a range of URLs. In the bad old days of silos, the NetOps/SecOps teams would probably never talk to a service designer (or be aware of each other’s existence). Today we would know to ask questions about which users are clearly communicating with crypto APIs from the outset, when and where they signed up, and see if any discernible patterns arise. This form of agile correction can be resource intensive but is just part and parcel of running a service anywhere bar the most trusted areas. A simple question on sign-up to the user about their intentions may both alert the service to the need to keep some obscure but harmless blockchain API open while forcing the less trustworthy to lie early on.
Limiting a Free Service (and Other Tactics)
Degrading a free service in a prescriptive way will not help to show off its potential. But limiting the service in a controlled way upfront is an honest way of qualifying the difference between the free and full service. For example, agreeing when your service can be offline or for how long it can be run uninterrupted. In fact, indicating that the service has such fine grain control may be seen as a boon. A genuine user will probably only need the app available during office hours, or can work around a known interruption by setting boundaries. This will be harder to accept for the unscrupulous.
Another targeting device, working from the other end of the customer life cycle, is to limit invitations. Targeting invitations to those attending relevant human events (conferences, dev community forums, etc.) is simple in concept — although after Covid, it may be deemed too awkward. And doing this with a worldwide audience is obviously not trivial for a small outfit. The extra marketing spend and reduction of simple access has to be measured against the increased lead quality. Sometimes this type of intention breeds a better audience in itself.
Gaming has advanced a long way through UI design to delight its users; and there are lessons here. How do you guide a new player into understanding how a game works? Game designers like to reward players who use innovative solutions to problems, but they also lay down bread crumbs for the less certain to follow. Testers will try to simulate odd things to see if they can exploit errors. Many early users of startup services are aware that they are the beta testers, yet may not be critical enough to spot and report exploitable situations. I suspect a lot of useful data is still lost early on because of this.
A strong habit of many startup web apps is to launch a chatbot when a user is starting a journey, and perhaps spending too long on a signup page. Now, this can be distracting, but it does cement a relationship early on. The startup wants to help genuine users. Obviously, this puts a bit of responsibility on the chatbot (either fully autonomous or a mix of AI agent with human backup) not to simply be an upselling device. It remains a great opportunity to see why something isn’t working.
The other side of the coin is to understand the value of “abuse” vs the advantages of access. Most big department stores accept what they call “shrinkage”, or shoplifting. They usually have security lookout for actionable cases in store, but no one has gone back to having products behind a desk that you have to explicitly ask for, as they did in the nineteenth century. I remember a very early talk on storyboarding the Nespresso service design. It covered an interesting case where they purposely made their corporate coffee machines use different sizes from their home offerings, because people kept stealing the office cups and pods to use at home. Later on, the product was sold as more of a luxury item for home users.
If you are honest about what your users want, you can also capture the grey areas that don’t really benefit you so much. Many phone games tease their audience, by making them watch ads if they don’t want to pay for the game. They gently hint at the benefits of paying, while accepting that (of course) our game is great and why wouldn’t you want to play it for free?
Service Designers: Check Your Assumptions
The increase in interest in observability, metrics and events would indicate that it is at least accepted practice to see where your customer use overlaps with your business goals, and hubris to somehow assume they naturally all do.
For any platform, there should be an increase in methods that a service designer can use to check their assumptions. If done properly, a service offering should be close enough to genuine user desires that abusers can be isolated early on. We all want to be at the best parties, but it falls to the host to put in the groundwork before sending out the invitations.
