One late night in January, as we were taking down a convention show booth, my product manager approached my lead developer and me and asked the question,
As we were working on Cambeo, we came across a recurring theme as we talked to clients and potential clients, a major concern for them was recruiting and staffing. We were addressing many of their concerns after an employee was hired, but we were not equipped to help with the process prior to this point.
Pivoting to tailor our product to this need would be a huge ordeal and where Cambeo was at the time, we were not in a position to make such a big change. But the idea lingered, and we kept running into it time and time again.
Fast forward 6 months, and my product manager asks me, “do you want to break off and go make the right product?” The new team consisted of my product manager (now president of the new company), our lead web developer, our lead iOS developer, another designer (who took on a product management role) and myself as the lead designer.
This is how Bacon came to be. A crazy idea in the middle of the night, a small but cohesive product team, and the desire to solve the right problem.
As we set out, there were a couple of things that we knew. we knew that recruiting and hiring were major concerns for many employers, and there was a large population of capable people not in the workforce because they couldn’t commit to a regular schedule.
So our idea was to bring those two two groups together via the “Gig Economy.”
With the onset of Uber and other on-demand jobs, the general population was getting more comfortable with the idea of non-standard work relationships. Everywhere you look there was another service trying to connect people to work. Drivers, lawn mowing, and restaurant delivery services were making headlines and people liked the freedom that it brought.
But there was a gaping hole in the space. A large majority of these services were either peer to peer, or professional contractors for hire. They didn’t address the needs of employers needing workers on a day to day basis.
Our research discovered that in the retail environment, a store would receive shipments 2-5 times a week. Without dedicated staff (which most stores didn’t have) this would take the sales team off the floor for anywhere from 1-3 hours each shipment. This took the sales team away from their primary role in helping customers, leaving the store front understaffed and unable to respond to customers needs, resulting in lost revenue and poor customer experience. But it was unreasonable to hire dedicated staff for shipments due to the uncertain nature of the size and frequency of shipments.
This was only one example, there were several other establishments that faced similar issues. In the restaurant industry, staff would call in sick and would need replacements for multiple shifts while they were recovering. Restaurant owners were lucky if they had enough servers willing to cover the open shifts, but often this lead to burn out and staff quitting, which caused all sorts of problems. Many restaurant owners would have to call on favors from friends and family, and others who may or may not know how to properly do the work.
Holiday seasons also created unique situations for many employers. Many big name stores began preparing staff for the end of the year holiday rush starting in early fall, a full 4 months ahead of time. These examples highlight the problem many employers faced when trying to organize and maintain their workforce through different situations throughout the year.
As we approached these establishments, we saw a high level of interest in the idea to provide on-demand workers. There were of course concerns, but the overall impression was very positive, something that employers were hungry for.
As we started planning how the service was to take shape, we performed some live market tests. Through a connection, we were able to staff the store opening of a big box shoe retailer. For this test, we replicated what we imagined the product we were about to make would do manually. First we reached out to a large population, inviting them to the “platform” where they would be able to find on demand work. We then presented them with the opportunity, the time, pay, and location, and received applications from those interested. We then ran checks on those applicants and “approved” those who met a certain standard. We communicated with them about the status of their job and facilitated their payment once it was complete.
Although it was done manually, we tried to prove the validity of our basic hypothesis: we can provide good work for good workers on demand. Our results were amazing. Not only did both the employer and workers have a great experience, they extended the scope of the pilot from the original first couple days to cover the whole week leading up to the store opening.
Key Findings
With what we had learned, we set out to build out our MVP.
From talking with employers, we knew that they wanted people who would be effective from the moment they arrived. We also knew that they wanted to feel secure about the people they were bringing into their workplaces, and that they didn’t have the time or mental energy to spend on learning a complicated new system.
At this phase, we began to settle into our roles. Our company president looked for opportunities to get our product into the market, our product manager went out to do research on user needs, I set out to design the skeleton of what the product was and translate the research to usable UI, while the developers started building out the frameworks for the system.
My tasks mainly consisted of working closely with the product manager in doing research and interpreting the results of that research into user goals, prioritizing which goals to solve for, ideating how to solve for those goals, wireframing, prototyping, testing, and delivering the designs to developers for implementation.
As we focused on the core of what our product needed to do, we decided that validated market value was our primary goal and that by the end of the year we would have a working system with jobs worked. To do so, we had to narrow the scope of our original idea to focus on those features that would ensure that we could meet that goal.
The platform had to do 5 main things:
Making it work technically was the developer’s job, but making it work easily and with as little friction as possible, was mine.
Early design work focused mainly on functionality and usability. Frequent guerrilla testing was performed to ensure that the flow of the product worked well.
We initially started working on the iOS app as our starting point for workers, but discovered that we couldn’t iterate quickly enough to test and revise as we learned from users. This resulted in the web app being the primary focus of development, with the goal that what we learned would migrate to the mobile app in time. Even with the focus on web, we emphasized the need for the UI working on a mobile device as well as a desktop experience, since we would eventually translate the designs and workflow over to the mobile app.
As development started to progress, we began to look further into the future of what we were trying to accomplish. Looking deeper at the questions “why are we doing this?” and “what are we really trying to build?” We established a purpose statement: “Help people build confidence through good work” and identified that we weren’t simply creating a product, but an economy in which our product facilitated the process in which people could build confidence by finding good work. Taking a step back to look at where our product stands in relation to the economy that we were creating, we developed a stronger resolve to ensure that not only were we building an app, but we were creating an experience. We no longer viewed the app as our product, but as a means to deliver the real product, which was quality workers, to good employment opportunities.
In light of this, we changed the way we worked. Instead of trying to focus on how do we make our product look better, or more streamlined, we focused on how do we ensure that people are finding the best opportunities, from both a worker’s and from an employer’s perspective.
We ideated on ways to ensure that employer’s received the best workers while ensuring that the platform was fair and accessible to new workers. We explored ways to help employers feel more confident in the workers that they were bringing into their workspaces. The types of decisions we made changed from aesthetic to strategic.
In this process, we experimented with what kinds of notification methods resulted in the best turnout from workers, how our language and style affected the commitment level of workers, how to manage people who didn’t meet expectations, and more. Each time, seeking to better the experience for everyone involved.
When we launched the MVP in early November, 5 months after we started Bacon, we knew we had a good product. It wasn’t everything that we wanted it to be, but by keeping it simple to begin with, it worked, and met the basic needs of employers and workers alike. Having the platform in the wild, being used by real employers and workers highlighted areas where we could improve, and allowed us to prioritize which features we would implement based on real user feedback.
One example of this was how we implemented group posts. Originally, a post was designed to connect an employer with one worker. This kept the platform simple from a technology standpoint. As our clients started to use the platform, we noticed that there were multiple posts being created with identical information, for multiple people working at the same time and place. This had never come up in our research or testing because people were in a simulated environment and while they were able to complete tasks smoothly and therefore the test “passed,” they were not real situations and our data was incomplete. By observing this behavior in real situations, we were able to quickly devise a solution to implement grouping of posts and reduce the amount of work required to use the service. This, along with other improvements we made along the way, helped our platform become the primary source of staffing for a company when we were previously the last of five options.
A point of emphasis as we decided what to improve was that we always sought to understand the reason behind the behavior we were seeing. We accomplished this by listening to feedback from users, looking at demonstrated behaviors, and comparing them with user goals. This allowed us to determine if what we were hearing/seeing was a problem we needed to resolve, or a symptom of a deeper issue.
As we iterated through versions of the design, we focused on clarity and standardizing across our multiple platforms, ensuring that users would have a consistent experience when switching between web and mobile. In the process, we made sure to include the fun and edgy brand personality that we were trying to achieve in our marketing efforts. This allowed us to create a design language that was familiar, but also felt unique to our brand.
Bacon was about connecting people. It was an opportunity to realize that the products we make are secondary to those who are using them.
