There are no products, nor projects, only services
I have a backpack. This backpack is about 20%-30% more expensive than similar ones, and on top of that, its zip goes wrong every half a year or so. I’m still not concerned about this. Why?
Because this particular backpack came with a little slip of paper, which has it written:
By showing this warranty card, we fix all of our products for FREE for many years!
So whenever its zipper derails again, I walk to the shop I’ve purchased it from, and based on our years-long partnership, I ask for their help. And they fix it. Sometimes while I’m at the shop I’ll buy another bag as well, even from the same manufacturer. It’s a really trustworthy brand, I have 3 bags from them, and only one (even if one of my favourite) has regular problems.
Every product is a service as well
This little story highlights that even if we would think that whatever made once is done, it’s not even true for physical products: across the EU you are obliged to have warranty for at least a year. In the US, the return rate for Windows Phone was a hot topic for years, as customers can return products they don’t like, but which are otherwise in good condition all through the year, not just after Christmas, like it is the custom elsewhere.
The same applies even more to IT “products”: even if you made a classic, Windows XP style desktop application like it was done around 2000, every single enterprise would try to get rid of it as fast as they can the very day after you announced end of support and product updates.
Therefore, every product designer is in fact, designing a service
There is no such thing as “project”
When you want to have children, we call it “working on a baby project” — yet this project isn’t seen as a one-night adventure, even if the specification (sorry) can be quickly made, it’s not even the 9 months of pregnancy and it isn’t birth which signifies the end of the project but rather the graduation and first workplace, when the “baby” starts their own life.
This is the same in the world of IT: a project is about having a deadline and a certain end goal, after which the project ends. Instead of this, “after” the project, a service is born, which is kept alive (and eating up resources) until there is a new “project” to relieve it, or it disappears altogether, sometimes with the organization which created it.
If we stop thinking in projects, and accept that good services never “end”, we can serve interests much better.
IT companies pretend they don’t know this, but they do
There is a hypocrisy here: on one part, every IT firm is charging upfront for creating a service, yet most of them can realistically expect that they will need to work on it continuously, often making more money (on the long run) with maintenance than with initial development alone.
Whether someone else can take over operating the service is a great question at every instance: the client usually tries to create situations where it is possible, otherwise they would get really exposed towards the operator, and sky is the limit for the maintenance fee then. On the other hand, for the short term, it’s the best solution for everyone that the service is operated by the very same company which developed it first.
Operating a service is more than IT
A lot of people think of operation like it was solely about system administration: you have to make sure to swap out faulty hard drives before there is a data loss, you need to update to the latest security patches and electricity should be provided every second, every minute.
But operating a service is also about handling complaints and requests, and reacting to them: this might bring up new development requirements, not just because the website starts to fall to its pieces in the newest browsers or because it is still not responsive a decade after smartphones became widespread, or because Flash is killed, but also because of compliance issues with new laws, or new technologies, or changing customs and usage habits making for example, supporting modern payment systems a requirement.
Operating a service also means having people on board to provide human assistance as a last resort: British public sector culture is already embracing it (probably based on the work of Lou Downe). Of course, every single digital service wants to minimize human resources, but the amount of requests is also a way to measure the effectiveness of the user experience.
It’s not enough to design for the product
The “let’s just get it through the door” approach of project management rarely works well: if a service is left alone after its launch, and no development is invested into it, it leads to user count decline in the long term at least.
Not only the Sagrada Familia, but any cathedral on the world is never ever reaching its “final form”, it’s only that tourism (and the closely related conservation policies) slow down change. Most of them still managed to install electricity, projectors and surround audio nevertheless, even if it is slower to get building permit as a world heritage site (and it’s faster to build if you don’t have a permit at all).
So when you design a new product, don’t just design the product, but rather, the whole service, how will it react to the needs of its users over time, across channels, beyond screens. You don’t need to predict the next 20 years (and since it’s even impossible, and only change is certain, we need to include funds for adoption to unknown changes into our expected budget), yet we still should be able to tell, as a service, how will it operate all day long, as long as it is possible to know.
This way we can serve real interests, as I didn’t need a bag for a single occasion, just because I only paid once for something doesn’t mean that you don’t need to care about me as a client anymore, not only in the digital, but also in the physical world as well.
