I have seen quite often people using the concept of internal customer or internal user when discussing work done between areas. Something along the lines of “I have here a demand for you and, as I am your internal customer I need that demand solved as soon as possible, preferably until the day X”. I have even seen some people suggesting that we evaluate each other as internal customers and internal suppliers.

The problem with using the internal customer concept for relationship between areas is that it tends to put people in these areas on opposite sides. Someone from an area has a demand for another area. One area asks and the other area executes. If the other area does not execute well, the demanding area complains. If the other area does not deliver on the agreed time, the demanding area complaims. Then the area that has to execute the demand justifies that the request was unclear and that the demand should be made in Z format, specifying A, B and C because, without it, they cannot execute the demand correctly or on time. And so it continues…

In addition, companies typically have more than two areas. Thus, an area may have more than one internal customer and thus can receive various demands which, most often, are all “needed yesterday” and all are “the most important for the company.” Then begins the prioritization dispute.

Internal customer vs. teamwork

In 2001 a group of people who worked with on-demand software development met to discuss the best ways to make software. These conversations gave rise to the Agile Manifest containing the basis of the agility concepts that have improved considerably the success rate of software development projects in our industry. During these conversations they came to the conclusion that, among other things, there needed to be more customer collaboration. To have more success in software development projects is essential that the customer became part of the team that is developing software, and not a mere spectator plaintiff.

We must stop with this concept of internal customer and return to using the good old concept of teamwork, even among different areas. Teamwork is not just for people of the same area, but also for people from different areas. Any business 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 viewpoints of others, put yourself in their shoes, 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 mainly because different people, working together, are able to produce a result with greater impact than using only their individual skills. If everyone thought alike, this would not be possible. Therefore, in order to have real teamwork, it is important not only to tolerate and live with the differences: we must exploit them. We must cooperate. We must exchange knowledge. Valuing healthy conflict, not being afraid of debate and disagreements. When two people exchange ideas, each one gets out of the exchange with more ideas. Everyone wins. Different viewpoints help to build better results, s as long as people is not motivated by ego or distrust.

Practical example

Moving from theory to practice,  let me give you an example. I’ll use the need for hiring new employees in a given area that will need HR for this these example. When we need to make new hirings, we should avoid simply sending the job description to the HR and passively wait HR to do this task and only then get back to the HR and ask if they managed to fill the vacancy. The problem to be solved is to fill the vacancy with the best person possible within the budgeted salary range for the position and within the deadline. This is not an HR only problem. It is a problem to be solved by the HR team together with the demanding area. For this reason, the person who asked for a new hiring needs to work with the HR department to fill that vacancy, not only doing the interviews, but also helping to promote the vacancy, discussing each received curriculum, each candidate interviewed and so on. A new hire should be a teamwork of the HR team and the area who needs to do this new hiring. The chances of making a good hiring in proper time are much higher when the demanding area and HR come together and work as a team to do this hiring.

So I suggest we stop using the concept of internal customer and get back to the good old teamwork, even among areas. This will greatly increase the success rate of new endeavours, as well as the motivation of the people of the areas involved.

Product Management: Delight your customers with your software

In 2015 I wrote a book on Software Product Management in Portuguese. In the beginning of 2016, Paulo Caroli talked to me about how he enjoyed the book and how this book could be useful to people in the software industry not only in Brazil but anywhere in the world. For this reason, we decided to create an English version of my book.

The book is organized in 5 sections:

• Definitions and requirements
• Life cycle of a software product
• Relationship with other areas
• Product portfolio management
• Where to use software product management

This book is suitable for anyone working with software. Even companies that do not have software as its core business use software in their day to day and often have developed some software that interfaces with its customers such as a website or a mobile application. It is important for these companies to understand the software product management role and responsibilities, so they can better manage this software and increase its chances of success.

We are working on the translation but as we progress we are already releasing the content. If you want to see the work in progress, please visit the book page at LeanPub. Still in beta but already with valuable content. Feedback is always welcome!