|
|
|
|
|
by lumost
1883 days ago
|
|
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. |
|