Skip to content

Managing the Legal Files - ProductFTW #41

How to stay organized when things are constantly changing

One of the more mundane, but important tasks in product management is managing legal documents that are a part of the product. Every product has some legal document. For most web applications it might be as simple as a privacy policy and a terms of use document. For fintech products, like we build at Totavi, a product might have a half-dozen documents or more, such as account agreements, rewards program terms, e-sign agreements and more.

Each of these files needs to be tracked and managed carefully. It seems easy, but I have repeatedly been tripped up by finding that we posted the wrong document to the app or let something get out of date. In addition to making sure users see the correct document, you may need to alert users to changes and track which users saw which document (and, in turn, what you are allowed to do with that user’s product or data as a result).

A cartoon-style illustration of a frustrated man with glasses in a messy office, hands on hips. Papers overflow from desks and cabinets, flying through the air, emphasizing the chaos and disorder.
At least we have computers now...

If you want to build an iron-clad system for managing documents, there are a few straightforward tactics you can use:

  1. Name all documents with an internal tracking code. For example, your privacy policy could be tagged with “LEGAL-PP-20250206-v2.0.2” to indicate the following:
    1. LEGAL: just a prefix
    2. PP: “privacy policy”
    3. 20250206: the date of the update in YYYYMMDD format (which is the only correct format 😜  )
    4. v2.0.2: a version number
  2. Include the document tracking code in the document itself. For example, you could put it in the footer of a multi-page PDF (or other document format) or simply at the end of a webpage.
  3. Keep a copy of all files in a cloud storage solution with version control (such as Dropbox or Google Drive).
  4. Post all documents for users to view to a stand-alone content delivery network (CDN) location, such as a separate AWS S3 bucket (named something like “legal”).

I know, this is a lot of process, but it’s going to save you down the road and isn’t that hard to do. It always feels like these things will be easy to manage, but then, as the product grows and things change, they start to get unwieldy.

Number 4 above is especially important, as you do not want to have to ask engineering to do a deployment to update documents. By placing the assets in a CDN location, you can enable a product or operations person to update without a deployment.

In the website or application routes, you should enable any user who should see the latest to link to an alias for the current version. For example www.example.com/legal/privacy-policy is a location you can depend on and easily code to. That can be set in the CDN to route to www.example.com/legal/privacy-policy/LEGAL-PP-20250206-v2.0.2.pdf as the actual source file.

Why not just replace the file? Well, there are cases where you may need to show users a prior version. This brings up the second big topic: tracking.

When a user signs up for your product, you should store the version of the terms in the user metadata (e.g., the user table) so you know what they agreed to. Some legal changes may be something you can force on your user (for example, a blocking modal that you must agree to new terms to continue). You can easily use the user metadata to trigger actions in your application.

On the other hand, especially in financial services, you may have to give users time to use the product under old terms before they have a choice to close their account or agree to new terms. For example, if you are operating a credit card and change the rewards terms, you may tell your users they have 90 days to continue or to agree to new terms. In that case, you will need to show the user the cardholder agreement and rewards terms that currently apply to them, not just the latest.

Depending on your product, the legal changes, and your legal team, you may also simply notify users (either or both of via an in-app notification or via a push). Again, you need to be able to build a list of who needs this and who saw it. It’s usually not enough to just post to your site for a month (“we just changed our terms”).

With some additional attention to detail and a clear plan, you can ensure your product stays compliant, you reduce risk to your organization, and ultimately provide a better user experience, by planning ahead on legal documents.

About ProductFTW

ProductFTW is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.

Part of the Fintech Product Management Field Guide — ProductFTW's writing on what makes building card, payment, and banking products different.

Subscribe to ProductFTW

Don’t miss out on the latest posts. Sign up now to get access to the library of members-only posts.
[email protected]
Subscribe
Start typing to search...