alt Hacker NewsWorking in b2b SaaS, there’s a real gravity toward checkbox-driven development. Any time we lose a deal because a competitor had feature A, the immediate response is “we need to build feature A.”
And from a sales perspective, that’s probably not wrong.
I think a new (or newly critical) engineering challenge is how to build in a way that keeps a codebase that’s churning out features from crumbling under the weight.
> from a sales perspective, that’s probably not wrong.
Possibly not wrong. One scenario that happens over and over again is that we lose a deal because we didn't have feature A. So we build feature A, and we still don't win deals with it. One way this happens is when the competitor has a focus on one part of the market, and we have a focus on another.
Example: We go after SMB, the competitor owns "The Enterprise." Just building A will never break us into the Enterprise part of the market. We have to build an entire strategy around seizing part of the Enterprise market from our competitor. That strategy may or may not include A, but it is definitely more involved than "Build A and customers will come."
if we aren't going to build an entire strategy around "The Enterprise," not only can building A fail to win the business, it may cost us some of our existing SMB business. Every feature our core market doesn't want or need is additional complexity and feature surface area for our customers to absorb. They stop thinking of our product as "tailored for their needs" as it begins to bloat with features they don't need.
And worst of all, the investment in feature A means some other feature—B—that our existing customers have asked for gets punted down-calendar because we're suddenly tearing up our road map and building A because the VP Sales threw a temper tantrum about being unable to close deals without A. This is another way that chasing feature A means sacrificing value for our existing customers who are asking for feature B.