Product-focused and sales-focused companies
itamargilad.com
itamargilad.com
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.
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.
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.
Obviously not the perfect metaphor, but for sure a part of it
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.
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.
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.
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.
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 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.
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 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.
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.
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.
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.
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.
That sounds like a different way of saying "you can end up with 15 years off revenue".
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.
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.
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.
In the end, all of this boils down to money/market share.
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.
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.
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'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.
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.
Sometimes there is value in stating the obvious, because it might not be that obvious to everyone.
One really needs all three players with equal power at the table in order to create a balanced company.
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.
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.
Hence, product-led.
> If sales-led or engineering-led resulted in business success then product managers wouldn’t exist
By this same logic, I should find that sales managers and engineering managers don’t exist in a world where ‘product-led’ leads to business success.
But of course they do, because everyone adds or creates value and contributes to business success.
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.
Does that makes sense now?
> 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 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.
Some key points:
- 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.
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.
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.
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.
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
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”
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.
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).
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.
Examples of missions:
1. Living Goods = save. african kids’. lives. reducing child mortality.
2. One Arce Fund = get. african families. out of extreme poverty. increasing income.
3. Island Conservation = save. island species. from extinction. recovering species populations living.
Definitions:
1.Verb = The measurable action of the program taking place on the target to achieve the outcome.
2. Target = The person/place/thing that is the served by the program.
3. Outcome = The measurable benefit that is expected for the target.
4. Measurement = The primary set of data being collected as an indication that the outcome is being achieved.
Edit: formatting adjustments
But these distinctions are just additional nuances to choose from in the same vein as the original debate.
The content does not have much depth and seems to be a build up for a silver bullet solution (author's workshop).
In my Lean Product Management workshops you’ll learn how to develop product strategy, research your market, set goas, prioritize ideas...
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.
If you want to see the sort that we do boost, there are lots of examples at https://news.ycombinator.com/pool and https://news.ycombinator.com/invited.
Edit: found it, it's probably the second chance pool: https://github.com/minimaxir/hacker-news-undocumented#second...
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!
1. Product teams create utility at ~zero marginal cost per additional user
2. Platform teams drive distribution
3. Monetization teams convert utility to cash
4. GOTO 1
- Apple: far from zero marginal cost per additional user
- Amazon: far from zero marginal cost per additional user
- Netflix : More or less works, if driven by the content they create. But not a product
- Google: Has monopoly on Ads search, all others projects bring close to nothing
Except Facebook, I don't see how 'zero marginal cost per additional user'-products have any impact of the revenue these company make
1. Get one thing right.
2. Sit back and make my monies.
Formula: 1. set up strawmen on either extreme 2. argue for the middle
Being sales-led vs product-led is not about your specifying your "company DNA".
It's about choosing the go-to-market strategy that maximizes your LTV:CAC.
And as the market changes, so too can your GTM strategy.
As evidence: HubSpot successfully transitioned their GTM from sales- to product-led. OpenViewVenture published a guide explaining it:
https://openviewpartners.com/blog/hubspots-5-strategies-for-...
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
[1] https://blog.luap.info/product-management-in-saas-b2b-enterp...
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.
1) Build a great product
2) Make money
3) 1 always comes before 2
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.
In the best case they think about solving a user problem as directly as possible.
I the worst case they just want to apply a technology or paradigm as correctly as possible, and everyone has their own opinion on how this is done.
But successful software is a non-trivial function of solving a users problem and extracting the most money with that solution from the market.
That and privacy, security, performance, usability, etc. pp.
Nobody cares how your solution is a perfect application for K8s.
If they can't find it because of non-existing marketing, it won't work.
If you can't make money to support it's maintenance, it won't work.
My advice would be to understand and focus on your strengths, and to avoid cargo-cults.
And yes, alignment in any company or team is extremely important, this is what leadership is for.
You need the right balance of everything in reality, including sales, and the mix is different for different companies.
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.
tech + team = investment driven
idea + team = investment driven
investment + team = product driven
revenue + product = sales driven
investment + product = engineering driven
revenue - product = acquisition driven
A product is something someone both wants and pays for, otherwise it's just a technology. Might build this out, but it's pretty consistent.
IMO, etc...
Garbage opinion piece.
Market driven companies, ta-da! Lol
most edge funds companies can be considered almost 100% market driven...
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.