When the Quality Manager comes to us and says: in the scope of the QMS it is necessary to define the key processes of the Organization, and as such you need to explain me process x, from the first to the last activity that you do, it is very likely that one of the first thoughts is:

· They want to start controlling my work?

· Do I no longer have the autonomy to do things as I want?

Now let’s imagine that during a lunch conversation, a co-worker reports that he wakes up every day at 7 in the morning, it takes only 10 minutes on the way from home to work, and yet every day he is late. The normal question would be: what do you do to take so long? And, after knowing his routine, we would try to see if it would be possible to change something, presenting our suggestion for improvement.

If we reflect on both situations presented, are they really so different? In the second situation, we started by knowing all the activities that are carried out from the moment he wakes up until he gets to work, we try to understand if, according to our understanding, it makes sense for the routine to be carried out in this way or if some changes could be implemented, and do some suggestions to help to improve.

Just as processes are part of our day-to-day routines, although mostly unconsciously, they should also be part of our work routines, but in a conscious and structured way.

The great asset of a QMS is not obtaining a certification, but the added value that its implementation brings to the organization. Stressing on a logic of approach by processes forces us to reflect on what we do, how we do it, why we do it, and how we can improve. At the same time, it helps us to understand the interactions between the various processes/areas/functions, contributing to a better alignment with the strategy and objectives of the organization.

And, regarding the initial thoughts, the answer is NO. The goal is not to control or withdraw autonomy, quite the opposite. Involving people in defining processes, monitoring and reviewing them is crucial for the QMS to fulfil its macro objective: to improve the quality of the services we provide and thus increase the satisfaction of our Customers.

Raquel Mendes.

Quality Management System: Real life problems was originally published in Making a Point on Medium, where people are continuing the conversation by highlighting and responding to this story.

All of us have fears. Moreover, each of us faces his/her owns or runs away from them as he/she knows or can.

We are living in times when almost everything quickly changes. So there is frequently a tension between our inner models and the outside world. For this reason, it is required and natural to try to find approaches that bring the extremes in harmony, in particular through:

1. Rejection of changes and the outside world;

2. Adoption of changes that alter our inner models.

When we see/feel that harmony (between the extremes), has been achieved through our actions we get enjoyment. It is instinctive and it is therefore understandable that we repeat the approach that leads us to that condition (of enjoyment); nevertheless, it does not always mean improvement for us.

Among other Eras, we are also living in the dubbed:

1. Era of the Information and Communication Technologies;

2. Era of the “Universally Synchronous Superficiality”.

At every tangible or digital corner, we encountered advertisements and buzz, to which we pay some attention, that more or less awake the bumpkin that is in all of us, on “Awesome Start-ups”, “IT Congresses/Summits with Celestial C.x.Os” and “Expert Speakers”, “Incubators”, “Venture Capitalists”, “Advanced Management Programs”, and others.

It does not cause us fear or discomfort to absorb more and more Tera of information. It even suits us for nurturing our digital social networks or for gaining a share in the small talks with our fellows.

It is much more risky, uncomfortable, and arduous to silently reflect and confront all the absorbed information with the contexts in which we are daily involved, to take on new challenges and responsibilities by having recourse to the wisdom that we have to overcome fears and to generate any RELEVANT collective transformation for the organisations.

Relevant should be understood as what transforms the world into a better place, where we become persons of finer character, more creative, helping more our family members, friends, and work colleagues. Consequently, we are happier. Relevant should also be understood as putting the Technology at the service of the Organisations (also at the service of Humankind) and hindering the contrary.

Be relevant, to live relevantly, and create relevance within the organisations is not at all easy. It is difficult to make them organically (and quickly) evolve (considering the consumption wishes). It is difficult to achieve high levels of performance. It is easier to speculate, sell, and buy. It is easier to stage and create perceptions of high performance. It is easier to talk about something and do another one.

We talk about the digital transformation of the companies, but we continue to work in the same way for 20 years. When we are on the move, we now share tons of Emails, Spread Sheets, and Presentations via the Smartwatches, Smartphones, and “Other Smarts”! We use sophisticated great sentences, but the content is the same.

We attend seminars, we leave them more or less excited, we go back to our workplaces, we create illusions along with those who work with us, and then we continue to do everything in the same way.

We either fear or we do not have the wisdom we need widely valued and developed to transform what we read or hear in the world. The casino and gambling economy that is applied to other contexts, sooner or later, ends up strengthening the false idea that we are transforming ourselves by digitizing the various processes

It is difficult to enjoy, be happy, and relevant. It is difficult to be relevant, happy, and enjoy.

The collective progress of the organisations is strongly conditioned by the illusory comfort of the individual progress given by the installation of new Apps and the acquisition of gadgets, which are the very latest.

In most companies, the following sentences continue to prevail: “my Excel files where I spent hours and hours to create formulas and assign colours and frames to tables and cells”, “my PowerPoints”, “my macros”, and my scripts”… I play in my own way as they were my Lego pieces of my childhood, but I share them with my colleagues via a “smart device” and I expect to have a like.

Each one talks about, for, and to oneself. I think that the digital transformation that has been occurring within the organisations is of limited relevance.

I am afraid of the Human Robotization and Digital Sameness.

Edson Leite.

The Fear, the Human Robotization and the Digital Sameness within the Organisations was originally published in Making a Point on Medium, where people are continuing the conversation by highlighting and responding to this story.

The first programming language I learned was C++, right before my first year of high school. I bought the book “C++: The Complete Reference” and with some dedication, I created a simple calculator as a console application (no fancy interface, just text). It was fun, but the keyword here is dedication. I wouldn’t have read that imposing book if I wasn’t completely interested in the subject.

So how can newcomers, young or old, approach a hard subject that is seen as a tool to achieve their main objective, like creating a game or moving a robot? Even for mature software developers, isn’t there more efficient ways to build software, besides the plethora of text-based programming languages?

What about visual programming languages? Could they be used to reduce the learning curve for newcomers or help software developers create mind maps of complex software architectures?

Let’s consider the younger folks first. They usually spend less time programming than a software engineer student, so the programming concepts, like statements, blocks, loops and conditions, should be made easier to learn and remember. By using a visual programming languages, shapes and colors can be used to help remembering those concepts. One downside is that we can’t use too much colors and shapes, otherwise it would become too complex to remember.

Another advantage of visual programming languages is that they translate easily to a touch screen, which seems more interesting for kids than the usual keyboard and mouse. By making programming seem more playful, remembering programming concepts becomes easier.

What about professional software engineers? Well, one advanced area that allows visual programming to shine is game development. During my master’s degree program, which included game development, I had the opportunity to build some small games. Back then, we either had to build them from scratch with the help of software libraries (ex: Ogre3D, Bullet Physics), or use an indie game engine editor called Unity3D. Using the game engine editor was a nice upgrade, but we still needed to write a lot of code. Fortunately, most game engine editors nowadays use visual programming languages for game mechanics and visual effects.

Visual effects are usually represented by text-based algorithms called shaders, which are interpreted by the graphics card. Eventually, the algorithms’ representation went from being text-based to something more visual, a block with inputs and outputs. For example, blending two images is represented by a block that receives three inputs, the two images and the blending strength value, and outputs the blended image. By joining several of this visual blocks, you can create complex visual effects.

The same approach is used for game mechanics, which started as text-based scripts and then ended as visual blocks. The main difference is that they usually represent state machines, with loops and conditions, while visual effects are usually a simple pipeline.

What if we wanted to develop something more generic, does visual programming languages allow that? Well, that’s what the people at Flowhub are doing. Their first tool was a flow-based programming language named NoFlo, which allows software engineers to create applications with visual blocks and connections between them. The blocks are reusable, independent components, which accept a certain amount of inputs and will send another amount of outputs. By joining several of those components, you will create a graph that can represent a complex application. You can even create a component that represents an aggregation of smaller components, making it easier to understand a more complex architecture.

One great example Flowhub gave us is a Jekyll’s clone, a static website generator using the NoFlo language. The original Jekyll project contains thousands of lines of code, which this clone was able to replicate using just a dozens of components, most of them reused from NoFlo’s software libraries, and only 4 had to be written from scratch in Javascript. It is true that every new component needs to be written in a text-based programming language, but after it is done and with proper unit tests, the component is easier to maintain, because NoFlo obliges the engineer to make it independent, contained, making the behaviour of that component expectable.

Visual programming languages have a lot of advantages if used for high level components. For newcomers to the programming world, they help achieve an objective quicker, by simplifying programming concepts. For veterans, they simplify our mind maps of complex architectures, by only showing us black boxes and connections between them. Even someone new to a project can easily understand the consequences of modifying a small component.

Text-based languages will always be needed for low level components, but visual programming languages definitely have a place when creating high level components.

Visual programming languages was originally published in Making a Point on Medium, where people are continuing the conversation by highlighting and responding to this story.

Having finished the 4th year of college and a mandate as a member of the Board of BEST Lisbon, I decided it was the right time to get some professional experience in a challenging project. This was the moment when Multivision stepped in.

The company had a project for a Summer Internship that envisioned the development of a Drive Test Tool integrated with Metric, a SaaS for Mobile Telecommunications Network Planning, Optimization (NPO) and Management. The plan was to develop an application for Android devices equipped with a mobile chipset, that could retrieve a set of measurements from a mobile network service, continuously while the mobile device was in one of the available service modes (voice, packet or idle). The objective of the application was to help technicians or engineers to execute field validation tasks. For instance, after a hardware replacement or to have a glimpse of the network coverage at a certain location.

Android APIs do not provide most of the information of Layer 3 and below, according to the OSI Model. Since this constrains the set of measurements, for a deeper scanning of the Network, one should look for devices whose focus is solely measuring and testing the mobile networks, such as Rohde & Schwarz’s R&S®TSME Network Scanner or ASCOM’s TEMS.

After some investigation, one can find multiple apps that can achieve the same results that we were looking for, but with an extensive feature set that isn’t required to integrate with Metric. Take as an example GNET from Gyokov Solutions or OpenSignal. These apps provide mapping and graphs integrated with the measurements taken by the chipset of the mobile device, but these are not necessary for the proposed objective. Also, the output of the existing applications has not the required information or a finely-tuned format that Metric could interpret.

As this was a challenging project and an opportunity to work in Software Development as well as to deepen the concepts of Telco that I have learned in my Masters, I accepted Multivision’s offer.

After the initial planning with Nuno Valente, we established as the objective of the first version of the app to have three distinct core functions for executing Drive Tests. All of them should register a set of network indicators and the respective location but each with a different purpose.

The Roaming DT function should execute tests in an Idle state of the mobile device, while the user moves across the network. Voice DT function should perform the same test during a dedicated service — voice call — registering Call Events, to check where the calls had started, ended, where the service provider switched technology or in the event of a cell handover. This type of test validates the network circuit-switching strategy. The last functionality, Data DT, creates packet throughput using multiple FTP connections for download or upload data in a mutually exclusive fashion. It allows the user to measure the network service throughput validating the packet-switching strategy.

At the end of the Summer Internship, I have managed to achieve the proposed objectives, delivering the first version of the app.

For each Drive Test functionality, one or more files are produced with the measurements and events from the user alongside with the timestamp and the respective location (latitude and longitude) where the measurement was collected. I have also developed a background service that sends the files to an FTP Server from time to time. Metric can consume the files from multiple interfaces and its already prepared to connect with FTP servers and process information that it can understand.

As a use case, let us look at the results of a set of drive tests performed with the application. The mobile device used was a Nexus 5X with a SIM card of the operator NOS. The use case takes place on the path that Nuno Valente takes every day to get to Multivision’s office. Noticing a constant drop of Technology from 4G to 3G or a much lower mobile data throughput between the train stations of Agualva-Cacém and Rio de Mouro, we started taking Drive Tests on the railway. These were taken inside the train from Algueirão/Mem-Martins to Sete Rios and vice-versa for around 30 days. Let us analyse the data using the Map feature from Metric.

The following picture shows all of the measurements of the signal strength from the 4G service between the 15th of August of 2017 and the 15th of September of 2017. One can see that the signal strength retrieved by the mobile device in this region is on average very low, i.e., lower than -115 dBm.

On the other hand, on the following picture, the measurements were taken on a single day, the 12th of September of 2017. At the left, the measurements are from a 4G service, while at the right, one can see measurements from a 3G service. From the analysis of the picture, we can conclude that there was an Inter-Radio Access Technology (IRAT) Cell Reselection from 4G to 3G and the subsequent IRAT Cell Reselection from 3G to 4G. Also, one can see the events that mark the transitions in both images.

The two pictures confirm the two cases that Nuno Valente and I suspected to be happening in that region.

Due to learning Android development as I was developing the tool and with a time-frame of two months, there are certain objectives that I had for the future of this app, that I could not conclude. One of them is to include a feature to allow the user to schedule different Drive Tests in sequence and, within a loop. With this feature, one could allow different sets of tests to run without user interaction.

As the app is now a beta-version and further development is secured by Multivision, this feature adds the cherry on top and fulfils the application’s potential.

As a last note, I would like to thank Multivision for giving me this opportunity of self-development and to Nuno Valente, in particular, for being a very helpful mentor and for teaching many concepts of Software Engineering that I was lacking, due to my electrical and computer engineering background. I am sure that the acquired knowledge will show its usefulness shortly as I endeavour in my Master thesis.

Internship at MULTIVISION — The Beginning of a Drive Test Tool was originally published in Making a Point on Medium, where people are continuing the conversation by highlighting and responding to this story.

“I have a vested interest in the future, because I plan on living there.” — Neil Gershenfeld (1999), When Things Start to Think.

I would consider myself an addicted to improvement with growing curiosity for any tech that can provide a better life. Today’s IoT offers a world of opportunities making life more convenient. As opposite to what most of the people would think, IoT is already a reality even if there is a lot of room for progress.

Nevertheless, there are still major breakthroughs to be made. Today’s infrastructures are still expensive to develop, operate and manage. Reason why operators are aggressively addressing these challenges by introducing lower cost solutions. That is the case of Cat-M devices being built for IoT applications.

Lack of trust and privacy issues are as well major drawbacks. Maybe not for younger people from Gen Z to whom technology is something essential as the air they breathe, but for majority of folks they might feel like an invasion of privacy. We need to draw a line and I think each individual person should be able to make that call, if they want IoT to be part of their world and decide how much connected they want to live. We, humans, should still be in control.

My major concern is Security. The astronomic volume of IoT devices constantly connected & communicating represent to me its highest vulnerability. It requires careful security and privacy considerations. Not such a long time ago, a ransomware attack named “WannaCry” affected computers in 150 countries causing several services to run on an emergency-only basis during the attack. Experts pointed out how dramatically this attack highlighted the vulnerabilities of the IoT and I agree. In today’s world, wars are not fought in the battlefields anymore.

What do I expect for the future of IoT? I hope a significant growth of IoT with deep consciousness for security issues. IoT can be revolutionary but it is not flawless, it will depend on human ingenuity and circumspection to develop risk-mitigation strategies.

Andreia Mateus.

IoT: Dream or Nightmare? was originally published in Making a Point on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nowadays in any country one can see a lot of data traffic being used and transferred and with this demand comes also the most common comment “Stop it, i don’t have signal here , let’s move to another place”.

Of course the average cellphone user will simply look to number of bars on the top bar to see it.

If one is curious on what is the current Signal Strength, and like most of the users doesn’t have a paid drive test logging tool on the cell phone, there are several free tools that can be used allowing for one to easily identify the signal RF conditions.

Of course that passing the common user curiosity an RF engineer can also use this free tools to have an rough estimation of network RF conditions it will be really helpful even without L3 messaging.

If any problem is detected then one can easily use dedicated logging tools and validate deeply the issues.

Multivision will soonly develop an integrated app to quickly log and upload automatically to the framework and like this visually analyze network data.

If you wish to learn more about this tool(s) feel free to leave your comment below.

Ricardo Maldonado Costa

Network Coverage “Analysis” was originally published in Making a Point on Medium, where people are continuing the conversation by highlighting and responding to this story.

In a time where I most listen that “recruiters are annoying because they just want to sell”. I would like to focus on the other side, when making a sell change people’s life, For Better. For Ever!

I will use a short cut to go straight to the point, but the truth is that despite the fact that I feel good around “sales”, I always thought that selling is something I must do to hit my targets, keep my job, and get my money.

But…it all changed back in the day I decide to face my fear of dogs and adopt one — Pancho.

I could spend days talking about how he changed my life, but I will focus on the woman (Julia) that brought Pancho to me in the first day I stepped into “Sociedad Protectora de Animales y Plantas de Málaga”, an animal shelter.

When I called by the first time, She asked me a few questions and I told her: I’m afraid of dogs, but I would like to have one. I live in a small apartment but I have some time to walk him and play at least 2 times a day.

With that, she made an appointment and told me: “Are you ready for adoption? Think of it like it’s a baby, responsibility is all on you. “ It scared me, but also prepared me.

So I went there, my friends Anabela and Fran went with me to support my big decision, and Julia came to me with a medium black dog, full of scars around the body, weak legs and more afraid then me. I looked at him, and at first sight, it wasn’t what I had in mind — Who thinks that for a first dog? Everybody thinks about a cute puppy. Well, I thought the same, but she brought me him.

I search for about 30 minutes for other dogs. She walked with me, but she was certain that he will be my dog (my friends too). I trusted all them, and the next couple of days I went back to adopt him, after prepare everything (and spent a salary) to make sure he will feel fine at home.

Result for HER: She “made a sale” because she wanted me to get that dog. She knew he would “fit my needs” and with that, she reduce the number of dogs in the centre and gave a new home and new friend to Pancho.

Result for ME: I GOT THE BEST FRIEND OF MY LIFE!

So, if you allow me to choose a MORAL for this story, it must be:

If you have pure reasons on what you are selling, and aim to help both sides — Company and Client — YOU ARE A GREAT SALES PERSON! And a simple Sale can change your client LIFE.

Do you have a better moral? Please share it with me :)

Rui Gomes.

Are you not a Sales Person? was originally published in Making a Point on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the Greek Mythology, Procrustes posed as a gentle caretaker, offered accommodation to any passing traveller. After an invitation for a satisfying meal, he provided a good night’s rest in his exceptional bed. Procrustes described it as having the unique property that its length exactly matched whomsoever lay down upon it. What Procrustes didn’t volunteer was the method by which this “one-size-fits-all” was achieved, namely as soon as the guest lay down Procrustes went to work upon him, stretching him on the rack if he was too short for the bed and chopping off his legs if he was too long. (Adapted from Procrustes — MythWeb)

In a Product Management position, one can imagine the many procrustean beds that are built for the private residents, i.e., engineering, quality assurance, operations, sales, etc. or for the passing traveller such as prospect trials, consultants, brokers and, existing clients. Let us refer to them as internal if they are to be fitted for in-house stakeholders, or external if they “accommodate” visitors that aren’t part of the company inner circle.
In this series, I’m going to focus on the external ones and mostly derived from my experience in B2B environments. The ones that may hinder revenue goals directly and create friction in the overall evolution of the product.

The prospect client’s trial is a moment of utmost importance and, especially when a product or service has a broad and/or complex feature base. It doesn’t stand for itself. It needs an attentive caretaker that invites the freshly arrived visitor to have the best possible experience and, that can steer him on how to take advantage of the available amenities. Eager as we are, to make an excellent first impression and, to close the deal in the shortest amount of time ( because trials always have a cost ) we invite the user to feel at ease and at the same time we push him to experiment our star features. With the least amount of effort, we show him how to achieve our product promised outcomes. While the caretaker and the user roam around, showcasing the product end to end and iterating over the feature spectrum, we fall into the mistake of force fitting the client to the feature, whether the use case applies or not.

As it should be expected of a product team, we want and need to be creative. We seek inspiration in every problem that we face but sometimes, repeating empty metaphors such as “thinking outside the box”. And regrettably, we try to find solutions on the spot, for the prospect client workflows, habits and, tools, that are allegedly defective, unorganised, inexistent, <insert another problem here>. On the other hand, a small void or even a domain that we’ve managed to exclude from our road-map can bring havoc when a client merely hints the fact of nonexistent work in that regard. Instead, we should take our notes and seclude our selfs, for a moment, where we can summon our creativity and muster our planning abilities towards a well-designed solution. On the spot, thinking and instant client fitting is the moments where we start amputating the prospect expectations and with the best of intentions in mind but ignoring the prospect client true needs and creating product fragilities. Doing this we fall into an uberous mind trap. Let’s delve into one type of this situations. The dreadful and pernicious Workaround.

The Workaround

It is a well-known term in the Engineering class and many times used ad nauseam. Whether it is the best option at a time of need, laziness, schedule compression, damage control or just a temporary patch. It is a well-known term in the engineering class and many times used ad nauseam. Whether it is the best option at a time of need, laziness, schedule compression, damage control or just a temporary patch. A seasoned Software Engineer evidently used it on several occasions and sometimes wakes a night, shivering with the memories of some that still work on a machine somewhere.

In Product Development, the Workaround has a very similar set of characteristics. It is some process or small addition that will leverage an alternative pathway of one or more features to attain, what we believe to be a quick win. Sometimes with the objective of solving an unexpected user need or capricious desire. Sometimes it’s a cover up of an edge case that the product team did not address correctly or just ignored because they’ve fallen into a pseudo-statistical fallacy.

The Workaround trigger usually occurs in a commercial or technical tour of the product. May it be a sincere question that has a genuine need behind or a more technical person that wants to show off his wits. Occasionally can be a snarky remark that may compare his current work environment or another tool that he tried recently with our own, and something is definitely missing in his eyes.
The fear and anxiety of not being able to entertain the user, makes us create a parallel thread with a request that the product team scramble the issue searching a way to meet our client expectations. It should not be a problem if at that moment a backlog entry is dutifully filled with a good picture of the issue, that popped up from the conversation, and a reasonable amount of time is taken to consider the proposition. It is a problem when we bypass our product development processes, and the proposed solution involves small feature adjustments that didn’t pass a thorough impact analysis. It is a problem when even avoiding the most minor alteration, it is the result of a collage of one or more features, or maybe, just making use of a feature quirk and painting it as a fully fledged product of human ingenuity. Unfortunately, the Workaround, most of the times results in a non-fluid and/or semi-automatic action plan, requiring the user to withstand some pain or to exert himself to do the same thing that he did or have seen in action before. At the exit of the Workaround, we claim victory if a significant amount of work that the user already does in a streamlined fashion or seen it being executed in the same way can be achieved in our product. We think that we’ve kept the user going, but we don’t see that the user is limping on its way. It may take just a small extra effort to vindicate the capabilities of our product but at the cost of an amputation.

For the attentive and sharp reader, another Procrustean Bed can be found A Posteriori. At the exit of the Workaround and this one with the bed and victim roles switched. This one can kill our product vision and eventually our product. Remember that for the Workaround to be put in place, some small change in our product had to be made. Even when we’ve just managed to pipeline a feature output to another as input, and with some caretaker good will. We’ve adjusted our product to fit that particular prospect or even client need at that precise moment in time without measuring the consequences of those actions. Expectations were created, and new plumbing was added disregarding our architecture, use cases and requirements. To do this, we’ve amputated, rearranged, bypassed and plug it again changing our product morphology. Again, with the best of intentions, to show how exceptional is our team and product. If we exit the Workaround multiple times, it is granted that our product will die in the bed that was made with our client’s hands.

The Workaround is avoidable, and it should be considered an anti-pattern in product development and management. It is damaging for our client prospects, and it is deadly for our product. Take the necessary precautions when you meet with the prospect of a Workaround and make time for fixing it before the product vitality seeps out from all of those newly created ins and outs.

Do you know more Procrustean Beds in Product Development and Management? Leave your comments and let’s have a chat.

Procrustean Beds of Product Management was originally published in Making a Point on Medium, where people are continuing the conversation by highlighting and responding to this story.

Data is a collection of information stored digitally that can be based in multiple sources, such as numbers, text, images, sound, video, etc. The awareness of “Data” relevance started happening significantly across multiple industries and businesses in the past recent years and it is now often associated with efficiency, growth and change.

Data has never been so much important as nowadays, since the number of digital devices that can both store it and generate it, are more and more. This “data emergence” has already created new infrastructures, new businesses, new politics, and new opportunities.

IDC (International Data Corporation) predicts that in 2025, the amount of data available, will be 163 zettabytes, roughly 10 times more than what exists today.

Obviously raw data by itself is often meaningless, but when properly analyzed into context and perceived, it can pinpoint areas of improvement or even new areas to be explored.

To picture one’s initial daily routine such as:

- Waking up at ideal time and being informed of what’s best meal for breakfast considering the person’s vital signs, followed by the most appropriate clothes to wear taking into account: what’s in the wardrobe, the personal agenda and weather forecast;

- Throughout the day, the same cognitive domotic system will automatically adjust temperature, light and locks of the house; and

- Going to work by a self-driven vehicle from Uber, automatically requested at wake-up time. Travel time is short since traffic lights can predict traffic jams and in real time dynamically adjust its behavior to minimize the overall traffic.

Might not be that far from common reality, since such solutions already exist.

Thus, data will not only play a crucial role in business, but also in an individual’s daily life.

The more devices exist, the more data is being created and the trend is already to interconnected the countless solution devices that exist — IoT (Internet of Things), and from there, by combining the diverse data, other information can be pulled-out. With the current typical gadgets, such as mobile phones and digital watches, plus the amount of different kind of sensors applied everywhere, e.g, a car communicating temperature, speed, fuel level, etc, a simple 5min ride will generate a huge trail of data. Later, by combining this one individual’s 5min ride data, with another few thousands of people, can lead to pattern detection, that can easily show which things or services are more appealing to a specific group of people.

A factual situation where a company took profit of its own data is for instance the TV Series “House of Cards”. By looking into its own customer’s preference indicators, Netflix knew of the popularity of both the actor Kevin Spacey and the director David Fincher and that the British TV Series with the same name had major acceptance. By popularity, it’s meant that the products they feature, not only achieve a high number of costumers, but also most of the public would watch the movie till the end. Combining these 3 ingredients, yielded a not so much surprisingly, hugely succeeded TV Series.

This new paradigm causes new types of jobs, associated to the data needs and potential — storage, tagging, analysis, IA — machine learning and security.

It can be said that Data is now, more than ever, a very precious resource.

César Luís.

The Importance of Data was originally published in Making a Point on Medium, where people are continuing the conversation by highlighting and responding to this story.