Evolving Web Projects Into Online Products

There's a difference between a software project and a product. I've been helping clients create innovative projects on the web for a long time. Lately, I've been responsible for evolving, or planning to evolve, several projects into online products. It's harder than you might think.

There are several reasons for this:

  1. A project is typically crafted to meet some set of specific and relatively narrow client requirements.

  2. Since the focus of a project is on meeting client requirements, project features generally are not designed with the flexibility to meet the more general needs of a wider audience.

  3. There's no client telling you what the requirements for the product are. You have to figure that out yourself.

There are several tactics to address these problems, which I helped apply to a real-life project. That project was an online video contest for the Department of State's Bureau of Educational and Cultural Affairs.

We structured the project in an unusual fashion. We threw two high-level architects on the project. The first was the team lead, Dave McVicar, whose responsibility was to ensure that we delivered a solution that 1) met the customer's requirements, and 2) made the customer happy (note that these two things are not the same).

The second architect was me, and my responsibility was to push wherever possible and feasible for a generalized solution that was as close as possible to a general-purpose product. The project solution thus gained a healthy push-pull dynamic between the two architects, with the team lead having the final say (his responsibility was the paying client, after all). This also worked well because McVicar and I were already friends and familiar with each other's capabilities; this was the third company we'd been at together.

The end result was a highly successful online video contest for the Department of State, which added more than 9000 members to their ExchangesConnect social network during the 2-month run of the contest. The contest site included the capability to run multiple contests (e.g. - separate annual contests), integration with Ning (a white label social network product used to host the Department of State's ExchangesConnect social network) and an Admin area with a rich set of reports and site moderation features.

The contest site wasn't completely generalized, but it was close. Through rigid adherence to the MVP principle, we were able to evolve the contest site into a generic contest platform called Votridea in three months.

Votridea, the Online Contest Platform

MVP stands for Minimum Viable Product, a phrase that we created to sum up our strategy for defining a new product. MVP requires that you concentrate on implementing only the bare minimum of features necessary to have a cohesive and functional product. You have to be ruthless to do this, because everybody will give you ideas about what the the product should be. Save the ideas for later consideration as feature enhancements, but prune them until you have only the core left.

These tactics helped us craft a high-quality solution for our client, the Department of State's Bureau of Educational and Cultural Affairs. Because we recognized the potential for a general product early on, these tactics also helped us create a solution, financed in large part by a client, that we were able to evolve into a viable online product in a short period of time. As another by-product of the online contest effort, I've now been asked to use these same tactics on a new project for another client.


David Keener By dkeener on Sunday, July 25, 2010 at 01:49 PM EST

Interestingly enough, we came up with idea of a Minimum Viable Product (MVP) independently, because it just seemed to mesh well with whole idea of agile software development. It turns out that the first known mention of this concept (according to Wikipedia) is actually credited to Eric Ries, in an online interview.

Leave a Comment

Comments are moderated and will not appear on the site until reviewed.

(not displayed)