[lumost]

I'd also add that chasing clients tends to be a loosing game in the long term. The devs know this, but sales only sees an individual commission. In enterprise you get a lot of the following coming off the sales team.

"We had a 5 minute phone call with someone doing a vendor comparison and saw that we didn't have features Y, and Z that X has. We got them to say they'd consider us if we delivered Y and gave them a 50% discount."

The customer already decided on X, X isn't a direct competitor - if you build Y you'll just be a crappy version of X. Not to mention building Y means pushing out features that your target customers keep asking for.

As a PM I got pulled into dozens of these calls as the sales team was desperate to hit quota. Not a single time did I see a feature that was worth building. The few times I saw a deal swing on these offers we had effectively guaranteed client specific dev work that other venders were turning down due to the risk of losing money.

[ryanSrich]

Conversely, chasing clients is the only real way to find product market fit. You need money. There’s no other way to get that money than to convince someone to pay for your product. Your product needs features and functionality to do that.

I’ve been in many scenarios where devs have pushed back on table stakes functionality simply because we didn’t have the data to prove that we need it. Even showing them a competitor and saying “we literally can’t compete with XYZ” is often met with “yeah, but do we have the data to prove that?”.

Early on in a startup your roadmap is essentially gut feelings mixed with features your prospects are telling you they’d pay for. A lot of devs, designers and PdMs can’t deal with this type of uncertainty. This is why I can’t recommend contract devs enough. They’re much more willing to just trust you and put the work in.

[lumost]

There's a fine line here between competitor focus and customer focus. If it's a table stakes functionality it should be trivial to describe the benefit the typical customer of your product gets from it (things like oauth/SSO, adjustable charts). If a competitor's product is resonating with customers and you think you should copy some of it - it pays to put in the work to describe the customer gap/what customers want the feature for.

If you want to simply point at competitors and say "build that" then you need to set yourself up to be a second mover. Unfortunately this is a bit of a one way decision as you need to build the whole business around being cheaper. Bain capital had a whole notion of velocity sales based around this model which spawned a few companies.

[ryanSrich]

I’m thinking of a specific example I’ve had to deal with on a number of occasions. It goes something like this.

Prospect A pays for Competitor B. Prospect A is willing to drop Competitor B and move to your solution, but they need feature X. A feature you don’t have. Feature X just so happens to be a basic feature 90% of competitor products have. However, this isn’t a feature any of your current customers have asked for. So while current demand isn’t high, you know that you can likely sign a net new customer, and you’ll have feature parity with 90% of your competitors.

So the situation is that the Prospect loves your core product, but they NEED this one feature. This isn’t a case of building a competitor clone and selling it cheaper.

[lumost]

I totally hear this, and sometimes product teams are just desperately grasping at anything that looks unique about their product to claim "differentiation".

On the other hand, you need to consider what happens if the prospect doesn't follow through. After all, As a buyer I often pit vendors against each other to get a better deal. Even if it's a common feature like "LDAP authentication support" it may only matter to enterprise customers, and your product might be better for SMB firms. A good test of this is to ask whether they'd be willing to sign a contract with a lump sum payment/longer term dependent on feature delivery. Bear in mind, the prospect offering to dump Competitor B may not be the most influential internal stakeholder of Competitor B (think Tech infra offering to switch DB vendors when the Dev team would scream bloody murder).

If this feature burns up 12 weeks of dev time, and you dropped a product feature to make it happen then you're out both the cost of dev time and the opportunity cost for the other feature being delayed a quarter. For a small/medium startup, it's entirely plausible the "one needed feature" doesn't show up as a customer/prospect ask for another year.

When it comes to "take-out" deals where a customer is offering to "switch" from one product to another you always need to be cautious that your product wasn't added to the comparison for completeness. If you're going to burn your VC building one-off features for a big firm - you better get good marketing out of it and a long-term contract.

With all that being said, there are worse PMs than paying customers. If your team is fast, and you have money in the bank - then building whatever customers tell you they want isn't as bad of a product strategy as most devs/PMs would let you think.