How Persistence and Stubbornness Change During a Long Build

Persistence and stubbornness look identical from the outside. Both involve a refusal to quit when things get difficult. However, during the multi-year arc of a long build, the difference between them becomes the difference between a product that matures and a product that stagnates.

Persistence is a commitment to the problem you are solving. Stubbornness is an attachment to the specific way you initially thought you would solve it. In the early stages of a project, a founder needs a high degree of stubbornness to survive the initial skepticism of the market. But as the build continues, that same stubbornness can become a liability if it prevents the founder from hearing the "product truth" that only users can provide.

The Shift from Vision to Interpretation

When I was building Postly, I did not have the luxury of building from a distance. I spent an enormous amount of time in support conversations, chat windows, and bug reports. This closeness revealed a tension that every founder eventually faces: the gap between the vision in your head and the reality of how people actually use the software.

Early on, you persist because you believe your vision is correct and the world just hasn't seen it yet. But as you enter the middle of the journey, persistence must evolve into a disciplined act of interpretation. Support is where users stop being abstract. It is where you see where your onboarding fails and where your UX creates hesitation. If you remain stubborn about your original interface or workflow in the face of this data, you are no longer persisting; you are resisting reality.

The Persistence vs. Stubbornness Matrix

Distinguishing between these two states requires looking at how you respond to feedback. Persistence seeks the underlying truth in a complaint; stubbornness seeks to defend the current implementation.

The Editorial Filter

To prevent persistence from curdling into stubbornness, we developed a system at Postly that was more editorial than technical. We learned that the founder’s job is not to obey feedback, but to interpret it. Not all customers deserve equal weight. Some users teach you how to grow, while others only teach you how to react.

When a request or a friction point arises, we filter it through five specific questions to determine if we are being persistent about quality or stubborn about a mistake:

• Is this a pattern or a single person's frustration? Stubbornness often fixates on the loudest voice; persistence looks for the signal in the noise.
• Does it align with the kind of product we are trying to build? This protects the product from becoming a support transcript turned into software.
• Will it create clarity or complexity? Persistence favors the long-term health of the system over the short-term satisfaction of a single user.
• Does it strengthen the system or merely satisfy an emotional moment?
• If we say yes, what future maintenance burden are we also saying yes to?

This filter is essential because maximum signups are not the same thing as maximum ROI. High activity is not the same thing as healthy fit. By using a filter, you can remain persistent about the product's core value while remaining flexible about how that value is delivered. You can read more about this balance in our essay on the founder tension between ambition and patience.

The Failure Modes of the Long Build

If a founder fails to transition from stubbornness to interpreted persistence, two primary failure modes emerge:

1. The Negotiation Trap

This happens when the founder stops interpreting and starts obeying. The product becomes a negotiation between incompatible desires. One user wants more settings; another wants less friction. Without a persistent vision to act as a North Star, the product loses its identity and becomes a bloated collection of edge-case features.

2. The Visionary Blindspot

This is the opposite of the negotiation trap. The founder remains so stubborn about their original "genius" idea that they ignore clear evidence that the market wants something slightly different. They treat support as a nuisance rather than a research lab. This often leads to a product that is technically impressive but practically useless.

How to Audit Your Current Stance

If you are currently in the middle of a long build, it is helpful to pause and ask which parts of your roadmap are born of persistence and which are born of stubbornness. Persistence feels like a steady climb toward a peak; stubbornness feels like pushing a boulder up a hill that no one asked you to climb.

Review your most recent support tickets or feature requests. If you find yourself feeling defensive or annoyed by the users' inability to "get it," you are likely slipping into stubbornness. If you find yourself curious about why they are struggling—even if their proposed solution is wrong—you are practicing healthy persistence. This is a core theme explored in GrowthDiary and the broader philosophy of the long build.

As you move forward, remember that the best way to respect your customers is not to build everything they ask for. It is to hear what their requests reveal about the product truth and decide whether that truth belongs in the product’s long-term identity. For more on managing these internal shifts, see our guide on how ambition and patience changes during a long build.

Field Notes

• Customers are often right about their pain but wrong about the implementation of the fix.
• Listening to feedback is not the same as submitting to it.
• The best products are shaped by interpreted feedback, not raw data.
• Persistence is about the problem; stubbornness is about the solution.

Follow via RSS: latest articles · full article archive