API, GUI, Front-End, Back-End What Does It All Mean?
What’s the difference, and why does it matter to you?
API, GUI, front-end, back-end what does it all mean?
Let’s first decode these terms, and what it means to you as a product manager (or wannabe product manager). Then let’s discuss what the measurements are of a successful deployment, and what may or may not “float your boat”.
API and Back-End
From Wikipedia:
“An application programming interface is a computing interface which defines interactions between multiple software intermediaries. It defines the kinds of calls or requests that can be made, how to make them, the data formats that should be used, the conventions to follow.”
But what does this mean!?
Simply put, an API is a method two pieces of software (software intermediaries) use to interact. It’s their “language”. When you need your piece of software to work with another piece of software, say of another company, you get their API spec.
There are product managers who work to improve the organisation’s API — both in terms of content and performance. In other words, a product manager who works with an API will look to enhance the number of attributes or capabilities of the API. They will then look to improve the performance.
Response time is typically a primary measure of performance. In this respect, another piece of software that calls your system expects a response in a short timeframe. There is no point in trying to check out at an online store, and the response time is 10 minutes, who would really wait longer than a second or two for this connection to be made?
A product manager who works with an API as their main product (or the main element to their product), is fanatical about improving performance. Responses should be in the milliseconds (application depending, of course).
Many optimisations need to take place to achieve this high performance. Often architecturally, or just through optimisation in the software itself.
In the past, I dealt with a different timing issue. We had credit card machines that needed to dial-up (using telephone lines), due to intermittent cell-phone and internet coverage.
The challenge we faced was that the whole process of dialling up and waiting for the transaction to complete could take a full minute (sometimes more).
We then implemented a “pre-dial”, which would start dialling the credit card company while a transaction was in progress. Pre-dialling meant that when the operator finally clicked on “pay”, it was already connected! We saved a tremendous amount of time and customer frustration with this method.
Some product managers get their kicks out of API performance and breadth. A product manager who deals mostly with this type of product focuses on the back-end. In other words, things that a customer is unlikely to see visually. They will, of course, still experience the benefits of API performance.
I, however, prefer front-end product management.
GUI and Front-End
Again, from Wikipedia
“The graphical user interface is a form of user interface that allows users to interact with electronic devices through graphical icons and audio indicator such as primary notation, instead of text-based user interfaces, typed command labels or text navigation.”
The GUI is the way we interact with the typical end-user (in most instances). Your PC, Mac iPhone or Android all have GUIs, it’s what you see on your screen and with which you can interact.
Impacting the GUI is the fun part of product management in my view. I often interact with customers to test what would be visibly appealing and most intuitive to use. At the end of each cycle, the output is something visible, whether a new menu item, a filter, or a whole new screen. This focus is called Front-End.
Of course, there is an interaction between the back-end and the front-end. There are APIs that need to be taken into account too.
It would be lovely to have a screen that presented all types of data in different manners and forms. Again, performance needs to be considered, including the capabilities of the various APIs that pull the data for use.
There is no use pulling all data when only some will do. It would also be useless to display all the data when response times would suffer too.
The work of a product manager is to balance all this and decide what is most critical to present. The method of showing this data is also vital. Do you present in a table, graph or chart?
On a standard screen, this is relatively easy to resolve, as you have more “real estate” to play with.
At the previously mentioned credit card company, we had 6 or 7 monochrome lines to decide on output, which was an almost impossible task!
We would need to spend hours agonising over each character, and it’s understandability on the screen. We would ask impartial people what they understood from the screens, and we would pivot until it was crystal clear.
What’s best for you?
In the end, when entering the product management space, it’s not always easy to choose where you start. It may take a year or two of working on front-end when you prefer back-end or vice versa.
Over time, however, once you can choose, you can focus and specialise in your specific field. The great thing about both of these though, is that neither exists in a silo. It’s impossible to work on an API without worrying about user experience, and it’s impossible to work on a GUI without understanding the underlying architecture’s and API’s capabilities.
As always, if you like what you read, you can subscribe here, and see more from me below.
