Experience Report Part 2: Types of Project

Following my previous experience report, it strikes me that there are mainly four types of project that we engage in. This is looking at product management but sparked from thoughts around involving the UX team more.

Recap – the Product Process

To explain the squiggles in the diagrams below, here’s the full version of the Product Management process that Chris Matts and I arrived at:

The Product Management process
The Product Management process

Starting with insights we note the hypothesised user needs, target audience and business outcomes. As these are hypotheses, we ensure that our concepts will test the hypotheses (rather than simply testing designs). This part is the Vision Board element.

Having created prototypes, acceptance criteria and stories, we validate these designs. Firstly with the team, to check that that we are still coherent with our hypotheses. Then usability to kill bad ideas (groupthink). And then having built the concepts, we go into MVT to validate our design concepts (hypotheses).

New Projects

At some point, a product is a new greenfield projects. Here we build a brand new Thing, which hopefully means that we’re testing a hypothesis rather than building a specific feature.

In the world of websites, this means that we perform a detailed discovery on those pieces that make a difference, where we will use our competitive advantage. And we should steal use established industry practice on the non-core elements.

The diagram below highlights this:

New projects. Build the minimum thing with the minimum effort
New projects. Build the minimum thing with the minimum effort

Migrated Projects – Type 1

Of course, websites and products don’t remain new for long. If not looked after, the infrastructure languishes until Somebody decides that it must be replaced. By this point, things are usually pretty crufty so organisations like to update the lot (especially if Somebody gets to put in their favourite technology). In this situation, a decision is taken to upgrade the back-end and the front-end too.

Migrating from one site to another
Migrating from one site to another

So the old site is maintained while a new site is created. At some point the customers cross over and we’re all happy.

Except that, as I mentioned last time, this approach builds up a lot of risk. Will we ever deliver? What if we’ve not fulfilled a critical user journey? What if the new infrastructure doesn’t hold up or if the new UI isn’t well received? Sure we tested it but…

Migrated Projects – Type 2

There is another way. The migration can take place as a planned Strangler application. In this situation the migration is prioritised by risk and is done gradually. Thus we only ever run a single system, rather than attempting to build a duplicate and migrate users over. User journeys are upgraded as they fit with product infrastructure.

Migrating a Site by Feature
Phased site migration

Do we migrate every system? Possibly not; when the risk profile is lower than the business gains from upgrading the user experience we may choose to upgrade the user experience. Ultimately it comes down to how comfortable we are supporting the remaining infrastructure. Because we’re not changing everything at once we can defer the decision.

Continuous Improvement

Ultimately, we’d love to get to continuous improvement. In this world, technical upgrades are prioritised with the customer and business benefit so that a big-bang migration is typically unnecessary. Here, we assess concepts based on insights and we’re into pure product management.

Continually updated features and infrastructure
Continually updated features and infrastructure

Conclusion and Thoughts

In my experience, Continuous Improvement is a difficult place to get to and I’m unsure whether it’s fully achievable. Often it’s not a technology that causes a big-bang rollout but a new feature that fundamentally changes the business model (my previous company, Cheapflights, recently rolled out meta search on the UK site; this isn’t a feature that lends itself to feature-incremental rollout). However, if a migration is required there are certainly ways to deal with this; running one site while working on a rewrite appears to invite risk that can typically be avoided.

Again, I’d love to hear experience reports and other views on this. How does your organisation handle migrations? And how could they have been done better? These diagrams are also going to be flawed – please share your thinking on the categories of project.


Author: Stuff Rich Writes

Cyclist and Product Manager. I blog about both.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s