Managing Partner @ Abstraction Capital
As an investor, I am focused on what I think of as ‘technical tools.’ That is, tools that either help developers build or deploy code, or tools that help pseudo-technical users do developer-like things. There are some edges for this where it’s hard to delineate what is/isn’t a tool for a technical user, especially in the collaboration space. In fact, much of my thinking here stems from the question, “so does this include stuff like Slack?,” which comes up a surprising amount in conversation.
I have been working on a simple test to better define the edges of this thesis… To start, let’s put the world of users into some discrete buckets, ranging from obviously technical to less technical:
Using the visualization above as a mental model, I’d say that I am targeting products that cater to the inner two circles: people who write code for a living (self-explanatory) and those who are code-literate, are part of some software development processes, but don’t write code for a living (product managers, some project managers, some business analyst types).
The best heuristic I have come up with for tools that cater to these segments is what I have dubbed ‘the Markdown test’ and it’s very simple: does this product support Markdown input?
It feels like a pretty good marker; I don’t know anyone with zero technical chops that knows Markdown, but it’s also not so abstruse as to exclude those pseudo-technical users that are part of the design/build/deploy process.
Hilariously enough, using Slack as a case study even provides a recent example of what happens when you start out with Markdown support and pull it in favor of a WYSIWYG input:
In summary: a revolt that led to Slack walking back the changes.
I’m not suggesting that developers or technical people universally love Slack, or really even Markdown. It’s just the simplest heuristic I have managed. So, for now, the edge of this thesis on technical tools covers collaboration tools as long as they support Markdown. Please reach out and help refine my thinking!
Another vein I have explored was along the lines of what integrations a tool has. For example, was it designed with integrations to(git workflows, Jira, Segment, etc)? The problem with this logic is that it’s self-referential… the tools in the integration set have to be defined as to whether they are technical tools.