Learnings from building Kelp: Getting people the information they need when they need it is hard!

I've decided to temporarily halt progress on Kelp and take [a job](https://www.akitasoftware.com/blog-posts/joining-akita-to-build-the-observability-solution-i-wish-i-had). Why? What did I learn? My goal with Kelp was to build a tool that "gets people the information they need when they need it." Hitting that goal proved more difficult than anticipated! Why? Recommendations are a multi-sided challenge. Kelp needs three things: 1. Access to the information to be recommended 2. Signals for when to recommend information 3. A UI for presenting recommendations For step one, we need to cross boundaries from native apps (like Chrome, Safari, or Messages) and API-driven tools (like Gsuite or MS Teams). Even with modern APIs, there are gaps in this data, leaving an "uncanny valley" of recommendations. > At best, Kelp can combine "meh" information with "meh" signals into a fantastic UI. > Meh times meh is still meh. For example, Kelp cannot compete with features like Safari's recommendations that pull from Messages. Kelp does not have access to links from Messages and cannot present recommendations on both mobile and desktop browsers on iOS.

For my users, Kelp was always missing some integration or they had a unique workflow that I didn't handle. As a solo-preneur, I found myself iterating more on integrations than on the core product. ## What does the future hold? I believe there is still space for a tool that provides contextual recommendations. We need less focus on helping people buy things they don't need and more on helping people be their best selves. However, with advertising dollars so close, contextual recommendations haven't yet had "big tech" dollars thrown their way. There are no tools that actively help us maintain relationships with friends ([clay.earth](https://clay.earth/) is perhaps the closest), prepare for work meetings, or find things based on context clues instead of keywords (e.g., "what was that book Nicki sent me?"). I'm not sure what the future holds, but I do want to reassess Kelp's optimal location (browser, desktop, or mobile) and how to best package it as a product (including questions around privacy importance). ## How might Kelp fit in with other tools? Kelp does not exist in isolation. It's part of a broader ecosystem of "personal information management" tools. Looking at the space overall is helpful for understanding potential positioning. NOTE: Similar to Kelp, these tools suffer from limitations of upstream APIs. ### Digital personal assistants Digital personal assistants have finally escaped the legacy of Clippy—only to run headfirst into the briar patch of call centers and support chatbots. As a result, consumer-facing digital personal assistants don't feel like an enjoyable "premium" experience. Some digital personal assistant startups targeted meeting scheduling (e.g., [x.ai](http://x.ai/)). Today we have Doodle, Calendly, and native functionality in mail/calendar apps that provide better UX around this messy transaction. It turns out that's all we really needed. What about voice-based personal assistants? Even with massive technological achievements, Alexa, Google Assistant, and Siri still remain [far behind](https://twitter.com/klivdahl/status/1475220450598924297) the prickly assistant in the [Knowledge Navigator demo](https://youtu.be/9bjve67p33E). The major issue they face is that the UX for a digital assistant is not clear or easily discoverable. A good product clearly sets expectations and then meets (or exceeds) those expectations. Digital personal assistants struggle to clearly indicate their possible behaviors, and as a result, people use them for a few narrow use cases they discover during initial usage. [[ref](https://mashable.com/article/amazon-alexa-usage-drop)] I believe the future of digital personal assistants lies in helping us navigate messy transactions. For example, in healthcare, chat UIs are meaningfully less frustrating than trying to actually visit your PCP. As a result, within that narrow scope, human-augmented chatbots are performing quite well for many digital health businesses. ### The 'command line' for your life There is significant hype in the "command line" space, but none have achieved mainstream adoption yet. Many will remember [Greplin](https://techcrunch.com/2013/10/02/cue-greplin/), and now we have [Raycast](https://www.raycast.com/) and [Searchable.ai](https://www.searchable.ai/). Similar concepts with different implementations. My hypothesis is that, similar to voice UIs, the interface for a command line is not easily discoverable. People will do some exploration when they first use the tool but rarely explore further. As a result, these will primarily serve the "optimizer" crowd. However, this audience is growing and has purchasing power. Expert tools can be viable businesses today. However, I believe the optimal UI for most tasks is direct manipulation—accurate and immediate. Command line tools sacrifice directness for the efficiency of hotkeys. For most people, correctness and control are more important than efficiency. ### End user programming End user programming is the concept that users should be able to write programs to perform simple repetitive tasks. Apple and Google smart home apps are probably the widest distribution of this idea. People can create rules such as turning off lights when they leave the house. This space faces challenges since it's easier than ever to simply learn to code. The segment of people who both have a problem that programming could solve but don't want to learn to code is relatively small. While "if this then that" has entered common parlance, spreadsheet-like solutions remain dominant, and "no code" solutions are evolving around narrower verticals (like smart homes). As a result, there is no mass-adopted solution for programming behaviors across all apps ([Apple Shortcuts](https://nick.comer.io/post/ios-shortcuts) might be the closest), and perhaps that's acceptable. ### "Desktop 2.0" (or 3.0?)

The "networked thought" model popularized by Roam Research and Obsidian promotes linking information not by "app" or "folder" but by [keyword]. What if this approach could extend to our entire desktop? Our files, web pages, and emails would be linked together like in Roam/Obsidian (minus all the [braces] and pound signs). While this solution might interest some users, it omits most social interactions and information that is passively rather than actively tagged by users. My hypothesis is that the next iteration of the desktop will center on people instead of apps. This new OS would extract data from apps (mobile) and files (desktop) via a global identity platform. As Meta moves to capture a higher percentage of people's time while navigating around Apple's ad blockers, I anticipate this becoming a major battleground in the next decade. ### Summary: The future is contextual recommendations I believe contextual recommendations need to be built seamlessly at the OS level to be effective, but as an independent developer, I lack the influence to effect this change. ## What did I learn from a business perspective? Find a small use case that people will pay for first. I should have conducted more thorough diligence on identifying specific customers with very specific needs. My target user group—people managers and individual contributors at startups with too many meetings—was too broad. Each individual uses their own set of tools (Gsuite, Notion, MS Office, etc.), and teams share information differently. I wanted to create a cross-tool solution, but there's value in a more focused approach like "we make Google Docs more efficient" rather than "we help you manage your team's information." I also learned that it's practically impossible to monetize Google Chrome extensions, so I should have abandoned that approach sooner. ## Last but not least: Open sourcing Kelp! I hope the tool proves useful to future innovators in this space. You can [check it out on Github](https://github.com/zamiang/kelp).