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

Assume any X in that initial number of cancelled orders, multiply that by the 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 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 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 (you can see here my 6 candid lessons of a failed Startup in Latam), and considering the fact that , the challenge to optimize “RappiAliado” (I’ll call it “” from now onwards), , sounded more than interesting.

I had to shift my mind for a final user (activation, engagement, retention), for the business.

Problem to solve:

The main objective was to (number of cancelled orders by restaurant attribution reasons),those are the ones that (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 .


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 .

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

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.

They gave me a 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 (). 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. , 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, .

I decided to ignore most of my stakeholder’s backlog, and decided to (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).
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.

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:

  • . (they accept the order, digit them in their internal system and/or print the ticket); (the ones that prepare/seal the order with the correct products); (those responsible for giving the right order to the right delivery boy).
  • Once the cashier transcribed the order on their own system and/or printed the order ticket, they could operate completely ignoring the app.
  • 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.
  • . 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:

  • . 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.
  • . 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.
  • . 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).
  • . 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

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

  • The order needs to be .
  • The order needs to be .
  • The order needs to be to the delivery boy.

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

Image for post
Image for post
Image for post
Image for post
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:

  • . As soon as they saw something new, . 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”.
  • . 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”.

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.

Image for post
Image for post
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 “”, but after the concept validations and early prototypes, we were ready to go into full “” mode, and we built the product relatively fast.


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

To be fair to the case, we allowed operators to “opt-out” of the new version, knowing that most operators would have a . 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:

Image for post
Image for post
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 .


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 .

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: , they believed in the redesign, and I think we had a lot of fun in the process. , 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.

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