Doordash

Ivey Project Society Fellowship

Overview

The Ivey Product Society is a team of Ivey alumni in product with three core objectives:

  1. Help other Ivey students and alumni learn, prepare, and break into product
  2. Foster a community where they can come to connect, learn, and help one another
  3. Establish Ivey as the top program for product management in North America

This year, they launched their inaugural Product Management Fellowship, a 16-week project oriented bootcamp will aims to give students the skills, connections, and experience to break in and succeed at their first product role. The bootcamp was focused on an individual keystone project with skill workshops, interview prep, and guest speaker sessions integrated tightly into the project curriculum.

Over the course of these 16 weeks, I attended 4 guest speaker events (featuring professionals at Google, Facebook, and Uber), completed 9 mock interviews, and went through the product development process to propose a new feature for Doordash. Keep reading to learn about the steps I took! Alternatively, you can read my product requirements document (PRD), view my final deck, or watch my presentation – I pitched the idea directly to a PM at the company!

Identifying the Opportunity – Understanding Customer Jobs, Needs, and Pain Points

The core responsibility of a PM is to deliver value to customers. This entails building products and services to solve real problems that customers have. Problems are challenges can be broken down further into something that prevents or makes it difficult for customers to get their ‘Job’ done.

The Jobs To Be Done (JTBD) school of thought is centered around focusing on what people seek to achieve in a given circumstance instead of looking at the demographic and psychographic factors of consumption. To put this into practice, I first strove to truly understand the key elements that make up a Job:

As well as the different levels of a Job:

The first thing I did was create Job Map, which helped me visualize the job performer’s behaviour and needs in the context of their daily lives. With the JTBD being “order delivery,” my Job Map looked like this:

This process helped me begin to hypothesize where some potential user pain points could be – indecisiveness (at many steps), wasting time manually re-entering order/delivery details, arrival delays. However, to be user centric, I knew it was important to actually talk to users. Given that myself, as well as most of the peers in my network, are university students, I chose this group as my user persona. Over the course of a week, I conducted 7 user interviews and organized my thoughts using Tony Ulwick’s Outcome Driven Innovation framework. This helped me focus on pinpointing user-centered opportunities and uncovering all desired outcomes that people want from getting a job done in a given domain.

I created a second Job Map that included even more desired outcomes and barriers / challenges uncovered through the interviews.

From there, I thought it would also be helpful to apply the Four Forces framework to help me understand:

Problem Attraction (UberEats)
  • Craving a dish / cuisine and I don’t have the ingredients or expertise to make it myself
  • Want a specific flavour that is not available at home
  • Show appreciation / congratulate friend
  • Laziness to cook
  • Flexibility in customizing pickup vs. delivery
  • Abundance of options, especially picking combos
  • Potentially has specific cuisine / item requested
Habit Uncertainty
  • Coupons and discounts
  • Previous orders that have been reliable and satisfied needs at the time
  • Pre-saved preferences
  • Order may get messed up
  • New driver may not know how to get to delivery location, causing unnecessary and awkward interactions
  • Slow delivery times
  • Higher service fees and costs (?)

At this point, I gathered a lot of data and was looking to thoroughly analyze this information.

Defining a Product Scope

It is important for PMs to synthesize and prioritize the jobs, needs, and pain points for their team. This helps hone focus on the most important needs to address, which leads into a strong customer value proposition that points to the most important features to include in a minimum viable product (MVP).

To identify the most important and underserved needs, I used the Importance vs. Satisfaction framework. Importance refers to how critical this need is to getting the job done and how frequently it comes up. Satisfaction refers to how satisfied users are with how this need is addressed with their current solution.

It can be concluded that the most important and underserved needs are the following:

Ultimately, I decided to focus on minimizing decision paralysis and sought to develop a value proposition to ensure Doordash would be able to serve this need better than alternative competitors. A Value Proposition Canvas helped me visually develop this hypothesis.

This exercise led me to identifying the following value proposition for Doordash: by helping users bookmark restaurants, users will be able to easily access and choose their favourite foods quickly without being paralyzed by choice.

Some success metrics that would help me measure whether or not a solution achieves this goal could be:

With a problem space identified and understood, it was time to start thinking about potential solutions. I only intended to create a simple MVP that would allow me to validate my key and riskiest hypotheses on this value proposition. I considered each stage of the product experience from beginning to end, and jotted down a few ideas that could solve the core need of minimizing decision paralysis. I resonated deeply with the thought of creating a bookmarks tab for users to make note of restaurants they would be interested in ordering from in the future. From there, I created a user flow diagram to flesh out and think holistically about the feature, then started to build an initial wireframe and prototype in Figma.

As with any idea, iteration is key and feedback is crucial. Testing the MVP would allow me to validate the assumptions I made both on what key customer needs to solve and how to tactically meet those needs (feature, design). I asked a few target users (university students) to walk through my MVP and comment their thoughts, feelings, and emotions as they went. The feedback I received was incredibly helpful in shaping a v2. Some highlights:

Putting It Together - Product Review Deck

With an MVP built and tested, the end of the project and bootcamp were quickly approaching. The final presentation took the form of a Product Review Day, simulating a strategic meeting that PMs usually have with leadership. It’s typically an opportunity for PMs to share important updates, get feedback on key strategic decisions, or secure support for their initiatives.

I took some time to craft the narrative I wanted to tell when asked “Why would Doordash need a feature like this?” The presentation summarized all the data, analysis, and insights I had been collecting and developing over the course of bootcamp. I also took a step back to think strategically about how this feature would align with Doordash’s mission – delivering good to customers, dashers, and merchants – as well as what the launch roadmap and big milestones would look like. The completed deck can be found here and you can listen to me presenting it here!

A Doordash PM was able to sit in on my presentation and she commented that this is definitely something the teams have been thinking about internally (phew). It was really great to hear here opinions on the feature and get feedback on what else I could have considered. A few days later, the Head of Enterprise Partnerships & Business Development for Doordash Canada reached out to me on LinkedIn and mentioned that he too had been impressed with my work (I died a little).

Takeaways

This experience was definitely one of the highlights of my school year and I would always find myself looking forward to the syncs and guest speakers. Being able to apply PM skills through the capstone project was a really great way to begin to “think like a PM.” This fellowship made me super excited to work as a PM this summer and hopefully full-time as well.

I learned so much over the course of these four months, but if I had to summarize my top 3 learnings, they would be:

  1. Go deep into understanding the problem and users. The insights are in the details.
  2. Don’t tie down to your hypotheses early and don’t get too attached to your ideas. Always ask yourself – what is your riskiest assumption?
  3. Think about your MVP as a minimum viable prototype (10x less engineering effort) as opposed to a minimum viable product. In the case that you’re wrong, there should be clear learnings you can take away – move fast and iterate.