RECOMMENDED READING FOR A BETTER CONTEXT:
KEY TERMS:
The founder never knows a customer: I’ve learned it from my 10 years of experience of engagement with founders. Also, that’s what many GTM books tell, a fresh example is “The Power of Pull” by Rob Snyder. If you don’t believe me, take a logical stance.
We have a syllogism here: two premises and a conclusion. Each promise is a conditional relation.
If you're a founder, you are looking for problems to solve. Problems justify your role as a founder. Yet, this attitude implies a false relation #1: if a customer has a problem, he or she needs to solve it. Counterintuitively, no. Many problems are simply not worth solving. Customers deal with hundreds of them daily, and live their normal life. But a founder's mindset is simply productivity-biased as he (himself) is looking to optimize the market. In the same fashion he sees the customers — as “optimization functions” who tend to maximise utility and avoid friction. In reality, customers simultaneously participate in multi-dimensional problem solving spacing and the majority of their motives are hidden from the observer.
A false implication #2 is if a customer has a problem, he or she is willing to pay to have it resolved.
And this leads us to the #3 element — a false conclusion: if we solve the customer’s problem, he / she will pay us. That’s absolutely not so.
Let’s take an example. A founder builds an MVP of a software that finds the most interesting episodes in long-term video and sends a customer a timecode. So, the founder builds a draft of the GTM framework and wants me to validate it.
Here’s my necro-analysis perspective (I use this term to revert a GTM perspective from positive to negative):
Let’s apply the logical fallacy framework to this case.
Proposition 1: The problem is real. But does a buyer need to solve it? In other words, is this buyer’s priority? If so, for whom?
The founder found a problem that lies in speed or time economy (addressable metric). So, it is relevant for time-sensitive operations, but it is not acute — “we still can perform, but it will be better if we can do it faster”. So, my blind guess is that it's a problem, but customers don’t necessarily need to solve it as a matter of first priority. This is to say: if other constraints are applied to the process under the same budget (strictly!), this solution is not a priority — buyers may sacrifice this feature at all.
Once I fired it, the founder argued — you don’t have much experience with it, it is important for customers. Especially, for agencies who charge to a 90 minute video and deliverables are highlights (among other things).
Right, let’s go on with Proposition 2: if a customer has this problem, will he or she pay for it? The founders normally go for introductory interviews and sales calls to discover it. In my case, the founder did a clipping of narrative of other (similar) products that’s used in their promotion — competitors' marketing claims. That’s the second order Voice of the Customer. So, I can’t seriously discuss it. Simply, no data here (too prone to speculations). But what is the role of this question? It’s a blocker discovery. Customers may lie and they often do. Narratives might be malformed or malinterpreted (most often). But the question reads one important thing — is this a blocker?
My perspective is as follows:
This is a necro-analysis premise. If you need to pressure-test your GTM, the negative perspective is essential. In our case, it’s the largest flaw — building the MVP on a mental construct that sound like this:
Does it hold together? No, it does not because there’s no separate recognizable line for this in a balance sheet. Any product’s value is a whole. If someone — as in our case — tells this: … "If [the feature ] saves you 30–60 minutes per project, then even $10–$20 is nothing for a working editor [like this]" it means that they are trying to sell the bundle of features at a discount from its face value (a marketing trick). If you unbundle, you can’t claim the pricing logic holds in your case. Simple as this.
Final reasoning: if we solve a problem, a customer will pay us. This forms an invalid syllogism: if the problem’s priority and a status of a “blocker” is confirmed, then, the customer must buy. But it’s not so.
Customers will buy if it's weird not to buy — it’s easy and all conditions are met, including: a perfect integration (export) to their preferred editing tools and a fair pricing. What’s important is the product is the third layer assistant tool (deeply in-flow):
This means for the customer it’s weird not to buy if the pricing model favours his / her workflow economy. For example, “pay per export” or a discounter model — buy usage tokens at a discounted price in large numbers and spend it on export as you wish.
But here’s comes the “Great doubter” risk — what if the 2nds layer assistant will introduce this feature later on? Every customer willing to buy may think of it: this will discourage a discounter model that reads “committing”.
Therefore, theoretically, the product might be solved if customers feel weird not to buy, which implies an attractive pricing. But in reality, it can’t be taken for a truth unless the willingness to buy itself is confirmed empirically, not from the competitors' marketing copies.
This implies a GTM strategy — a limited test to prove the buyer decisions and to earn some early champions.
This is an example of necro-analysis — a deliberatively negative perspective over the GTM framework that starts early on, with ICP definition and Value Proposition testing.
This example shows that a founder is deprived of an ability of reading buyers mind as he falls into three logical fallacies here.
Why the Acquisition plan seems wrong?
Growth rarely fails because of lack of effort. Often, it's a result of misalignment between what customers want, what they need and what they are willing to pay for.
If you want to discuss your GTM or SEO strategy, let's chat.
About the author
SEO/GEO consultant with 17 years experience in Organic Acquisition and findability.

Bohdan Lytvyn
"WASTELESS GROWTH" BOOK AUTHOR