For the past 20 years, I have either managed or consulted clients on website analytics. In the early days of web analytics, the websites I managed were little more than digital brochures and my job was to report on which content was the most or least popular. Next, I was asked to determine the effectiveness of digital advertising spend for paid search keywords or display advertisements. Later, I was asked to monitor the key paths visitors were taking and see how I could help drive more conversions. When experimentation became popular, part of my role was to identify possible things to test in hopes of improving the website in some way. As website technology changed, I spent more time capturing data around single-page website applications. Finally, I was brought into situations, where I was asked to capture data for multi-screen customer applications, such as credit card applications, complex ordering funnels, complex content approval processes and so on.
Taking a step back, it’s amazing to see how much websites have evolved since the early 2000’s when I began doing website analytics. Being on the data side, I have had a unique perspective into this evolution. As websites became more complex and more “app-like,” the data used to judge their success grew more complex as well. In the early days, it was common for organizations to have only a few metrics (e.g. visits, page views) and dimensions (e.g. page name, site section, URL) available for data collection. That’s why many website analytics vendors began with a small number of metrics and dimensions as part of their product. I can’t recall exactly the numbers, but I think that Omniture SiteCatalyst and Google Analytics originally came with 25 metrics and 25 dimensions. Those numbers have greatly expanded over the years.
As I recently moved from the website analytics world to the product analytics world, I have been learning a lot more about products and product development. I am fortunate that I get to work with John Cutler, who is one of the foremost product thought leaders. During some of our conversations, John has challenged me to think about why there is such a big difference between website analytics and product analytics. At a high level, website analytics has traditionally focused on websites only and, more specifically, the customer acquisition and content aspects of websites. While product analytics always existed and was used to improve applications via data, it was supercharged when mobile applications exploded onto the scene. The former was built for marketers and the latter for product developers.
But recently, John had me listen to this podcast discussion about what makes a product. My favorite part discusses the milkshake as a product (the canonical “Jobs to be Done” explanation pioneered by Clay Christiansen) and the functions that milkshakes serve. I encourage you to listen to the entire podcast, but suffice to say that it got me thinking more and more about what John and I had been discussing. Are websites products?
Are Websites Products?
If we think of products as things that are created to help users get a job done, then you could easily make the argument that websites are products. Organizations don’t build websites just to have websites or because they are bored. Most websites are built to help prospects or customers achieve some objective that previously had to be done in non-digital ways. For example, when the internet arrived, The Home Depot built a website to show its locations and operating hours of our stores, the types of products and services offered, and information about the company. Then came ecommerce, the ability to create an account, and now it’s the central place to sell products, engage customers, and differentiate from competition. The website has gift cards, subscriptions, DIY simulators and project calculators, service pro finders, order management, and so much more. But while The Home Depot website has products, its website was a digital product that they built in order to sell their physical products. Ironically, of all of the products involved in their business, the website was the only “product” that The Home Depot owned, since they were really just the middleman between the actual product creators and their customers. The products on their shelves were only owned by The Home Depot temporarily, but the website was a product owned in perpetuity.
Strangely, many organizations consider their mobile applications or software as a service (SaaS) to be “products,” but not their websites. In many cases, the objectives of the website are the same as the mobile app, so why would one be a product and the other not be? I think some of this stems from the fact that the marketing department has traditionally owned the website and a product development team has owned the mobile application.
But when I think about products, I think about the following types of questions:
- What are the product’s objectives?
- What flows are needed to get users to complete desired actions?
- Are there new features that can be added that can improve conversion or the experience?
- What can we do to increase user loyalty?
- How can we increase experimentation so we learn as fast as possible?
I think that all of these apply equally to both websites and mobile applications.
Product Mindset
What I do think is different about websites and products like mobile applications, is the overall mindset when it comes to development and improvement. Anyone who has been involved with product development (any software product or mobile app), knows that there is always a massive backlog of ideas, product feature requests, strategic objectives, etc. There is a constant demand to add new features and functionality to products. While we could debate whether adding so many new features is worthwhile, in my experience, I have not seen such pent up demand for improvement requests for websites. While it may be just what I have experienced, I have seen website development move at a glacial pace when compared to product applications. Whereas products might push a new version every two weeks, it is common for new updates to websites to be measured in quarters or years.
I am not sure why this is the case, but perhaps it is due to the fact that many websites are still managed by marketing vs. product and that marketing teams don’t have the same development mindset or methodologies as product teams. You may have experienced this when you engage with a brand that has a really great mobile app, but when you visit their website, it feels like it is a totally different experience and one that feels dated in comparison. But since the same customers will use both the website and mobile app, it makes sense for the both experiences to have the same functionality and feel.
This is why I think it is important for organizations to recognize that websites are products and consider a product mindset. Websites deserve the same rigor, features and experience as mobile apps (for a great example of this, click here). For some organizations, this may mean moving the management of the website to the product team, ideally the same team that is also responsible for the mobile app. For others, it may mean the creation of hybrid teams that include marketing and product resources.
Additionally, I have seen many organizations that are tracking data related to websites and mobile app products differently and even in different analytics products. This is not ideal since it creates unnecessary data silos based solely on the platform experience (website vs. mobile app). This means that the organization cannot easily view cross-platform visitor journeys or create segments of users that span actions from both platforms.
Questions to Ponder
So while much of the “Are websites products?” question can be dismissed as semantics, I will challenge you to think about the following:
- At your organization, is the same team responsible for the website and mobile app?
- At your organization, is the look and feel and functionality of the website and mobile app the same?
- At your organization, is the speed of iteration and improvement the same for the website and mobile app?
- At your organization, are you using one digital analytics product for both the website and mobile app?
If you answered “yes” to all of the above, then you are probably treating your website as a product. But if you answered “no” to any of the preceding questions, you may be missing out on opportunities to improve efficiencies and customer experiences by treating your website more like a product.
