The pros and cons of specializing in specific martech products

Martech practitioners specialize in specific products. That’s not news. Further, it makes sense for people to learn how to really use a specific platform well. However, that’s not always ideal when putting together a team.

This is important to keep in mind when developing one’s skills, recruiting new employees, and orchestrating a martech stack.

Recruiting with one product in mind

For instance, in the past I’ve seen companies with job postings for Drupal developers that require applicants to have expertise with PHP, but no experience with the platform. Drupal is based upon PHP, and any developer hoping to work proficiently with it must know that specific programming language.

However, there’s so much more to Drupal than PHP, and the platform and community have numerous standards and practices that aren’t involved in knowing PHP.

Thus, I’ve seen many different companies hire competent PHP developers who — despite their best intentions — didn’t use Drupal that well, at least from the get-go. This caused trouble down the line.

Providing support and education for new hires

There are ways to address this lack of knowledge. For instance, if an organization already has Drupal developers who understand the platform, they can help educate the new hire.

Further, if the organization has a Drupal vendor, the vendor can help the new hire acquaint themselves with the Drupal way of doing things. Of course, the organization could’ve listed Drupal experience — even if it is just preferred but not essential — as a requirement as well.

This is not just applicable to the CMS space. The same applies to marketing automation platforms, CRMs, and so on.

Evaluating personal investment in a platform

As I mentioned in an interview with Chris Wood about marketing ops in merger and acquisition situations, people not only specialize but also personally invest in specific products. As humans we’re primed to form and join groups, and that tendency comes with positive and negative outcomes.

Personal product investment certainly can offer benefits as people, for example, develop advanced skills and actively participate in user communities to find new and better ways to accomplish goals. Deep investment in a community may also help practitioners better influence product roadmaps to address the needs of their organization.

However, there are some drawbacks. When people invest deeply into products, they may intentionally or not opt-out of following developments regarding competing products. They may also not follow relevant trends as they primarily rely upon their favorite product’s booster community for broader specialty trends. This means they may not adjust to changes over time. Their favored product may make the best sense at one time, but its competitors may evolve to change that calculus later on. The personal investment may blind them to many important factors.

Taking into account the entire stack

Further, products rarely operate by themselves. A broader stack perspective may suggest that it’s worth switching to another product in order to work better with the rest of the stack.

This could lead product specialists to feel threatened or frustrated that they have to learn a new product. They may even fear that a temporary dip in productivity will threatened their jobs.

This, of course, mimics concerns that arise when integrating stacks following a merger or acquisition. Fortunately, change management can help team members respond more positively to such changes.

Considering employees’ perspectives

While there are certainly stack-wide considerations at play, it’s also crucial to consider the employee side as well. For example, two senior stakeholders may disagree on which analytics platform is best for the organization. One stakeholder may specialize in a particular product while the other stakeholder had a lackluster experience with it in the past. Whose perspective prevails?

A more indirect interplay occurs when the stakeholders may champion products for their own stack functions. What happens if that pairing is less than ideal in regard to integrations or other important connections?

I’m a big proponent of the fact that for a product to succeed it needs invested owners and users. So, if the two stakeholders can’t agree upon a better pairing, it’s better to have two stack components that are both used. That may very well justify the business decision to stick with a certain pairing, but it is prudent to consider the costs of such an arrangement.

It’s important to note that practitioners specializing and investing in products is not bad at all, in and of itself. As I mentioned with PHP and Drupal, there are advantages to this. That shouldn’t come at the expense of keeping track of broader trends and developing portable skills that are valuable regardless of the particular product in question.