Tools for Discerning Home Cooks
Lead Product Designer
A Breif Introduction
Mealthy Recipes is a startup building digital products and appliances to make the lives of home cooks a little bit easier. Along with a website and native mobile apps, it’s become a highly engaged multi-platform online community.
Structuring a New Kind of Recipe Company
We wanted to build a first-of-its-kind, community-driven recipe product—a platform for home cooks that offered support, suggestions, and feedback without the trade-offs. We wanted to steer away from advertising and data revenue, to focus on the experience. We wanted to combine this online community with a repository of healthy recipes and the best tools out there to execute on them. We brought in experts from organizations like AllRecipes and Buzzfeed Tasty to help us identify our core market and create top-tier branded content. We worked with some of the core team that designed the original Instant Pot to design our spiral slicer and Multipot Pressure Cooker. We were all in on being a multichannel product and appliance organization like no one had done before.
As the Lead Product Designer for Mealthy, I led and grew the design and (for a time) engineering teams. I was involved in high-level strategy and implementation of every feature in the products through the V1 launch. Being the first designer and transitioning to design lead is filled with pitfalls along the way. For example, you have to define processes and tools for everyone who comes after you. When we started work on Mealthy, I chose to work with Sketch and Abstract for designing screens. I knew that with a small team it would be imperative that we all pitch in where we could so I biased toward designers who could write some production front-end code. These decisions would come back to haunt me later but served as simple enough building blocks to move forward building our team.
What Problems Were We Solving?
Designing a recipe product in an already well-saturated market was not the the most fun or most groundbreaking project I’ve ever worked on - but Mealthy felt really special. As anyone who has worked on editorial platforms based around recipes can tell you, the traffic is, by its very nature, transient. Other recipe brands had long focused on broken media models demanding and monetizing the user’s attention and trading off privacy and security. We did not want to fall into that trap. We refused to become ad-saturated and filled with editorial aspirations instead of a product focused on what people wanted to do - find a recipe!
Beginning with research
from the start, I worked with our CEO to do competitive research to understand the landscape of recipe products on the market and compile user demographics assumptions. Working with our CX Researcher and editorial partners, we surveyed Mealthy team members and contacts who had worked at places like Buzzfeed and Allrecipes - compiling competitive analyses to understand the landscape of recipe products on the market. Based on this anecdotal data, we had a good idea as to what our target audience looked like:
- 30 - 40 years old
- Mostly females (~70/30 split)
- Household Income ~$100k per year
- College Educated (at least some college in most cases)
- Health conscious and digitally savvy
As time went on, we found we were more or less spot-on with our expected demographic with some variants that we didn't account for - people who like kitchen gadgets, gift recipients, meal-prep enthusiasts, and more generally transient traffic.
Soon after getting rolling, I recruited and hired my favorite front-end engineer. Ryan applied his years of startup experience to help the CEO and me define and scope MVP and V1 feature sets and sort them into epics. We used those epics and feature lists to start sketching out wireframes for some of the high exposure features like the Recipe Detail, Profiles and Saved Recipes. With some of the demographic and messaging guidelines planned out, we began working with a brand designer to help flesh out our logo and some other visual branding guidelines.
Working with CX, we tested those early wireframes to try to validate some of our assumptions. We did this using Usertesting.com and by doing some simple testing with friends and family members. We ran competitive user tests pitting our wireframes and ideas directly against our eventual competitors. We were very diligent in using real content and recipes to flesh out our wireframes. This gave us the ability to alleviate some of the guesswork as we stubbed out the front and back end engineering specs. Ryan was writing all of the Elixir and React and I was working heavily in markup and scss.
Within a month or so it became more and more clear that - as Ryan and I split our time between design, strategy, and implementation - we needed help. I recruited another senior-level engineer that Ryan and I had worked with before and we brought in our first design hire - a former designer with AllRecipes. Being the de-facto design lead, I began taking on more and more responsibility. I continued contributing day to day as a designer but was defining processes, having 1:1’s and reporting back to the CEO. This transition into leadership was not an easy one. I started reading every management and pseudo-management book I could remember - asking for recommendations from friends managing design teams as well.
Around this time we were also talking with the amazing folks at Treble Apps about transitioning our general web presence to native apps. We were incredibly lucky to have one of their designers - Diana - come on board part-time to help speed up our product design workflow. Our recently hired Senior Engineer - John - transitioned into a CTO role. Not long after, He and I worked with the CEO to bring in another designer - Tim. Tim dove right in, taking a huge load off my shoulders implementing designs that had been approved and were bottlenecking on the front-end. At this point we, unfortunately, ended up having to let one of our designers go. It was heartbreaking. Regardless of what his skillset was and how it matched with the company, it is never easy to make the decision to let someone go.
As we got through beta release and approaching the finish line on our V1 feature sets, I was starting to feel burnt out. 60 to 80 Hour weeks over the last few months had caught up with me. Balancing my contribution and leadership responsibilities with Mealthy and the responsibilities of my “Day Job,” had become untenable. Our CTO’s incredible leadership and the addition of a couple more engineers had alleviated any bottlenecking in feature production and release cycles. With Tim and Diana taking on the bulk of the day to day design work, I was able to start to transition myself out. After 8 months of working on Mealthy, I took a step back to transition to being a consultant and set of fresh eyes for the design and engineering teams when needed.
What I learned
Once upon a time I was in retail store management and before that I was a QA manager at a telemarketing company. I’ve been in positions of relative influence in the past but not in organizations built around collaborative work. During this time I was reading books like Leaders Eat Last, Crucial Conversations and The Hard Thing About Hard Things. A lot of the lessons I was learning centered around working with people in a position of institutional influence. One of the things I encouraged all of our team members to do was to work cross-functionally so that decisions could be made closer to the problems. We purposefully hired designers that could code and engineers with opinions on UX for this reason. Working on something this early-stage also re-enforced the power of working quickly and iteratively and revealed very plainly the dangers of working that way without definitive plans and roadmaps.
What would I do differently?
I am a loud voice on any team. I’m passionate and confident and willing to be wrong. to that end I think that when I left Mealthy I did so in a fashion that - despite my best efforts - did not set the designers on the team up for success in the ways that I could have. There was a vacuum left in the power structure that felt like it pushed some aspects of design and UX away from the forefront of the conversations.
While I mention above the importance of cross-functional team members and their efforts being an important part of the success of the products, I would be remiss if I didn't mention the strain that structure put on our design team. After the fact, I had one of the designers on my team mention to me that he wasn’t sure he *really* did much design work at all on Mealthy. He spent all his time implementing designs and iterating them on the fly. I think this is fine sometimes in small pods or squad models. When this is the reality of team members for long periods of time it can become a problem. Over-use of one set of skills in a person tends to deplete the tank on other skills. If we’re going out of our way to hire T-Shaped folks, It stands to reason that we would want to keep them T-shaped in practice and in development. Obviously sometimes we have to make use of those skills to meet deadlines. I really wish we had hired a couple more engineers with Deep T’s into front-end development, so we could put more time into ideating and testing, rather than implementation.
Last time I looked, Mealthy had nearly 340k unique likes on facebook, 340k followers and a bustling online community built around facebook. The Mealthy Multipot is an Amazon Best Seller within a year of release and other products by the company are Amazon Picks. I'm insanely proud of the work I was able to do with the team at Mealthy. Echoes of my early work can be seen on the website, in the app and across the content they create. I look proudly at their ongoing success and look forward to the amazing things they launch in 2019.