Product development vs. in-house team

Basically, it is a matter of differentiating between external service providers and in-house teams in terms of content. Usually, the engagement of an external service provider is limited to a certain term or budget. Therefore, it is not only normal for us, but also our motivation to regularly deal with different projects, each of which brings its own challenges and framework conditions.

The in-house team – equally at start-ups and corporations – deal with a product over a longer period of time and this with a mostly constant team constellation. Depending on the requirements, different business units are occasionally involved, but basically they keep to themselves.

Both constructs deal with the development of products, but to different extents. Above all, the expectations placed on external service providers differ from those placed on in-house teams.

At the skill level, people like to differentiate between breadth and depth of experience. For our team, I wouldn't want to sign it that way, but of course specific expertise is something that an external service provider initially lacks when starting a new project. Especially if, like us, you provide industry-unspecific support and therefore find a variety of content challenges.

Not better or worse

What kind of organization one wants to work for is not a question of quality, but of mindset. Opposite to this is the decision whether to focus on a product or a process.

In this area of tension, we try to develop solutions in partnership. Becoming aware of the team constellation at an early stage is an essential factor. Especially in larger organizations that work with internal teams on one or more products, it must become clear that a common goal is being pursued. Trust, empathy and constructiveness are required for the time of engagement. If these conditions are not met, successful collaboration will be hindered.

In order to pursue a common goal, it must be clear to those involved not only what the goal is, but also how one is trying to achieve it. For us as service providers in particular, the defined goals should ideally be clarified before we enter into a project. In doing so, we try to weigh up opportunities and risks, point out stumbling blocks and outline an individual approach that meets the project requirements and framework conditions.

Who benefits?

At first glance, getting involved with external expertise for internal challenges seems like a risk that is difficult to calculate, but there are several points in favor.

Efficiency

Especially in new product development, companies face the challenge of creating a new, internal team constellation. It is not uncommon for a large part of the project time to be spent on the organization and distribution of tasks for the project.

In some cases, the specialist domains that need to be filled do not exist in the company or are busy with other projects. Jobs have to be advertised without further ado, which can be a considerable time factor in a competitive market segment coupled with a shortage of specialists.

If there is also an ambitious deadline, valuable time is wasted during which no progress can be made on the project.

If all or some of these circumstances come together, the decision to call in support from an external service provider is obvious. Well-rehearsed teams can thus ensure that schedules can be met and a product can be created while working on building up internal expertise.

The view from outside and user acceptance

Products, whether internal or customer-facing applications, must meet business objectives. In-house teams, in particular, know these very well and are therefore essential for the project. At the same time, this circumstance is their greatest weakness, as there is a danger of only dealing with the business requirements. This may result in solutions that are technically correct but difficult to use.

In order to create acceptance for the product, it is eminently important to check whether general, learned operating paradigms are adhered to. If comparable products exist or if internal solutions are already in use, it must be ensured that the product can be integrated into the existing landscape.

User centricity is even more critical. The future user community must be involved in the product development process in order to develop an audience-ready product based on their requirements.

Sounds logical, but is ignored with unhealthy regularity.

In our experience, all the points mentioned here are recurring problems that we identify with in-house teams. The origin of these errors can be in the organization of the project team, but can also be the result of excessive demands. If user interviews are not on the agenda, they will not be conducted.

Sprint vs. marathon

As already mentioned, the engagement of a service provider is limited from the outset in terms of time and budget and, at least in the design context, there is a requirement-oriented expectation of results. Regardless of the project volume, the engagement can be viewed as a sprint. During the time of collaboration we try to achieve an excellent work result, which is sustainable and value-adding. In plain language, this means for us: full throttle.

Design-driven products have a great need for different roles to be filled, especially at the beginning of the project. From requirements engineering, to UX research, to UX design and finally interface, visual or even brand design. This need is gradually reduced, because when the technical realization begins, the conceptual and theoretical groundwork must have been done.

In this phase, a transition occurs. The scaled-down commitment of those roles that were primarily required for the tour de force at the beginning of the project now provides a good starting position for moving from the sprint to the marathon. This may mean that it is time for the external service provider to slowly say goodbye and enable the in-house team to continue the project effort. At the very least, this situation should be strived for, as probably no client would be happy with having to rely on external support on a permanent basis.

The time of handover and the type and scope of the artifacts always vary depending on the project. However, it should be clear from the outset when, under what conditions, and to whom the baton will be passed.

Experience

It's not about a difference in quality, it's about defining roles with different objectives. With our colleagues:inside some of whom have over 15 years of experience in digital product development, we can not only accelerate a project but also improve it in the long run.

Again, filling a permanent role on a product team and managing the product over a long period of time is a role that is ideally filled internally.

Our focus is excellent results and that requires good teamwork. Therefore, it is at least as important to have experience in dealing with interdisciplinary and regularly changing teams.

The desire of every company is certainly to have this experience within its own ranks. Reality shows us that it is often different.

Partnership

There are also many other reasons for engaging an external service provider, but ultimately it is about supporting clients in their projects with expertise and experience that is not available in-house, or not sufficiently so.

When assessing whether a service provider has done a good job, the ability to work in a team is also a key factor. The willingness to work together as a team to get something done is the basic prerequisite for this.

If we are perceived as partners at eye level in projects and not as vicarious agents, the chances of smooth collaboration are very good.