[HN Gopher] How to sell if your user is not the buyer
___________________________________________________________________
How to sell if your user is not the buyer
Author : mooreds
Score : 130 points
Date : 2025-08-07 15:09 UTC (7 hours ago)
(HTM) web link (writings.founderlabs.io)
(TXT) w3m dump (writings.founderlabs.io)
| Brajeshwar wrote:
| This is how the likes of Slack, Postman sells, "Hey, 96% of your
| developers/team are already using it. It makes sense to buy it."
| micromacrofoot wrote:
| this happens all the time at large companies with small teams,
| plus if there's a security team they hate it so that's always
| an angle to lean on "hey 400 people are using 12 different
| slack workspaces, wouldn't it be nice to manage them all from
| one corporate account?"
| mooreds wrote:
| Obligatory mention of the SSO tax: https://sso.tax/
| tw04 wrote:
| So how exactly are open source software stacks supposed to
| make money if not by withholding enterprise features from
| the free version?
|
| There's a reason they all do it, and it's because SSO is
| one of the few features enterprises are almost universally
| willing to pay for.
| thewebguyd wrote:
| The problem is there's a huge gap between "We are a small
| company, and don't care about SSO" and Enterprise.
|
| The company I work for is in the middle - anything where
| SSO is gated behind "Enterprise" is not even considered
| by us. We don't need 90% of the other "features" under
| the Enterprise plans, and most aren't willing to custom
| quote us for Basic+SSO.
|
| Withhold it from free versions, sure - but definitely
| don't lock SSO only behind the most expensive option.
| closewith wrote:
| Locking SSO behind the Enterprise option works. Your
| company is an outlier that can be ignored.
| thewebguyd wrote:
| I'd hardly call a business with between 150-300
| employees, that cares about SSO but doesn't need the full
| suite of enterprise features an outlier, I'd imagine
| that's fairly common nowadays.
|
| Maybe in 2015 it was an outlier, but SSO is now a non-
| negotiable and with many of these businesses on M365
| business premium, which includes EntraID P2, SSO is now
| accessible to a large number of companies where it wasn't
| before. It's no longer some niche enterprise only
| functionality, it's a bare minimum for business SaaS.
| tw04 wrote:
| The fact you're unwilling to even consider a product with
| SSO behind the enterprise license is what makes you an
| outlier, and frankly probably a bad customer.
|
| And if you're trying to negotiate custom, non standard
| licensing when you've only got 300 employees you will
| likely be a noisy customer in perpetuity.
|
| No offense, that's just how I'm betting 99% of folks read
| your response.
| codeflo wrote:
| Companies of that size are common. It would in isolation
| even be profitable to serve them. The problem is if you
| introduce a middle tier that includes SSO, many
| enterprises will go for that instead of the expensive
| enterprise tier you want them to buy. Basically, you
| sacrifice medium companies as customers in order to chase
| after that sweet enterprise money.
| thewebguyd wrote:
| That makes sense, but I still think there are other
| features that can be gated behind enterprise to help make
| sure that doesn't happen while still providing SSO for
| smaller companies.
|
| You can have user limits on the non-enterprise plans
| (Microsoft does this, for example, with Business Premium
| locked at 300 users or less), or gate other features
| behind enterprise: Have MFA across the board, but lock
| conditional access behind enterprise, lock more advanced
| audit logs & reporting behind enterprise, lock RBAC
| behind enterprise, or data residency, custom security
| policies, API limits, etc.
|
| There are numerous other features that are non-negotiable
| for enterprises to help funnel them into the enterprise
| plan, while still being able to service medium companies
| with SSO.
| MoreQARespect wrote:
| Companies of that size are served by the "enterprise call
| a salesperson" offering. If you really don't need all of
| the other features you can probably negotiate a discount.
| autoexec wrote:
| withholding enterprise features from free versions isn't
| the problem, the problem is charging extortionate rates
| for an important security feature.
|
| > "Decouple your security features from your value-added
| services...If your SSO support is a 10% price hike,
| you're not on this list. But these percentage increases
| are not maintenance costs, they're revenue generation
| because you know your customers have no good options."
| ozim wrote:
| Problem is lots of SSO implementation will be dealing
| with some arrogant architects claiming you know nothing
| and their semi broken SAML is something you should
| implement for them for free - repeat for 100 times for
| each customer having their own way of breaking the spec
| or using something crooked.
|
| It is getting better with Entra P2 or Okta as it is
| couple of minutes to configure if you use good framework
| in your projects.
|
| But the tax was because of what I wrote about in first
| place.
| tetha wrote:
| This is why at work, we're encouraging and recommending
| to use some kind of SSO, but we're basing our cost off of
| the customers IDP.
|
| Some "green" IDP like O365 OIDC, Okta, Entra and such are
| usually included without extra cost (and will be self-
| service soon, too). Some "yellow" - usually SAML - IDPs
| come at a fixed fee. We know them, we know they are
| weird, but we can deal with it.
|
| Other things are flagged as red and call in hourly billed
| projects and recurring maintenance fees. Like, one
| customer has an in-house developed SAML IDP written in
| PHP a decade ago or so. I want our customers to use SSO,
| but that's a level of jank I'm not supporting for free.
| mooreds wrote:
| Heya, I work for a commercial auth provider but we
| provide a free version with unlimited SSO connections.
| (Details in profile if you are interested.) So I have a
| bias.
|
| There's a number of ways for open source software stacks
| to make money, but I agree that finding features that
| companies with money will pay for is a great one.
|
| I think Patio11 said it once, but SSO feels now like
| HTTPS felt in 2015. Used to be super expensive, but now
| should be "table stakes".
|
| Other ways open source companies can make money:
|
| - hosting (offers that sweet sweet recurring revenue)
|
| - support (especially SLAs, which pair nicely with
| hosting)
|
| - other enterprisey features, such as integrating with
| enterprisey tools (DataDog, SIEM tools)
|
| - other auth features like fine grained authorization
| (RBAC, ABAC, PBAC) and provisioning (SCIM)
|
| - control planes (I see this with tools like Cerbos and
| Permit which both offer fine grained authorization
| execution engines that are free, but charge for the
| control plane)
|
| - certifications (SOC2, FIPS, HIPAA, PCI). this might not
| make sense in all cases, it does depend on the tool
|
| - custom feature development (better if this is pulling
| forward planned development rather than something
| unplanned)
|
| It's not easy, though.
|
| I wrote more on my personal blog about freemium[0] and
| open-source[1] business models.
|
| 0: https://www.mooreds.com/wordpress/archives/3621
|
| 1: https://www.mooreds.com/wordpress/archives/3438
| ralferoo wrote:
| Some of these seem iffy. Looking at one at random with a
| seemingly excessive increase:
|
| Coursera: $399 per u/y -> $49875 per year [7], 12400%
|
| So, I check out the footnote:
|
| [7] Coursera requires a minimum of 125 users to access SSO
| pricing. As they do not have an Enterprise price listed,
| this price just scales their lower cost tier up to 125
| seats.
|
| Dividing by 125 shows the SSO pricing is $399, so exactly
| the same as the non-SSO pricing. I fail to see how this is
| an SSO tax.
|
| It might be that there is an SSO tax as the Enterprise
| price wasn't available to them, but listing it as 12400%
| increase seems like a deliberate attempt at deception.
| theamk wrote:
| looks legit to me.
|
| I've used to work in small startup with ~10 people. The
| owner was always happy to pay for tools to developer
| productivity. We did not subscribe to Coursera, but in
| the theoretical case we'd all want to, the pricing would
| be:
|
| 10 users, no SSO: $3999/year
|
| 10 users, with SSO: $49875/year
|
| It's an SSO tax, and a super hefty too. We'd probably
| balk at it and chose the less-secure option instead. And
| the fact that we'd get extra 116 licenses we had no need
| for is absolutely irrelevant, there is nothing we can do
| with it at all.
| ralferoo wrote:
| Even in your example, and assuming that the only feature
| that the enterprise plan offers is SSO, that's not even
| close to a 12400% increase, that's a 1147% increase.
|
| My point was that saying the minimum order is 125 seats
| for enterprise, and so claiming that the price for a
| single seat is increase by 12400% is being deceptive.
|
| If you buy a six-pack of beer, you don't say "This is
| terrible! I only wanted one beer and this six-pack is a
| 500% increase in price!". If you only want one beer, you
| just buy the single beer and leave the six-pack on the
| shelf.
| theamk wrote:
| If there is an option to buy a single beer on the shelf,
| sure. But in this case there is no such option.
|
| Imagine you _really_ wanted to try Foobar beer. So you
| get to beer distributor, and you find out that while each
| bottle is just $5, the minimum order is a crate of 144
| bottles and they give no samples.
|
| In this case, you might say: "Yeah, I really wanted to
| try that beer but there is no way I am paying $720 for
| that". It's exactly the same here.
|
| (re 1147% vs 12400% - sure, maybe you could argue you
| should not look at a single license, but rather at a pack
| of 5 or 10 licenses... but this does not change numbers
| much for Coursera, it's still huge increase.)
| stronglikedan wrote:
| It why students get so much free software too.
| ezekg wrote:
| I think this is also one of the hidden benefits of commercial
| open source and similar models: individual adoption grows
| corporate adoption.
| apples_oranges wrote:
| Clearly, yet many open source contributors just work for
| free..
| ezekg wrote:
| I specifically said commercial open source, which is
| different -- one hopefully has a business model and the
| other does not need/want one. Working on open source
| outside of a commercial context has never promised
| compensation, and expecting compensation for it ends in
| pain.
| scarface_74 wrote:
| Except for that whole every company that tries it ends up
| either not making money money on it, get Amazoned (where
| Amazon offers a hosted version and makes money), or ends up
| seeing the error of their ways and using a more restricted
| license and still struggles.
| ezekg wrote:
| Agreed. There are better models to commercial open source
| that align better with business sustainability, like fair
| source. I was mainly referring to bottom-up adoption, not
| sustainability.
| ta1243 wrote:
| Amazon already has a relationship with your corporation,
| it's easy to buy their hosted elastic search
|
| Even if the original elastic company offers it cheaper, or
| better, that's a massive hill to climb. Corporations don't
| care about costs, they care about pieces of paper, or less
| charitably nice dinners with the sales team.
| gcatalfamo wrote:
| "If they already use it, why should I buy it?"
|
| It sounds like a trivial question to answer, but it just
| exposes the level of detachment that exists between who makes
| the purchase decisions and its users in SME context.
| takinola wrote:
| Because you want to control who uses it (offboard separated
| employees, onboard new employees automatically), integrate
| into your auth systems to make it easier for employees to
| access, get an SLA if something goes wrong, connect to your
| data auditing systems, etc, etc. Companies have a lot of
| needs outside of just the core functionality of a product.
| kube-system wrote:
| You might want to understand the politics and business
| dynamics before you go too far down that route. You could
| just end up getting your product blocked and/or replaced
| with a competitor instead.
| esafak wrote:
| "Don't you want them to use it more securely, and with
| enterprise AI features?"
| jagged-chisel wrote:
| Wait - it's not secure now? We'll be banning it
| immediately!
| esafak wrote:
| "No, it's _more_ secure! We have encryption, which means
| intermediaries can 't snoop, but don't you want to be
| able to monitor what data goes out?"
|
| etc. There's a laundry list of features enterprises care
| about, better spelled out in the sibling post.
| kube-system wrote:
| "Well we have Bob from purchasing on the phone and he
| says we have to put this out for a bid first. And Alice
| from compliance wants to know, do you have [insert
| esoteric certification]?"
|
| You really have to know who you are talking to and their
| motivations before you know what the right sales angle
| is.
| hinkley wrote:
| I knew at one point some engineers who added RFC2549 to
| see if the salespeople were just being yesmen. A few
| years later I had similar problems with HSM salesman
| lying about Java support in their products so I can
| sympathize. Buying a product you cannot use without
| extreme effort is the pits.
|
| One of them put in a bid to Cisco and got a reply back
| saying something like they were working on it but having
| some issues with the birds.
| ecshafer wrote:
| For enterprises its not usually as simple as sell to the CTO.
| Some things you need that, if you are AWS or Azure, the CTO and
| some principle engineer are who you have to convince to move the
| whole 20k person org over. But for a lot of software its the Line
| manager or director who is calling the shots, or a division head
| since division A may use different software than division B.
| user_7832 wrote:
| This works if the users are able to use the product (in this case
| on their personal device maybe) first, and are part of the same
| organisation.
|
| But what about cases where the user isn't directly related to the
| decision maker? Doubly so when it's a hard to justify purchase?
| (I.e. you're not selling bread or IBM machines.)
|
| For example, say, a keyless entry fob for a car. The driver
| benefits immensely. The CTO of Ford may probably not even
| entertain a meeting ("Huh, what does he think, locks are bad or
| something?! What's wrong with a secure lock?")
|
| Does anyone have any suggestions for how to approach such a
| situation if you developed the fob and now want to sell it?
| SoftTalker wrote:
| Demonstrate that competitors are adopting fobs and try to build
| FOMO.
| at-fates-hands wrote:
| In your scenario, you're looking at a bottom up approach.
| Instead of going to Ford, you start at the bottom of the food
| chain. Used car dealerships, auto body shops, and other places
| that sell/install accessories for your car.
|
| A great example is remote starters. Same idea. Great for the
| user, not so much for say Ford. The first places I saw these
| being installed? Stereo shops would use it as a cross selling
| feature whenever they were selling something else to a
| customer. I could be wrong, but it took a few years for the
| manufacturers to start including remote starters as an add-on.
| Before then, it was all kinds of other shops selling and
| installing them.
|
| But its a trench warfare type of deal. You have to get into the
| hands of the people who can install them, then work your way up
| to approaching dealerships and larger clients.
|
| I've done this with an anti-theft device. Start small, then
| build your client base and use that as a springboard to get
| interest from larger clients.
| SoftTalker wrote:
| Just be sure your product actually works. Third
| party/aftermarket remote starters and car alarms are (were)
| nortorious for causing a varity of intermittent, obscure
| electrical issues. Not sure if it was the devices themselves,
| or the installation, or both.
| doppelgunner wrote:
| Be a middle man, charge a percentage like tiktok per sale.
| greenail wrote:
| This is a bit of a simplification of how enterprise sales works.
| A few extra dimensions are sometimes required. For "decision
| makers" their own personal view of reality may not in fact be
| accurate. You sometimes must vet that what they tell you (and may
| in fact believe) actually reflects the actual power dynamics of a
| big enterprise. There are extra dimensions to consider; The first
| is: are they in a cost center or are they generating revenue. The
| second is: are you trying to get new technology adopted or is
| this considered "standardized". The third is: who might perceive
| your product as a risk, or a threat to their power? These data
| points inform your sales strategy both in who you sell to, who
| you avoid, and when you might choose to engage a particular
| persona, when to go small and when to go big.
| spauldo wrote:
| I'll tell you how not to do it.
|
| Require me to give you my contact information just to download
| something. Have sales people blow up my phone and/or email and
| ignore polite brush-offs. Keep reaching out to me periodically
| with requests to have a meeting about how you product can help
| me.
|
| I don't have buying power, but I do have bitching power and your
| product will wind up getting bad-mouthed by the whole team
| eventually. And when the engineer asks us for recommendations,
| guess what we tell him?
|
| Lookin' at you, Veeam, AWS, and Keyence.
| whstl wrote:
| Adding Auth0/Okta to the list. Funny enough I had buying power
| and budget for it, and was gonna ask a Senior engineer to look
| into it, but the calls got so crazy that I just soured on it.
| vipa123 wrote:
| Same experience
| thewebguyd wrote:
| IT Manager here, and deal with this almost weekly at this
| point. I'll add to your list of how not to do it - ignore my
| brush-offs and start email blasting others on my team or within
| the company to get around me. Quick way to get your domain
| blocked all together.
|
| Also please don't make me sit through a demo just to get a
| quote. If I want a full demo I'll ask for it, and I need to
| know pricing first before even considering going any further.
| I've probably already researched your product, maybe even did a
| trial if available - I don't need to sit through any number of
| sales pitches, just give me the numbers.
| mnhnthrow34 wrote:
| I fairly recently got to switch sides on this. I never take
| sales calls or want to get on demos as a developer ... but I
| moved roles a bit and needed to join some calls with the reps
| at my company for a product I now manage. It has no public
| pricing.
|
| I was surprised by how much the people who show up for demos
| seemed to like them and have good relationships with their
| reps. They thank us for saving them a lot of time they would
| have spent reading docs and marketing materials to learn the
| specific things that applied to them, or for us talking about
| roadmap stuff they don't get to see in the public materials.
|
| Sometimes the price is a surprise to them and it needs a bit
| of context. Customers who are used to buying software this
| way seem to read between the lines really well and ask
| suitable questions about discounts or whatever, when they are
| surprised by pricing. Often we are able to make something
| work at a different price than the typical quote, or we can
| connect the dots so that the rationale is more clear, or the
| value requires some customization to be done.
|
| My reps tell me this sorta thing is difficult over email,
| that nobody makes $10k+ purchases without talking to
| somebody, so if we can't get you on a call the deal falls
| over.
|
| So I dunno. I'm not a big fan of the requirement for calls
| really, but I can understand why reps don't just throw quotes
| around without some conversation.
| thewebguyd wrote:
| Appreciate the other perspective. I'll even admit there's
| been cases where the demos have been useful and sparked
| other questions, but in those cases I hadn't heard of the
| product before or was coming in blind.
|
| Most of my cases now (and I may be an outlier), I'm looking
| at something because I both have a need and someone I know
| recommended it or uses it so I'm already familiar, but at
| that point it's not so much a sales process and more so "I
| already know I want this, and I already have the budget and
| approval, let's get this buying process over with as quick
| as possible."
| mooreds wrote:
| Love the idea of "bitching power"; basically anti-"word of
| mouth". Even if you make something freely available, your
| sales/marketing/GTM folks can hurt your company's name by being
| too aggressive.
|
| You should contact to people how they want to be contacted, not
| how you'd want to be contacted.
|
| It's a difficult incentive design problem though.
| neilv wrote:
| I've seen some insanely obnoxious email saturation bombing from
| some SaaS marketing teams. One was emailing me every 5-15
| minutes.
|
| Sometimes it could just be a rogue sales/marketing person. But
| other times it looks like it's probably blessed from the top,
| if not the startup-CEO personally setting the email marketing
| tool slider controls to maximum trashy level.
| doesnotexist wrote:
| Situations like this are instances of the
| https://en.wikipedia.org/wiki/Principal%E2%80%93agent_proble...
|
| In this case, corporate management holding the purse strings but
| their workers (devs) using the actual tools. The solution they
| offer to founders is to make the user your champion and have them
| sell your product for you.
|
| "The meta point here is that you're not going to talk to the
| credit card holder; the user/dev is going to do that for you.
|
| Give them the best possible chance at convincing the leadership.
| Make them look awesome for even bothering the leadership with a
| choice like this. Make it obviously awesome for them to decide
| "yes". These users/devs are your sales people."
|
| Maybe that works for dev tools with freemium models, but in many
| industries where this problem arises its just not possible to
| even get your product in front of the users. Take hospital
| systems and EHR purchasing where Doctors and Nurses are the users
| of the EHR day in and day out but it is the hospital
| administration that ultimately gets to decide which EHR is
| deployed. How do you get users to be champions of your product if
| you can't even get it in front of them?
| hinkley wrote:
| Too often we get the reverse. Slick salesman targets the person
| with budgetary discretion while avoiding letting the users in
| in the transaction, so by the time they can complain about how
| terrible the product is, the check has already cleared.
| mlinhares wrote:
| Yup, then the technical people have to deal with the bullshit
| and nightmare that is implementing the shitty thing that was
| purchased. Hard to get around this in large enterprises,
| someone just decides they're going to use some shitty tool
| (like that cloud provider no one uses but has great sales
| folks) and you just get a notice you have to migrate all your
| apps to the new thing in 3 months cos they got a better
| contract there.
|
| The school district my kids are changes the parent app almost
| every year, its always a nightmare for everyone involved, I
| can't imagine what it is like to work IT in such a place.
| hinkley wrote:
| I believe open source is approximately an order of
| magnitude larger than it would be if developers controlled
| their own purchasing. What FOSS introduced was the ability
| to use software without someone with a little power saying
| no, you can't, because we won't pay for it.
|
| Jetbrains threaded this needle for years by having
| professional licenses tied to an individual with clauses
| for time and location shifting. So you could use their
| software at home, drive to work and also use the same
| license there.
|
| And they priced it at around the cost of three tech books
| per year, which it is at least that useful for
| productivity. I suspect we would be in better shape now if
| others had copied their model. Rather than the (defunct)
| Microsoft model of ignoring home piracy and demanding
| commercial licenses from any company large enough to make
| it economical to fire off a cease and desist to them and
| demand back pay.
| amelius wrote:
| Do what big companies do: sell your users!
| shalmanese wrote:
| Employees, by and large, all share three common desires:
|
| * How do I get promoted?
|
| * How do I get a raise?
|
| * How do I not get fired?
|
| Beyond those common desires are a constellation of more
| personalized that is specific for each salesperson and the cohort
| they target (I'm somewhat of an idealist in that I believe people
| are quite often strongly driven by meaningful non-capitalist,
| non-realist desires).
|
| In any case, when you're working in enterprise sales, what you
| have to realize is that, regardless of what the desire is, what
| your corporate champion is "buying" is a way for them to achieve
| their goals and only incidentally what is good for the company,
| where your product is merely a proxy to accomplishing this.
|
| Of course, companies also know this and anyone who has owned a
| P&L immediately recognizes that the sum of all things everyone
| wants far exceeds the resources of the balance sheet, thus, some
| selection process needs to be put in place to allocate scarce
| resources.
|
| Your corporate champion is ideally far more aligned with you
| against the company than they are with the company against you
| and your job is to figure out how to win this selection battle
| together.
|
| The core insight though, is that people are actually
| astonishingly bad at performing on this and it's actually quite
| easy for an outside sales person to become a subject matter
| expert for 3 core reasons:
|
| 1. Any employee usually only ever has a sample size of 1 whereas
| you have a broader peek into how this has happened across a range
| of companies industry wide.
|
| 2. Any employee, only a minor part of their job involves
| interfacing with outside parts of the firm responsible for
| allocating resources whereas you treat this as a core competency.
|
| 3. For any person, it's always easier to advise a 3rd party on
| what to do than to practice the same actions yourself.
|
| What this means though, is that, as an enterprise salesperson,
| you should understand that your core value comes from developing
| subject matter expertise in how to help people in your industry
| get promotions, get raises and avoid getting fired and the
| product you're representing at the moment is merely the avenue
| through which you enable that to happen.
|
| The best salespeople I've ever met always share a common core
| value that they deeply care about making sure everyone around
| them is getting rich with the faith that some of that money
| eventually reflects onto them but that's not what drives them.
| That's why so many immigrants and children of immigrants make
| such great salespeople, they've seen the material difference
| wealth has made on their circumstances and they want to spread
| that opportunity to others.
|
| This is what I advise Founders who start Enterprise focused
| businesses. Fundamentally, you should be thinking about how do I
| get someone to VP/Director/Line Manager/Tech Lead 2/3/5 years
| earlier than if my product doesn't exist and how do you breathe
| this passion day in day out.
| mlhpdx wrote:
| Agreed, with the modest addition of "How do I avoid unexpected
| hassles?" It shares a corner with not getting fired but is more
| about comfort than risk.
| mfrye0 wrote:
| This hits home. We're building business intelligence APIs around
| entity resolution, and the buyer/user split gets messy when you
| have engineering, product, and data science teams all involved.
|
| Engineers immediately understand why matching messy company data
| is a nightmare, but executives just see delayed projects without
| grasping the technical complexity.
|
| We're seeing more success lately with "your team burned N months
| on data matching that should've taken weeks" rather than
| explaining what entity resolution even is. We're talking to one
| company right now that's spent 10 years building their own entity
| resolution system and it still doesn't work well.
|
| But even then, it depends on the company and what they're trying
| to do.
| arkmm wrote:
| How are you guys reaching users with such a technical value
| proposition? Cold emailing engineers first and then expanding
| the conversation from there?
| klik99 wrote:
| The company I founded previous faced this problem - we were
| selling to a part of the development team that often had no clout
| in making financial decisions. We were able to sell to smaller
| companies and larger ones that happened to have people who had
| enough power to purchase. But the majority of companies had super
| long sales cycles where we had to work with them to prove out the
| cost savings to people higher up. Most of the time this went
| nowhere and cost us a ton of time. It wasn't the only reason the
| company failed, but a major contributing factor. Glad to see
| people talking about it because it's something a lot of small b2b
| companies face and there's surprisingly little advice on it.
| robot wrote:
| best course: don't. they have a shitty structure so don't bother.
| find users who are also buyers.
| johngalt wrote:
| This problem is why so many organizations will do an SSO tax.
| btown wrote:
| B2B2C marketplaces - especially ones that don't charge the "B2B"
| users, but take a cut of each transaction, and empower users to
| encourage transactions through a customized instance of the
| platform - are a fascinating "final boss level" for this mindset.
|
| Your user is not your buyer, but they _can_ be a distributed
| salesforce. You need to growth-hack not only for your penetration
| at the B2B level, but to give them the tools they need to growth-
| hack their own B2C client bases, with your product at the
| forefront.
|
| That's a lot to build as a founding team, and occasionally it can
| be like herding cats - but it can be incredibly lucrative,
| because you have an incredibly low barrier to entry at the B2B
| level, but every account naturally scales with value delivered to
| the end customer.
___________________________________________________________________
(page generated 2025-08-07 23:00 UTC)