Defining a Digital Product

A static site usually consists of a number of pages, which might have a CMS to allow you to edit content and make new pages. Each page is essentially static - each visitor gets the same content. Sure, there might be some multivariate testing running over the top so some visitors get different messages, but the core experience is the same.

A Digital Product is different in a number of ways. First, they provide utility to the user - to store information, learn new things, or interact with others. Second, the pages tend to be fairly dynamic, customising the experience and content based on that user. To give an example:

• Facebook - all members log in and get the same page. But that page changes radically between members depending on who their friends are and what they’ve done.
• 12WBT - all members get delicious recipes. But the recipe I see as a female wanting to lose weight will be different to the one you might see as a male on a strength program. Your weekly nutrition and exercise plan is completely different, as is your shopping list, the videos you see, etc.

A static site can be relatively straightforward to build, with a wide variety of tools available ranging from popular ones like Wordpress or Drupal, through to more enterprise options like Sitecore or Adobe CQ.

Digital product development is generally more involved, due to higher technical complexity. The focus is more on the user experience and providing that utility. Technical problems like caching and site speed become trickier - speeding up a static site is generally pretty straightforward, but a page that is different for each user is an entirely different challenge.

In creating Digital Products, we tend to focus on “features”. These features are things people can do - a simple feature might be to upload their profile picture, while a more complex one might be an ability to customise their meal plans on 12WBT.

Each feature takes planning and effort to create. Some of these features need to be in the first release - the Minimum Viable Product (MVP). Others can be released once the product is live. We use a Product Road Map approach to map out which of these features need to be created when, how they are going to interact or build on each other, and when they’ll be released. Typically we would plan to release new features each week or so.

Why bother with giving our users all these features and functionality?

One option is to create a big static site, and try to fill that with lots of interesting content. And that is a great solution for in some/many instances. But there are several reasons to go further and develop a Digital Product instead:

• The web site is the Product. This is what you’re selling (even if you’re not charging members for it). If this experience isn’t compelling, engaging and of interest, you probably won’t get many members. And you’ll need strong features to do that. Depending on marketing efforts you may well get lots of visitors, but if you want them to hang around you may need to provide that elusive utility.
• Make your users love you - useful features will increase utility provided to users. Which they’ll love, and will increase both word of mouth recommendation and retention - they’ll be more likely to come back.
• Barrier to competition - if you’re considering investing time and effort to build a site, consider how easy or hard it would be for someone else to see your idea and do exactly the same. Tools like Wordpress are free and can be set up in minutes. Creating lots of really sticky features takes time to plan and build.
• Scale: with a static site, the pathway to growth is to just keep on adding more pages. But say you have twice as many pages, are you actually providing twice as much value? Moving to a Digital Product approach creates pathways to scale and growth. For example you might want to start doing more advanced member segmentation or split up your idea into different types or levels of program.

Why not just build it in Wordpress?

The advantage of tools like Wordpress (and there are others like Drupal, Joomla and Expression Engine) is that they allow a site to be built relatively quickly with key functionality already in place:

• creating and editing page content
• publishing videos
• log in for members
• payment system to become a member

Building these sites also doesn’t require a particularly high level of technical expertise.

It isn’t that a large site can’t be built in Wordpress- there are several examples of quite large sites that run WPress. The issue is more around when it comes to start adding additional functionality - complexity of development suddenly kicks up steeply. Ironically, there are lots of “plugins” available for WPress that make it seem like you could add pretty much anything. And you can- just not at the same time. The issue is these don’t all play nicely together- so the forum plugin might break the SEO plugin, and cause the payment system to stop working. Something that should take a day might take a week due to this spaghetti style complexity.

Can I just build something simple now and then add later?

Certainly starting bare bones is a good approach - following the MVP approach your first iteration should be only what is required to engage users and get them to join.

However, the path you take at the start will influence your technology choice. If you build a simple static site now, it isn’t really something that can be built on to create a digital product.

To use a building analogy, you could build something using simple tools like Wordpress, Drupal etc and that is fast to create and relatively low cost - a bit like a prefab kit home. Relatively cheap and quick to set up. And yes, you’ll get a one storey house. But if your plan is to build a multistorey building or a stadium on top of that, it just ends up getting in the way.