What is a stereotype? A stereotype is a concept that puts a limit on reality. Stereotyping is represented as a negative paradigm, often present in the context of short-term decisions without a broad vision of the future. Corporations, generally those working in the IT field, have well-defined processes as a result of many years of analysis and testing of various techniques. Processes within a business are typically divided into three categories: primary, support, and management processes.
First of all I should begin with what I do: I manage a 40+ IT consulting, training and software development company, and I work as trainer and consultant for customers in Romania and abroad, dealing mostly with Cloud technology.
According to the Scrum Alliance, “Scrum is an Agile framework for completing complex projects. Scrum was originally formalized for software development projects, but it works well for any complex, innovative scope of work. The possibilities are endless. The Scrum framework is deceptively simple.
Big data seems to be on everyone’s mind nowadays. As a product person myself, I know that good product managers have always been data driven. However, what we witness today is an explosion of endless tools and methodologies that depending on how they are used can either make or break a future product. A growing number of product managers are struggling with this abundance of data that generates more “noise” rather than better clarifying analysis and decisions. It’s a known fact that 96% of all innovations fail to return their cost of capital (Deloitte). In this context, it is almost a no brainer that smart companies should change the way they are managing new product development. Several studies have demonstrated that those companies that manage to determine their customers’ needs and then innovate to meet them are much more profitable overall than companies who are not customer-centric.
A colleague (who is more thorough than I am) told me to how many technical interviews he attended in 2016. It was a big, but irrelevant number, which made me ponder about the power and responsibility people have when they JUDGE a person. Scared of how curt and terse « to judge » actually sounds, I applied the corporate filter and I decided to use “to evaluate” instead. It does not come off so strong. The evaluation process entails a person’s ability to be objective, while judgment seems godly and somehow final!
We all know that the way in which software products are delivered has changed a lot in the last few years. There is an increasing need to deliver things faster and to ensure that what we deliver is high-quality. If some years ago, development teams had enough time to design an architecture, to plan what they developed very well, in the last few years, the same teams do not enjoy the same amount of time. For this reason, the work methodologies laid great focus on the time required to deliver a product. We live in a globalized world, a state of affairs which can be seen in the way teams are built. Some time ago, development teams shared the same location. This is no longer valid. The majority of the development teams are distributed on different time zones and across various cultural contexts. In spite of all this, the high-standards of software product quality is as high as it will ever be.
Feb 1st marked my one year anniversary at my current company. I’ve been here several times throughout my professional life, but never before did I feel like sharing some insights about it. During my almost 10 years in business, I’ve been working for both big and small companies, local and multinational, with corporate and entrepreneurial cultures, in managerial and operational positions, yet this time something is different. Thinking about this from an inquisitive analyst perspective, it seems that at some point along the way I’ve learned some lessons, discovered new passions and confirmed some hunches about the world around me, just enough to keep the journey ahead interesting and just enough to think sharing them would bring value.
The idea that luck plays an important role in the field of innovation is well known. Just google "lucky inventions" and you will receive tons of lists with all kinds of novelties that were invented by chance – at least the authors of the lists say so. However, I have another opinion. Briefly, I believe serendipity does not exist. Okay, I know this statement is a bit radical. Everything depends on how somebody defines “serendipity”. I don’t want to start a semantics debate, I just want to show that “luck” has a much lesser role than what is commonly believed.
Imagine that you are searching for a new potential product or for a new functionality for your existing product that will be successful on the market. You are convinced that the market you’re targeting is in development, you talk to people in the industry, you research online, and you finally find the information needed to support your belief that the market is on an ascending trend and that your product will be a successful one. You decide to invest time and energy in the product and, soon enough, you are launching it backed up by a major marketing campaign. But your product fails. Nothing went as you have expected it to go: the market didn’t develop fast enough, you have fewer and fewer customers than you have initially estimated, you can’t cover the product costs, and you are working now in losses.
In the previous issue, we introduced the performance management framework OKR (Objectives and Key Results) and how it can help us build and grow performant product teams. In short, OKR is a set of measurable objectives and key results that we set quarterly. Each objective has a responsible, and at the end of each quarter we draw the line and evaluate the results: how many goals we were able to accomplish? Next, we will consider a timeline for implementation of OKR in a company, with a snapshot of annual and monthly activities.