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:
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.
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 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:
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.
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.
Defining a Digital Product
25 Mar 2014