What Fable Means for Product and Engineering
In my first use of Fable, it fixed a bug that had vexed all the highest models from OpenAI, Gemini, and Anthropic for two weeks. For that I will forever be loyal. It does point toward a world where more software is built from specs instead of traditional engineering cycles. The bottleneck in software companies moves even further from engineering output to product marketing: sales enablement, customer education, and feedback loops.
Someone asked me a good question recently (really they did):
I feel like you’re on this interesting thread of spec engineering, and I’m curious how engineering and product change when the models are all Fable-level and we’re just writing specs.
I think I’ve had the right endpoint in my head for a while. Fable is probably the leap that makes this clear to non-developers. Engineering output is becoming dramatically more assessable for everyone, not just developers.
For the last decade, the hard part was getting software built. You needed enough engineers, enough time, enough prioritization, enough product clarity, and enough patience to turn ideas into production software.
AI is changing that. Now you can build far more than before. You (YOU!) can turn specs into features. You can prototype, ship, rewrite, and extend products at a pace that used to be unrealistic.
The Most Interesting Question: “What breaks when we can build almost anything?”
I think the answer is product marketing.
I do not mean product marketing as writing a launch blog post. I mean product marketing as the operational system that turns product output into revenue.
When engineering can build dramatically more, someone still has to answer three questions:
- Does sales know how to sell what shipped?
- Do customers and prospects understand what changed?
- Does the company know which features deserve more investment?
That is where most companies are going to struggle.
How Fable changes engineering
Spec engineering changes the shape of product development because the distance between idea and implementation gets shorter.
A product person can write a more detailed spec. A model can turn more of that spec into working software. An engineer can review, shape, correct, and integrate the work faster than before.
This is a huge shift.
But it also creates a trap. If the only thing a company measures is output, the company will assume more shipping means more progress.
That assumption is going to break.
More features do not automatically create more revenue (obviously). More releases do not automatically create more customer understanding. More roadmap velocity does not automatically make sales more effective.
A company can ship faster and still fail to create more market impact.
That is why product marketing becomes more important in the Fable era.
Why product marketing becomes the bottleneck
Product marketing becomes the bottleneck because it sits between what the company builds and what the market understands. AI is not as incredible for Product Marketing as it is for engineering. If you've read AI slop, you know why.
When product output increases, the company has to process more change. Customer success has to know who needs to hear about it. Support has to understand what changed. Customers have to notice the features that matter to them. Prospects have to understand why the product is now more relevant than it was before.
That work does not happen automatically for many (For Arkweaver customers it does :)).
In a slower product environment, companies can get away with loose product marketing. A quarterly launch, a few internal docs, a customer email, and a sales enablement meeting might be enough. In a high-output environment, that system collapses.
The problem is not that companies will lack features. The problem is that they will lack the machinery to turn those features into awareness, adoption, pipeline, retention, and expansion.
Why sales enablement breaks when engineering output increases
Sales enablement is the first obvious breakage point.
If a team ships five meaningful things a year, enablement can be handled manually. A PMM writes a few docs, runs a meeting, updates the deck, and sales mostly keeps up. Although if you ask anyone outside of sales, "sales never listens"!
But what happens when a company ships 200 things in five months?
Some are small. Some are massive. Some are deeply relevant to specific deals. Some only matter to one persona. Some should change the sales story immediately. Some should be ignored. You've got a big, messy information routing problem.
Someone in the Arkweaver subreddit described this well. Their company had built over 200 things in five months. Some were small, like a new report, but a few were huge. The roadmap had 10 or more huge things ready for the second half of the year.
Their comment: Management was going to be shocked if they expected decent revenue from all of that output. Marketing and sales budgets were not increasing. Headcount was not increasing. If anything, the new product output was creating an ungodly distraction.
That feels right to me.
If you increase product output without increasing the company’s ability to explain, sell, and support that output, you do not automatically get more revenue. You have a massive water hose trying to fill a tiny hole.
Sales reps do not need a list of everything that shipped. They need to know what matters for their accounts. They need to know which customer asked for it. They need to know which prospect blocked on it. They need the right talk track, the objection it solves, and the proof point. They need to know whether this is a small improvement, a wedge into a bigger conversation, or a reason to reopen a closed-lost deal.
That is product marketing work, and it gets much harder when engineering output goes up.
Why customers and prospects tune out product updates
The second problem is customer and prospect education.
Most companies already struggle to get customers to notice what they ship. Now imagine the release volume doubles, triples, or 10x’s.
Customers will not read every changelog. Prospects will not remember every feature. Sales will not manually follow up with every person who asked for something. Customer success will not perfectly connect every shipped improvement to every account that cares.
This is especially dangerous because the team can still feel productive internally. And once you fall behind, its almost impossible to catch up.
The hard part is making sure each person hears about the specific thing that matters to them.
A prospect who asked for role permissions should hear when role permissions ship. A customer who complained about reporting should hear when the new report is live. A sales rep with three blocked deals should know exactly which shipped feature gives them a reason to re-engage.
Generic product updates will not solve this. Communication has to become customer-specific, account-specific, and revenue-aware.
Why feedback loops matter more in spec engineering
The third problem is feedback loops.
When building is expensive, companies naturally spend more time deciding what deserves attention.
When building gets cheap, teams can move on too quickly. A feature ships, everyone feels good for a day, and then the organization immediately turns to the next feature. But the most important question is often what happens after shipping.
Did customers use it? Did prospects respond? Did sales bring it into deals? Did it unblock revenue? Did it reduce churn risk? Did it create a new problem? Did it reveal that the company should double down? Did it prove that nobody actually cared?
This is where AI can create a bad habit that we all fall into. It becomes easier to build the next thing than to learn from the last thing.
The highest-performing companies will learn faster from what they ship. They will know which features deserve a launch, which deserve sales enablement, which deserve customer outreach, which deserve more engineering investment, and which were distractions.
That is the real product marketing job in the Fable era: making sure the company knows what matters.
Why buy vs. build gets harder in the AI coding era
There is another issue underneath all of this. A lot of companies are realizing that building everything internally is insane (my words).
At the same time, everyone is being pushed to use AI internally. So if you are a software company selling to other software companies, you run into this objection, “We’re building this ourselves.”
Often, they are not REALLY building it. Mostly they are experimenting with something that works in a demo but will not survive real workflows, integrations, edge cases, permissions, data quality, user adoption, or accountability. I can't blame them, their job depends on it.
This is the cycle we are in now but need to get through so we can move from performative ai impactful ai (yes a human wrote that line!)
The first wave of AI adoption made every company feel like they could build every workflow themselves. The next wave will be companies realizing that internal AI experiments and production-grade software are very different things.
There is a reason people still buy software.
They do not just buy the feature. They buy the maintenance, edge cases, integrations, reliability, workflow design, security posture, product judgment, and the fact that someone else is responsible for making it keep working. I think the “we’ll build it ourselves” reflex will fade. But for now, it is real.
The Fable era exposes Product Marketing and the divide between Dev and Revenue like no other model
Fable is exciting because it makes the act of building feel more accessible TO EVERYONE. More people will be able to turn a clear spec into working software. That is a massive change, and I do not want to minimize it.
If every team can ship more, then shipping itself becomes less interesting as a standalone achievement. The advantage moves to the companies that can turn what they ship into something the rest of the business and market can actually use.
Over and over the questions should be (or will become!)
- Can sales sell it?
- Can CS explain it?
- Can customers understand why it matters?
- Can prospects connect it to a problem they already have?
- Can leadership see whether it created revenue, retention, or adoption?
- Can product learn from it before moving on to the next thing?
To quote Angela Bassett in Mission Impossible, "That's the job".
The companies that treat Fable as a way to build more features will get more features. The companies that treat Fable as a forcing function to redesign how product, marketing, sales, and CS work together will get a much bigger advantage.
I think this is the next bottleneck for software companies. Engineering output is becoming more accessible. Product marketing capacity is not.
So the question for the Fable era is not only who can write the best specs. It is who can turn all of that new output into awareness, learning, and revenue.