#001 Orlando thinks: The product is what your customer uses
Hi everyone, it’s me, Orlando. I’m an Apple fanboy and software engineer at arconsis. I’ve decided that every week I’m going to publish a short article highlighting a specific topic that I see as important or interesting. Sometimes it might just be certain aspects of everyday life, but other times it might be tips, hints, thoughts or appeals — but I also do not exclude non-sense.
We at arconsis believe that knowledge has to be shared. This is how you get into conversation and broaden your horizons in all aspects of life — and thus also of your work.
I really hope that I can reach a few people with this and especially — make you think.
Let’s start with “Orlando thinks”: Since the written words here are mostly a result of moments when I am lost in thought.
Today I would like to start with the term “product”. I have made the experience that this term is interpreted differently by teams in companies. This always becomes a problem exactly when this interpretation does not match what the end customer actually uses.
In the first version of this article, I first tried to narrow down the term “product” using everyday examples in the supermarket or at the bakery. I wanted to make it clear that the product is not only what the end customer ultimately buys as a good (specifically, an apple — a coffee — or whatever) — but also all the aids that accompany him along the way.
Of course, one could also include other points of view here, especially those of managing directors of a wide variety of companies from different industries. One could declare and define the term “product” exactly, quote Wikipedia, and possibly find some philosophical approaches.
But for me as an iOS software engineer, a quick look at the App Store is enough to clearly see what makes some people tick. And when users write reviews for an e-commerce app like “Great app, does what it’s supposed to” or “Terrible! The app is completely overloaded” they are obviously not only rating the goods they ended up ordering through the app — but also their personal experience with the piece of software itself.
But what does this mean now for the employees of a company developing this e-commerce application? Most of them don’t need to be told that they are also working on a product. That is not the problem.
But it is more important to make clear to them what the product is.
Whenever software applications cover many use cases, many teams and areas of a company are involved, the risk of losing sight of the actual application increases. These are always the phases in which teams like to argue about whether a certain feature belongs more to their area of responsibility and is actually “their product”, or whether it is not rather part of the other team.
You need something more specific? No problem: It makes perfect sense to approach development in a modularized way and assign it to different domains. In an e-commerce application, one team can take care of the checkout process while another implements the search function. But the teams should not make the mistake of declaring e.g. the search as a separate product. (Unless you run a search engine like Google, then you are allowed to do that ;)
That’s the time when the feeling for the customer gets lost and you think only from the company’s point of view. If the search has a bug that crashes the app, a customer is unlikely to write a review like “The search causes a bug that crashes the app” but rather something like “Stupid app, just crashes”.
It may seems a bit trivial — but not losing sight of the bigger picture is very important. And unfortunately often not very easy. You should always be aware of what people actually use, how they experience something, and what they interact with. Dear development teams — this is your product! Treat it as such!
Cheers 🍻
Orlando
