It is probably an example of ‘professional deformation’ but every time I interact with a website, a mobile app or a service I cannot help but to put them under the microscope.
I applaud when I have had a good experience and I even wish I could commend the people that work in the business or customer experience areas on the good idea they had or the usefulness of what they did.
Likewise, I would love to be able to talk to them when I see that they could improve small things to bring about significant changes without having to make big investments (as they are surely doing).
Since it is impossible to reach all those people individually, I would like, by means of this post, to give them some examples – should some of them end up reading them – and thus be able to help them.
If I were to tell you that the IoT is experiencing fast growth and that it will keep doing so for the next few years, you would answer that I am not telling you anything new. In fact, you would be right. I even said so myself in this post: we already talked about it.
Thus, to take things one step further, in this post I will focus on one of the main reasons why the growth of the Internet of Things is unstoppable: the importance of connected devices, which are continually gathering and transmitting data around the clock and have become natural drivers of the IoT.
Google already has 8 products that have 1+ billion users. Have you ever asked yourselves how is Google able to manage all those services? How do its teams work to keep everything in an optimal state? How does it deploy new functionalities?
When Google launched its browser in the early aughts, it already was aware that one of the biggest problems it had to manage its services was the tussle between the development people and the operations people.
The dev teams wrote code and sent it to the ops teams for deployment. The latter tried to make it work; if they failed, they sent it back to the former. As a general rule, operators did not know much about coding and developers did not know much about operating practices.
Developers were worried about finishing code and deploying new functionalities, whereas operators paid attention to reliability and keeping things running smoothly. In short, they had different objectives: functionality and stability respectively.
DevOps is one of the terms that more debate and controversy generate in the IT sector. Most of the confusion stems from confusing what’s DevOps with the requirements that
are needed to implement it or with the benefits that will be gained once it is implemented.
There are a lot of questions about this concept. Is DevOps a culture? Is it a profession? Is it necessary to digitally transform a company? Can it help us in developing a digital product?
In view of this hotchpotch of ideas and confusion of concepts, we will try clarifying what DevOps is and, particularly, what it is not with the help of this infographic.
I am increasingly more inclined to think that most companies do not oversee the progress of their digital business. And I am not just talking about small companies but also big ones.
One of the problems I have run into when doing consultancy work on digital analytics is that people think that it is a subject matter pertaining to technicians or marketing people only.
The digital activity, from marketing to the end results of a conversion, is too important an element NOT to be monitored and controlled.
If you have made an investment, wouldn’t you check to see whether it is making money or not? I am assuming the answer is yes.
We must do the same with our digital projects – for two obvious reasons: because they are an integral part of our business and because, irrespective of the size of the investment, their effectiveness has to be checked to see whether it is worth it to keep putting money into them or whether it would be better to shift the budget to other channels.
Before we start, stop for a second and look around you. I am convinced that if you are reading this blog, you are using a smartphone or tablet, and if you are sitting in front of a computer, it will most likely be a laptop.
You are probably wearing a smartwatch or a fitness tracker around your wrist, and I would venture that if you are a gamer you own or are thinking about buying a Nintendo Switch to take it on vacation with you.
Mobility is no longer a trend; it has become a lifestyle. It has redefined the way we work, communicate, buy and, even, have fun.
Mobility has reshaped the way we live and has become a catalyst for the digital business and the advent of new technologies. If you take a look at current emerging technologies and most business trends, you will see that what they all have in common is mobility.
Smartphones – the crown jewel of mobility – have evolved so much that right now the less important thing is being able to make calls from anywhere.
From the first iPhone in 2007 to the latest iPhone X, these devices have been stocked full of sensors (GPS, NFC, fingerprint reader…) and their processing capacity has grown so much that it almost matches that of a PC (e.g. the iPhone 8’s processor has a performance similar to that of an Intel Core i5-7600K chip, the processor mounted on many all-purpose laptops on the market).
Owing to this, to digitalization and to the evolution of mobile networks, complex tasks can already be done from any location and in any situation.
And even if the first thing that comes to your mind when you talk about mobility is your smartphone, we are not only referring to mobiles. Wearables, beacons, connected vehicles… all these technologies are part of this ecosystem.
Group dynamics sessions are an essential tool in my daily professional life. I use them to design products and services, to generate new ideas, to solve problems… The more I work with them (both as a moderator and as a participant), the higher my opinion of them. Thus, I recommend using them.
The results obtained from a session are mind-boggling. The result of teamwork is much more creative and productive, and the time saved by holding a group dynamics session instead of doing individual work is significant.
But not only that: holding this type of sessions helps to motivate the people who take part in them by taking them outside their routine and giving them a place where their contributions will be heard. Furthermore, they will spend more time with their co-workers.
It is a pleasure to read John Maeda’s Design in Tech report, where he claims that for every developer there are now more designers, that we are more and better appreciated than ever and that we have a greater presence and more responsibility at the corporate and business levels.
Working with user experience design teams can add great value to any digital product or service if properly managed.
Even so, right in the midst of this customer centric era, the amount of decisions that are made against the interests of customers and users is astounding. UX designers will make sure your customers can purchase things easily, return to buy other items, be satisfied throughout the process and have a good opinion of your brand.
If you want to know how to improve collaboration with this kind of professionals, here are some tips for unlocking their full potential.
If you have ever worked with Scrum, it is highly likely that you have run into problems more than once trying to define a Sprint Goal.
You may have wondered if the highest element in the Product Backlog is theoretically the most valuable. Should it be the basis for defining the Sprint Goal? Or what do we do when we have several items at the top but they are uncorrelated? Do we craft a Sprint Goal with ‘A’, ‘B’ and ‘C’? Can there be more than one Goal per Sprint?
In the previous post The power of the Goal Sprint, we saw the importance of working with Sprint Goals in Scrum. In this post we will see when they should be created and the main techniques we can use to define them, and we will explain some types of Sprint Goals.
“Perhaps we no longer have to think about servers”. This is what Werner Vogels, AWS’ CTO, said on 7 July 2016 to sum up the value of Serverless computing during his speech at the London Summit.
He saw it as the next big revolution after containers and mentioned that some companies were already starting to remove the big parts from their apps and replacing their servers, virtual machines and containers just with a code.