Tag : product development

The benefits of moving JUST EAT International sites to a responsive web design are pretty clear. In a nutshell, responsive web design means that if a user switches between viewing your website on a Mobile device to viewing on a Desktop, the website should automatically adapt to cater for the different resolution.  This is all achieved through things like CSS media queries and fluid grid layouts.  

Responsive Web – a ‘fluid’ design means your site should adapt for different resolutions and devices.

But, as well as the customer facing benefits, responsive web also provides efficiencies of scale from an engineering point of view – by moving to one common code base for all our international sites means we can develop features and enhancements more efficiently.  

That said, rolling out a completely new version of a JUST EAT website is bound to cause some sort of nervousness and its down to the International Product teams to manage this to ensure that the countries feel confident about the change and supported at every stage.

As the Product Manager in the team that has rolled out responsive web in Denmark and is in the process of getting the Canadian responsive website live, I thought it was worthwhile to share the experiences I’ve had and the steps taken to make sure the roll out of responsive web was a success.

Gap analysis
The starting point is to identify the features or requirements for the country. Whether it be sales tax in Canada or integration with a specific delivery service in Denmark, the earlier you identify the unique requirements up front, the earlier you can consider them as part of your scope.

Story development and prioritisation
With our scope defined, we followed the principles of grooming the stories with the team and prioritising the stories based on what was the minimum required in order to get a beta version of the site ready and in front of staff to place real orders.

Automating the testing as much as possible
We created our acceptance criteria in the ‘given, when, then’ format, so the acceptance criteria could help form the basis of our Gherkin based feature files. Together these become our Executable Specification. We implement the feature files in .NET using SpecFlow and Selenium WebDriver to automate functional testing and identify regression issues more efficiently. Having experienced working in development teams where testing wasn’t automated, it can’t be underestimated how much time and effort can be lost without automation.  

Stakeholder engagement
Once we’ve developed the responsive web version of the site that meets our MVP definition, we will demo the site to the country. These sessions are really positive as the countries can start to see the benefits that the new responsive website will give them.  

After the demo, we will then get the ‘green light’ to launch the site to a group of internal staff members, eg beta and running through the process of collecting feedback

Establishing a phased roll-out approach
Our approach typically takes four stages, beta, 10% of customers, then 50% and 100%. Beta, involves launching the responsive website to a set group of internal staff from the country team, where we set up a feedback form for the country to feedback issues they’ve faced, or general comments. Moving beyond beta through to 100% of customers, is largely based on how quickly we resolve defects identified during beta.

Daily triage and defect prioritisation calls
When it comes to the point of trying to move from 10% to 50% to 100%, I’ve found it particularly useful to run daily triage calls with the country to help establish a priortised view of the defects and, most importantly, an agreed accepted level of outstanding defects before going to 100%.  When you have this agreed target, it’s far easier to motivate everyone to reach that goal!

Analytics  
Once we’ve gone live with beta, we verify that conversion events are being successfully recorded, but we are also make sure that we set up our reporting dashboards in advance so we can report back to the country about how the responsive website is performing versus the legacy website in each step of the funnel. Being proactive with this type of analysis also helps when pushing from 10% to 50% to 100%.  

Efficient defect resolution
To ensure clarity and expected resolution for defects, I would discuss the detail of the issue with the country and replicate myself. Then, by detailing the current behaviour and expected behaviour of the issue, the dev team team were able to rattle through the prioritised defects and in the majority of cases resolve them first time. This quality output also helped to give the country team confidence that we would deliver against our promises and suggested ETAs.  

Based on our experience with Denmark, from the start of the development process through to going live to 100% of all customers has taken 6 to 8 weeks. When you sit back and think about it, 6 to 8 weeks to roll out a completely new version of a fully functioning website across desktop, mobile and tablet, that’s pretty cool huh?! #minifistpump

In 2015 we began a project to migrate countries running the legacy JUST EAT frontend application to a new platform – a change that delivers enhanced features such as responsive design, backed by a component based microservices architecture, opening up new doors to innovation for myself and other Product Managers to explore.

Migrating a country to the new platform gives users in that country a better JUST EAT experience and provides us with new tools to support the business of our restaurant partners. The flipside of such a change is that there is a new list of product enhancements for the team of software engineers I work with to deliver. Old development plans are thrown out the window, and feature requests are reconsidered based on changes in functionality and capability of the new platform.

The initial migration is handled by our Platform Improvement team, whose core remit is to ensure feature and performance parity between the new and old platforms. By the time the site lands in my team post-migration, all urgent problems will have been addressed and the key performance indicators of the site will be at, or exceeding, pre-migration levels. It then becomes my responsibility to work with my Technology Manager and software engineers to prioritise and resolve any outstanding issues, and build a roadmap for the future with the country teams to take advantage of the new platform.

Screenshots showing the improvement in the user interface delivered to JUST EAT customers through migration of a country from a legacy platform to a new responsive platform.

Following the successful migration we assess the processes that are in place, and look to shift them from a short-term tactical solution to build a longer term strategic partnership between country and technology team. This involves taking an active part in the relationship towards the end of the migration and building a relationship with all key stakeholders to ensure a smooth handover.

Effective visibility of progress

Typically during high pressure activities such as platform migrations, quick and easy tools such as shared spreadsheets are used to manage the project.  These are familiar to people and simple to edit, allowing everyone involved to send updates and responses easily and quickly.  However, over time spreadsheets and any documents not dynamically linked to the source information get out of date and become a chore for everyone involved to keep in sync. This eventually leads to people working from different versions of the “truth”.

To improve upon the use of shared documents,we replaced this with the use of a wiki page.  The JUST EAT wiki tool is Confluence, which is from the same suite as our development issue tracking tool, JIRA.  Based on saved filters in JIRA we pull in charts and tables with the information we need to discuss priorities and progress with country management.  Managing the filters in JIRA means that we can reuse them for different countries, and if an improvement is needed then this can be made across the board without having to update each country page individually.

The wiki provides the country with a more user-friendly experience, showing the up-to-date status of platform improvements.

This means that the country staff know the latest information about the progress of each ticket in one single place. No more need to copy and paste information to update spreadsheets, no more working from an old version of the truth and happier stakeholders due to increased visibility of platform improvements.

Staying in touch

During the migration, the team handling the work had daily calls with the country to work on defects and signing off changes. This is not a long term communication strategy and we have now transitioned to weekly calls (well, Google Hangouts actually) with an an agenda alternating between strategic and tactical each week. These have allowed us to keep on top of defect priority for the country and shift our focus on short term to longer term strategic development work.

In addition to weekly calls we’ve flown out to each country, visiting the JUST EAT offices and building relationships with the country management teams. The value of face-to-face meetings cannot be underestimated, and even in today’s global instant-messaging world, nothing beats physically meeting someone in person in order to build a strong relationship. And, to maintain these good relationships we aim to visit each of our countries at least once a quarter, to check-in and carry out quarterly reviews and perform high-level planning – covering those topics that aren’t quite as easy while talking with slightly raised voices (as you’re never quite sure if they can hear you clearly) into a “Chromebox for meetings”.

Looking to the future

We’re never quite sure what the future will bring; we can try to predict what will happen and sometimes we’re right, sometimes wrong. But whatever it brings, it’s crucial for us in IPD to maintain strong relationships with our countries. We will continue to look for tools and process improvements to make international collaboration easier and to make our colleagues feel more involved in product development wherever they are. Ultimately, with all of this, our aim is to make sure that our colleagues around the world are kept well informed and most importantly confident that we’re supporting them and their business.