Maturing a martech stack is a critical yet often overlooked aspect of marketing technology management. While marketers frequently focus on executing immediate projects, their technology ecosystem’s long-term health and effectiveness require ongoing attention and strategic development.
The building blocks of martech mastery
Scott Brinker has his five Ms for martech roles — marketer, modeler, maker, maestro and manager. They play key roles in Brinker’s martech maturity model with the hope that virtually all people in a marketing department can do far more than random acts of martech.
Getting back to those five Ms, what about “maturer”? Progressing through a maturity model just doesn’t just happen; somebody has to guide people through it.
As martech practitioners, we spend plenty of time executing projects. That is a major way our employers and clients measure our success, but there is more that we must accomplish to truly excel as individuals, teams and organizations.
We also need to mature our martech stacks, which requires attention to each component. When there are so many immediate and pressing needs related to projects, it is easy to forget about the bigger picture.
Efforts to mature a martech stack require far more than a technical focus; it is important to consider other factors, including contracts, ownership, organizational goals and others. Here are some ideas about maturing a martech stack. While this is not a comprehensive list, it includes many critical factors to include.
Start with documentation
Martech documentation is critical to success. While it is a lot of work to create, it becomes far easier to maintain it over time.
An important step is to create templates for tracking components, use cases, current state, capabilities and other items critical to a particular situation. Gathering information will take time, but that process will help illuminate the information needed for maturation initiatives.
The great thing about documentation is that maintaining it aligns well with the overall maturation process. It provides a great guide and perfect excuse for tracking an ever-changing stack.
Here are some important things to track, but this list is far from exhaustive. Further, different situations will call for tracking different things.
- Purpose
- Why does the organization have the component? What does it do?
- What organization-wide goals does the component support?
- What are the associated KPIs? How are things measuring up now?
- Contract
- When does the contract end? How much time is needed to decide how to renew or retire a contract?
- How is pricing structured? Does it make sense?
- Are all the features used?
- When it comes to support, how is the SLA? Is it too little or too much?
- Component ownership
- Who justifies the need for a component?
- Who gets the component the funding and prioritization it needs to succeed?
- Are they sufficiently fulfilling their ownership duties?
- User enablement
- Who are the component super users?
- How effectively are they operating the component?
- What training do they need to more effectively use it and stay abreast of changes?
- Component needs
- Does a component need an integration with another system?
- Does it need an owner (or a different owner)? Does its users need training?
- Overlaps
- Are there other components that have the same features?
- Does it make sense to have two systems doing the same thing?
- Tech debt
- What code or infrastructure shortcuts were taken to get something done?
- How is tech debt impeding future work?
- What plans are there to address tech debt?
- Security
- What are the audits (like SOC 2) should a component undergo?
- What do regulators and insurers expect of the company?
- Standards
- When it comes to accessibility, what standards, like WCAG 2.2 AA, are relevant?
- Are these required by a regulator?
- Would adhering to them improve UX or help with conversation rates with certain customer segments?
- Regulations
- What regulations do stack components need to adhere to?
- These can include anything from PCI for credit card processing, CAN-SPAM for collecting contact information and privacy-related regulations like CCPA (California), GDPR (European Union), PIPL (China) and LGPD (Brazil).
- Business continuity and disaster recovery
- How will the department react and recover when there’s a sudden change to a component or its power user team?
A continual process
It takes work and effort to document all of this information. This is a continual process.
Once the documentation is created, it provides a great guide of what to keep an eye on and update as things change. For instance, just because power users of a component got great enablement one time does not mean that they’ll need more training in the future.
Maturing the martech stack occurs at the component level and continually updating documentation is a great basis and foundation for that work.
The frequency of updating documentation can vary for each component. For example, documentation for an expensive and anchor component should receive more frequent attention than that of a cheaper, peripheral component. A CDP should get more attention and effort than a $100/month SEO crawler tool.
Further, the procurement cycle can help dictate when to check in on a component. When a contract renewal approaches, that’s a good time to check all the documented factors to ensure that the proposed contract (keep an eye out for contract gotchas) makes sense. However, for components with multi-year contracts, remember to check in those even when a potential renewal is more than a year out.
The bigger picture
Focusing on projects’ pressing tactical needs — what needs to happen now — is easy, but paying attention to the components is important.
For example, a company may make some significant UX changes to a website that yield positive results. However, has the content management system (CMS) that the website built upon been maintained? Most vendors update the core code and the modules, plug-ins and other add-ons to the core. These updates include enhancements related to security and performance and changes to code libraries and hardware the website uses. Applying such updates is critical.
While this is at the component level, ignoring such factors can impede project-level needs.
Effort and attention
Martech maturation doesn’t just happen; it requires effort and attention. This work typically falls in the “important but not urgent” quadrant of the Eisenhower Matrix. Productivity experts advise planning and scheduling such work. I argue that we also need to prioritize this work.
Maturing the martech stack is critical to organizational, team and individual success.
Contributing authors are invited to create content for MarTech and are chosen for their expertise and contribution to the martech community. Our contributors work under the oversight of the editorial staff and contributions are checked for quality and relevance to our readers. The opinions they express are their own.
