I see this issue popping up ever so often with startups I either work with/for or advise (nowadays) and it’s a valid one and I’ve encountered it often enough that I feel it deserves at least a blog post from me. (Realistically, I can see this growing into a series as there are a lot of corner cases and occasionally multiple facets to it, but for now I have to put a stake in the ground and this first post is it.)
The challenge is this: I have an idea, and I get some funding to put together a working prototype which gains traction and attention from VC’s — enough to get you some investment so you can take this to the next level. And this is where one of the challenges arises: you now hire a proper engineering team which can build your “web 2.0” web-based product. Since you are going to grow big and “10X” you hire a marketing team to push you in front of a lot of more customers.
The engineering team wants to build the product make it better and faster and everything else you want too! The marketing team wants to put out there press releases, news flashes about your milestones being hit (1,000,000 active users / day ? woohoo) and your rockstar hiring and your new offices being opened and design some landing pages to attract leads and then push those leads into their CRM and marketing automation tools and transform those leads into customers, they want a website which can allow them to control the whole marketing funnel and make use of it to generate you more customers — all things you want too!
So you might think: fair enough, I’ll get engineering to spend a part of their efforts to build these tools for marketing. Don’t! Unless you are Uber or Netflix or Amazon or any of the big giants, do NOT spend your engineering efforts at this point in building this component of your website to support your marketing efforts! You will find out that marketing needs to move fast, and their requirements are complex and they change them occasionally (nothing is set in stone, right? and one major advantage as a startup is you CAN afford to change your mind, pivot, try new things). Also the scope of their requirements expand as the marketing strategy develops and grows or changes direction at times — a website like this is a living product on its own and as such it has its own lifecycle. Committing engineering resources into this is costly — and as I said, unless you have resources to spend on this I would advise against it.
However, do not misunderstand me: I am NOT advocating for not supporting your marketing efforts with engineering resources necessary! On the contrary! I am advocating against building in-house a tool for your marketing team. Let me explain:
The moment this sort of situation arrives, both teams (engineering and marketing) tend to think upon the lines above: we’ll have engineering build what we need. Since both teams (in most cases) agree on this, this quickly turns into a plan and teams start executing on it — and in doing so exhausting your engineering resources (which, in a startup, tend to be lean and tight), which will derail you pretty soon from developing the actual product you set to develop. This leads to frustration on both sides — and more often than not creates a big rift in between engineering and marketing. And from there on you have the 2 teams which were meant to help you shape your product and take it to a new level trying to score point against each other and dragging themselves into a stale-mate. There be dragons from there on 🙂
The truth is they are both wrong in agreeing on the above! What marketing needs is a NOT that your product integrates all of their marketing needs, but instead they need a part of your website they can control fully — so they can iterate in their marketing strategy, produce and release content as and when they want and so on; and be able to do all of this ideally without interaction with the engineering team (which again is lengthy and costly at this stage in your startup life). And if you read that phrase again, that means that rather than building all of their requirements into your product at this stage you can settle for implementing an off-the-shelf CMS and hand it over to them.
This is how this would work: let’s say you are running our product at http://liviutudor.com. Your marketing team will tell you this is the front page people arrive at when they are looking for you. And as such they should take control of it and do all the marketing magic a good marketing team can do to keep your user interested and engaged. And you agree. (You’d be silly not to!) But rather than decide based on this to build this into your product, offer them a server running a CMS system which manages the domain http://liviutudor.com. A typical choice here is WordPress, which really nowadays is more correctly described as a “web OS”.
You then go and instruct your engineering to build your product and deploy it under http://app.liviutudor.com — this is a subdomain of your main domain (liviutudor.com), but now because you made that separation it can leave on its own, separated from the main liviutudor.com. This means now that the choices for technology and platform for these 2 components are independent of each other! A common misconception I have encountered is that because my marketing part is now WordPress, therefore written in PHP, my main product / app has to be PHP based too — and in fact a lot of times it is this misconception that causes the engineering team to reject WordPress or other platforms written in other languages than the one used for the main product. Even more, quite often it is the also the reason for choosing a CMS for marketing: “we write our product in Python therefore we need to use Django or a Python-based CMS”. Both of these approaches are wrong!
If you separate the marketing web space and your app/website then you can work independently of each other and you can choose different platforms for each one of them (I mean “platform” in the broadest sense here: OS + database + backend and front end and everything else in between). All that is require is that your marketing web space has clear paths of directing the user to your actual app — and it will: that’s what the marketing team is there for!
“But, if I have my marketing CMS deployed in WordPress, don’t have I have to use the WordPress theme files in my product? And doesn’t that mean then I have to write my product in PHP — since WordPress is PHP-written?” “NO” is the answer — to both of those questions 🙂 There are 2 ways to deal with the look of your product website:
- you make it look identical to the wordpress site, pixel to pixel
- you don’t make it identical but you maintain the brand consistency
For the former option, you don’t need to write your product in PHP and copy over the theme files — instead your product has to generate the same HTML as the theme! And it’s very easy to “decompose” a WordPress theme — it has a certain structure (header, footer, navbars etc) and for a lot of those you can pretty much copy over the actual generated HTML; for the dynamic parts you just transfer over the html part into your server side product code such that it ends up generating similar HTML structure.
There are very few instances where you have to have your product to be a pixel-perfect copy of the marketing wordpress site. But if you have to go down that route bear in mind that this is no different to the exercise you would normally go through to define your product website UI/UX, where you would have your designers and front end techies coding this up. The only difference is that rather than coming up with a new UI you now have a working copy of it in the marketing site and you just copy that. It’s a misconception to think that the look and feel of the marketing site is changing often — it’s not! Once the brand guidelines have been establish those are going to change very rarely, which means that once you implement the marketing site look and feel into your product you won’t have to change that side of it until the company goes through a rebranding!
The latter option is more common and relies not on copying the design of the marketing website pixel by pixel but instead on using a set of branding guidelines which ensure consistency of the brand across any website you might be deploying. These branding guidelines will be typically set up by your marketing folks and consist of a set of rules which help represent your brand best — for instance:
- we always use font XYZ
- text will always been dark blue on light grey
- logo is this and will always be placed on the top right hand side
- headings will be using this font and this color with double underlines and this icon next to it
This basically ensures that your brand message is uniform across all media (print, web, mobile etc) and across all websites — so you just have to follow these rules (think of them as a “generic CSS”) and design the UI/UX of your product as you normally would but just apply these rules. This would ensure a consistent user visual across all your websites.
For instance, think of all the Google products you use: the search engine, gmail, google+, DoubleClick suite of products maybe? The list can go on. Each one of these products has its own interface and user experience, but the logo, the buttons, the way the buttons interact with the user is always consistent — they look and act the same so the user experience is uniform across Google products. This refers to exactly that — and as you can see it allows you to build your product UI with very few limited constraints.
I feel like there are a lot more questions I typically see around this that I have missed but hopefully this serves as a good starting point and I will come back with following posts when I have more on this.