From discovery to execution. A real life Product Redesign case

Step by step of how my team correctly redesigned Rappi Restaurant App. From a Product Manager perspective.

Cesar Hoshi
Jul 25 · 11 min read

About this product redesign case

TL;DR of final results:

My team and I redesigned Rappi Restaurant App (the one the restaurants use to receive users food orders for delivery), and immediately improved by 30% our main key metric “Restaurants fault cancelled orders”.

Image for post
Image for post
This case revolves around a restaurant app in the food delivery context — Photo by Nathan Dumlao on Unsplash

Rappi background:

Rappi is one of the few Latin American “Unicorns” (TechCrunch 2019: “Softbank makes a huge bet on Latin America”), it’s an on-demand delivery startup with impressive ambitions to be the #1 super-app in the region.

Personal background:

Considering that my last product & entrepreneurship was a Dating App (you can see here my 6 candid lessons of a failed Startup in Latam), and considering the fact that I had NO prior experience in the restaurant industry, the challenge to optimize “RappiAliado” (I’ll call it “the restaurant app” from now onwards), an app that already received hundred of thousands of food orders per day, sounded more than interesting.

Problem to solve:

The main objective was to reduce what we call “Restaurants fault cancelled orders” (number of cancelled orders by restaurant attribution reasons), those are the ones that harm the end user who will not receive their food (affecting final customer experience, user retention in the Rappi app, and directly impacting restaurant sales). Some examples: the restaurant…

  • …accepted a new order but forgot to prepare it.
  • …kept waiting for too long the delivery boy because of a false input in the cooking time.
  • …fucked up the order by placing a product that the client didn’t ask for, or giving one order to the incorrect delivery boy.
  • …etc.

Process for understanding the business, current situation and the user problems

Benchmarking

It was obvious to start doing benchmark reviews to see what the food industry was already doing. It caught my attention that the main players of the region (UberEats, iFood and Rappi) had almost a copy-paste of the product.

Image for post
Image for post
This was the standard for restaurants apps (2019).

The source of ideas (client vs user)

Since day one, I received a huge backlog of “incredible ideas to improve the app” from Rappi Operations team.

“The source of ideas: This model leads to sales-driven specials, and stakeholder-driven products (…) but for now let me just say that this is not the source of our best product ideas.”

Marty Cagan: Product Fail (2015)

Let’s analyze those sources of ideas:

  • Stakeholder-driven product: The product was built according to our internal (as a business) desires. Every single request from Rappi’s Operations team was smart and well analyzed with data. But still, it was what our Operations team wanted, not what the users needed.

Roles in the kitchen

I spent great part of my first weeks doing field research:

  • Observing how cashiers operated.
  • Discovering their operational struggles.
  • Doing informal Q&As with restaurant operators.
  • Trying to understand the whole process (from accepting an order, to dispatching it to the delivery boy).
  • Avoiding to speak to owners and administrators (this was key in the discovery process).
Image for post
Image for post
Clear insight: most of the magic occurs “offline”, the restaurant app is only needed in certain parts of the process.
  • #2: For most part of the process, nobody is even looking at the app. Once the cashier transcribed the order on their own system and/or printed the order ticket, they could operate completely ignoring the app.
  • #3: Restaurant layout is key. Every kitchen is different, some only have one computer, others have 2 tablets (in the counter and in the dispatch zone), even others have several people manipulating the same device.
  • #4: For operational apps such as this one, operators get used to them no matter how confusing is the product. Once an operator gets used to a tool, they will repeat the process in a really efficient way. When we asked 10 different cashiers: “how the current product works?”, we could get up to 6 different answers. That bothered me from a product point of view, but I learned to understand operators.

Busted myths of our product and users

These were some of the “myths” and beliefs that were used to build our features before the redesign:

  • Myth #2 - It’s important to show all the order information at all times in the app: FALSE. Most of the magic of the order occurs OFFLINE. The app is mostly only used to accept the order. The cashiers have almost no need to see an order again once they accept the order.
  • Myth #3 - There is one user using the restaurant app: FALSE. Even if technically there can be only one person operating (specially in small restaurants), there are three very different roles at different stages of the orders: the ones accepting the order; the ones packing them, and the ones dispatching it to the delivery boy. Even in some (bigger) restaurants, there are physically three different devices in the layout with our app opened at the same time (one for each role).
  • Myth #4 - The restaurant has a dedicated person operating the restaurant app: FALSE. The operator that accepts our orders is the same one that is taking orders in-situ for table customers, charging customers that want to pay, administering the inventory, resolving a chaos in the kitchen, all of that at the same time.

Process for designing a new solution

After understanding how kitchens operate, I felt totally confident to point out the current model mistakes (for us Rappi and for UberEats or iFood):

Image for post
Image for post
The classic model had serious problems to follow the kitchen’s natural flow
  • The order needs to be prepared.
  • The order needs to be dispatched to the delivery boy.
Image for post
Image for post
Image for post
Image for post
Early mock-ups of new 3 column concept.
  • Second reaction = Easy to explain to others. After the initial resistance, once they had seen a complete flow of an order, the generalized feedback was something like “this makes absolute sense, here you accept the orders, here you track them, and here you find when to dispatch”.
Image for post
Image for post
After the initial concept validations and early prototypes, we started to add UI final Design to the process.

Results

The results were immediate for reducing “restaurants fault cancelled orders”, here is a comparison of the first 14 days that the A/B test was 50/50 (old vs kanban model). On average we improved by 30% our main metric (and saving tons of dollars to Rappi and the restaurants) just by changing the display of the main features of the product. This is a number that would have cost us much more time and several optimizations if we kept the traditional model and only incremental improvements.

Image for post
Image for post
Consistently, during the whole A/B testing process, the Kanban version performed 30% better in reducing “Restaurants fault cancelled orders”.
Image for post
Image for post
Rappi Restaurant App — Before vs After

Conclusions

I started the project knowing that we were following benchmark standards, and with a huge backlog with lots of inputs from owners desires (clients) and key Stakeholders ideas (internal needs); but the key part of this redesign process for me was to understand the final user’s reality first, and only then, start suggesting product improvements.


Main takeaways for a product redesign process

#1 Differentiate your client vs your user

Many times they are the same, but it was key in this process to start listening to the user (restaurant CASHIERS), and stop listening to clients (restaurant OWNERS). They can sometimes have opposite opinions.

#2 You don’t have to copy the industry standards

Even if the biggest players tend to resolve the problem in the same way, that doesn’t mean there isn’t a completely new way of resolving a problem. The “Kanban model” (the 3 columns proposal) now sounds obvious to us (and to the restaurants that use it), but there was a complete process to get there.

#3 Never jump to build features before understanding your user (also, don’t literally do what they ask you to do, they don’t know how to build products, that’s your job)

Even if it sounds cliché to start listening to the user, not every Product Team starts with the users pains. Many teams I know jump directly to the execution part. Once you have a clear understanding of the user and the problem, building features is a much easier and straightforward process to do.

#4 Have a clear definition of the metrics you will attack

For an operational app, the classic product metrics such as Activation, Retention or Engagement are not that relevant. It helped me to have a clear operational metric to attack (“restaurants fault cancelled orders”).

#5 Bring developers to your Discovery process

Personally I like to balance my job (as Product Manager) in 90% Discovery time, and 10% of Execution time. In the same way, I like to invite Developers to the Discovery process (they should do 90% of Execution time, and 10% of Discovery). Trust me, if the developers also understand the user, and see the purpose of their solution, they will be more compromised to build the final product. Also they are a great source of ideas for potential solutions, they are the experts in building stuff.

#6 Don’t be afraid of “resistance to change” feedback

For an operative app, this is not a minor point. People get used to repeating processes, even if they are confusing. So of course the users will hate change. But it is our jobs as Product Managers to build a better solution, so they don’t miss the older versions.


Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store