>Maybe I'm being naive, but this seems a tad obvious, and not all that useful.

IMO I've often seen extreeme scenarios and then a reactionary 180 swing to the other extreeme, it's usefull to recognise that both approaches are extreemes.

It might be obvious to you but I constantly see devs that fail to recognise sales focus has value - like we need to ship feature X by Y to get client Z otherwise the opportunity is gone. I'd say 2/3 devs I've worked with will immediatly push back with concerns such as long term maintainability, scalability, etc. None of those would be a blocker for the sale or the initial customer, and once you land the customer you'll have the budget to go back and fix it - but yeah still a deathmatch to get those through sprint planning.

And queue jaded devs here claming "they do it because they know once it's commited it will never get fixed", honestly whenever I come up with actual problems and solutions I can't remember being turned down (deffered a couple of times, still got to do it eventually) - I've worked for 2 startups, and 4 enterprise teams.

So if you're not getting space to do this kind of improvements and care about code quality - maybe consider changing your workplace.

> and once you land the customer you'll have the budget to go back and fix it

There’s always one more sale in the pipeline and you can end up with 15 year old products that are entirely the result of feature chasing.

I think it is absolutely necessary for development to develop a better understanding of customers and their requirements. Is it possible for us to predict some of the features from customers 1..2.. or maybe 5 years down the line in a way that the architecture and design can easily accommodate? I think it is somewhat possible and there are many examples of flexible products that do just that.

The key here is that product is a buffer between sales and engineering. Sales teams should be a constant source of feedback for product teams who can spot the synergies you're talking about.

SDMs should be a constant buffer between engineers and product.

This works wonders at an enterprise or mid market company. I don't envy smaller companies that need to drive alignment between stakeholders that have to straddle all of these lines.

A good portion of my job is helping small businesses find that alignment and being able to present the big picture to all of these teams. Somehow being external seems to help.

SDM?

I was thinking software development manager

Software Development Managers, yes

From the context, "Sales Development Manager".

As a user of software, I have to add that it is nicer to have the features, and I don’t find myself worrying about what hacks went into making it. Most of the time.

I know there are exceptions, but, usually I’d rather a company be customer focused and deliver a product I want, rather than worry too much about the methodology they use to deliver it.

Sure, there's absolutely no reason for customers to know or case, but that's beside the point. It's going to be the developer's job to modify or fix things in the future. You're happy with the footbridge they built, but when sales comes back and says "okay new customer, now we need to be able to drive fully loaded Humvees across" you aren't the one tearing out the wooden posts and pouring concrete.

How much enterprise software have you used over the years that has terrible quality? Vision and execution matter a lot in user experience and doubly so for security.

> There’s always one more sale in the pipeline and you can end up with 15 year old products that are entirely the result of feature chasing.

That sounds like a different way of saying "you can end up with 15 years off revenue".

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.

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.

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.

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.

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.

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.

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.

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.

“we need to ship feature X by Y to get client Z otherwise the opportunity is gone.”

When you say client it becomes consulting that happens to have a software project at that point. If your market needs feature x Like a mobile app because a competitor is going to crush you without it then it makes sense. Reacting to a market every now and then is understandable. However I think the horrible sales driven companies react to individual customers and that destroys your chances of any cohesive plan as each sales person hijacks your devs...which means at that point they are selling your devs time for their individual gain hurting company’s ability to make a large impact on the market. Shouldn’t happen but that’s sales driven.

I don't know - I've worked for a startup (in the size/age sense, not in the unicorn scaling sense) where they focused on one market segment (small customers) then got the opportunity to onboard a huge franchise. This required a huge change but would basically make their buisiness stable for X years and allow them to grow into a different market. But they had specific dates that needed to be met because existing provider contract was expiring, etc. etc.

So the product wasn't built for their scale, it took a bunch of invasive changes, dirty hacks, and accepting client specific workflow initially. You can look at that and say "we're lockign ourselves into their workflow" and "we're making client specific features" - but this client literally 3x their revenue year one and increased it a couple times more for extra features developed. And once you have one big client and solve their problems - you can try to generalise and sell to their competition as well.

Devs aren't loot crates.

Could you please explain what you mean instead of repeating an empty catchphrase? And did you really create this account to say the same thing over and over ?

> When you say client it becomes consulting that happens to have a software project at that point.

100%. If you cannot qualify a feature being important for the product and most/all customers you're chasing dollars. It's a common trap, driven by commission structures that incentivize a sale over anything else.

How do you qualify a feature being important enough for the product?

In the end, all of this boils down to money/market share.

Short answer - 2 factor login option likely interesting for > 60% of users, special thing for client X good for < 1%. Maybe a mvp for the 1% can be ok and maybe that could show promise as a new side hustle or enterprise feature.

Long answer - It’s very tough. It really is checkers vs chess and thinking 3 years ahead vs a quarter. Big client X wants to give us 100k now for quick thing but what will it take to babysit them going forward, also client X is a 1% of our revenue and everyone else is medium sized...I’m leaving out the 99% and making the product more bloated, etc. But can that feature be a enterprise level feature if your product is b2b enterprise sales.

There was a great article a few years ago about how Dell ditched all of its manufacturing to improve its balance sheet for Wall St analysts. In the process, they basically built up Taiwanese companies like Asus into competition at Dell shareholder expense.

The CEO of one of the Taiwanese companies said something to the effect of “American managers like ratios, I prefer cash”.

Leadership is different than management. In a growing company if some McKinsey alum solves all of your problems with a spreadsheet and fancy PowerPoint, you’re in trouble. Likewise, if some engineering team is setting money on fire building the platonic ideal of an application, you’re in trouble. Good leaders marshal those resources to make the sum of the parts greater and better.

It seems obvious in retrospect, but over-focusing on a single domain (sales, product, design, marketing, engineering) to the detriment of everything else is a common problem with first-time leaders. Inexperienced leaders tend to focus on their own background while downplaying the importance of topics they are less familiar with.

The genesis of these problems is often the CEO or other executive’s own background. A CEO who came from a sales background tends to give sales whatever they want at the expense of everything else. A CEO who started as an engineer might overengineer everything and neglect distribution. A CEO with a design background might focus too much on making a beautiful product while neglecting usability, engineering, and distribution.

These are common traps for first-time leaders, especially those who have risen quickly through the ranks. It can take time to understand that balance is necessary.

I’ve also seen the flip side of this. Sometimes the founder understands the need to hire and build for the other domains, but their own function remains immature because they rely on their own skill and don’t know how to externalize it into a self sufficient department. They get the high level stuff right but don’t have time for the details anymore.

Yeah, the message is to elevate the company's perspective to be aware of both sides of the transaction in which it takes part.

Life is always a game of balance. It may be obvious that you have to balance giving/taking as a business, but I've never seen business leaders talk this way. My experience is inline with the article in that businesses seem to go all in on one or the other as opposed to harmonizing the 2.

A big reason for this, in particularly with big companies, is that managing them is like steering a tanker. Do you want to stop ASAP you need to do full thrust the other way for a while.

Obviously not the perfect metaphor, but for sure a part of it

These two examples do feel like strawmen, and are somewhat simplified. For example, "product-led" in this example lumps together PMs, designers and developers into a single group, whereas in fact there is conflict inherent in features vs user experience vs technical debt/constraints. Moreover even a sales-driven company is not going to promise a unique feature for every customer, unless they want to run out of money quickly or they are in the enterprise customer market with a small number of clients.

It seems to me that picking any single extreme will leave you losing on other fronts. Market-focused has its own problems, for example because the market doesn't actually always know what it wants, needs or already has.

Abstracting people into a 'business' with 'tech and business', interacting with other people that are 'market' is nice for pictures, but rarely tells the whole story, and oversimplifies things to the point where you can't make complete choices.

That was my takeaway too so if you're naive, you're not alone.

What’s funny is that bullshit factories like McKinsey and BCG convert shallow insights such as this into billion dollar pipelines. You could turn this blog post into a PowerPoint presentation, and corporate boards will happily pay you $250k a pop to interview people and diagnose their company as too sales or product driven, with the recommendation to become market driven. Even the football offense/defense thing, delivered verbally during the board presentation, will be met with deep nods of understanding and help energize the room and make you look like a rockstar. Some of the board members will literally be thinking, “we need a CEO like this guy”. Once their check clears, you give the same analysis to the next company down the road for another $250k.

Speaking from 11 years of consulting experience (and 5 years of SaaS product dev BTW), when I was consultant we always used to say that the price was part of the medecine.

People tend to clear their agenda and listen closely more easily if they think you are worth listening to. Hence the suits and ties. It's stupid, but it works.

Even if it's the placebo effect, if McKinsey can make organizations operate more effectively with pre-fab slide decks, then it's worth it. They are providing value to the organization.

The point is that probably 20% of the ICs at the company could diagnose the problem over a beer but management keeps such a stranglehold over access and narrative that only an overpaid consultant wearing a nice suit is acceptable politically.

Sure. Similarly, the US government "knew" about 9/11 and Pearl Harbour hours before the planes hit anything. But understanding which signals to pay attention to and make decisions upon is genuinely a hard challenge of leadership.

Agreed. But are you saying McKinsey is better at that?

For better or worse, McKinsey and outfits like them have an ability to package a given set of advice in a way that the needed audience will be more likely to heed. Partly because they can MBA the lingo, but also just from the imputed competence that comes from having spent a goddamn boatload on their brand name.

That makes sense, and is a really good example of organizational cognitive dissonance. https://en.wikipedia.org/wiki/Cognitive_dissonance

McKinsey are overpaid lifestyle coaches for companies.

The difference is that with football every single week you get to see the score and watch the defense and offense separately. So it is very obvious that your awesome offence didn't make up for your lack of a good defense. With a startup you can end up with the equivalent of the coach saying that although the defense never stopped a single play, the offense should have done a better job running out the clock, and that is why they lost. Or the coach saying that although the offense never got a single first down, the defense should have returned some of the interceptions for touchdowns and that is why they lost.

There's also more angles than these. An engineering-focused company builds stable sustainable products for the long haul. Which means sometimes saying No to customers and to visionary product managers. On the negative side, sometimes sight of the forest is lost by focusing on perfection of each tree.

One really needs all three players with equal power at the table in order to create a balanced company.

sounds like a false dichotomy to make a naive point. define two extremes, label them bad, and label the middle good.

i'd note that it's hard to go wrong delivering value to the customer first ("product-led"), then trying to capture some of that value for yourself later, because the key to the whole system is that there is some new value created that can be shared. the main danger is not being capitalized enough to eventually capture some of the value and sustain the business.

sales-led tries to capture the value first, then deliver (some of) it to the customer, which can create misaligned incentives and a potentially antagonistic relationship, as it's hard to predict (and agree on) value in the future, and it's tempting to cheap out on the delivery.

but importantly, both can work depending on the market dynamics. it's not strictly an either-or situation, which is the domain of the false dichotomy.

It might seem obvious to you, but I've been in plenty of companies that focused on one or the other and wondered why things were always burning down.

Sometimes there is value in stating the obvious, because it might not be that obvious to everyone.

As always: Reasonable and thoughtful beats all alternatives.

It's useful for building the blogger's brand.