Field Notes on Support as Product Research
Support is often viewed as a distraction from building. In reality, it is the primary lab where the invisible work of SaaS—the reliability, permissions, and edge cases—is discovered and refined.
Customer support is not a distraction from building the product. It is the primary lab where the product is actually discovered. In the early stages of a startup, we often mistake the visible layer—the calendar, the composer, the analytics chart—for the product itself. But as you move through the valley between validation and scale, you realize the product is actually the pile of operational truths required to make those visible features usable by real teams with real stakes.
When a user reaches out with a question or a complaint, they are rarely just reporting a bug. They are identifying a gap in the machine-shaped structure you are building around your features. Support is the research method that reveals the dense underside of SaaS: the reliability, exception handling, billing rules, and permissions that make ordinary user behavior feel uneventful.
The Framework: From Friction to Infrastructure
In the middle of the journey, the founder often feels a specific type of quiet insanity. Every time you solve one obvious product problem, five invisible operational problems step forward and introduce themselves. To survive this, you must stop viewing support as a series of fires to extinguish and start viewing it as a roadmap for industrializing reassurance.
The goal of a SaaS product is to be uneventful. When software feels calm, it is because the founder did an enormous amount of invisible work to absorb chaos before it reached the user. Support tickets are the data points that tell you exactly where that chaos is still leaking through.
The Support-to-Product Mapping Table
To turn support into research, you must map the user’s immediate frustration to the underlying operational system that is missing or immature. This is how you move from shipping features to building a company-shaped machine.
| User Input | The Research Insight | The Required Invisible Work |
|---|---|---|
| "Can my assistant draft posts without hitting publish?" | The product lacks a hierarchy of trust. | Role systems, approval workflows, and workspace permissions. |
| "I didn't realize this would post to all my accounts at once." | The interface lacks guardrails for creative intent. | Validation rules, channel-group management, and draft handling. |
| "Why did my scheduled post fail to go out?" | The failure recovery system is insufficient. | Timezone search, retry logic, and automated notification systems. |
| "I need to change my billing email for the invoice." | The administrative layer is decoupled from the user. | Entitlement management, billing plans, and self-service dashboards. |
The Hidden SaaS Work
Building Postly taught me that the "real" product was not the ability to schedule a post—that was just the entry fee. The real product was the infrastructure that allowed a team to do it ten thousand times without a catastrophic failure in communication or execution. This included things like shared calendars, recurring rules, bulk-posting flows through CSVs, and media browsers.
This is the part of the build that many people underestimate. They evaluate a product from the visible layer, but they do not see the retries, migrations, and fallback states. If you listen closely to your support channels, you will find that users aren't usually asking for "more features." They are asking for the existing features to be more robust, more collaborative, and more reliable. They are asking for the machine to tell them, "Yes, this will hold. You can rely on it again tomorrow."
Failure Modes in Support Research
While support is a goldmine for research, it is easy to mine the wrong ore. There are two primary ways founders misinterpret this data:
- The Feature Trap: Treating every request for a new capability as a mandate to build it. Research should focus on the *intent* behind the request. Often, a request for a new feature is actually a symptom of a failure in an existing operational system.
- The Emotional Debt: Allowing the volume of support to dictate the product direction without filtering for your ideal customer. Not every user's friction is worth solving if that user is not aligned with the long-term vision of the product. This is especially true when dealing with the emotional debt of early-stage deals.
Field Notes for Founders
If you are currently in the middle of the build, feeling the weight of the founder breaking before the product, use these principles to reframe your support work:
- Categorize by System: When a ticket comes in, don't just ask "What is broken?" Ask "Which operational system (permissions, billing, reliability, etc.) failed to absorb this chaos?"
- Document the Underside: Keep a running list of the invisible work required for every new feature. If you launch scheduling, immediately plan for timezone handling and failure recovery. Do not wait for the support tickets to arrive to know they are coming.
- Build for Calm: Measure your success not by how many features you ship, but by how uneventful the user experience becomes. A week with zero support tickets regarding "how do I do X" is a week where your product research has succeeded.
The job of a SaaS founder is to build a machine that repeatedly provides reassurance. This is a much bigger job than shipping a feature. It requires endurance, a high tolerance for tedious operational work, and the willingness to let your users be your most honest teachers. For more reflections on the reality of the middle years, you can follow the journey at GrowthDiary.
Next Steps
- Review your last 50 support tickets.
- Identify the "invisible work" (permissions, validation, notifications) that would have prevented those tickets.
- Prioritize one piece of operational infrastructure over one new visible feature in your next sprint.
Follow via RSS: latest articles · full article archive