RUTHLESSLY PURSUING SIMPLICITY IN DESIGNING GTM SYSTEMS
Aug 24, 2024
Ruthlessly Pursuing Simplicity in Designing GTM systems
In software engineering you have to ruthlessly fight complexity less you will create tech debt, 💩 code, and overthink yourself into a corner. In designing GTM systems, this is exactly the same.
If you are designing a GTM system (your Clay, Smartlead, CRM, etc.) you are designing a software system, it is just often not approached like a lower level one because we are optimizing for business value instead of technical/functional requirements.
Think like an engineer to design GTM systems that have the minimum necessary complexity to create your business value.
A specific example is thinking about Clay tables columns as a game of telephone.
In telephone, the more times a message transfers from one person to another, the more likely it is to get garbled - that human telephone chain is a system passing information from one person to the next, just like your Clay table, passing information from one column to the next.
The more columns, the more likely you are to add in noise, (something you think you need but really don't is a classic) - I used to have sooooo many unnecessary steps in my Clay tables - they cost me credits, time overthinking and actually produced worse outcomes.
Every column in a Clay table must justify its existence, if it does not do something critical, remove it.
Complexity is expensive, it slows you down, and it compounds any errors/incorrect assumptions you've made. A great visual of "simplicity is the ultimate sophistication" is below SpaceX's rocket engine generations - see all those hours of testing and iteration in those?
So fight and reduce complexity wherever you can. Always ask yourself "is this worth the complexity cost?"
"Is this added complexity going to improve my likelihood of producing business value?"
And weigh how much additional complexity it will cost.
When you make mistakes and your assumptions turn out to be wrong, (as a certain percentage will always be wrong) they will compounded less, and your future self will thank you for not wasting time overengineering something that is a pain to maintain AND when it turns out that problem your client told was a hugggeee pain and required a fully end to end automated solution, and that the best solution was really they should have just stopped that business process entirely because it wasn't actually attributable to any new value and wasting bandwidth (may have experienced this once or twice lol) you'll be grateful you saved the time and effort