This Post Brought To You By The Letter “P”
Ah,the famous business “pivot.” All a tech startup need do to reach eminent fame and fortune is simply pivot once their original idea goes south, right? Clearly, every company anyone has ever heard of got their feet wet in a humorously unrelated business. Nokia started out making rubber boots to compete against the well known Russian imports. YouTube got its start as an online video dating service, and Flickr was some sort of online game. Even Starbucks had absolutely no interest in selling coffee, content with their profitable business manufacturing brewing equipment and distributing coffee beans.
Etymologically, the word pivot in this connotation is rooted in a basketball analogy. To avoid losing the ball or getting stuck, a player can pivot. Eric Ries (a well-known expert on pivoting if there ever was one) put it like this: “rather than hit the ground with the product, they ‘pivot’ just in time to save themselves from crashing.”
Learning when to pivot (and to what extent) is perhaps one of the most difficult choices to make as an entrepreneur. You could have the greatest product on the planet, just no one knows about it because you lack the marketing budget necessary to bring your idea mainstream. Finding out if your vision has any sort of basis in reality is something that takes market research, time, and flat out asking a lot of people. It also requires you to face your fears of admitting everything you did was crap, and needs to be thrown in the source code scrap pile. It leads to depression, as you contemplate the insignificance of your bitty little site on the Internet, like an ant peering up at the milky way. Maybe that revolutionary idea you had, though still intriguing to your consolatory friends and family, just doesn’t have the oomph required to go viral.
To make matters worse, there’s of course a spectrum of magnitude when it comes to a pivot. Do you scrap your rubber boot work force and hire a bunch of electrical engineers? Perhaps you just need to emphasize a single part of your product that seems to click. Twitter started out as Odeo, a audio-based microblogging platform. Turned out, setting up recording hardware is somewhat of a hassle and no one cared that much. However, once they made it simple and text based, Ashton Kutcher started using it the next day (ok this may not be entirely true.)
So what’s the difference between a pivot and just adding a bunch of new features? In my view, a pivot requires you to re-address the core user scenarios and customer problems addressed by your product. It may be the problem your business is trying to solve didn’t exist in the first place, or it could be the very business model has been obsoleted by the progression of technology (Blockbuster should have pivoted, instead they’re now all but dead.)
When pivoting, you don’t just burn down the building and forget everything you’ve learned. Pivoting involves keeping one foot where it is, and simply changing directions. This provides the advantage of bridging everything you’ve learned from the past and adapting it to a successful vision for the future. Of course, it also involves pissing off anyone who actually did like your product just fine before, so one should pivot only if certain death lay imminent otherwise.
The point of this post, as promised before, is to comb through what I learned through collecting data from real users and outline my ideas for the future of KitchenPC. After spending days of self reflection, it’s become clear that KitchenPC needs to pivot.
The First KitchenPC Pivot
Every web startup starts with a business hypothesis; “My theory is that business plan x will work.” The challenge is to prove or disprove your hypothesis before you run out of money. My original hypothesis was that people want an easy way to plan meals online using simple tools like a calendar, a grocery list, and pantry management. The fact I even had a recipe database in the first place was simply a technical requirement, as the ingredient aggregation behind shopping list generation necessitates a very normalized and proprietary data format. Searching for recipes was almost an afterthought, and I was happy to just be on par with other recipe databases on the Internet.
With that in mind, it’s quite possible there is a market for online meal planning. I’ve even managed to get a small collection of die-hard users who rave about how KitchenPC has changed their life. However, this business model caters to the type of user who wants to plan out each meal on a daily basis, manage their inventory as not to waste a single leaf of lettuce or ounce of onion, and print out accurate shopping lists to take to the grocery store on Sunday at 4pm sharp. Do they exist? Sure. Am I going to find a few hundred thousand of them to build a profitable business around? Not likely, at least not without a pretty massive marketing budget and a joint endorcement from Martha Stewart and Oprah on prime time television, just before the Desperate Housewives season premier airs.
Plus, 57% of users who filled out my recent survey said they just want to find recipes, they really don’t care about meal planning. Their words, not mine! Oh wait, those were my words – but the point is, they agreed!
The new KitchenPC will focus on searching, not on planning. In fact, I see this pivot as more of a bit flip. The old KitchenPC was perhaps 90% meal planning and 10% searching, the next iteration will be just the opposite.
I can now hear the disembodied voice of Eric Ries saying, “but Mike – a successful pivot requires you to adapt what you’ve learned from the past. How can we leverage the unique advantages of the current design to provide a better solution for recipe search?” This is a valid point, and also alludes to another aspect of this pivot. I’m now transitioning from creating a new market (online meal planning) to entering an existing market (online recipe search.) This transition requires a whole new thought paradigm in marketing, feature requirements, etc. Anyone who has read “The Four Steps to the Epiphany” will, of course, know what I’m talking about. It’s rather pointless to just create a search engine that lets you dig up recipes online. Google and Bing do that, and they have a whole team of people to make that pretty awesome too. Sites such as Foodily and Yummly are now my competitors, and I have to provide a better solution to have any sort of chance at gaining significant traction. The way to stand apart from these sites is to leverage the advantages my site already has, implementation wise. This advantage is, of course, KitchenPC’s ability to deal with multiple recipes at the same time.
Only 27% of users surveyed said they find recipes one at a time. The majority of users want to dig up a collection of recipes and work with several at a time. 58% of users want to search based on what a recipe contains or does not contain, by far the most desired from the survey. A staggering 95% of users expressed interest in pre-built meal plans, allowing them to just grab a bunch of recipes at once and be done with it. KitchenPC is definitely in a position to offer all of these advantages, and do it right.
Old Features, Out
The following features will be phased out, as there’s simply not enough interest to continue to invest in them. They also distract from creating a single, unified vision of simplicity.
- Pantry: The pantry has been wrongly accused of being an inventory management system and mostly scares users away. The pantry was originally intended for grocery store integration, which was a feature that was never implemented.
- Calendar: Users are, for the most part, not interested in this level of planning. Very few users are able to accurately predict when they’ll make a recipe and stick with it. There is no accountability with the calendar feature, and most recipes just “fall off” the schedule completely ignored.
- Shopping List: After studying the current shopping list behavior, it became clear that users are not interested in an online shopping list tool. While these make fun cell phone apps, people are not quite interested in logging on to a website and entering in what they need to buy at the grocery store. For the most part, the shopping list feature is used in conjunction with combining multiple recipes to figure out what to buy. This user scenario can be addressed in a much simpler way.
- Social Networking Features: Talk about a complete market failure. I spent much of my vacation in Hong Kong working on this feature, and pretty much no one uses it. Obviously, there is no interest in “following” another user to find out what they’re putting on their calendar, what recipes they uploaded, when they rate recipes highly, or when they leave comments. Most likely because no one uses those features either.
- Editing of Recipes: Since KitchenPC is being re-invented as a search engine, there’s actually no need to even have a recipe database. This will simply be a cache of recipes indexed from other sites on the Internet.
- Suggestions: Only 6.5% of users wanted KitchenPC to suggest recipes for them. Since suggestions only work if users take the time to rate recipes, and only around 2% of users have ever done that, I see no reason to maintain this feature.
New Features, In
The new face of KitchenPC will be geared around powerful recipe searching, while providing a simple to understand and minimalist user interface. Basic recipe searching will be front and center right on the home page, and will be the first thing people see when they enter the site. Searches can be done by keyword, by ingredient inclusions or exclusions (58% rated this as a high priority) and what meal the recipe can be served for (48%.) All other searching options will be hidden out of the way and exposed through a “More options” popup.
There will be three ways to search, each targeting a certain user scenario.
Scenario 1: Basic Recipe Search
This will be the default search mode (though trying out other defaults would be a good opportunity for some A/B testing) and provide basic searching abilities to find recipes on the Internet. This mode targets users who are looking for recipes to make before acquiring ingredients, which appears to be around 33% of users.
Scenario 2: What Can I Make?
This is the next evolution of the meal planning engine. In this mode, users can enter ingredients and (optionally) quantities, select the number of recipes they want, and generate an optimal set of recipes that will use those ingredients. This mode targets the 55% of users who claim they dig around the pantry or fridge to see what they have, then figure out what they should make.
Scenario 3: Pre-Built Meal Plans
An overwhelming 95% of survey respondents expressed some sort of interest in pre-built meals (though perhaps the question was loaded, so we’ll see how many users end up using this feature.) This mode will allow users to simply browse through plan categories and find sets of recipes that accomplish various goals.
For those of you reading this that are virtually yelling at me across cyberspace for my obviously ridiculous decision to remove meal planning and shopping lists from the site, here’s where you can start paying attention. Just wait.
All three of these search modes will have the common ability to work with sets of recipes displayed on the page. Every recipe will have a checkbox allowing the user to check or uncheck a result (or individual recipe within a pre-built meal plan.) At any time where multiple recipes are selected, a “What you’ll need” ingredient aggregation box will make itself visible along the side of the screen. This view will give you a real-time list of what ingredients and amounts you’ll need to make the selected recipes. This list is read-only, so there is no longer a need to worry about saving your shopping list, dragging stuff around, or modifying the contents. This decision was made after a careful study of exactly how people used shopping lists.
Furthermore, selected recipes can be saved as a menu in your cookbook. Menus are a logical progression of the cookbook that offers simple meal planning without all the fuss. A group of selected recipes can be added to a new menu, or appended to an existing menu. A recipe can exist in multiple menus as well (this is very important.) A pre-built meal plan can be saved directly as a menu, or individual recipes can be added to a new or existing menu. Menus will have names and optional “notes” associated with each.
When a user goes into their cookbook (which will probably just be called My Menus,) they can easily thumb through all saved menus. Whenever a menu is displayed, the aggregated ingredients are displayed at the side. Of course, individual recipes within that menu can be checked and unchecked as well. There will also be the opportunity to print a menu, which will print each recipe as well as the shopping list required for those recipes.
This feature provides some basic meal planning abilities without the convoluted calendar approach. A user can create a menu called “Thursday dinner party” and browse the site for recipes to add to it. There’s nothing stopping anyone from creating a new menu each week, or even each day. When they’re done, they can print that menu (or access it via the upcoming mobile app) complete with shopping list.
There will also be a built-in menu called “Recipe Queue” that is based around the familiar NetFlix® movie queue. Users can click one button to “queue up” recipes from anywhere on the site. There’s really no difference between the recipe queue and any other menu (besides the one-click ability to add to it) until a user goes to de-queue a recipe. When a recipe is removed from the recipe queue, the user is presented with a popup dialog asking if they indeed made the recipe. If so, they’ll be asked to rate the recipe, and have the opportunity to add the recipe to another menu. This will provide a way to close the feedback loop with the user and find out whether they made the recipe or not, and gather input as well. Users who simply want to browse the site looking for great recipes can just start queuing stuff up without having to worry about menu creation, losing track of their search results, and definitely not having to worry about what date they’ll make the recipe. For all KitchenPC cares, a recipe can stay on your queue for a year.
So, to summarize, KitchenPC will be re-invented as a powerful recipe search engine that can index millions of recipes out on the Internet through advanced natural language processing abilities and an in-depth understanding of ingredients and relationships. Users can save and group search results into menus, or browse pre-built search results known as meal plans. This design is far simpler than the current implementation, but still addresses 90% of what my users do.
What about my recipes that I spent hours uploading to your dumb site?
I knew you’d ask that. 34% of you said you want a place to store your own personal recipes online. Though this isn’t a majority, I would still feel bad about kicking you to the curb. That’s why I also plan on supporting “recipe uploading.” Users will have the ability to upload a recipe directly into a menu from the cookbook page. This recipe can be uploaded in any text format, including a Word document or PDF file. The recipe can also simply be a hyperlink, pointing to another recipe on the Internet. In the case of a hyperlink, KitchenPC will attempt to scan and index that link and assimilate the data into the KitchenPC search cache. If successful, the recipe will act as any other recipe available through the site. Of course with custom user recipes, features like ingredient aggregation and shopping list generation won’t be available, and these recipes will be private and not visible by other users. This will hopefully provide an opportunity for the 28% of users who bookmark recipes in their browser and the 43% who store recipes on their computer to use KitchenPC as a means to store recipe collections in the cloud; a Dropbox of recipes if you will.
I also haven’t forgotten about the 25% of users who jot down notes on recipes, and the 40% who want to change amounts and customize recipes. Recipes, once saved in a menu, will be editable by that user through the existing recipe editor (yay, I don’t have to throw away that massive chunk of code!) Users will be able to change any part of the recipe or add their own personal notes and a “fork” of that recipe will be persisted in the database just for them. This feature might also be exposed as a “Personalize this recipe” link on the recipe viewer. It would allow the user to modify the recipe and then immediately save it to one of their menus for later retrieval.
And I can get all this when?
Well, I’ve been working on wireframes and specs for all these changes but it’s no small amount of work. As of yesterday, I also received some new UI prototypes from my Polish designers that incorporate some of my ideas. With any luck, this new vision should be realized in the coming months depending on how all the various details get finalized. I figured I’d “tease” my readers now in order to get some feedback on this plan; perhaps I’ll be spammed with hundreds of nasty messages about how these ideas are terrible and no one will ever visit my site again. I guess better to know sooner than later. I’m quite excited about this new vision, and I really think this is a huge step in the right direction for KitchenPC. If not, maybe I can start selling rubber boots online.