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
11 min readJul 25, 2020


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”.

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

Assume any X in that initial number of cancelled orders, multiply that by the hundred of thousands of food orders Rappi make per day accross Latin America, and that improvement is the impact we achieved, while building what we consider a better product for our users. In this post I’ll try to describe step by step the process we took from discovery to execution of that product redesign.

The case revolves around a restaurant app in the food delivery context, but this post will be interesting and insightful for Product/Design/Tech people and problem solving teams in general.

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.

Among all of its verticals (supermarkets, banking, e-commerce, etc), the Restaurant one is one of their biggest ones. The hundreds of thousands of food orders per day that final customers make, have to pass through the restaurant app that we’ll analyze in this post.

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.

I had to shift my mind from finding product-market fit for a final user (activation, engagement, retention), to savagely optimize operational metrics for the business.

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…

  • …missed to accept a new order from a client.
  • …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.

The challenge was to reduce these cancellations from a product perspective.

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


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.

If every other company is doing this (left side: list of active orders; right side: order detail) it must be the best solution right? We’ll get to it.

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.

They gave me a backlog based on the restaurants owners desires and Rappi Operations team requests. That must have made my job easier right? Well, it was quite the opposite actually, it instantly reminded me of Marty Cagan’s classic post “Why products fail”:

“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:

  • Sales-driven specials: Product requests were made by the clients (restaurant OWNERS). It makes sense to listen to them, they are the ones that pay Rappi for the service, and the happier they are, the more deals Rappi closes. But it bothered me that those guys are not the real users. The real users of my app are the CASHIERS and OPERATORS of the kitchen, and they have a completely different mindset than the owners.
  • 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.

I decided to ignore most of my stakeholder’s backlog, and decided to start from where every Product Manager should start: understanding the user (I know it sounds cliché, but I’m still surprised to see how many Product Teams jump straight to new features, instead of pausing for a clear understanding of the user and their problems).

Roles in the kitchen

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

  • Going to different type of restaurants (small ones, big chains, dark kitchens, high volume, or worst offenders).
  • 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).
Clear insight: most of the magic occurs “offline”, the restaurant app is only needed in certain parts of the process.

Initially every visit gave me a new perception. But after more than 25 informal field trips (in many of them I also invited my Developers), I started to feel confident in the insights I gathered regardless of the type of restaurants. Here are some of them:

  • #1: There are clearly three user-roles for every delivery order. Cashiers (they accept the order, digit them in their internal system and/or print the ticket); Packers (the ones that prepare/seal the order with the correct products); Dispatchers (those responsible for giving the right order to the right delivery boy).
  • #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 #1 - We should prioritize the owners needs: FALSE. The owner or admin of the restaurant has his own pains. The cashiers and operators have totally different problems in the kitchen, we should optimize for them, not the owners.
  • 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):

The classic model had serious problems to follow the kitchen’s natural flow

Instead of thinking of incremental optimizations for the old app, I decided to start from scratch, based on the 3 user-roles. I tried to design a proposal that made sense even in a story-telling approach:

  • The order needs to be accepted.
  • The order needs to be prepared.
  • The order needs to be dispatched to the delivery boy.

These are some of my original mock-ups, we called them “Kanban model” (as in a traditional kanban):

Early mock-ups of new 3 column concept.

I went back again to restaurants to show my early mock-ups (and then early-prototypes). I learned two things showing them:

  • First reaction = Resistance to change. As soon as they saw something new, most cashiers HATED the idea of a new product. Generalized feedback was something like “please, don’t change the way we already operate, we hate it when we have to learn new things or press new buttons”.
  • 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”.

A technique I love to use to validate a product concept is to ask the user: “Please, in your words, explain to your colleague/friend how this app works”. With the old version I got up to 6 different answers for every 10 operators asked. With the early mock-ups version, 9 operators out of 10 told exactly the same thing, they could explain how the product was intended to be used.

For me, if the user can explain in a really consistent way how your product works after seeing mock-ups, you nailed the concept validation test.

After the initial concept validations and early prototypes, we started to add UI final Design to the process.

Notice that up until now, everything was “Discovery”, but after the concept validations and early prototypes, we were ready to go into full “Execution” mode, and we built the product relatively fast.


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.

Consistently, during the whole A/B testing process, the Kanban version performed 30% better in reducing “Restaurants fault cancelled orders”.

To be fair to the case, we allowed operators to “opt-out” of the new version, knowing that most operators would have a strong “resistance to change” mindset. But the results were so consistent, that we decided to keep rolling-out the new version.

In addition to the good numbers, what made us proud as a team, was that the new product was really easy to explain:

Rappi Restaurant App — Before vs After

We kept including some minor features in the next weeks early 2020 (listening to the cashier’s initial feedback, or noticing things they missed from the old version), adding some nice-to-have visual details, and currently we keep optimizing the product, but the Kanban model redesign was here to stay, we deprecated the old version some weeks later.


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.

For closing the article, I’m rounding up the main takeaways this product redesign process left me.

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.

We believe that by giving a better product to the final user, the client will also have an easier path for achieving his goals.

#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.

Personal disclosure: This personal post is written based on my experience, my willingness to share Product learnings & point of view on how I approached the problem. This is not an official Rappi post.

Acknowledgments: My awesome development team, they believed in the redesign, and I think we had a lot of fun in the process. My main internal stakeholders, even though my team had tons of other company priorities, they supported the redesign as soon as they saw how we were doing the Discovery process.



Cesar Hoshi

Product Manager. Peruvian, ex co-founder of a Dating App in Latam, currently in Colombia working in a hyper-growth tech company.