// NOTE: this post serves as an open request for feedback as I try to articulate the edges of a thesis I find compelling. I need to pressure test it, so please send me your thoughts!


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:

  • Developers - people who write code for a living
  • Code literate - people who don’t write code for a living, but understand what’s involved
  • Code aware - people who can wrangle a good spreadsheet, but are unlikely have never opened a text editor besides Word (this is the bucket that I have the most trouble with, so any thoughts are welcome!)
  • Obviously nontechnical - a large catch-all bucket for the widest part of the distribution, people who have a very limited technical understanding

Concentric circles of technical aptitude

Segmenting technical aptitude... you can't see it at this resolution but there's a tiny inner circle within the green where people are fighting the vim vs emacs flamewar

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:

HN post on Slack removing Markdown

HN discussion on Arthur O'Dwyer's November post

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!

A possible alternative

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.