Product-led growth for dev-first business: Is it inevitable? | Hacker News Reader

Product-led growth for dev-first business: Is it inevitable?

thenewstack.io

42 pointsmooreds21 comments

Apart from bottoms up and top down, there is a strategy called middle out where you target engineering managers and then simultaneously get developers excited with product experience and directors/VP(purchasers) excited about product value. This generally accelerates purchasing decision. What I have seen go wrong with pure devtool bottom up is devtool can see value but org does not value the tool. Just devs do not have purchasing power to get to a target Annual contract value that can justify valuations they raise. Everything is devtool space has become product led by design.

Bottom-up really requires the “and up” part:

- each pricing plan targets an org scale

- and the features address those problems

That’s why websites tend to go from selling you on individual features (5 servers a month!) to team features (10 headcount!) to organization features (auto-invoice! SAML!). Your entry point is the bottom user (5 server home IOT), who convinces a manager (our team needs this!), who convinces a director (we can solve this org issue!).

The problem you’re describing is “bottom only”: if you only solve the basic problem, you’ll only attract bottom clients.

(I agree with your point about middle-out; just emphasizing the “up” part of bottom-up.)

Your individual->team->organization breakdown is an excellent way to look at it. Simple, short, perfect. Thanks.

Definitely.

got some other interesting insights from the BCG post by Akash Bhatia related to the stage of the company and their cloud adoption

see `Creating a Developer-Focused GTM Model` [here](https://www.bcg.com/publications/2022/developers-influence-i...)

taking the purchase pathway of: 1. need/demand 2. shortlisting 3. testing/evaluation 4. final decision

it seems like the dev teams has (and derivatively, the developers have) say in at least the testing/eval and the final decision stages. as cloud native becomes more mainstream, i'm sure we can see how this influence will affect each stage of the purchase pathway.

Do you have examples of successful middle-out devtool businesses?

Databricks, confluent, sumologic are often mentioned as examples of middle out.

Who are the middle that databricks targets? I thought their product is usually something org wide, hence a near executive level decision. Then again I'm not too familiar with them

There's of course middle out compression, the guys came up with it while calculating MJT.

with unbelievable weissman scores, including 3D video.

Agreed with your point and glad to see a name "middle out" tied to the strategy that we are following at DevZero for the similar reasons you pointed out.

>simultaneously get developers excited with product experience.

Would love to hear some strategies companies are using for getting developers excited with product experience and what's working better - is it freemium / free-trial / personalized demo or something different?

I agree with the central thesis of the article (I didn't watch the video...), that PLG is basically inevitable for developer tools, particularly given the way that devs push for adoption of tools that they personally like from within an organization. Cloudflare has done a particularly good job of this, and as upstarts, I'm really optimstic about stuff like Tailscale and Fly.io

But I also think that startups and VCs alike are going to have be a LOT more reasonable when it comes to valuations. You can build very sustainable, profitable businesses with PLG, but it does usually require burning a lot of money up front, and won't likely end in a Cloudflare scale home run. And I've seen firsthand how just getting a _little_ bit wrong with your free vs. premium tiers can result in some significant and unforeseen infra charges.

>And I've seen firsthand how just getting a _little_ bit wrong with your free vs. premium tiers can result in some significant and unforeseen infra charges.

Can you elaborate?

I don't know if I got in me to write out a ton here--I probably owe this sort of thing a blog post or write up at some point--but I'll just say that marketing _really_ likes terms like "unlimited", sales loves to sell committed and contractual spend, and engineers love to automate (particularly in a PLG motion).

So you get things like...a lot of compute or bandwidth spend. (You know, I tried to think of other examples, but at some point it really does come back to the compute and bandwidth.)

And in a up-or-out kind of growth mentality, it's easy to handwave a lot of that away as just growth spending. But if the returns don't kick in big time at the end, you've just accelerated your runway.

>And I've seen firsthand how just getting a _little_ bit wrong with your free vs. premium tiers can result in some significant and unforeseen infra charges.

same question here - would appreciate some war stories here.

Great points and thanks for the tailscale mention. That is exactly the product we needed this week. One thing not mentioned is how to make product led growth accelerate by word of mouth and how to encourage that. It’s the key to acceleration imho. That is hire to get a network effect. From the last century but this was how AWS started our Blackberry if you go farther back. The value proposition is individual to team to enterprise but how do you get team success to multiply. The term for this was influential end user marketing. :-). Who you get is as important. The opals trope was are these people who give more advice than they receive. Those are really important folks :-)

This way, we will have companies that are open source but manage the ecosystem as they want. I don't know, maybe that's what it should be.

This happened to music and TV/movies:

People pay relatively little per album, movie, or show — which is made up mostly in upsells (merchandise) or hosted versions (concerts, theaters).

I think that may just be the fate of easily copied IP — which is good for society.

"non" potential customers who demand apps to be open source likely to just want to feel safe that said apps won't go away. I've seen a lot of opensource SaaS "manage the ecosystem as they want" because of that. Actual customers be like .. I'm done when I get the value I want (don't care anything else e.g. privacy,lock-in doesn't matter)

Great point on the hierarchy needed

I'm a co-founder of a company called Factor House[1]. We build a devtool called Kpow for Apache Kafka[2] and I guess you could say we rely on PLG. I can't say I had heard of the term when we started back in 2018. We are bootstrapped and have always preferred to describe ourselves as a business rather than a startup.

Kpow provides enterprise-grade Kafka tooling. It comes from our experience working with Kafka since 2012 and more broadly working in the enterprise space for much longer. I'm an old-ish engineer and when everyone else was raising we were coding, selling, and supporting.

Our growth has been slower than I expected but we are profitable and growing. We sell to everyone from startups to Fortune 500 companies. In every case the sale begins with an engineer in the client company evaluating our product after finding it themselves.

We don't spend much on sales or marketing. If you start a trial and chose not to continue with the product you never hear from us again. We cancelled our Google Adwords some time ago, that may have been a mistake but we felt we were paying for crap.

At the end of last year we soft-launched the (inevitable) free, community edition of Kpow[3]. It is scary giving away four years of hard work and the associated risk but we believe in our product and we think the best way to grow our company is to show value to engineers and make sales to organisations.

I think some advantages/disadvantages of this approach are:

Advantages:

1. The Sales That Matter Are Comparative.

For the sales that matter an engineer will evaluate three products in the market to fit the needs of their team/org. We don't need to be the first product you think of, we just need to be in the comparative evaluation. We make an expert system for experts, if our product is on-point we will win.

2. Purchasing Power Is Shifting.

Who needs top-down sales through the CTO when teams/engineers have access to AWS and some discretionary budget. We started selling Kpow on the AWS Marketplace in 2020. You can pay by the hour if you like. This model has a lot of legs in it. Counterbalanced significantly by disadvantage [1].

3. Engineers See You.

The no-bull approach pays dividends with our target audience. Our users are very supportive and we have 0% churn in 3 years of sales/renewals.

4. Focus.

We're a small engineering team, we focus on doing what we do best which is shipping working software. We also have the pleasure of being able to focus on a fixed surface area without having to broaden our pitch to appeal to investors.

Disadvantages:

1. The Sales That Matter Are Big And Slow.

We sell to plenty of companies, but it's the bigger ones who pay the bills. The enterprise sales cycle is slow and unavoidable.

2. PLG Doesn't Mean No Marketing.

We intend to switch our focus into marketing this year, there's no point having a great product if no-one knows about it. A great product doesn't make a great business and there's more to it than just coding.

3. Getting it Right is Hard.

You bet a lot on a narrow focus. We cut our first code in May 2018 and our product vision has not changed. It would be easy to get that wrong and hard to recover.

[1] https://factorhouse.io/

[2] https://kpow.io/

[3] https://kpow.io/community/

[4] https://aws.amazon.com/marketplace/seller-profile?id=ab356f1...

Reply on news.ycombinator.com