Templatization — What it is and Why it Works

Heard about technical debt? Here I am going to talk about a very specific kind of technical debt, and its solution in something I call Templatization.

This is what Google gives you on the query ‘Templatize’:

Let’s understand more with an example of this website you are on — Medium.com. Every blog post written on medium has a separate webpage and each of these web pages have the same header and footer of the page which runs across the website, right?

If you’re a techie and you’ve come across different website frameworks across any programming language, they give you a very basic feature of defining the header of your website into a separate file (viz., header.php) and footer into a separate file (viz., footer.php). Now whatever code you write in header and footer files reflects on all the pages of your website as common header and footer (of course limited by the span of these files, what you’ve defined).

So basically what the writers of framework did was they took out common elements out of a page and put them in a separate file so that managing a website becomes a lot more easier. You want to change text of a link in Header? Fine, just do it once and it reflects on all pages.

This is the first level of templatization which we are all aware of. Now let’s expand this concept further.

An organization might own multiple similar websites (Properties, as they call it), each spanning across more than one channels — web, app, mobile web etc. You could assume cases in point to be News — content based organizations or companies which manage online presence of their clients and build a lot of websites in bulk.

Suppose in such a typical org, the product portfolio consists of the following:

So Property 2 is let’s say an Indic News property, which has a website, a mobile site and a mobile app (3 product channels)

Now the target user persona consuming news might be the same or different across these properties. Let’s assume that it’s more or less the same, for this particular example. Let’s also assume that structure / information architecture on one channel does not change across properties.

Problems

In the above case, you have 4*3 = 6 different products to manage. You might conventionally allocate each product with a development team and possibly a Product Manager to own that product and a QA to test it (shared or dedicated people, depending upon requirement) — which is how it looks like in a majority of such orgs.

Now there are certain glaring problems with managing this kind of a product portfolio in the conventional way as mentioned above:

1. As you can see, the more the number of properties, the more is the effort which goes in and your team grows bigger and bigger; with your codebase becoming more and more extensive whose manageability going south due to inverse proportionality relationship.
2. If launching new properties and new sections within those properties were a priority for business as a major way to meet KPIs (basically throwing more content to users, as is the general alignment of conviction in content-focused orgs), team’s major bandwidth would be getting pumped into new product development rather than going deeper into existing products to generate traction / improve vital KPIs, generally by following a rapid experimentation + testing process. Ideally:

Tradeoffs with having more number of properties

3. If you go deeper into one particular product (say, mobile web of Property 1), generate learnings and are able to enhance KPIs, it requires a separate effort and time to replicate those learnings onto other Properties and depends on bandwidth availability of the respective teams + respective alignment of Product Managers. Also, you might not be able to drive it this way as other properties might be generating learnings from respective effort and cross-pollination of such optimizations might become too hard post a certain limit.

Solution

So what we are saying is that (as an example), we have medium.com as one website and if we want to launch xyz.com as a new website with mostly the same features offered by medium.com, we configure xyz.com on the same template as medium.com. This template now starts powering both xyz.com and medium.com.

So effectively we build a codebase and run all the different properties through that single codebase. Which would mean that you’d have the same front end UI for all of the properties. You could always introduce some customization like changing colors or rendering property-specific elements by putting up conditions but remember that a lot of that would defeat the purpose.

A good example can be:

1. Maharashtratimes
2. Samayam Tamil
3. I Am Gujarat
4. Vijay Karnataka
5. Samayam Telugu
6. Ei Samay
7. Samayam Malayalam
8. NavBharat Times

Look at the above properties closely, you’ll realize that all of them carry the same design — all belong to one prominent news group in India and collectively represent their multilingual news disbursement effort. Some colours might be different and some ad units might be placed differently over some of these properties, but they are being run from the same template. Of course, editorial teams which punch in data in these websites are different for each property and input data from a comprehensive CMS designed to support the giant templatized structure.

So now in this kind of a system, you’d basically have just 3 templates:

1. Web Template
2. Mobile Template
3. App Template

Now how’s a template different from a normal website:

1. It runs on feeds - more like a mobile app than a website
2. Content Management System at the backend runs a bit differently — has a similar templatized structure wherein different editorial teams see the same UI but data they enter goes on to reflect on their corresponding properties using IAM (Identity & Access Mgmt).
3. In case of template for a Mobile App, just compiling of the code happens separately (wherein property-specific variables are passed for corresponding compilation), before pushing it to the app store.

Here’s how the architecture would look like, for a system with 3 properties:

Templated Architecture, depicted through a DFD

Benefits

Now what this does is:

1. GTM of experiments goes down to a fraction. Continuous experimentation is a must in such B2C orgs to optimize on traffic, conversions, CTR etc. and so rapid experimentation means a huge advantage.
2. Time to roll out the successful experiments onto the whole product portfolio (across all properties) goes down to a fraction.
3. Instead of optimizing every channel of a property separately, if you closely observe, now you are doing optimizations at a template level. Basically you reduce the number of products from 12 to just 3, giving you direct economies of scale.
4. Launching new properties now happens in a jiffy.
5. Now having more properties is no disadvantage. Add any number of properties (given you have the required bandwidth to create content) without affecting manageability and the extent of optimization.
6. Huge bandwidth optimization happens for your team. Basically now you need (hypothetically) one Product Manager for each template and just three dedicated teams to run the whole show. Easy, right? Also, this would free up the team’s bandwidth who had been launching new properties previously. The bandwidth you just freed up could now be utilized on optimization stuff — SEO, SMO, User Research, A/B testing — I could go on and on with this.

What this further means is that the number of successful experiments (if we keep x% as the success rate all the time) also rise in absolute number ! Now mind you that the time required to roll these experiments out on the whole product has crashed. What all this would mean is:

Ideate -> Hypothesize -> Build -> Measure -> Validate -> Tweak -> Rollout on whole product

The above cycle could invariably go on a hyperdrive!

What we effectively did above was to sort tech out so that growth could take over. Having implemented this in 3 different orgs, I believe this is a great lever for moving needles in such orgs.

And believe me every software org has some or the other application for the above. For example, a single page SAAS app is also a templatized version of a desktop software spanning across hundreds of screens. Can you think of more applications? Do comment below and let me know. Thanks for reading!