Module 6. What I learned building this end to end.
The hard no was harder to keep than to write.
In Module 1 I wrote one sentence: we will not optimize the companion for attachment. It took two minutes and felt obvious. Then it cost me something in every module after that.
In Module 2 it made me cut daily streaks, which was easy, and Fable for Teams, which was not. That one had real revenue behind it and a sponsor in business development. The scoring matrix would not have killed it. I cut it because employer reporting incentives push against both the hard no and our privacy promise. I did write down that it is the first thing to revisit if the companion works, because pretending I would never look at it again would have been dishonest.
In Module 3 I found out the rule was not usable. Retention's fastest levers and the thing my hard no forbids look the same inside a real ticket. Both are a notification. The difference is intent, and you cannot test intent. So I had to write an actual line: if a signal from that specific user triggers the check-in, it is fine. If elapsed time or a frequency target triggers it, it is not.
Then in Module 4 I nearly gave the rule away myself. In the negotiation I was ready to concede which signal fires a check-in as long as the cadence ban held. That concession breaks the whole thing, because time since last open is a user-specific signal. My own bright line had a hole in it and I did not see it until someone pushed.
One sentence in Module 1 took four modules to turn into something my team could actually use.
My business case fell apart the first time I tested it.
I wrote it as a growth story. It did not hold up. The numbers said something less exciting and more useful: Fable is sitting within cents of its cost of capital and nobody knows which side of the line it is on. It took three rounds to reframe the bet as fixing that, rather than as growth. The version that worked is the one that leads with what we do not know.
Good unit economics do not make a bet worth funding. In Module 5 I reviewed a case where the numbers were better than mine, and the right answer was still no. The problem was the ceiling. It treated a fixed group of 3,000 people as if it refilled every quarter, and the whole prize was about $414K a year against a business with 4.2M users. I have said yes to things on a good ratio before without asking how big the pool underneath it was.
Speed can be a strategic bet. Making sub-2-second load time a Rock felt wrong, because it takes engineers away from the differentiator. For this product it is right. If the promise is that Fable is the first thing you talk to when something feels off, then a four second cold start is not a performance problem. It is the promise breaking at the front door.
The assumption I worried about was not the one that mattered. I spent the whole model nervous about the link between felt-understood and retention, because I derived it from my own OKRs instead of measuring it. It turns out a 30% miss there still approves the bet. What actually carries the case is a 4% churn tail that nobody has ever measured. It is 74% of the value and it flips the headline. I only found it by asking what breaks the case instead of reading what the model showed me.
A strategy is only as real as the number that would end it.
I thought I was done when the cascade held together and the OKRs came out of it cleanly. It read well. Nobody could have argued with the logic.
But nothing in it could have been proven wrong. I could defend every part of it, and that is not the same as being able to test it. Writing the kill criteria is what changed that. A metric, a number, a date, and what happens to the budget and the people when it trips.
It is the same lesson as the hard no. That was a value until I wrote the test that catches it in a ticket. The strategy was an opinion until I wrote the number that would make me stop. Judgment only travels if someone who is not me can act on it.