Develop Zomato Features using Agile Methodology

Introduction

Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.

Agile way of Product development

Zomato is the top aggregator of restaurants in India. Zomato allows user to search, browse and discover restaurants in their locality. It also helps them see the menu, assess their credibility and check similar options in the vicinity. It is a one stop solution for anyone’s restaurant selection process in India.

In this article, we discuss briefly about the Agile Methodology as well as it’s incorporation in the release of few vital features at Zomato.

We shall be addressing three key features in this post:

  1. Rating and Reviews
  2. Filter for Search
  3. Online Ordering

This is a direct attempt at utilising Agile as a framework for prioritising and scheduling the development plan for the aforementioned features.

Agile-An overview

Agile breaks down larger projects into small, manageable chunks called iterations. At the end of each iteration (which generally takes place over a consistent time interval) something of value is produced. The product produced during each iteration should be able to be put into the world to gain feedback from users or stakeholders.

As made popular by the “Agile Manifesto”, agile values:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to a change over following a plan

Agile realizes that software (and marketing) projects are inherently unpredictable. Over the course of any project there are likely to be changes. Be it market changes or feature changes as the product comes to life. Agile embraces this unpredictability. By breaking down projects into small chunks, it makes it easy to prioritize and add or drop features mid project. Something that is impossible in traditional waterfall projects.

Scrum, like all of the agile processes, is both iterative and incremental. They are iterative in that they plan for the work of one iteration to be improved upon in subsequent iterations. They are incremental because completed work is delivered throughout the project.

Scrum is Agile but Agile is not Scrum.

Just as all Fords are vehicles but not all vehicles are Fords. Scrum is Agile but Agile is not Scrum. Scrum is something that, when used properly, is Agile. It allows for constant, short feedback cycles. It allows for continuous improvement. It gives transparency to the people who need it. Agile allows for more. Agile allows the framework to change as needed to best deliver value to the customer. Agile allows people to be placed in front of defined roles.

“If we have a fully defined backlog, we no longer have a true Agile Product Development situation. Instead, we have a project”

- Ron Jeffries

How Scrum Works?
Sprint Model

Salient aspects of the framework in the context of mentioned features

  1. The above features of Zomato are not implemented yet
  2. The Agile team would be composed of 6–7 members
  3. Sprint time would be defaulted at 2 weeks
  4. We will bracket the above features as Themes, and develop epic/user stories for the finer aspects of each of the features/Themes
  5. Product Backlog would populated with the, thus developed, user stories. These User stories could be, if required, sliced down later
  6. Product Backlog prioritization would favour User Stories that have a High Impact to Effort ratio i.e. stories that would create greatest impact, but need least effort to develop

Rate/Review Restaurant

Arestaurant’s chances of converting browsing users on Zomato, into a customer who dines with them rests heavily on social validation. Reviews & Ratings help the restaurant exhibit this. It also serves as transparent metric of credibility. Rating and Reviewing are two independent aspects that plug into the gross user experience & create value for both the user & restaurants simultaneously.

High Impact Feature

Ideation:

Ratings are voluntary actions by users/diners, and the gross accumulation of ratings as a metric would also serve the users directly. Additionally Reviews would also be voluntary and be deployed as individual items on the restaurant detail page. ‘Most recent’ would be the default sorting for the reviews displayed.

Product increments desired:

  1. Each restaurant quick view card, should have three new attributes: Average Ratings score
    Total ratings till date 
    Total reviews till date
  2. Each restaurant quick view card to have an option to add a quick rating and review
  3. Option to add Rating & Reviews on Restaurant Details Page
  4. Ability to add images and videos in Review
  5. Option to edit review & rating

Design:

  1. Restaurant Cards should have clear CTAs to ask user to Rate & Review, mutually exclusive.
  2. If reviewed/rated already, CTA should imply option to edit.
  3. CTAs action should yield a Popup
  4. Rating Popup should be simple: greyed out stars, and a final CTA of ‘Confirm’
  5. Review popup should be a simple text editor, allowing line breaks, bullets, bold, italics — followed by a Confirm CTA.
  6. Reviews should have a Title bar to add title for review
  7. All Ratings would be displayed in Most Recent sort fashion, on the restaurant detail page
  8. Adding images & videos should be intuitive with a Drag & Drop acceptance for upload

Testing:

Unit testing of components would lie within the scope of development teams. Tests mentioned below are indicative to user adoption & acceptance.

Below hypothesis for each Theme is a direct validation of feature adoption by users. Our metrics would be aimed analyzing and assessing the same.

Ratings:

  1. Ratings drive more time spent on restaurant detail pages.
  2. More users convert into diners at restaurants which have good ratings.
  3. Rate requests for restaurants yield >30% conversions in ratings posted for restaurants.

Reviews:

  1. Reviews compliment Ratings, leading to even more time spent on restaurant detail pages, compared to Ratings alone.
  2. More users convert into diners at restaurants which have good ratings and credible reviews.
  3. Review requests for restaurants yield >10% conversions in reviews posted for restaurants.

Implementation & Deployment:

Prioritized on estimated Impact to Effort ratio, we are considering that launching Reviews and Ratings together would be a boisterous effort.

We want to minimize wastage of human capital.

Hence, we launch Ratings first, and followed by its success — we launch Reviews too. That way we keep it iterative & incremental — thereby ensuring the team does not wast effort on features whose precursors are not favourable.

Filters for Search

Adding filters to the search bar and its results would yield to an improvement in the relevance of results for the end users. They can consequently drill down, sort and filter out the less relevant results populated by the generic search.

High Impact Feature

Ideation:

Filters would be an increment upon the existing search page. Filters should be searchable and must have a quick action button associated against each filter. Filters can be categorized as:

  1. Cuisines
  2. Area Range (comparative to current location fed)
  3. Open/Close timings
  4. Cost (incremental — extrapolate from ‘Cost for Two’ data per restaurant)
  5. Average Rating score and # of Ratings
  6. # of Reviews

Additionally, ability to save a search — along with the filters added, is another desired feature.

Design:

A panel dedicated to filters would be aligned to the left flank of the search page. A tiny search bar on the Filter panel would help you find filters quickly.

Filters would be subjectively designed, in parlance to filter type. For ranges, a slider is desired. For absolute filters (like cuisine, etc.) a checkbox against each option should suffice.

Testing:

Unit testing of components would lie within the scope of development teams. Tests mentioned below are indicative to user adoption & acceptance

Below hypothesis for each Theme is a direct validation of feature adoption by users. Our metrics would be aimed analyzing and assessing the same.

  1. >30% users have used search at least once
  2. Average filters applied per search session is greater than 0.5, implying there are a good bunch of users who rely on filters for optimizing search
  3. >50% of users using filters are choosing Ratings &/or Reviews as one of the filter options

Implementation & Deployment:

In line with the implementation of Ratings, the deployment of filters would go ahead with:

  1. Cuisine (checkboxes)
  2. Ratings (range — on count & avg. rating score)
  3. Area Range (range)

The success of the above three would pave the path for the others:

  1. Open/Close timings
  2. Cost (incremental — extrapolate from ‘Cost for Two’ data per restaurant)
  3. # of Reviews

The above manner of cascading 3 filters only as part of the initial sprint is based upon testing the user adoption against each filter & its functionality type (i.e. checkbox, range). The success of the 1st set of filters would validate the choice of UI against each filter.

In case, a particular filter (say, Ratings) does not find great adoption — one iteration with a change in the UI type (say, a drop down) for the filter could be experimented to ascertain if the UI on the filter was a cause of redaction or the filter itself had no merit.

Additionally, Ratings as a feature can derive more validation and a complimentary avenue of testing. The success of Ratings being chosen as a filter would help make a better case for prioritizing the Reviews feature as part of next sprint — while invigorating the spirits of the team.

Online Ordering

Success with curating and bench-marking restaurants is almost a mammoth feat in itself. Dominating the space unilaterally, calls for utilizing the advantage appropriately too. Online ordering is simply the most obvious channel to unlock new revenue streams.

However, this is one segment that could take a while to deliver the pink cowswe’d expect. Operations aligning with online bookings is a challenge in itself. While impact of this feature is humongous in the long run, the setup effort will stretch and test any well settled organisation.

Medium Impact feature

Ideation:

Expectation is enable quick order options on the restaurant quick detail card and restaurant full details page. The action on these cards would ideally launch a popup with menu options to order from and add/edit quantities. A quick address update should be a priority too.

A dedicated landing page for online ordering enabled/supported restaurants, to minimize clutter with dine-in only restaurants — would be an essential factor.

Order Online Product Increments:

  1. Order pane — each restaurant’s Order Online CTA should lead to a order pane that shows menu with easy add/edit of items.
  2. Final order summary page, prior to confirmation
  3. Payment page
  4. Order tracking pane — post order placement

Design:

This would be an exhaustive project — as an entire functionality to enable order taking, order management, menu display with item increments, etc. It is desirable than the project be handled with much more engineering and human capital.

As an MVP for the feature, a simple CTA ‘Order’ that would orchestrate a personal call being handled by a Zomato Liaison undertaking the order from the customer.

Let this be rolled out as a web-only feature that allows users to scan the restaurant menu while taking the call with Zomato Liaison.

Testing:

Unit testing of components would lie within the scope of development teams. Tests mentioned below are indicative to user adoption & acceptance

Below hypothesis for each Theme is a direct validation of feature adoption by users. Our metrics would be aimed analyzing and assessing the same.

  1. Over 2000 ‘order’ CTA actions in a month — implying appreciable interest to order food online from Zomato
  2. >30% conversions from CTA action to Liaison enabled order placement — implies that users have a fairly strong buy intent & quick order completion aspiration
  3. Average call length is <5mins — implying users find menu options easily navigable while talking to someone (two things at same time) — i.e. users are driven to negotiate through friction in process in lieu of home delivered food.

Implementation & Deployment:

A simple call center team of 5–10 individuals handling the pilot on rolling shifts, should be the ideal start. The Zomato Liaisons would comprise of a few voluntary product manager — whose motivation is to grab quick learning on how to navigate the user quickly through the order process.

These shall serve as iterative user stories development activities, as we gather enough insight. The said orchestration is a typical Concierge model and helps gather validation & key inputs on the design of the entire feature.

Summary

Agile methodologies help product managers to incrementally and iteratively enhance their products. It helps them to manage any changes in the product requirements at any stage of it’s development. It also helps the product manager to maintain visibility across all aspects of the product.

Zomato incorporates agile methodologies in it’s product development process and agile ensures that the team is tacit in its approach — and my take on using Agile to schedule development cycles for the features of rating & reviews, filter on search & online ordering — takes into account all the salient points of the framework.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.