Why did we set up a product team?

Product teams are increasingly in evidence. It is very common for companies to have these teams, regardless of their size, industry or segment.

This article is the first in a series in which we will discuss concepts related to our product team. We will divide the subjects into:

Part I: Why did we set up a Product team?

Part II: How do we apply the MVP concept?

Part III: What influence does data really have on our strategic decisions?

Introduction

Before we begin to discuss our product team, it is worth making a small introduction on the company in which the team is inserted.

MZ is a leading company in the Brazilian investor relations sector. With 19 years of existence and a consolidated position in the market, our goal continues to fulfill our purpose entirely, which is to offer products and services that facilitate and increasingly add value to our customers’ daily investor relations responsibilities. Yet, we still perceived that we needed to undergo changes as we take our company forward.

With this need for change came the decision to prepare the Company for an increasingly fast and digital world and with this focus we began a digital and cultural transformation process. As part of this process, we designed the Company’s operations around the new products we are creating, investing in state-of-the art technology and changing the way we had been working until now.

One of the first effective actions we executed was the creation of our product team, which became responsible for our new positioning.

To understand what this change represents, it is essential to look at our past. During a long time, our teams were divided as follows:

Business Team: Responsible for identifying our clients’ needs and ensuring that they are met.

Technology Team: Responsible for maintaining existing products and developing new functionalities requested by the business team.

This operating model, which is widely used by several companies, has certain flaws, in which we highlight:

• The business team does not have the necessary knowledge of technology and this eventually leads to the creation of “phantom” products, which cannot be reused and will require future maintenance and incur costs for company.
• The technology team does not have a clear understanding of possible product growth, and therefore strategic decisions are rarely effective.
• Extensive documentation and difficulty of control: In an agile world, full of changes, delivery have to be quick. Transforming maintenance into megaprojects causes inconveniences to all parties involved (client and internal teams).
• Update Difficulty: The process of creating new tools and updating existing technologies is extremely difficult due to the existence of many business rules spread across all the applications that were built.

As we looked at this scenario, we realized it was extremely necessary to have tighter control over our products and to ensure that only effective and relevant functionalities were developed.

When analyzing the market and companies, we came across several operating examples, two of which caught our attention. Thus, and we decided to study them in depth and apply their operating model to our company: Spotify (Squads) and Google (OKRs).

Team Structure (Squads)

The basic requirement to achieve excellence is having professional with different qualifications working together for the same purpose. Therefore, we created a product team comprised of:

The main challenges of this team are to ensure that the development team produces only what will bring value to our clients, and that such products can be scalable and replicable, and analyze the data generated by the platform to make decisions about existing features (necessary changes or discontinuation).

The fact that we have a multidisciplinary team is fundamental for us to fulfill our objectives. We are able to analyze a product from end-to-end, understand if it can be created with the existing technology (technical specialists), if it will bring benefits to the market we serve (IR specialists), if it is well designed/structured and will be accepted (UX specialists) and if the timing for its launch is correct (leader).

Prototyping / Validation

There are many literatures on what a product team’s routine should be. We’ve chosen to follow the teachings provided by Google Ventures (GV), which can be found at this address: http://www.gv.com/sprint/

Our sprints, just like GV, are divided into five days. Each day has its specific routines and activities and at the end of the week (Friday), we either approve, or not, our idea. If it is approved, this functionality goes to the development team to be implemented.

In summary, new functionalities follow the principle that there is no need to implement them without previous validation. Therefore, we focus our efforts on discussing which business rules should be met and how best to serve them.

After defining what should be delivered, we create functional prototypes and validate them with clients and other experts. If we receive a 75% minimum approval from our target audience, we move forward.

The only rule that we do not strictly follow is the amount of time spent. According to GV, it is necessary to have, at least, 6 hours of daily focused work. Because we have a lean operation and other demands, we dedicate only a portion of our work day. Despite this, we did not feel this was a disadvantage and our development rework rate declined dramatically.

Measurement / Maintenance

For features that have already been developed and are currently in use, nothing is more assertive than data. We collect various information on use, time spent on each task, how easy it is to use, among other data.

Based on this data, we suggest changes (layout, flow of information or even business rules) and validate with our clients/internal audience before them.

The most incredible thing about working with data is that, in over 95% of the situations, the suggested changes are very well accepted and complimented. With this, we spend less time correcting bugs and invest it more wisely towards the creation of new features.

Analyzing data, however, do not mean we do not need to interact with our clients. It is always very important to listen to the client and validate their requests. To achieve this, we use Google Forms, a feedback tool with four questions. These questions allow us to better structure requests/suggestions, avoiding the traditional “what if…” method, and changing an uncertain suggestion for something that will really bring value to the requesting party.

Conclusion

The world is changing. New technologies emerge as we speak and we need to be prepared to achieve excellence by using what is most modern out there. It is impossible to innovate, improve and evolve if we are stuck in old and outdated processes. Creating a team of products like ours can streamline and ensure the necessary speed for the necessary evolutions and adjustments.

It is also important to point out that collecting data on any implementation is highly important. We’ll discuss more on that in the third article of this series.

Our next article will be on how we use the MVP concept and how it helped us save hours and hours in product development.

Authors: Felipe Furlan