Building Substack | Sachin Monga (Substack, Facebook)

Executive Summary
Sachin Monga describes communication, principle-based choices, creator control, recommendation context and building with users. Selected third-party transcript coverage excludes sponsor reads, AI passages, earnings and growth figures, product availability, roadmap predictions and political or creator recommendations. Substack examples are his historical accounts, unverified here. Untimed editorial topics are not video chapters.
Key Takeaways
Build trust through repeated communication
Monga describes regular discussions with the founder about the important problems and worries, followed by later check-ins. In his account, working together repeatedly helped trust form. A recurring meeting is useful when it supports an honest conversation, not merely because it occupies the calendar.
Use a principle to choose between options
He describes writer and reader control as a principle that shaped product choices. When several approaches are possible, the principle offers a reason to prefer one. This is his account of Substack's thinking at the time, not a claim about the product's current behavior.
Inspect who owns the experience
Monga asks whether a discovery feature changes a space the writer previously controlled. A seemingly useful growth idea can still conflict with the relationship between a creator and audience. Identify who makes the choice and whose experience changes before adding a feature.
Test the simplest principle-consistent version
His recommendations example asks writers whom they recommend rather than inserting unrelated choices into their space. The approach depended on several user actions and was uncertain before testing. A principle can guide a concrete experiment without making the outcome predictable.
Consider the trust behind a recommendation
He distinguishes a recommendation seen by a new subscriber from one received after a long relationship with a writer. Those contexts may carry different meaning. The placement of a feature is therefore part of the experience, not merely a way to expose it to more people.
Build changes with the people affected
Monga describes involving writers when making fundamental changes. Early feedback lets the team learn how a feature fits the existing relationship with the product. The purpose is to bring users into the process rather than surprise everyone with a fully settled change.
Let feedback change the first release
He says the feature shipped on day one could differ substantially from the original idea after feedback. A pilot is useful when the team is willing to revise what it builds. Treat early users as sources of learning rather than only as people confirming the plan.
The Conversation Breakdown
Build trust through repeated communication
⏱ Untimed topicMonga describes regular discussions with the founder about the important problems and worries, followed by later check-ins. In his account, working together repeatedly helped trust form. A recurring meeting is useful when it supports an honest conversation, not merely because it occupies the calendar.
Use a principle to choose between options
⏱ Untimed topicHe describes writer and reader control as a principle that shaped product choices. When several approaches are possible, the principle offers a reason to prefer one. This is his account of Substack's thinking at the time, not a claim about the product's current behavior.
Inspect who owns the experience
⏱ Untimed topicMonga asks whether a discovery feature changes a space the writer previously controlled. A seemingly useful growth idea can still conflict with the relationship between a creator and audience. Identify who makes the choice and whose experience changes before adding a feature.
Test the simplest principle-consistent version
⏱ Untimed topicHis recommendations example asks writers whom they recommend rather than inserting unrelated choices into their space. The approach depended on several user actions and was uncertain before testing. A principle can guide a concrete experiment without making the outcome predictable.
Consider the trust behind a recommendation
⏱ Untimed topicHe distinguishes a recommendation seen by a new subscriber from one received after a long relationship with a writer. Those contexts may carry different meaning. The placement of a feature is therefore part of the experience, not merely a way to expose it to more people.
Build changes with the people affected
⏱ Untimed topicMonga describes involving writers when making fundamental changes. Early feedback lets the team learn how a feature fits the existing relationship with the product. The purpose is to bring users into the process rather than surprise everyone with a fully settled change.
Let feedback change the first release
⏱ Untimed topicHe says the feature shipped on day one could differ substantially from the original idea after feedback. A pilot is useful when the team is willing to revise what it builds. Treat early users as sources of learning rather than only as people confirming the plan.
Core Frameworks & Ideas
Principle-based choice
Compare alternatives by how they preserve the writer's and reader's control in Monga's account.
Experience ownership
Identify who chooses what appears and whose relationship with the product changes.
Build with users
Bring affected users into early feedback and let that feedback alter the release.
Actionable Next Steps
- ✓Compare two feature approaches against a stated principle.
- ✓Name who controls the changed experience.
- ✓Invite feedback from the users affected by the change.
- ✓Record what the pilot changed about the first release.
Notable Quotes
“There's just a lot of open communication. I think that helps a lot.”
“What if we just ask writers, who do you recommend?”
“Often the thing that we end up shipping on day one tends to be pretty different from what we had in mind before we went through this process.”
The One Thing to Remember
A product principle earns its place when it changes the concrete version the team chooses to test.