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:
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).
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:
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.
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.
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.
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.
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.