Web Growth vs. Web Operations: Driving Leads & Revenue

How to differentiate web operations and web growth, responsibilities by team, and recommendations on how to approach team structure.

What is Web Operations (WebOps)?

Web operations teams are development/engineering groups concerned with the deployment, maintenance, and uptime of one or multiple public customer-facing websites. This is primarily an engineering/development team focused on ensuring website uptime and efficiency, triaging web sprints, prioritizing projects, and scaling web development processes while balancing internal requests, external resources (agencies and contractors), and a request/ticket backlog. 

What is Web Growth (aka Growth Hacking)?

Web growth, sometimes referred to as growth hacking (part of growth marketing) is primarily a marketing/sales function, focused on driving business metric growth via website analysis, website experimentation, and existing optimizing marketing technology (Martech). This usually includes analyzing/forecasting/growing website traffic, increasing conversion rates across the full marketing funnel with a dedicated CRO program, and optimizing marketing/sales lead handoff while consistently increasing website engagement (signups, content submissions, downloads, etc.)

Challenges Scaling Web Growth Within WebOps

One consistent pain point I’ve seen in high-growth SaaS companies is that often having an existing internal web operations team is not enough to fully optimize website performance for revenue. This often is phrased as "taking the website to the next level" or becoming "best in class" by executive teams. The core issues driving this are that the existing marketing website is underperforming against existing business goals, not growing as fast as competitors, or operating too slowly due to code debt and legacy processes.

Often leadership expects website growth (marketing/sales discipline) from a web operations team (engineering/web development discipline) when those teams' primary objectives and KPIs are not aligned against marketing goals. Not only are those teams goaled differently, but they often have different stakeholders or operate in completely different departments (when engineering teams own the website for example). At high digital maturity organizations, these teams may also compete for the same resources (in my experience, usually front-end development and design) which also contributes to an expectation that one team should be responsible for both these distinct disciplines.  

Competing Goals and KPIs

Common Responsibilities By Team: Web Operations vs. Web Growth

WebOps teams are primarily focused on website uptime and measure team efficiency by sprints, key projects (epics) completed and successfully triaging/executing web tickets while meaningfully chipping away at an ever-growing backlog of change requests. WebOps teams may appear understaffed or misaligned compared to organizational timeline expectations of website changes. Part of this is often a lack of visibility of how long projects may take to complete from start to finish. I've built or started WebOps teams in several organizations and they often lack a standardized web change management in tools like JIRA. The scope of web changes is often magnified with localization, marketing-specific CMS setups, and multi-device QA that is not reflected without a standardized project management tool and process. As WebOps teams mature they often face legacy code bases, redesigns/migrations, and competing internal prioritization across teams. 

In an enterprise SaaS environment, WebOps teams are often responsible for numerous web properties and sub-domains in addition to owning several corporate sites. As organizations scale, these teams have to balance requests from several competing departments such as partner marketing, event marketing, content marketing, and support/documentation teams. WebOps teams are also often balancing localization requests, code reviews, and internal QA while inheriting additional responsibilities such as maintaining customer portals or additional websites from acquisitions. 

When these teams are asked to take on marketing/sales functions like web growth they may treat these as individual tasks to be completed against a larger backlog, rather than treating these as initial stages of an iterative, strategic growth roadmap. In addition, these tasks are hard to prioritize against the required work to maintain/update the website properties themselves, as ultimately WebOps teams are often goaled against their velocity to execute web requests within a timely manner. 

Web Growth teams, by comparison, are primarily goal against quantitative business KPIs such as quarterly traffic growth, organic search ranking increases, paid media return, lead/form conversion rates, and sales pipeline/revenue results to demonstrate consistent business growth. These teams usually sit within the marketing organization and are closely aligned to sales, while WebOps is more closely aligned to engineering teams or pods.   

Web Growth Team Structure & Approaches

Outsourcing Web Growth To Third Parties

Outsourcing a Web Growth function to external contractors, agencies or consulting can work especially well for organizations with limited primary web properties or organizations that run lean WebOps teams (1-3 employees) that may sit in engineering teams. 

Third parties can bring specialized growth experience and successes from other industry verticals, which can help accelerate digital transformation while being highly incentivized to prove results as part of their contract.

On the other hand, companies that rely almost exclusively on their websites for revenue (ie. websites that generate 70%+ of sales pipeline) or target a sophisticated enterprise market or technical audiences are better off building in-house WebGrowth teams. As businesses scale internal knowledge of the sales process, market landscape, and competitors are critical to hit more aggressive website growth returns.  

Separating Web Operations and Web Growth with Shared Resources

In the long term, I advocate separating Web Growth and WebOps into their distinct functions across marketing and engineering/development respectively. In my experience, this scales the most efficiently, particularly for portfolio companies with many websites, multiple distinct sub-brands, and/or that aggressively focus on company acquisitions.

Companies with significant paid search spend that have to demonstrate increasing ROI or companies with mature freemium software cycles, eCommerce targets, and Enterprise sales motions are also better served with dedicated Web Growth teams. 

Prioritizing Web Growth Within Web Sprints 

I’ve worked at companies and also worked with clients that started prioritizing dedicated portions of each web sprint as measured by effort or points (ie. 20% -30%) for specific Web Growth initiatives. 

This works great in theory and can be promising early, but often doesn’t scale well as business needs as Web Operations expectations increase (ie. supporting acquisitions, building microsites, implementing/migrating new technology) as the organization matures. Eventually, these business requests take higher precedence which makes it difficult to consistently dedicate resources to Web Growth.