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. Why? What did I learn?
My goal with Kelp is to build a tool that ‘gets people the information they need when they need it’. Hitting that goal proved difficult!
Why? Recommendations are a multi-sided challenge. Kelp needs three things:
- Access to the information to be recommended
- Signals for when to recommend information
- A UI for presenting recommendations
For step one, we need to crossing 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 this data, leaving an ‘uncanny vally’ of recommentations.
At best, Kelp can combine ‘meh’ information, with ‘meh’ signals into a fantastic UI. Meh times meh is meh.
For example, Kelp cannot compete features like Safari’s recommendations that pull from Messages. Kelp does not have access to links from Messages and cannot present my recommendations on both mobile and desktop browsers on iOS.
For my users, Kelp was always missing some integration or they had some unique workflow that I didn’t handle.
As a solo-preneur, I iterated more on integrations than the product.
What does the future hold?
I think there is space for a tool that does contextual recommendations. We need less of helping people buy stuff they don’t need and more helping people be their best self.
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 maybe!), prepare for work meetings or find things based on context clues instead of keywords (what was that that book Nicki sent me?).
I’m not sure what the future holds but I do want to reasses the location (browser, desktop or mobile) of a Kelp and how to best package it as a product (how important is privacy?).
How might Kelp fit in with other tools?
Kelp is not a tool in isolation. It exists in a big space of ‘personal information management’ tools. I find looking at the space overall helpful. How might Kelp fit in here?
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…and 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 tried to target meeting scheduling (x.ai…). Today we have Doodle, Calendly and native functionality in some mail/calendar apps that provide better UX around a messy transaction. It turns out, that is all we really needed.
The big 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 have a very difficult time clearly indicating their possible behaviors and as a result, people use them for a few narrow use cases they discover when first using the tool. [ref]
I believe the future of digital personal assistants is in helping us navigate messy transactions. For example, in healthcare, chat UIs are meaningfully less annoying than trying to actually visit your PCP. As a result, within that narrow scope, human-augmented chatbots are doing quite well for many digital health businesses.
The ‘command line’ for your life
My hypothesis is that similar to voice UIs, the ‘interface’ for a command line is not easily discoverable. Similarly, people will do a little exploration when they first use the tool and then never again. As a result, these will be tools for the ‘optimizer’ crowd. However, the optimizer crowd is a growing audience and they do have purchase power. Expert tools are not a terrible business these days.
However, I believe the optimal UI for most things is direct manipulation - accurate and immediate. Command line tools sacrifice directness for the efficiency of hotkeys. I do not believe efficiency is the most important thing to most people - but correctness and control.
End user programming
End user programming is the idea that a user should be able to write programs to do simple repetitive tasks. Apple and Google smarthome apps are probably the biggest distribution of this idea. People can write a rule that turns off the lights when they leave the house.
This space is in a tough spot since it is easier than ever to just…learn to code. The segment of people who both have a problem that programming could solve but who don’t want to learn to code is relativel small. While ‘if this then that’ is common-ish parlance, spreadsheets-like solutions remain king and ‘no code’ solutions are being created around narrower verticals (like smart homes!).
As a result, there is no mass-adopted ‘let me program behaviors across all my apps’ solution (Apple shortcuts?), and maybe that is ok.
“Desktop 2.0” (or 3.0?)
The ‘networked thought’ model popularized by Roam & Obsidian is pushing a way of linking information - not by ‘app’ or ‘folder’ but by [keyword]. What if this could be adapted to our whole desktop. Our files, web pages and emails would be linked together like Roam/Obsidian (minus all the [braces] and pound signs).
While that solution might be interesting to some, it leaves out most social interactions and information that is passively rather than actively tagged by the user.
My hypothesis is that the next iteration of the desktop will center on people instead of apps. This new OS would pull data out of apps (mobile) and files (desktop) via a global identity platform.
As Facebook moves to capture a higher percentage of people’s time while avoiding Apple’s add blockers, I see this as a big battleground of the next decade.
Summary: The future is contextual recommendations
I believe contextual recommendtions need to be build in seamlessly at the OS level to be effective, but on the outside as an independent developer, I am powerless to affect this change.
What did I learn business wise?
Find a small use case that people will pay for first.
I should have done much more diligence on finding a specific customer with a very specific need. My user group was people managers and individual contributors at startups with too many meetings. However, that group is just too broad since each individual has their own set of tools (Gsuite, Notion, MS Office…) and their team’s share information differently.
I wanted to be cross-tool but I do think there is power in saying ‘we make google docs not suck’ and building a tool around that rather than say ‘we help you manage your team’s information’.
It is impossible to charge money for Google Chrome extensions so I should have killed that idea sooner.
Last but not least: Open sourcing Kelp!
I hope the tool is useful to future people in this space. You can check it out on Github.