At a Glance
Client: Global CPG company
Opportunity: Helping food lovers identify, track and share restaurants. Identifying B2B opportunities for the CPG company through the collection of new data and insights.
Solution: Built an MVP (minimum viable product) for users to track, list and share restaurants. Validated the need for new data & insights with key business units.
- Conducted primary research into users’ pain points
- Prototyped and tested multiple ideas
- Built a working prototype, followed by a working MVP
- Explored B2B opportunities with the global CPG company to identify new revenue streams and opportunities
Results: Built and validated a new venture that allowed food lovers to better explore, research, track and share restaurants. Put a software product into people’s hands, iterated and learned. Validated through prototypes that there was a B2B opportunity and business case as well.
One of the largest food and beverage companies in the world approached us to identify, develop, and scale opportunities beyond their core business.
We started by supporting the implementation of an innovation framework within the organization. In that space, employees took the role of entrepreneurs. They explored opportunity areas, ideated solutions and pitched their concepts to an innovation board.
In this case study, we’ll cover the work by one of those teams. Bites started with the team’s efforts to learn more about a segment of the market traditionally foreign to the core business (urban millennials under 38 years of age). The team identified several organizationally held assumptions about those individuals: things like ‘they would order delivery’, and ‘mostly ate out’.
We always start with people (2-4 weeks)
We started by looking at all the information we had about this market, including market studies and insight papers. At Highline Beta, we believe market research has a shelf life. The world changes at such a rapid pace that a lot of the facts we knew to be true yesterday very quickly become invalid. Because of that, we use a tool we call the proto-archetype.
An archetype aggregates a set of characteristics and behaviors we find interesting about a group of people, instead of focusing on a specific persona. This enables us to acknowledge, and account for the fact that people’s priorities change. They change during the day depending on the context they find themselves in, and they change over time, as they move through different life stages. Because these archetypes are based on market studies and secondary research, we call it a ‘proto’ archetype. That way we can signal to everyone in the team that this information is not very reliable.
At this stage, the proto-archetype is an artifact that helps teams remain aligned on who we’re focusing on, in a simple and easy-to-understand format. It is the inception of the customer development practice for a new venture team.
The team used the proto-archetype to recruit participants that matched the description. In total, we conducted 75 interviews in Toronto, Vancouver, Montreal, Chicago and New York. The goal of the interviews was to get to know these individuals, to hear their anecdotes about finding food, eating, and cooking — and to uncover any interesting painful situations we did not think about before.
In total, the team identified 28 unsolved problems, with varying degrees of importance. Here are a few examples:
- Some participants saw cooking at home as a chore. So they tried to spend as little time as possible planning, and as a result, wouldn’t know what to cook. This often resulted in unpleasant meals or hangry decisions to eat out.
- People would write down restaurant recommendations in a variety of places but then would have a hard time remembering who gave it to them, or why they were good, or what to try there.
- Some people enjoyed cooking so much, they saw every opportunity as a way to try new techniques, ingredients, and recipes. However, they struggled to find places to buy more exotic ingredients.
- People who cared about food and restaurants judged others on the recommendations they made. As a result, people always gave the most expensive and exclusive restaurants they knew as the first recommendation.
With fresh insights in hand, the team updated the proto-archetype. In fact, we were able to identify patterns related to each problem statement, and we mapped out 6 distinct archetypes that shared a set of characteristics, problems and behaviors.
The archetypes included people that saw eating and cooking as a valuable experience to learn about others and express themselves. They typically cook new things frequently and experiment with different kitchen equipment. They’re intimately familiar with the culinary scene of their community (in fact, they probably chose where they live in part because of the restaurants and chefs nearby).
Naturally, through these interactions, we spotted connections with other people we needed to investigate. We created proto-archetypes for chefs, and owners of small restaurants, and conducted another round of interviews to learn more about them.
Through the process of understanding our potential customers, we created a few prototypes that functioned as conversation starters. They helped us learn more about their problems and the things they valued most. For example, we created a quick mockup of service to help chefs track their inventory. We knew this was something they struggled with, and we had no idea if we would end up focusing on solving that problem. Ultimately we got immense value out of this exercise because we learned so much about how they thought about keeping inventory up to date, and how understanding which dishes were most popular was paramount to structuring that part of their business.
As we moved through findings and built relationships, having conversations with potential customers became less valuable, and in order to learn more, we needed to start creating a solution.
Framing a solution (2 – 4 weeks)
Our process is not linear, it feels messy and uncertain, but once teams start having conversations with people we provide the structure and guidance to keep them moving forward. The interview framework helps the team identify and prioritize the most crucial problem they need to solve for their customers—while keeping in mind their financial and technical constraints.
For the Bites team, the single most common set of issues that affected a large segment of the people they talked to revolved around finding, sharing and keeping track of restaurants and places to go.
We spotted interesting behaviors in people who cared about food: they would tag restaurants on Google Maps, or create restaurant lists on their notes app. When traveling to new places, we saw people create a curated list of experiences for their friends and family.
However, receiving and sharing recommendations to places remained difficult. People frequently complained about choosing the wrong places or feeling lost when visiting new cities.
We listed our top problem insights and as a team ideated on all the possible ways we could solve them. At Highline Beta, we facilitate a set of guided workshops to help teams move through this step quickly and efficiently. We diverge, by exploring all possibilities freely, and then we converge by cutting down on ideas that would be impossible to implement.
When we’ve landed on a few concepts, we ask the most important question every business should be asking themselves:
What do we believe about the world, consumers, technology, and the market, that if we’re wrong, these concepts wouldn’t work?
This question helps teams be laser-focused on what they need to learn next.
We wanted to build a solution to help people track the restaurants they go to, and the recommendations they get from others. The long term vision was to create a community of like-minded people, that would create content to help each other.
In order for our solution to work, people would have to be okay with sharing their precious restaurant lists with us. We had seen indications of this behavior before, as users would curate lists for friends, but we had never seen people share their entire, unfiltered records.
Our first experiment was a simple web prototype built on Webflow. We used basic material design components, and we leveraged the Google Places API to populate restaurant information. To make it even easier for us, we built the prototype so it only worked in Toronto and we offered early access to a few people we had previously spoken with. These types of prototypes take about a week to put together, so we kept the team moving fast and scaled our ability to learn.
- 100% of participants shared their restaurant list with us.
- 70% of participants requested early access for their friends. We collected at least 3 referral names per customer.
Iterating and scaling (4-8 weeks)
We pitched the innovation board, armed with the data we gathered from our first experiment, and all of the information we learned about the users. The innovation board helps keep the team accountable, and ultimately they make the go/no-go decision on ventures continuing.
In this case, they helped us identify potential new customers within the organization. A few business units currently purchase data from third parties that looks a lot like the data we were able to gather.
When we conducted interviews with them, we learned that the data is used to design new iterations of food and drink products, and also to help support the sales team responsible for establishing relationships with large food chain restaurants.
We created proto-archetypes for both the internal staff at the business units that used the data we had and the large food chain customers. We used those artifacts to externalize the things we wanted to learn, and as a team, we targeted and interviewed people to learn more about their needs.
Within the organization, data was used to sell. It was structured on pitch decks to potential buyers as a way to support the relevancy of certain products. For example “you should buy our new avocado sauce because avocado toast is gaining momentum in all these major urban centers” — In addition, we learned that large food chains used that data to update their menu over time. On average, it took them 2 years to put something new on their menu.
We started asking ourselves if there was an opportunity for us to provide the data used to design products, and the data used to update restaurant menus.
We used the sales pitch decks to create a quick prototype of what a Bites dashboard could look like. The data is fake, and it was very flawed, but it was an excellent conversation starter for large food chain chefs and culinary teams.
With each conversation, we started to map out potential business models. One of the benefits of working with Highline Beta is that we leverage all kinds of methodologies and tools, we simply use whatever is best to get the work done. In this case, we leveraged Strategyzer’s Business Model Canvas to visualize and keep track of alternative business models we designed.
The power of co-creation
Following our conversations, we redesigned our Webflow prototype and created a new Progressive Web Application (PWA). The initial version of the app took 5 weeks to build and put into users’ hands. A PWA allows for creating complex applications, without having to go through the lengthy application submission process via the App Store (which is required for a Native Application). This time, we leveraged the relationships we had within the organization, and with teams within large food chain organizations to co-design interfaces.
This helped us address the needs of users, while also ensuring we designed interactions in a way that enabled the collection of useful data that could be leveraged.
Our team at Highline Beta also provided guidance to design the interfaces in a way that adhered to available technical libraries. We used Angular’s Material design library and customized it to make it dark — because we knew customers opened the app in restaurants, typically during dinner, in a dark environment.
Building the right features
The PWA app also incorporates feedback from users on the previous version (for example, we removed star reviews, and started experimenting with other ways to rank restaurants). We invited some users as referrals, increasing our total user base.
Strategy and execution come together
At Highline Beta, our teams are able to look at problems at a high level, strategizing concepts that are relevant to the world, and the market — and then roll up our sleeves and do it.
Building software solutions is hard, and even if the idea and market conditions are right, teams fail when they’re unable to handle the complexities of building digital products.
We leverage practices and tools from different disciplines. With Bites we used a service blueprint, typically used by service designers to study, plan and build abstract experiences (such as making your way through airport security or going to the emergency room at a hospital).
The blueprint enabled the team to unpack everything that needed to be in place to deliver the experience. It maps the customer’s journey in relation to every touchpoint with Bites, and the technical back end services. This enabled us to build, iterate and learn frequently, developing a comprehensive but quick minimum viable product into the market for further testing.