Blog post: Terms and Conditions as a Service – literally

Some time ago I changed my title to Product Manager. For many years I have worked as a developer and later team-lead for a development team, so this was an interesting change.

Working as a team-lead had slowly removed me from actual day to day coding, doing more and more human-resources related tasks and meetings. So when it was suggested to me to play a more active role in the software development, without the team responsibilities I accepted. The only requirement, which was presented to me in my new role was:

– Use your knowledge and know-how to continuously support our software services and products.

I was a bit uneasy with the new role and perhaps mostly the title. Having worked as a developer for a long time, it was hard to loose the techie. I suggested “Technical Product Manager”, but it was denied – I got over it and at that point it really did not matter – after all it was just a title *1

Still fearing that it would move me away from coding, I decided to try to shape my new role to suit me better. The organisation I work for has never had a Product Manager before, so I figured I might as well try to outline my own role.

I started out by examining an idea I had played with for some time, but had not implemented. As a Product Manager I decided it was totally legal to create prototypes to evaluate possible candidates for our service portfolio.

The idea was to handle the problem area of “Terms and Conditions” and communication of these. The problem area can be described in the following way:

1. The terms and conditions has to be available in a preservable format (I am not a legal specialist, so I do not know the exact wording, but this is the way it was explained to me)
2. The terms and conditions have to be available to the end-user in the revision/version, originally presented to the user

In addition, the following, more basic, requirements followed:

1. We want to be able to link to the current terms and conditions, so you can find them for example via a website
2. We want to be able to link to specific revisions so we can create links for websites
3. We want to be able to communicate the terms and conditions via email, without sending the complete terms and conditions, but just providing a link
4. We want to support both danish and english

I boiled together a prototype service to handle exactly these requirements and the prototype can be found on GitHub and on DockerHub.

The solution offers the following:

– Terms and Conditions can be downloaded as a PDF and this has been accepted as a preservable format

– You can link to an exact revision, for building lists for example

– You can link with a date parameter, which will give you the revision relevant for the given date

– You can link to the service and get the current revision of the Terms and Conditions

– You can point to a given translation of the document in the URL by using the language indication ‘da’ for Danish and ‘en’ for English

Lets walk through it:

– Providing PDF files as an asset it pretty easy in any modern web development framework

– The date based query:

/en/terms_and_conditions/20020611

Returns terms and conditions active for the specified date. This can be used in email for example where you then can stamp with the current date.

– The revision based query:

/en/terms_and_conditions/revision/2

Returns current terms and conditions revision 2. This can be used for enumerations and listings or specific deep links.

– The basic query:

/en/terms_and_conditions

Returns current terms and conditions, which can be used for webpages where you want to show the current revision for evaluation by the requester.

– The basic query, supporting another language:

/da/terms_and_conditions

Returns current terms and conditions in danish, can be changed to English by specifying: en instead of da.

All of the available documents are assets to the service, these could be fetched from a database or similar, in the prototype they are just publicly available files.

The prototype solves the problems outlined and gives us an overview of the public facing part, meaning the service and feature parts, but can be improved in many areas, especially in regard to the internals.

– You could annotate the documents, if they are no longer the current revision. My suggestion is to annotate the actual PDF, alternatively the presentation in the browser could take care of this. The current prototype does not handle this.

– Handling the problem of different timezones can be quite complex, my recommendation is to decide on one timezone being the authoritative timezone

– The algorithm for resolution could be optimised

– The representation of the terms and conditions artefacts in the back-end could be moved to a databased

– The date parameter is a weak point and the parameter handling could also be improved, at the same time, we expect to label the URL, resulting in a query, with a dateformat we already know

The prototype even holds a bonus feature, due to the way the central algorithm works, you can actually add an asset in advance. It will not be served as the current revision of the terms and conditions until it’s startdate is passed. This means that nobody has to work on New Year’s Eve to publish the new revision of the terms and conditions for availability on the 1st. of January.

These can of course be retrieved based on the revision. Handling of this could be implemented, but I actually consider this as a good thing, since it means that you can test the application, without jumping too many hoops.

I have never worked much with prototypes on a larger scale before, but using my boring stack, it was actually quite fast to get something to work, it would shed light on interesting aspects of the UX and the internal implementation, like the main algorithm and finally it provided a proof of concept, which could spark new ideas.

Becoming a product manager is hard, but it does not necessarily mean that you have to be removed from coding. Prototyping is a lot of fun and it is most certainly not the last time I have approached a problem area in this way.

*1 titles changes can backfire and ever since I changed my title on Linkedin I have received a lot of Product Manager related stuff