I have talked to some people lately about IT departments and how they seem disconnected from the companies they belong to, often being very reactive to business demands. It is common to hear complaints from business people about IT saying they almost never deliver what was asked and that it is hard to understand what they say. On the other hand, it is also common to hear IT folks saying that the business area does not know what they want and that IT cannot answer “zillion” high-priority demands of the business. This lack of understanding between IT and the business areas of companies is so common that it even became a subject of cartoons of all kinds:

But what is wrong? What is the IT problem?

Software development

For those who live in the part of IT that has to do with software development, this problem has been addressed for some time now. The Agile Manifesto, from 2001, makes this clear:

• We have come to value customer collaboration over contract negotiation.
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Business people and developers must work together daily throughout the project.

As the software developers need to deploy their software somewhere, they decided to involve the people who take care of the production environment in this new way of thinking that brings together IT and business. Thus was born the DevOps movement in 2009:

DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals. DevOps is a response to the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services.

Source: Wikipedia

In these software development teams, it is common to see someone with the role of Product Owner or Product Manager. This is a role I’ve already described earlier:

Product Manager is responsible for all aspects of a software product, from strategic objectives to the details of the user experience. She is responsible for making the connection between the business strategy and the problems and needs of customers through the software that should help the company achieve its strategic objectives while solving the problems and needs of the customers.

The IT problem

Now imagine the IT department of Gap, American Airlines, Disney, MIT, or any other non-tech company. These IT departments will have among their scope the following functions:

• Hardware inventories.
• Software inventory and installation.
• Server availability monitoring and metrics.
• Security management.
• Anti-virus and anti-malware management.
• Anti-manipulation management.
• User’s activities monitoring.
• Capacity monitoring.
• Storage management.
• Network capacity and utilization monitoring.

As you can see, these IT departments already have enough stuff to worry about and will hardly develop software. If they choose to develop software, they will most likely use third parties to do this development. Even if they decide to develop internally, software development is still a small piece of IT. The concern of these IT areas is how to integrate off-the-shelf software and make them work to meet business needs.

The problem is that unlike software development, which already discovered the importance of having a product manager to help deliver results more aligned with the business, all other functions of an IT department do not have this bridge between IT and the business.

One possible solution to the IT problem

I would like to propose a solution to the IT problem: have more people with the role of “product manager”. I believe that name does not fit very well when the IT delivery is not software. That person will need to create a bridge between IT and business. Perhaps a more appropriate name is “business manager”.

This person would have the following responsibilities:

• Gather IT needs in all areas of the company and identify and propose solutions to any conflicts between these needs.
• When these requirements have an impact on the end customer of the company, understand this impact on these customers.
• Negotiate requirement implementation priorities with all business areas.
• Work with IT teams to ensure that deliveries are made in accordance with the requirements gathered with the other departments of the company.
• Act with the demanding areas and IT teams on any relationship with suppliers/partners. (e.g. banks, consultants, etc.)
• Inform all areas of the company on new IT implementations as well as upcoming implementations. Prepare training as needed.
• Work with marketing to inform customers when the new implementations are customer-facing.
• Define, track, and analyze usage metrics from IT, to use them as further relevant information for decision-making.

And to be able to carry out these responsibilities, this person needs to have:

• Experience working with IT teams to deliver quality projects within expected deadlines.
• Good understanding of IT and technical topics to be able to negotiate delivery options. Having been in the IT field is not required, but may help in the function.
• General knowledge about the company’s products and services, as well as an understanding of the different departments of the company.
• Good oral and written communication skills.
• Negotiation skills between different stakeholders with different priorities.
• Ability to document requirements and use cases.
• Leadership.

As you can see from the above description, this person has a senior profile. It will be a pair of the IT manager.

A question that may arise while reading this proposal to add a “business manager” to the IT team is why IT managers can not assume this role. Actually, they can, but they shouldn’t. IT managers already have many concerns. The IT manager has two main focuses, technology, and people. She needs to be up-to-date on the technologies in her area to learn how to better meet the needs that arise. And she needs to manage the team, finding and coordinating good IT professionals is no an easy task. Putting on the IT manager the additional burden of business requirement management can lower the overall quality of current tasks.

In software development, we’ve realized that it’s better to have a separate person taking care of business needs. Why not apply the same role separation for other IT areas?

Using business manager in practice

At Locaweb, we had a team for many years that develops and maintains what we call the company’s core systems. These systems have customer and product data and the relationship between each customer and the contracted products. In addition, they are responsible for charging for the services provided and, when payment is not made, for deactivating the customer’s service. These are Locaweb’s billing systems.

For many years, they were treated as systems in the traditional way, that is, the area manager himself, in addition to taking care of the development team and technical issues, was also responsible for interacting with all areas of the company to collect and prioritize demands.

In 2014, we decided to change the structure of the area by creating a PO (Product Owner) figure for central systems, alongside the area manager. Shortly afterward, we realized that this change was essential, not only to improve the quality of deliveries by this team but also to relieve the area manager so that he could focus on the technical issues of systems development. The team was happier with the new way of working, as well as all internal and external clients in the area, who began to see him as a facilitator.

When I joined Conta Azul in August 2016, there was also a team with the same goals and the team was creating this product management function to help interface with the other areas. At Gympass we created a similar team, which we called Cross Features, and at Lopes, we also created the Central Systems team.

ThoughtWorks suggests “applying product management to internal platforms”

I was once again pleased to see that once again a technique I’ve been using for some time to help create better software has been mapped out by the ThoughtWorks team! In the November 2017 issue of Radar Tecnológico, they suggest “applying product management to internal platforms”:

We’ve seen a sharp increase in interest in the topic of digital platforms over the past 12 months. Companies looking to deploy new digital solutions quickly and efficiently are building in-house platforms that give teams self-service access to the company’s APIs, tools, knowledge, and support needed to build and operate their own solutions. We found that these platforms are most effective when given the same consideration as an external product offering. Applying product stewardship to internal platforms means empathizing with internal consumers (read: developers) and collaborating with them on the project.

Platform product managers establish roadmaps and ensure the platform adds value to the business and enhances the developer experience. Some owners even create a brand identity for the internal platform and use it to market the benefits to their peers. The platform’s product managers take care of the platform’s quality, gather usage metrics and continuously improve it over time. Treating the platform like a product helps create a thriving ecosystem and avoids the pitfall of building another, stagnant and underutilized service-oriented architecture.

This will certainly help us to develop better software, including internal systems, that meet the needs of its users while helping the software owner achieve his goals.

The “internal customer” fallacy

Many times I saw people using the concept of internal customer or internal user when discussing the work carried out between areas. Something like “I have a claim for you and, as I am your internal customer, I need the claim to be resolved as quickly as possible, preferably by day X”. I’ve seen some people suggest that we evaluate ourselves as internal customers and suppliers. The problem with using the internal customer concept for the relationship between areas is that it tends to put people in those areas on opposite sides. Someone from one area has a demand for another area.

One area asks and the other area executes. If the other area doesn’t perform well, the demanding area complains. If the other area does not meet the agreed deadline, the demanding area will complain. The area that must execute the demand justifies that the request was not clear and that the demand must be made in the Z format, specifying A, B and C, because, without these, they cannot execute it correctly or on time. And so the story continues…

Also, companies typically have more than two areas. Thus, an area can have more than one internal customer and, therefore, can receive several demands that, in most cases, are all “needed yesterday” and all are “the most important for the company”. Then the prioritization dispute begins.

Internal customer vs teamwork

In 2001, a group of people who had worked with on-demand software development got together to discuss the best ways to build software. These conversations gave rise to the Agile Manifesto, containing the foundation of agile concepts that have considerably improved the success rate of software development projects in our industry. During these conversations, they came to the conclusion that, among other things, greater customer collaboration was needed. To increase success in software development projects, it is essential that the customer becomes part of the team that is developing software, not a mere bystander requester. We must stop with this concept of internal customers and go back to using the good old concept of teamwork, even between different areas. Teamwork is not only for people in the same field but also for people in different fields. Any company can and should be seen, ultimately, as a team of teams.

To work well in a team, you must have empathy, that is, know how to understand and respect the points of view of others, put yourself in their shoes, and try to understand how others think and why they think that way. Different areas have different cultures and different ways of thinking. And that’s good! Teams work primarily because different people, working together, are able to produce a result with greater impact than using their individual skills alone. If everyone thought alike, this would not be possible. Therefore, to have real teamwork, it is important not only to tolerate and live with differences: we need to take advantage of them. We must cooperate. We must exchange knowledge. Value healthy conflicts, and not be afraid of debates and disagreements. When two people exchange ideas, each leaves the exchange with more ideas. Everyone wins. Different points of view help to obtain better results, as long as people are not motivated by ego or distrust.

A practical example of teamwork instead of internal customer

Moving from theory to practice, let me give you an example. I’ll use the need to hire new employees in a certain area that will need HR for this example. When we need to make a new hire, we should avoid simply sending the job description to HR and passively waiting for HR to do this task and only then go back to HR and ask if they were able to fill the vacancy. The problem to be solved is to fill the vacancy with the best possible person within the budgeted salary range for the position and on time. This is not an HR-only problem. It is a problem to be solved by the HR team together with the area that requested it. For this reason, the person applying for a new hire needs to work with the HR department to fill that vacancy, not only conducting the interviews but also helping with the search, discussing each resume received, each candidate interviewed, and so on. A new hire must be a team effort between the HR team and the area that needs to make this new hire. The chances of making a good hire in a timely manner are much greater when the demanding area and HR come together and work as a team to make this hire.

Therefore, I suggest that we stop using the internal customer concept and go back to good old teamwork, even between areas. This will greatly increase the success rate of new ventures, as well as the motivation of people in the areas involved.

2023 update

This article was originally written in 2014 and is one of the final chapters of my book “Product Management: How to Increase Your Software’s Chances of Success”. Despite being almost 10 years old and having evolved, there are still many companies using the business demands => technology implements.

That’s why in recent months I’ve been applying myself more and more to my mission to help people and companies connect business and technology through training and consulting in product management and digital transformation.

Workshops, coaching, and advisory services

I’ve been helping companies and their leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) bridge the gap between business and technology through workshops, coaching, and advisory services on product management and digital transformation.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article without depending on any social network algorithms to notify you! Just subscribe to my newsletter.

Digital Product Management Books

Do you work with digital products? Do you want to know more about managing a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books, where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Startup Guide: How startups and established companies can create profitable digital products
• Product Management: How to increase the chances of success of your digital product
• Leading Product Development: The art and science of managing product teams

You can also acquire the books individually by clicking on their titles above.