Designing For
On-Demand Services: Kitchensurfing Tonight
For $25 per person, a personal chef will cook you dinner tonight. (2014)
In the summer of 2014, Kitchensurfing had been in business for less than two years. We had six-figure gross revenue and were posting 10–20% month-over-month growth. We had launched operations in six US cities, plus Berlin. We had helped hundreds of chefs find private clients — some making as much as $150,000 a year from Kitchensurfing gigs. We had stellar investors and had raised a total of about $19M.
We were doing a lot of things right, but also a lot wrong. Scaling the business became our biggest challenge. Every day, our customer service team — SALT (Service and Logistics Team) — faced familiar questions from both chefs and customers, meaning the online experience wasn’t able to provide critical information.
From the customers: How much does it cost? Are the ingredients included? Is this chef available? How do I know I’ll like the food?
From the chefs: How do I write a great menu? How much should I charge? What should I charge for dinner for 2? What should I charge for a 20-person dinner party?
Understanding
Kitchensurfing had an exceptional end-user experience, as evidenced by consistently high NPS scores. However, our business faced significant hurdles to growth:
- Delayed “aha!” effect. Users often waited weeks between booking a chef and actually hosting their event.
- Low-frequency product. Irregular, “special occasions” made up the bulk of our use cases.
- High price point. In per person terms, meals with a Kitchensurfing chef were comparable to restaurants, but the all-in cost of a full dinner party created “sticker shock.”
- Planning is real work. Our product did little to address tasks associated with hosting, apart from food preparation and service.
At the time, Kitchensurfing was positioned as a medium-priced service for 6–18 people. We knew that in order to grow, we had to create less expensive experience geared toward casual weeknight meals for smaller groups, rather than special occasions.
We wanted our new experience to feel like a perfect neighborhood restaurant: tasty, comfortable, not too expensive, no planning required. Somewhere you’d want to eat once or twice a week for a good, simple meal or a casual date night.
Ideation
In our brainstorm sessions, we looked into new models for smaller groups and casual dinners: drop-off, on-demand, weekly meal prep. Based on our goals and research on competitors in our space, we decided an on-demand product would be the best fit for the “new” Kitchensurfing.
Overall goals:
- Customers can use on a weekly basis
- Value proposition fits into existing behavior
- Affordable price point (not for special occasions)
- Scalable customer acquisition model
- Consistent, standardized experience
- In-home experience includes a chef (brand differentiation)
User goal:
To provide healthy, freshly prepared meals for users and encourage habitual use with a simple, convenient experience and affordable pricing.
Research
First, we did a lot of qualitative and quantitative research to learn about weeknight dinner habits and to determine what experiential attributes and price points appealed to potential users.
Sample questions we asked a group of existing Kitchensurfing users:
- How much interaction would you want to have with the chef?
- What sort of cooking equipment do you have available in your home/apartment?
- Under what circumstances would you consider booking this service? How often would that occur?
- Please select the two factors you consider most strongly when deciding what to eat for dinner on any given weeknight.
- Please select the two factors you consider most strongly when determining the quality of a meal.
Busy couples and families showed a lot of interest in a weeknight product because they felt their current weeknight options were limited to cooking (labor intensive) and Seamless (not the healthiest or tastiest option for everyday use).
Definition
Based on our research, we decided to develop our new product with a focus on busy couples. Kitchensurfing Tonight (called “crack” internally) would enable couples to spend meaningful time together while enjoying tasty, casual meals at home, free from the stress of planning, shopping, cooking, and clean-up.
To simplify the end-user experience, we centralized important operational processes:
- Menu development. All recipes were created by Kitchensurfing, rather than individual chefs.
- Food preparation. We leased a commissary space where we could execute bulk preparation for mise en place, sauces, and other menu elements.
- Pricing. We fixed pricing at $25 per person for 2–6 diners. This price included ingredient costs, chef labor, clean-up, and gratuity.
- Duration. Chefs’ on-site cooking and clean-up could be executed in 30 minutes.
- Booking. Users could book meals same-day or up to 7 days in advance.
For $25 per person, a personal chef will cook you dinner tonight.
Execution
We created a very small team to work on Kitchensurfing Tonight in a series of one-week sprints with the aggressive goal of releasing a mobile app in three months. After one month, we had beta website where users could book chefs for same-day dinners.
Process
We used Sketch to coordinate product design and engineering. Sketch functions like Google Docs for product development and has a lot of advantages in environments where designers don’t code:
- It’s a vector / pixel editor
- Engineers program in shapes, but also have to realize that those shapes become pixels eventually
- Sketch UI is very similar to Interface Builder
- You can explore every numerical value of the design and replicate it in software.
We worked with fluid, less-defined specs, but made sure we were on the same page with the data model. (E.g. We built backend tools before the user-facing product to make sure we were able to accurately manage inventory.)
We knew building a mobile app would be time-consuming, so we decided to build a responsive mobile website first, and add native iOS elements around it to get it into the app store. Early email marketing tests also suggested that push notifications could be important tools for driving repeat bookings.
Design
After three months, our first version of the iOS apps (webview + native iOS elements) included three main screens: Overview, Menu, and Booking. It was far from ideal, but it did the job.
Nine months after our initial testing, the product has taken off, leading Kitchensurfing to pivot from a marketplace to an on-demand model.
Thoughts
Hybrid apps. Semi-native iOS apps have terrible user experiences. The are slow and have limited functionalities. In the beginning, they are easier to build quickly, but ultimately aren’t that different from a native app. Depending on your team, time constraints, and the maturity of the idea, I would almost always prefer to build a native app rather than a hybrid.
Mobile first. Mobile is transforming every business. But for some products, a web experience can (initially) be sufficient, and it may not be necessary to go mobile first. For a service like Uber, it makes sense to go mobile: the product fulfills a truly on-demand need (I need a car within minutes), depends on the user’s current location (where should the car go?), is enriched by real-time updates (where is my driver?), and removes payment friction.
Most services don’t depend on the ability to deliver within minutes. A house cleaner is most often a recurring need, not an on-demand one. Subscription services, like Blue Apron, require planning and are not impulsive purchases. Kitchensurfing Tonight is in between.
As a user, you can book a Kitchensurfing chef for dinner service the same day, but only when you complete your booking before 3pm. Your booking can be impulsive, but not truly on-demand because the chef won’t show up and start cooking until dinner time. That means the user has to think about dinner while still at work — and likely in front of a computer — where a web experience is sufficient.
Credits
Product Management
Prithvi Raj
Design, Creative Direction
Borahm Cho
Concepting
Chris Muscarella, Borahm Cho, Prithvi Raj
Development
Evan Farrar, Austen Ito, Danny Sullivan, Dan Kaufman, Matt Horan
Marketing
Ben Cole, Akshay Rathod
Operations
Sophie Benjamin
Follow me on Twitter or shoot me an email (borahm@borahm.de).
Im looking for new and fun things to work on.
