From what I've skimmed, the author blames sales-focused companies for being too obsessed with capturing value. And this is a bad thing.
He also blames product-focused companies for being too obsessed with delivering value. And this is a bad thing.
His silver bullet at the end seems to be that the company should be marked-focused. Which appears to be shorthand for both delivering value and capturing value. Ie, being sales-focused or product-focused is bad. Instead, you should strive to be BOTH!
It seems analogous to me telling NFL coaches that being defense-focused is bad because they won't score very many points. And being offense-focused is also bad, because they will give up too many points. Instead, they should focus on BOTH!
Maybe I'm being naive, but this seems a tad obvious, and not all that useful.
>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.
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.
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.
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.
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.
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.
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.
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.
If this is your definition of “product-led”, you have a bad Product team.
The Product teams job is to make sure that you aren’t relying on the “if you build it they will come” approach to product development.
One of the only real arguments against product-led, as I see it, is when the quality of the product is less correlated with success (e.g., low competition markets with long contracts), and I’d still argue against it. Who wants to build a business strategy around products that don’t fit a market need?
Yes, Product needs to work with Sales and Marketing to determine whether something is valuable to the customer and viable for the business. No, Sales teams are not the best decision-maker for “what should we build next”.
Before reading his bio, I’d have thought the author had only a cursory understanding of real product management. Given his background, I’m more inclined to believe this is click-bait.
> One of the only real arguments against product-led, as I see it, is when the quality of the product is less correlated with success
In B2B enterprise the quality of the product is not correlated with success at all. Almost only the sales strategy and go to market execution counts. If you think this is not the case, join any B2B enterprise company and you will see it in action. That doesn't mean the product has to be shit.
> Who wants to build a business strategy around products that don’t fit a market need?
There is a difference between fitting the market need and being product-led. Customers don't only buy a product, they buy a vision, they buy an execution, they buy a service. There are tons of domains (if not most) that don't need a good product but only a ok product.
Product-led is a go to market strategy when a company is growing. There are almost no established big companies in the world which are still product-led
Yeah, I feel like the product side of enterprise software involves lots of box-ticking features for someone with purchasing authority. The rest is driven by timing, sales, and support contracts.
Enterprise B2B is my go-to example of when product quality is not correlated with success. Distribution and getting through procurement processes is much more important.
As to your other points, Product-led matters when good products matter. Some products are bought purely for the brand/identity element (Seth Godin writes a lot on this), and product is irrelevant in those markets. Imagine there are a number of cases where product quality is irrelevant, but that goes back to my earlier point of the “only argument against product led”
yeah but you usually don't choose between product led or sales driven. The founder creates a company, a culture is created around and this culture will stay more or less the same throughout the live of the company, so you don't choose to be product led, nor can't you advise it. It is just there or not
Product-led typically means "driven by customer needs" but also being able to make the correct trade-offs vis a vis engineering and sales considerations. That is, delivering something that is in line with what you can build and not delivering "value" that the customer is not ready to pay for.
Which can be opposed to "sales driven" where the sales team sold something, engineering has to play catch up, which can lead to technical debt and lack of focus mid-term.
Or engineering led, where the engineering team will decide priorities and might push cool tech demos that will never become successful products. Google being the best example of this type of culture.
Edit: article is terrible. He creates strawmans to sell his wares. As always, beware of consultant blogs.
Product led is about building the best product, with the “best” taking into account customer wants.
But product is just one dimension of customer needs, and customer needs are fulfilled across all other departments either directly or indirectly. A sales-led company can still be driven by customer needs, so the definition is way too broad.
Also the statement that “product led” means “making the correct trade off between sales/engineering” is too broad. You could just as easily say “sales/engineering led” means “having the correct mix of product”.
There's no such thing as "customer-led". That's not a common term, or when it's used it's used so generically as to mean pretty much everything.
"Product led" describes specifically what a "product manager" is hired to do -- make trade-offs primarily between engineering and sales (as well as take into consideration management priorities and general user satisfaction, but user satisfaction is only one priority out of many -- and often not the top one, either).
And if "sales-led" or "engineering-led" resulted in business success then product managers wouldn't exist, because they wouldn't be needed. But sales and engineering often have very conflicting priorities, and would result in drastically different products if left to their own devices.
You don't seem to be understanding what I'm saying at all. Let me try again.
Sales managers specifically focus on sales, they manage internally and have people underneath them. Similarly, engineering managers focus on engineering, manage internally and have people underneath them.
Product managers don't have people underneath them, they don't have reports (except for other product managers). It's a fundamentally different position that is explicitly cross-departmental.
And the idea of product managers existing without sales/engineering managers is nonsensical. Who would they talk to in those departments then?
Of course everybody tries to add value. But the point here is that product management is the only position that is explicitly cross-departmental, precisely to prevent departments from making decisions that seem to make sense internally but don't for the company as a whole.
Because experience shows that, without product managers, departments often do make decisions that make sense for the department but don't for the business as a whole.
At very small companies, the founder/CEO is often the de-facto product manager, but once you reach a certain scale you need to hire product managers to handle all the lateral communications and decisions, while the CEO focuses on things at the top.
I am understanding, I am disagreeing. I've worked at both "product-oriented" and "non product-oriented" companies, including as a product manager, and what you are saying applies to both.
> But the point here is that product management is the only position that is explicitly cross-departmental, precisely to prevent departments from making decisions that seem to make sense internally but don't for the company as a whole.
At non product-oriented companies, companies still have cross-departmental roles. This is sometimes a singular function (called something like central planning, pmo e.t.c.), but can also sit in cross-functional meetings for heads of departments, or sometimes there are divisional strategy teams which then meet, negotiate and divide back.
> At very small companies, the founder/CEO is often the de-facto product manager, but once you reach a certain scale you need to hire product managers to handle all the lateral communications and decisions, while the CEO focuses on things at the top.
Product Managers at large companies do not facilitate all lateral communications. They facilitate lateral discussions to and from product, for example between "logistics and product", or between "sales and product".
They won't facilitate the discussion between logistics and sales (i.e. "we need a bigger warehouse in 3 years"), or between retail and logistics ("your delivery is late") for instance (which requires other cross-departmental collaboration and planning).
> And the idea of product managers existing without sales/engineering managers is nonsensical. Who would they talk to in those departments then?
Exactly! All I mean is you can't use proof that product managers exist as proof that a company is product-oriented. I've worked in a company that wasn't product oriented that had product managers, and they still added plenty of value :)
My view is that you can have a product-oriented company without having any product managers, because product-orientation isn't to do with any of this stuff. It's to do with the company setting its primary goal to make the best product (i.e. making better things than competitors). It's the focus on building products that's the different thing, not the focus on customer or reducing silos.
As an example, an outsourcing cleaning contract company will not be product oriented, but will be customer oriented and will have an organisational structure that allows cross-departmental communication. They could also still have product owners and a 'product-led' IT division for instance.
I'm in agreement with pretty much everything @crazygringo has said.
I don't know if this will help, but if I can offer a clarification on why I think product-led id not synonymous to "customer-led" or "market led" is that it's not simply finding and responding to market demands.
You have different types of product managers (f. ex. I am kind of excluding "technical product managers" from this characterization), but typically, product needs to own and understand what customers want BUT be able to understand the tradeoffs, factor in what delivering that value actually entails* AND assess the opportunity cost of pursuing these features vs 1 000 000 possible ideas.
This is typically not the job of sales managers, engineering managers or marketing managers, etc. So product is the function that uses market demands + input from all these other managers, gets buy-in and then helps things go smoothly.
* Building a feature is only part of the cost of a feature. It has to be marketed, it has to be maintained, it has to be improved, etc.
Product-led is where users drive the full funnel of marketing, sales, and hopefully, product + engineering. Consider GitHub:
Marketing: You get invited to collab on a github repo and make an account. People share links to OSS repos you depend on. You see a Add CI/CD/Actions button on the PR review page and eventually click it.
Sales: You need to make a private repo, and convert from freemium. Your company grows, and so does your seat count. You hire a CISO, and they demand upgrading for SSO. You get a phone call that you added SSO but not scans. You get an email that they ran a scan, and here are the first 3 Caves on one of the 3 languages you use, and would you like a consultation on that + price optimization?
Product: Your actions are recorded by analytics for everything, your google searches mined, and basically you live under a digital microscope for where dropoffs and slow growth are around inbound, usage, conversion, internal growth, and churn. Pricing scales with value/use.
Engineering: Feature requests are tied to teams analyzing the above, both internal and external. Things like observability and fast deploys matter more as teams are explicitly interested in experimenting with users.
Product-led doesn't mandate other orgs go away nor freemium, but does emphasize flywheels around self-serve and usage patterns / funnels, which rethinks a lot. It requires heavy product market fit (and helps get there). For something like big b2b, that is super hard, but if you hit it, sales flips from slow, expensive, and oppositional top-down to more of a lead-rich, warm, and even automatic flow, which is amazing.
The original article showed a misleading view of product-led by doing a bad strawman, or maybe from pre-use/fit that's not tied to customers ("if you build it, they will come" is not product led). Product-led is generally slow (ex: SaaS) and hard to get fit, which is a tough spot and IMO why VC funding needs to be of a limited and patient sort for early stage. ("You're spending too much and need to do layoffs to get time to get to better fit" said no VC ever.) The article _does_ make a good point that value-driven leaps are tough, and doing 0-1 stuff requires different work than 1-n, and especially when product-driven.
- Product led growth makes it easier to launch a start-up. Global market, nice product features, some word-of-mouth publicity. That’s all it takes to launch a product led SaaS business.
- Product led growth is not just a go to market strategy, it's a complete business growth strategy. Product led everything, from product management and design to marketing and sales.
- The products must be built for the end users... Even if you are targeting a business, you need to remember that it is an individual who is going to use that product. And it is for these actual users for whom the product must be designed.
- When it comes to corporate buy vs team buy, team buy is much quicker and frictionless. Having a product that can be purchased by a team on their own is the best for product led growth. The scaling can come later when you have multiple teams within the same organization using your product.
- Each sale is a small ticket sale but this also enables people managing just a small or large team to decide whether they want to buy your product. As this decision is based on experienced value and not some perceived value promised by a sales guy, the success probability is really high.
- There are two things that product design teams need to ask themselves. One, can the user start with the product without any training or help video? If the answer to this one is yes, you are in a good place... Two, do I need to send the user outside the product for any information? If the answer to this one is yes, you are in trouble.
- The product led marketing has to happen inside the product, once the customer has signed up. Each and every aspect of the business must be thought out according to the user journey.
Disadvantages:
- On the face of it, product led growth sounds so doable that most startups begin with a very grand vision of what they wish to achieve. Whereas in reality, they need to start small and gradually step up to reach their grand vision.
- Churn is the biggest problem in product led growth. Churn rate is a good metric to judge how good your product execution is.
- Another disadvantage of product led growth strategy is that product execution must be stellar. If product experience is not great, users will move elsewhere.
Pivoting to Sales-led:
- Product led growth is capital efficient. It is very easy to go from 0 to 100 million in ARR. But beyond that sales led growth is more effective because the brand is set and it is easier to move to enterprise level.
- Once you have used the product led growth to find that wedge into the enterprises, you can consider sales led growth. The point to remember here is that demands on the product team increases dramatically once you pivot to sales led growth. You are no linger thinking of single workflows or single teams. Your focus must shift enterprise wide and there can be no compromise on API coverage, customization or integration.
Are you not invoking a classic no true Scotsman argument, “a true product team always leads to success”?
I think a more interesting view might be to understand boundaries between product, sales, marketing, customer development, business strategy, support, operations, etc. Those boundaries may be where the problem is at.
Moreso, I’m trying to emphasize that the Product teams job is to know what factors go into effective prioritization decisions, and work across the boundaries you just mentioned.
They are an integration function for decisions about value generation activities (I.e., product development) and should be spending the majority of their time working with customers and across the business to make sure they’re guiding the business towards the right decisions.
There are a lot of Project Management jobs that masquerade as Product.
The historical reasons for sales-driven and product-led was due to internal politics. As noted in the article, these are internally focused, as most employees work “in” the business and not “on” the business. I would recommend using different wording than the article, as Market-Focused will lead to focus on competitors. This is again leads to focus on the wrong party, not the right party and the reason why the organization should exist and consume resources including people’s/employees’ time.
Mission-driven in both for-profit and non-profit context works very well to focus the team on the right party (customer, patients, citizens, large enterprises in insurance, the local environment, etc. “target population”) as the organization scales to provide value to the target population. A shared mission to ensure the fulfillment of the primary reason for the existence will ensure the team focuses on delivery of value to the right party, target population. However, the mission needs to provide enough value to justify its existence, and with three parts: (1) large value proposition, (2) large target population and (3) large unmet need, then you have a justification for the continued existence of the organization and the resources it consumes.
Agree broadly with what you're saying; having a common mission is a good way to align on goals within a company and also with customers and community.
It's debatable, but the phrase "target population" seems potentially non-ideal from a cultural perspective. To me that has some negative connotations, implying that the recipients might not be aware/participating/accepting. It feels like companies should want to support and encourage their audience, as opposed to pushing things onto them.
Perhaps a minor point, but I think that if you develop a large organizational culture which begins to repeat various phrases or terms, then those words and the way they are perceived become significant (in proportion to the company's influence).
I fully agree that “target population” isn’t the best wording. If you have a suggestion of another phrase in English that would be readily understood without further definition, please do share as I would love to find a better phrase than target population. I typically use just “target” but I was avoiding being ambiguous while attempting to be brief. Again, “target” also carries a lot of cultural baggage for its military associations.
To go a bit deeper, underneath my comment is method of accomplishing a mission through organizational/program design, where a mission consists of:
verb. target. outcome. measurement.
* To maintain brevity in the above format, the “need” and the “how” may be implied in the mission statement but are typically not well covered by the above suggested mission statement format, but should be codified in a logical model of the programs/executable units of work.
Thanks for the suggestion. Markets can be qualified and quantified in very different ways across different domains of knowledge. The general interpretation is a system, but a complex system is hard to measure a program’s or organization’s impact on it without investing more money in data tracking, which is beyond the scope of most all organizations outside of governments. I do eventually see that within governmental level datasets will be able to quantify outcomes, but we are still a ways off that point in time.
Re "manual steering", that's just another way of saying "moderated" or "curated" (or, some people's favorite, "censored") - no? HN is a curated site and always has been: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que.... We don't tend to boost submissions like the OP though.
There's a 3rd axis missing - Customer Centered which can and should drive both Product-led and Sales-driven.
Both Product-led and Sales-driven alone are putting the cart before the horse. The horse is the customer first.
When you do it right, you get all three!
When you simply use a recipe book of heuristics without understanding anything about economics (btw a university Economics course teaches you next to NOTHING) and your particular market, then you are practicing Cargo-Cult Superstition business. You might as well strangle chickens and wave the entrails over your lobby door for all the good it will do you!
You hit the nail on the head. Talking to the customer in some way shape or form should be the first step that informs whether you take a more product or sales led approach and more importantly /why/. Without a customer centric approach, all you end up with is (as you point out) a solution in search of a problem -- a poor place to be.
The introduction of the idea of a "Market-focused" company is so trivial and unimaginative here that I can't think for a second anyone worth their salt as an operator would do much more than roll their eyes. This kind of content that creates these sort of false dichotomies that capture some bad aspects of poor business strategy and then present some idea where you correct these wrongs as novel is just so... brutally uninteresting. The fact that this stuff floats to the top of HN as become as unsurprising as it is disappointing. Some "bad thing bad" title that people don't even bother reading gets pumped up, and then when you take a moment to dig in and digest the content, it's a whole bunch of nothin'.
The beginning of the article is pretty on point. Most PM dream about working in a pure product-led company and spend their time complaining that it is not how things should be done. Which is a big misunderstanding of the PM job, I've written before how to navigate the PM in role in Saas enterprise (very likely sales driven) [1]
Actually if you search the web for PM resources you will mostly find insights on how to run in a product-led environment. Which is funny because most of companies are not operating that way. It is even more funny because it is easier to fail a product-led company than a sales driven one
The rest of the article is bullshit to enroll people for his workshops. There is no better gurus than ones who invent terms who don't exist and then spend their time explaining how genius it is. A market-focused seems to be the kind of companies that someone who has never run a company would imagine. Wins on all markets, but also on the product and the sales. And we all know that this is impossible
My experience with “sales-driven” is sales people selling things that don’t exist, ill-defined, and delivery dates that are demand based. This leads to all corners cut, products that can only be sold once. In other words, sales-driven companies are a way to turn your company into a consultancy.
When reading the caricature of a product-focused company, I couldn't help but think of NeXT. NeXT was before my time (I was about 8 when the first NeXT computer came out, and completely unaware of what they did until decades later), but I've read about them and watched their first launch event [1]. It's obvious from that presentation that they were state-of-the-art, way ahead of their time. But from what I've read, NeXT computers didn't sell very well. I'd be interested in any detailed postmortem of NeXT's failures.
The impression I got at the time was that NeXT was selling a fairly high-end Unix workstation with features that made it a better desktop PC than contemporary workstations, but lacked the enterprise sales experience to hit most of the Unix workstation market (which also had considerable vendor lock-in, so it was hard to get people to switch) while having a price point that, despite the features, made it a very hard sell as a PC replacement. The nonstandard storage on the original NeXT probably didn’t help, but that waa addressed quickly with the second generation machines which had more traditional storage.
This is not Sales vs Product. This is bad product management, full stop. It is not sales’ responsibility to define the product, it is product’s responsibility to do that, taking into account sales requests, market analysis, executive vision, user feedback and engineering feasibility. In any given situation it takes a lot of expertise and judgement (and often luck!) to know where they need to be focused. Trying to reduce actual product problems to some simple knob between caricatured role definitions will help no one except management consultants. In reality product management failure is very contextual to the problem at hand-—details matter.
Balance. Sales, marketing, product (and the g&a team) are all crucial to success. The market, sales, and product all can be signals... But without balance the biggest opportunities and dangers will be missed.
That's exactly right Indymike. Business should be vision and mission lead. If people have an understanding of the CHANGE they want to capture in the world (either by creating it or taking advantages of it), a good leadership will know when to pull on the levers inside the company of the business at the right time to complete a mission on a step towards the vision. Sometimes that's leaning into sales, sometimes it's leaning into product, sometimes it's leaning into technology, sometimes it's playing them all together. Business is more art than science, and the startup trope should be "I'm going to capitalize on change" not "I'm going to change the world".
I can't think of a single company that would advocate anything else and yet all of them prioritize money over product, even if it means enacting petty user-hostile policies.
When you're large enough growth slows down so you make more money by building a moat and squeezing your customers. When you're still growing quickly a good product and the resulting growth leads to more revenue.
Most companies have a list like this and other values they claim but rarely follow.
In all large companies at one point the stars aligned and you had smart, connected devs and sales people that made a great product, executed and sold. This fades after a while, you get academics and newbies that derail and complicated a good thing.
I have seen it over and over again. Hulu is a good example, started out very strong and slowly became a terrible product. Til this I dont understand the UI.
Ultimately these are just generalizations. Your company can be focused on both and regularly fail to execute either.
What the execs know is that all they need to do is generate profits. There are many tricks you can use to do that, even if you have shitty product that customers don't like. This is where established behemoths sometimes end up, to the point that people hate their brand, but use it anyway. At that point the customer is just poultry, and the company's focus becomes keeping foxes out of the hen house.
"The beating heart of the company is its product teams, full of rockstar developers, designers and PMs, and rich in methodology and “culture”. But these folks are compelled to follow the grand vision of management, which leads to convoluted product extravaganzas that don’t blow anyone away."
One question? What we have to do when the market is not yet created? May be the author ignores the idea of iPhone? Can you imagine Jobs to be "market focused"? When there is no market for touch based phones?
Market focused by the way perfectly describes Apple of today.
The Irony is big.
I skimmed the article, but I would argue product focused has to understand everything including being “market-focused”. You need to understand what the market is asking to guide your product decisions.
Ha, I got past the sales-driven company caricature, into the product led, and thought: "Well, like many things, it depends. "Which blend best suits the market?"
Product is already market-focused. As a career product manager that has also worked as a software engineer and a salesman - I find your article offensive and polarizing.
meh, a not-so-kind but equally apt critic can also be made for the case that the article is trying to promote, the so called "market-driven" companies.
most edge funds companies can be considered almost 100% market driven...
Most essays like this begin by pointing out that a company that over-focuses on X is headed for trouble, for almost any value of X. They then present Y, which if properly pursued, will solve the problem of X. Both sides of this argument are subject to “No True Scotsman” problems. By definition, over-focusing on X is going to be problematic, that’s tautological. But what about companies that are giving X the right amount of focus?
Likewise, of course if you’re doing X badly and then you change to doing Y “right,” things will get better. But how much of that is X vs Y, and how much is magically going from doing something wrong to doing something right?
The essay pitches some education on how to do “market-focused” right. Fair enough, let’s grant that in the hands of the well-intentioned, doing market-focused right will lead to success. Ok, but will taking a similar approach to fixing sales-focused also help? Is the assumption that sales-focused cannot be done right under any circumstances? I’m not sure the essay establishes this.
Same for product-led growth (“PLG”), the current hotness in product management thanks in large part to Amazon’s success. Ok, if PLG done wrong is bad, can we fix PLG and do it right?
So my first observation is that the argument “Doing X badly is worse than doing Y correctly, so do Y correctly” neglects scenarios where we fix X. Is that an option as well?
—
My second observation is the dual of the above. What makes us think we can do Y correctly?
Now don’t get me wrong, I am not suggesting the author’s educational offering is suspect. Come to your own conclusion about this, just like evaluating any vendor of a silver bullet.
I’m suggesting something else: For those companies doing sales-led or product-led badly, what if the problem is the company and its leadership, not the methodology?
In that case, you have to fix the company and its leadership, or they’ll bring their problems with them to “market-led growth.”
I think of this second scenario often.
Consider the time when companies were transitioning from shipping software on media to SaaS. Continuous integration and other practices transformed the very notion of “shipping,” and solved many problems companies had with death marches to press golden masters.
Shipping software on media was X, SaaS was Y. Many companies benefited greatly from the shift. But they were usually companies that were already doing reasonably well with shipping software on media.
If a company was good at shipping software on media, switching to SaaS was a shock, but it removed the limitations imposed by physical media and distribution.
But if a company had trouble shipping quality software to plan with physical media, it didn’t magically become good at shipping quality software incrementally with SaaS. SaaS did not fix problems with engineering culture or leadership.
—
p.s. None of the above applies for much of HN’s demographic: If you’re starting from scratch, you don’t have a “Doing X badly” problem to begin with. You can sit down and evaluate sales-led versus product-led versus market-focus purely on their individual merits. This is one of the great advantages of starting from scratch.
But even if you don’t have a “Doing X badly” problem, be careful with arguments that contrast “Doing X badly” with “Doing Y right.” A balanced approach to choosing X versus Y would be to compare doing X right with doing Y right, and also to think about whether X or Y is going to be easier to do right for you in your situation.
He also blames product-focused companies for being too obsessed with delivering value. And this is a bad thing.
His silver bullet at the end seems to be that the company should be marked-focused. Which appears to be shorthand for both delivering value and capturing value. Ie, being sales-focused or product-focused is bad. Instead, you should strive to be BOTH!
It seems analogous to me telling NFL coaches that being defense-focused is bad because they won't score very many points. And being offense-focused is also bad, because they will give up too many points. Instead, they should focus on BOTH!
Maybe I'm being naive, but this seems a tad obvious, and not all that useful.