Just-Eat spectrum-bottom spectrum-top facebook google-plus instagram linkedIn pinterest reddit rss twitter_like twitter_reply twitter_share twitter_veriviedtwitter vimeo whatsapp youtube error_filled error file info-filled info loading star tick arrow arrowLeft arrowRight close download minus-filled minus move play plus-filled plus searchIcon settings

Tag : product management

281 views

Product management in country improvements

Product management can be a difficult role to define. Most companies have a slightly different view of what a product manager should do, and so the definition (and even job title) of a product manager will often vary between organisations. It is also the case that within the same organisation different areas of the business can evolve their product management positions in different ways, as is the way at JUST EAT. And this is fine, as product managers are typically people who are willing and able to adapt themselves to the needs of the team(s) they work with and the products they manage.

Technology at JUST EAT is split into eight core areas, one of which is International Product Development (IPD), which I work in. Each area has their own focus and each have evolved independently in terms of their requirements of product management. However, we’re all working towards a common goal – to build a JUST EAT experience for consumers and restaurant partners that delivers against our mission to “Empower consumers to love their takeaway experience” and supports our restaurants to become as successful as possible.

So what’s working as a product manager in JUST EAT like? As product manager of the International Advanced Market (IAM) team it’s my responsibility to ensure the team is supporting the group of advanced market countries (Denmark, Norway, Ireland, Belgium, Netherlands), together with my team’s technology manager. The support my team provides is underpinned by our mission statement:

IAM_mission_statement

All this sounds very nice, but what does it mean in practical terms? On a day-to-day basis my job as a product manager can be broken down into the following areas:

  • Supporting the team
  • Partnering with the countries
  • Looking to the future
  • Personal development

Supporting the team

This is what I would call fundamental product management. It’s the core task of requirement definition (in whatever form it takes) and prioritisation. In the IAM team we use the Scrum framework for development and this covers user story creation, backlog grooming, sprint planning and representing the user. It’s a privileged position, working between my colleagues in Tech (engineering, UX, QA), Business Intelligence and the teams in the countries, bringing together lots of different skills to create an awesome product.

IAM_PM_post

With such a fast-paced environment at JUST EAT this aspect of the job is very demanding, but with such highly skilled people across all of Tech this is also extremely rewarding, and continually delivering tangible improvements gives me the drive to keep on pushing the bar even higher.

Partnering with the countries

Each of our businesses around the world are run independently, managed by local teams who understand their market and drive success. With all product development resource based in the UK and Kiev it’s critical that we stay closely aligned to their businesses and understand what’s happening in their local markets. We have regular calls with the country teams and collaborate on requirements and prioritisation (see my previous blog post – Tools for International Communication to Manage Technical Change), share market research and data analysis as well as experimenting with changes to the site/apps to see what works for users in different countries.

The remit of the team I work for requires additional responsibility of understanding and representing the countries I support. With so many teams across Tech delivering changes at breakneck speeds, I get called upon to ensure country specific requirements and nuances are not lost in the continual improvement happening across the platform. It’s an immensely satisfying part my job and comes with added benefits of regular travel to visit the country teams.

Looking to the future

It’s easy to fall into a trap of only focusing on what you have in front of you, fire-fighting today’s issues while forgetting you need to be planning what comes next. There are times when this might be the correct move but you need to be conscious of it and take action.  JUST EAT plan on a quarterly basis using the OKR methodology (we’ve even built our own tool for managing them – Managing OKRs at JUST EAT tech with our own web app) and so it is paramount that the product managers maintain that roadmap and vision for what comes next – not just the following quarter but for the next year or more. Of course your plans change, that’s the great thing about working in such an agile company, but having that draft plan to start with is key to figuring out what’s changing in the marketplace and how you should react.

We’ve adopted some of the templates created by Roman Pichler and adapted them for our own requirements – for anyone looking to instill some structure into their planning for agile teams this is a great place to start. We’re continually developing our templates and have established a great framework within IPD for planning and communicating our vision for the future.

Personal development

Personal development is a big deal at JUST EAT, and all employees are supported to create and maintain a personal development plan to achieve their career aspirations. The document leads with the question “Where do you want to get to?” and helps you create a plan to get there. This is backed up with personal OKRs and a training budget of £1,000 each year to spend on the resources you need to support your development plan. It’s great to work somewhere that values people development so highly, and backs that up by empowering you to take true control of it.

In summary

JUST EAT is a fantastic place for product managers – there is so much energy and enthusiasm, a ton of exciting work happening across the company, and it’s immensely satisfying to be working for a company that truly understands what product management is all about.

324 views

The road to responsive web

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.  

Screen Shot 2015-11-25 at 10.34.35

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

379 views

Tools for International Communication to Manage Technical Change

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 legacy to responsive 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 provided the country with a more user friendly and useful page, showing the status of platform improvements.

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.