Martech stack documentation is vital, here are some tips to do it right

It’s important to maintain documentation about a martech stack. Stacks typically have dozens of components used by dozens of people, and keeping track of everything is tough. By maintaining documentation, important details are shared more easily and less likely to fall through the cracks.  

There are many ways to manage documentation, and the correct decisions are dictated by individual circumstances. It isn’t easy and is an ongoing process. Here are some things to consider.

Program and platform

In many cases, documentation likely begins with spreadsheets. This is a good place to start, but they have limitations.  

Fortunately, there are services designed specifically for martech stack documentation like CabinetM, Airstack, and Martechbase. There are related and more general tech stack solutions like StackShare and Zylo, which are also useful. These solutions offer features like stack visualization, product directories for comparison, data exports for external use, skill mapping, and information importing and exporting.

These solutions are great for providing information to vendors, but it may make sense to maintain a related set of documentation for internal purposes. If an organization has a wiki, that’s a great candidate for hosting the documentation since most employees should have access by default. Thus, this a good place for people from other departments (IT, legal, and procurement) to have access to stack information. Further, in this venue, documentation can include more confidential information (like budgets, strategic planning, and internal assessments) that wouldn’t be appropriate to share with vendors or other external parties.

What to document

Regardless of the venue (internal or external), there’s some important high-level information to track.   Two very important pieces of information in this category include the overall purpose of the stack component as well as who are the main people associated with it (executive, sponsor, technical lead, and power users). This information alone is very valuable as it will help address why a company uses something and who to ask for more details.

Another thing valuable for external and internal audiences is information regarding system integrations.  Vendors in particular will likely need access to at least high-level information so that they can better align their efforts with where information from their system will flow to others. However, not every vendor needs such information, and an internal system is likely a better place for more detailed information that vendors don’t need access to.

Contract information is another very crucial information category. Important factors are contract dates, total expenses, billing cycles, and which budget funds the contract. Further, information can include – if applicable – the number and types of user licenses, features contracted, and any contractual limitations.

An important question for documentation to answer is: How is the stack component performing in regard to the organization’s needs and goals? If it is not, what’s needed to address this deficiency (user training, contract adjustment, integration work, etc.)? In many cases, the best people to provide the component’s goals and overall performance are the sponsor, technical lead, and power users. Usually a simple classification of “succeeding” or “not succeeding” is sufficient. Documenting component needs and recommended actions near the goal performance information can logically allow others to quickly find what actions are needed, if any.

Tracking stack overlaps is also helpful. It is certainly possible that a stack has components that have duplicate functionality. Sometimes there’s a reason for this. For instance, site uptime monitors, web governance platforms (for accessibility checks, broken links, etc.), and tag auditors all check sites to ensure that they’re running as they scan them. However, they all focus on different core competencies; thus, a tag auditor won’t cut it in regard to minute-by-minute uptime checks nor accessibility standards compliance. In this scenario, it makes sense to have components with functionality overlaps, and documentation can help keep track of why that is the case. Further, documenting overlaps can spark questions about if the overlap is necessary, efficient, or needed.

Perhaps one of the most robust types of information to document is freeform notes. These can capture anything else specific to an individual component. It is useful to indicate the date of each note as well as using full names of people and explicit identification of external parties so that a broader audience can get a clearer picture of decisions and circumstances.

Conclusion

Documenting stack information is very important for martech management. However, it’s not easy and requires constant attention. Considering the factors above should help determine what one should do given their unique circumstances.

Here’s a template to get you started: