Startups often get dismissed for what they do not have yet.

We have been there. At Glyphic, one of the recurring requests in competitive deals was commenting, especially for coaching and feedback. Every established product had it. Buyers expected it. It felt like table stakes, something we had to build before we could be taken seriously.

But there is a question worth asking before copying any supposedly mandatory feature:

What if the feature is really a workaround for a product that never solved the underlying problem?

In sales coaching, people often leave comments because the system cannot identify the useful moments itself. A manager has to find the right call, locate the relevant section, explain what happened, and direct the rep back to it. Commenting makes that manual process slightly easier, but it does not remove the bottleneck.

The actual need is not “let managers attach text to recordings.” The need is “help every rep improve from the right evidence, consistently.”

Once you state the problem that way, the design space changes. An AI system can review every call, compare behavior with an agreed framework, surface recurring patterns, and give personalized feedback while the context is still fresh. Managers can spend their time on judgment, motivation, and the situations where experience matters most.

The old feature can still be useful. We built commenting too. Humans will always want to add context, disagree with the system, or discuss a specific moment. But it became one component of a different product rather than the center of the workflow.

This pattern appears everywhere in enterprise software. A spreadsheet export compensates for a weak reporting layer. A mandatory status meeting compensates for missing shared context. A complex approval queue compensates for a system that cannot express confidence or risk. After enough years, the workaround becomes a category requirement.

Startups should take requirements seriously, but not literally. Buyers usually understand their pain better than anyone. They do not necessarily have the time or incentive to redesign the system that produced it.

Before adding the next checkbox, ask:

  • What job is this feature really doing?
  • Which limitation of the existing system made it necessary?
  • Does the new technology remove that limitation?
  • Can we transform the expectation instead of merely satisfying it?

Sometimes the way to stand out is not to check more boxes. It is to rethink why the box exists.