I agree with the main point already made here, but I would separate a narrow audience from a genuinely different workflow, because they are not the same thing.
A narrow audience alone does not protect a product if the work it does is the same as every other tool. What AbadPonda called workflow integration is closer to the test: does the product fit into a specific job, with that job's inputs, checks, and outputs, so switching would mean rebuilding a routine? A good example is a tool that does not just generate text, but takes a particular team's existing documents, applies their approval steps, and returns a finished draft in their format. That is much harder to copy than a cleaner interface.
I would also test demand before building too much. Before adding features, try to get a small group to commit to a paid trial based on one clear outcome, such as time saved on a repeated task or errors removed from a review step. Track three things during that trial: how long setup actually takes, how often users return in the second week, and what each heavy user costs to serve. Many crowded products fail on that last point, because the model cost grows faster than the fee.
Finally, think about distribution as part of the product decision. In a crowded market, a general search audience is difficult to reach, so a product that is already present where a specific profession works, or that connects directly to a tool they already use every day, has a clearer path than one that depends on broad visibility alone. Good support, as littlepuzzle noted, helps retention, but it cannot rescue a product that has no distinct workflow or distribution advantage.
