Product approach in outsourced development. Inside a large IT integrator. Part 1

Do you know the situation where the client sees the developer as a feature provider rather than as a team member helping develop the product?

Does it ever happen that the need for some features the client wants to implement is unclear?

Moreover, there is no understanding of the project's final numbers and metrics.

There is no exact benchmark for what level of quality a specific feature needs.

Do we need an interface, or is it enough to specify settings in files; should the functionality be split into a microservice, or is it enough to embed it in the current architecture, and so on...

With this mindset, developers are often evaluated by the number of features.

In this case, the actual level of quality is determined subjectively, case by case, or depending on the budget.

But when a company slips into feature acceleration, there is no time to think about quality.

But is a team that develops its own product always free from such problems?

Is it true that product companies have no client, so you can work there at a relaxed pace and with less pressure?

In this article, we will discuss what product development is, what makes it distinctive, and why it may be absent in a product company but present at an IT integrator.

Outsourcing development means custom software development for external clients.

Product development means creating and evolving your own IT product.

The client here is internal, for example the marketing department or the product analytics department.

An internal client may not differ much from an external one: they also expect a certain result by a certain deadline. And it matters to them that the result meaningfully advances their business goals.

It is often believed that outsourcing is characterized by a project-based approach.

There are deadlines and a technical specification: you have to meet the deadlines and deliver on the spec.

Product development is expected to follow a product approach. Seems obvious.

But let us see in practice whether that is really true.

A product approach means focusing on business goals: the development outcome must solve specific problems and be profitable. "Product approach" does not mean "product company" - an IT integrator can use it too! Because of entrenched stereotypes about project and product approaches among developers, five prejudices about outsourcing companies circulate: 1 client requirements constantly change (you can never please them),

You can get acquainted with some of them on the page "Projects We Are Working On Right Now."

We cannot name everyone openly, since many are under NDA (non-disclosure agreement). So let us examine how fair the stereotypes about product and outsourcing companies in IT really are.

For each employee's contribution to be assessed fairly, you need to define in advance who is responsible for what and establish objective metrics - we already discussed this in the previous point.

Sometimes developers distance themselves from business goals and say that business metrics are none of their concern, that they only need to implement their task well.

In that case, it is no surprise that the client values their work poorly.

Marketers would say it was all them, since they were responsible for leads and SEO tasks.

Logisticians would say that without stock in the catalog and proper shipping, there would have been no sales.

The boss will say that his farsighted eye caught everything.

A talkative loafer promises everyone everything, and even if someone else delivers on those promises, he still counts it as his win.

But if something goes wrong suddenly (and with a certain level of managerial itch, trouble can always be found), the developer will end up being blamed.

After all, if you dig through the analytics, any failure can be tied to any number if you try hard enough (and in our practice, we do not even get to the point of working with numbers).

The only thing is, all of this happens with equal likelihood in both product companies and outsourcing companies.

With a product approach, success is not delivering as many features as possible. Success is a valid hypothesis that helped achieve business goals. And even a bad hypothesis is not a defeat, because it helped us better understand the product and move faster.

There are simply no losing situations here.

Thus, recognition does not depend on whether you work in a product company or an outsourcing company.

What matters is how responsibility for the future result is initially divided between the client and the contractor.

To assess the contribution of all sides objectively, we use the Impact Mapping method. There is already an article about this method on the blog - "Impact Mapping, Unit Economics, and PDCA: Effective Management of eCommerce Development."

We will cover three more myths about the differences between product development and outsourcing in the next part of the article. We will publish it on Saturday, March 14, 2020. Stay tuned ;)