4 ms·

Treating developers like loot crates is the surest way to turn your company into a shitshow. Feature chasing needs to have very coarse data attached to it: -

Treating developers like loot crates is the surest way to turn your company into a shitshow. Feature chasing needs to have very coarse data attached to it: - how many overpromised features attracted revenue? - how many delivered overpromises features didn't win the potential customer? That last one is about 80% for my career.

Centigonal 5y ago
What do you mean when you say, "treating developers like loot crates?" I understand your point that developer effort is valuable and should be directed toward features that have impact on the business and customers, but I don't see how that relates to the loot crate analogy. Is this about objectifying people? Is it about gambling related mechanics? I'm honestly very confused.
- LootCrateDev 5y ago
  Sales: Potential client wants feature Y. Can we code it? Coder: Anything can be coded. Can sales bundle a contract where a SaaS covers that feature for us while we code it? Just to test drive the clients actual needs? Sales: no Coder: okay. Do you have data to show that's the actual need? Sales: I have an email of them saying that's their need. Coder: okay, no data. What are the odds of the customer onboarding once the feature is done? Sales: 100% Coder: okay, no reasonable thought process behind conversion odds. Do you have a memorandum of intent from the potential customer? Sales: no Coder: okay, so you have no capacity to wrangle a contract that bundles a third party for feature Y with our product, you have no data or insight about why this person wants this feature, and you say we have a 100% chance of converting to a customer despite not having a memorandum of intent. Sale: ...... but can we get feature Y tho? At this point, sales is myopic and thirsty and will use social pressure to force the dev to do something stupid. The company agrees because they see devs as loot crates: a concept where an interaction has a very low chance of very high rewards.
lumost 5y ago
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 5y ago
  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 5y ago
    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.

Centigonal 5y ago

What do you mean when you say, "treating developers like loot crates?" I understand your point that developer effort is valuable and should be directed toward features that have impact on the business and customers, but I don't see how that relates to the loot crate analogy. Is this about objectifying people? Is it about gambling related mechanics? I'm honestly very confused.

LootCrateDev 5y ago
Sales: Potential client wants feature Y. Can we code it? Coder: Anything can be coded. Can sales bundle a contract where a SaaS covers that feature for us while we code it? Just to test drive the clients actual needs? Sales: no Coder: okay. Do you have data to show that's the actual need? Sales: I have an email of them saying that's their need. Coder: okay, no data. What are the odds of the customer onboarding once the feature is done? Sales: 100% Coder: okay, no reasonable thought process behind conversion odds. Do you have a memorandum of intent from the potential customer? Sales: no Coder: okay, so you have no capacity to wrangle a contract that bundles a third party for feature Y with our product, you have no data or insight about why this person wants this feature, and you say we have a 100% chance of converting to a customer despite not having a memorandum of intent. Sale: ...... but can we get feature Y tho? At this point, sales is myopic and thirsty and will use social pressure to force the dev to do something stupid. The company agrees because they see devs as loot crates: a concept where an interaction has a very low chance of very high rewards.

lumost 5y ago

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 5y ago
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 5y ago
  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.