Does Product Mindset Leave The Space For Services?

Does The Product Mindset Leave The Space For Services?

Last year, I wrote an article about Scrum and web development destroying development teams because of separating them from the end users. What I experienced after writing that one was that there are just a few people who had an opportunity to work in different setups differentiated by the distance to the users and the business. I spent some time jumping between service companies, product companies, and business companies.

In this article I use the following phrases:

• Services Company - the company, which sells the service of design and coding in a time&materials manner.
• Product Company - the company, which builds the digital product, that they sell.
• Business Company - the company, which sells non-digital stuff, but they do that with the use of technology.

The Product Mindset delivers value and empowers engineers

In June 2021, Marty Cagan published a series of 2 articles pointing to the key problems in digital product engineering. The first one was about The CSPO Pathology, explaining the destructive role of the administrative/proxy product owner; and the second one about The MBA Pathology.

Marty’s article got followed by Jeff Patton’s one. He’s the man, who actually put the very first seed in my head towards product thinking thanks to making user story mapping technique popular across the world. Jeff published The Mindset That Kills Product Thinking, which is focused on cooperation with software development service providers.

I strongly encourage you to read all of these articles. I agree with all the statements mentioned there.

What I saw in the comments of the most social shares mentioning these articles is that most of the people take one the following stands:

• “I know that and I am truly empowered.”
• “I know all of it what Marty and Jeff wrote but I work for the company, which doesn’t allow me to be empowered.”
• “The whole engineering world should do like they write.”

Lack of empowerment

Among all of these the most common statements, there was one more that Jeff wrote in his tweet mentioning that the services company anti-pattern is a rarity.

From the standpoint of the guy sitting in Poland (me) - this is not a rarity. It applies to the most of the Polish engineers, who work for the US or West Europe-based tech companies. In result, big number of engineers work as delivery teams and all the key and empowered decisions are being made in the headquarters where the products have been founded.

Services seem easier than building your own product. Services enable you to create suitable businesses and earn money. Empowerment is not a key if coding is just a job, that you do.

Service companies are here to stay

I agree with Jeff that there is no simple solution for overcoming this problem of creating thousands of delivery teams because of the current services company model. The world is way too big and there is a huge differentiation in the mindset, way of thinking, and geographical possibilities.

Especially, when we take under consideration the current state of software engineering. The demand for good software engineers is getting higher and higher. Engineering became a hot and well-paid job a couple of years ago. The number of developers grows exponentially. Maybe in the next years, it will become a commodity and most of the people will code.

Lowering the seniority median

Exponential growth of the number of programmers might cause a similar effect, which is happening in service companies when these want to scale up. The more people = the lower entry-level = the lower the percentage of experienced engineers = the faster the promotions. Due to this disproportion of junior to senior people, it will be hard to support the new generation of developers with proper guidance and coaching. Most of them will end up in service companies coding the Jira tickets described by the product owner, they will code stuff for the users they will never see.

And it is not that bad. Talent acquisition for the big players is super challenging. Simply put - there are no enough engineers to deliver the needs. As a result, many companies look for the team extension in the services/outsourcing model for software delivery.

Shall we get rid of service companies?

The top-of-mind idea would be “service companies sux, let’s get rid of them”. To resolve this problem of having delivery teams with a very low level of empowerment we could move all of these specialists to product and business companies. However, not all product or business companies have the budget, time, or knowledge to build in-house software development teams. Still, these companies want to be the first in their market.

There are a few great articles written by my previous boss. I encourage you to take a look at them (How to Outsource: 3 Things You Should Prepare Before Nearshoring Software Development, Software Development Outsourcing: 5 Holes in Your Contract) to understand the perspective and challenges of providing software development and design services.

The demand for the project-oriented work and the services

It is very unlikely to happen that the service companies will disappear and all the people will move closer to the end-users and business by moving to product and business companies. There is a huge space for team extension in environments working on complex products as well as a huge space for delivery teams for the applications in well-known domains, which do not require strong discovery skills. Based on the knowledge from books like Team Topologies, some companies started to play around with structures, that enable them to create an in-house product team working on the core differentiator of the product/service, that they offer and outsource the rest.

Sad truth is, there are projects, which just need to be delivered. Pretty often the key metric which is being optimized in such cases is that there is a manager in the company of your client, who promised something to the bosses. And that’s it. Many organizations measure success on just the delivery of the promise. There might not be a space for the product mindset as long as the sponsor doesn’t want or doesn’t know how to create it. Sponsor pushes for the delivery, service companies push for the money, pretty often noone pushes for the value.

We’re a young industry and it will be getting shaped in the next years.

May the Sponsor shape the product culture?

I do not know the solution. I worked in service companies leading the single team as well as huge programs made on top of 5+ service companies, which had to deliver the working system collaboratively. The client in such cases means - the sponsor. The reason why this is important is that - the one, who pays the money usually has the power to shape the culture of such collaboration.

Legal, bureaucratic, and agreement complexity

If you’ve read the article mentioned above about outsourcing contracts you are able to imagine how complicated it becomes to coordinate the cooperation of 5 software development service providers. Even when the sponsor is trying to do his/her best then it is just a super hard and tough challenge to create a truly empowered and collaborative environment.

For example, you can imagine achieving a close partnership with 1 of the companies but there are remaining 4, and the whole setup remains not very well empowered. Sticking to the agile value of placing people and collaboration above processes, contract negotiation, and procurement is not an easy thing to do.

Cost of delay vs long-term quality of the product

Could the sponsor switch the approach from using the services of 5 programming service companies to in-house built truly empowered teams? In theory, they could. In practice, it may take years to build the in-house team to deliver something at that scale. Especially, taking into consideration the pressure being created from the top of the organization. Many existing and successful companies can’t afford the cost of delay due to competing in a highly competitive (and pretty often commoditized) market.

Why they do not let 5 service companies work on the outcomes? It doesn’t make sense to let people, who have never seen the business or end-users make the decisions. They cannot fully understand the product strategy, nor the business strategy.

Is it possible that service companies would become part of the sponsor company to become truly empowered? Yes, it is possible. There are a few companies even in Poland, which achieved that state. However, from my experience in such scenarios, the demand for software engineering is pretty small. Successful service companies, that managed to achieve that are white ravens. But, maybe I am just not experienced enough to imagine how that could work at a huge scale complex system.

For many sponsor companies, the trade-off is about choosing speed or quality. Choosing quality especially in corporate environments might be hard. The leaders need to make tough decisions to balance these 2 aspects.

Keeping the product mindset in-house

All the sponsor companies, who decide to work with service companies, eventually realize that they need to create a strong in-house product team, which will make the decisions and drive the whole venture. Just because they (sponsor company) are the ones, who have the access to insights from the end-users and the business.

Then the job of the in-house product team is to drive, guide, and decide. They are the ones, who can try to help the outsourced teams to deliver value.

Usually, the job of the service companies is to deliver and to bring design and programming kind of expertise.

In the majority of the cases, this setup leads to unsatisfying outcomes, a lack of empowerment, and a lower level of engagement. However, due to the lack of engineers in the world and the rising demand for the software maybe we need to come up with the methods, that will allow this structure to create an empowered environment? Maybe the new buzzword of product mindset services company will appear?

The key is acceptance and education

The older I get the more frequently I see the world through acceptance. The world is huge, the software is eating the world, and the IT industry is still being very dynamically shaped.

The markets of Silicon Valley, Europe, and Asia might be similar for product companies, which are focused on building product-led businesses. In all of these markets, you are able to build a product and make it grow. To achieve that you need creativity, engineering, collaboration, design, and empowerment.

On the other hand, you do not need to create your own solution or build your own business to work in software development. That’s absolutely fine to work in the services model. If you are in that position, I encourage you to keep looking for ways for becoming a partner instead of the code-selling company.

You can make an impact on all levels from being a CEO of the services company to being a junior software developer. We all are responsible for shaping the world, that we will live in, and this is our job to care about the future.

Product mindset is not overrated, but

What do I prefer? Of course, empowerment.

In parallel, I accept the fact that the future will keep shaping the various collaboration models in IT industry.

We need more articles like the ones wrote by Marty Cagan and Jeff Patton about empowerment, the product mindset, and product management. More people speaking about Domain-Driven Design and Event Storming, which encourage development teams to get closer to the business. More customer advocates and support specialists, who help development teams to become more emphatic about the end-users.

And more patience.