Having spent many hours recently learning to code, and after having spent 17 years in sales, I decided to build a tool for people who sell technical saas products.

This is because having worked in both non-technical and technical sales, I have learned there is vast differences in what is required to be effective.

For starters, non-technical products are easy to understand for both the person selling the product, and the person buying the product. Therefore there is not much complexity in use-cases to worry about. For the sake of talking about this in the future I will name this dynamic sellingSimpleProducts.

The definition of sellingSimpleProducts: is a product that a buyer can understand with no real explanation needed. A salesforce seat for a sales person neatly fits this definition. It’s super easy to understand what salesforce does, how to use it, and who would buy it.

By contrast, what I’ll call sellingComplexProducts is not intuitive. If they are API tools, or something else that might fit into your tech stack, it is often harder to understand the core value the tool may provide. It is often also true that there will be multiple use cases for the tool – and each use case may be quite independent and standalone.

Definition of sellingComplexProducts: a product that a buyer struggles to understand – even after speaking with a sales person for an hour or more. Often times sellingComplexProducts require a sales engineer to explain and sell. This further complicates the sales process because there is no longer a single person responsible for generating revenue – there are at least two people – the sales person and the sales engineer.

Further complicating things is that sales people and sales engineers must now navigate an often months-long, multi-step, multi-threaded sales process that includes further complexity, like:

• Changing stakeholders
• Changing use-cases
• Changing priorities
• Changing budgets
• Changing value prop to the buyer as the use-case changes and therefore pricing sensitivity is also changing either up or down.
• Etc.

All of which is incredibly hard to keep track of using unstructured data in a notes field inside of a salesforce opportunity – or – using unstructured audio data in a sales training AI tool like Gong or Chorus.

This is because sellingComplexProducts does not lend itself to audio or text very well. (If you’ve ever tried to listen back to a 60 minute call in which an architect or CTO explains there current architecture, you’ll know what I mean).

In fact, in my time working in very technical saas companies I’ve found that short, structured, simplified data (that is often visual) is easily the best way to capture high-signal information with little effort.

However, making something that is intuitive, easy-to-use and does the task as needed is not easy or simple.

And so I’ve decided to attack this problem and am currently building a sales tool to help technical founders, technical sales people and sales engineers get more signal faster, collaborate more easily and close more revenue with less pain.

Stay tuned.