🌱 5-Bit Fridays: Startup misconceptions, why to build slowly, the Modern Data Stack, monetization advice, and the LinkedIn algorithm explained
www.howtheygrow.co
Discover more from How They Grow
In-depth analyses on the growth of world-class companies, unpacking their early strategies, current tactics, and the product-building lessons we can learn from them.
👋Welcome to this week’s edition of 5-Bit Fridays. Your weekly roundup of 5 snackable—and actionable—insights from the best-in-tech, bringing you concrete advice on how to build and grow a product.
Happy Friday, friends 🍻
I’m sure you’ve been privy to at least one video (you never asked for) of Mark Zuckerberg doing some Mixed Martial Arts training. And no, not just in the metaverse. And no, he’s actually got skills!
Also, in a somewhat surprising move by Disney, Marvel has used generative AI to create the opening credits for the new show, Secret Invasion. As you can imagine, creatives are not happy at all. You can watch it here.
And lastly, before we get stuck in, shoutout to Turner Novak for finding this gem of a meme…
Ok, onto the more serious stuff.
Here’s what we’ve got this week:
Misconceptions held by early-stage founders
The value of building slowly
What's the Modern Data Stack?
Monetization lessons from growing revenue from $10M to $50M
The LinkedIn 2023 Algorithm, explained
Small ask: If you learn something new today, consider ❤️’ing this post or giving it a share. I’d be incredibly grateful, as it helps more people like you discover my writing.
, and I thought it would be a fun one to share today because it bucks a lot of the conventional wisdom we’ve covered so far in this newsletter, playing Devil’s Advocate to many of the lessons we’ve learned.
Of course, that is not to say any of this has been wrong. But rather, there is always another side to every piece of advice worth considering. And for startup founders, “advice” can be overwhelming, chaotic, and contradictory.
So, I’ll let Ben add some more of it here for you. ✌️
I’ve argued many times that platforms always win. And generally, I still believe that to be true. However, as Ben describes very persuasively:
Platforms are cool, but they suffer from the challenge of being too horizontal. [And] horizontal platforms leave the use case up to the imagination.
Unfortunately, platforms struggle when users don’t have an immediate or painful enough use case, or can’t figure out how to use a generic platform designed to do “all the things.” Going to prospective customers and saying, “You can use it for this, and this, and this, and this!” isn’t helpful.
It’s tough to be the world’s greatest platform that [helps with a high-level broad thing.]
It’s easier to be the world’s greatest [product that solves a specific use case.]
You don’t need to build a platform at the outset. Typically I discourage it, and prefer to find very specific use cases (leaning into specific verticals or industries) where you can really understand the need, the user/customer and dominate. Use cases help people understand what you’re doing and why. Use cases help people figure out if you’re right for them versus all the other “generic platform tools.”
You need to go after a big market
Bigger isn’t always better. If a market is already large—like a tiny ship entering a massive ocean—there’s the risk of you just getting washed out and lost.
Proclaiming that if your startup just gets 1% of the video game industry you’ll be a billion-dollar company, is/should be the quickest way to the door.
Besides indicating that you probably just Googled “video game market size” and showing you used the laziest/most inaccurate way to “calculate market size” for your product, you also likely don’t know enough about the space and the customers to calculate it more appropriately.
Simply, just never do that. Top-down market sizing is usually a mistake (especially for new products) even if it does give you a nice big number to show off in your pitch deck.
And while it’s true that VCs generally prefer larger markets, or markets growing quickly, because it makes for a more justifiable opportunity and a clearer path to a big win in theory, as Ben says:
I prefer niche markets that you can really go deep on, learn from and take a big chunk out of. Then you can expand up market or go sideways into another market. I’m not suggesting doing this is easy, but it’s easier than going after the biggest market possible and pretending you can win. By the way, you can also go after a smallish market and grow it.
And to continue with this thread:
It is possible to go after too small a market. There is no magic bullet for a Goldilocks market size. Ultimately, it’s more about how you define the market (i.e. who’s in it, their propensity to pay, frequency of the problem, etc) in the beginning, vs landing on an actual number. Ben does give a loose range though: “If your target market is sub $1B that’s probably too tiny. Anything over $50-$100B is probably too big to really wrap your head around.”
Small markets should not equal small vision.
It’s not just about the total market size (TAM). Firstly and more practically, it’s about which section of that market you can reasonably go after with your product. And secondly (and this is the sweet spot), it’s about demonstrating a strategy for how you will expand the market (e.g. the new people you will bring into it).
More features = More usage & sales
According to a study by Pendo, ~80% of features in software products are hardly ever used.
In other words, being a feature factory and just shipping stuff is not how you solve customer problems, and drive usage and retention.
Instead of focusing on adding more features, figure out what really makes your product tick and get that right. It’s much more effective to go deep on one problem and type of customer than it is to spread yourself thin across many mediocre solutions.
You can copy competitors’ pricing because they tested it first
Just because it works for someone else, does not mean it will work for you.
It might, but just copying pricing is not a pricing strategy.
What it can do though is help you with price positioning and finding some benchmarks while you do your homework. As you map out what competitors at different areas of the market are charging, you’ll learn about what units of value people are charging for, and what customers’ propensities to pay for a solution are.
As Ben writes: “You don’t know how other companies are making decisions. You’re not in their board rooms. You don’t know if what they’re doing is based on any legitimate research/validation or just the CEO’s gut.”
Everyone is out to steal your idea
The reality is that no one is looking to steal your idea. Why? Because they have their own ideas (and their own problems!)
Ideas are everywhere. I’m not belittling the importance of ideas (they’re great starting points) but they’re not proprietary or secret.
Building in stealth isn’t necessary. I get why people don’t want to reveal what they’re working on too soon. This should be less about someone stealing your idea and more about avoiding distractions. If you’re heads down and super focused (by hopefully talking to users/customers!) feel free to stay in “stealth mode” from the general population. You don’t need to be on Twitter sharing every gruesome detail. You don’t need to be generating buzz. You can do both of those things, but neither is necessary for success. Stealth mode from the hustle culture startup ecosystem is fine; stealth mode from key users, customers, partners is not a good idea. (Note: You can also go the opposite and build in public. Some folks have had great success with that.)
Investors won’t sign NDAs. Founders still ask me (and other investors) for NDAs. We won’t sign them. We see too many things. I completely understand why a founder might be nervous about sharing with an investor (b/c they know the investor sees a lot—heck, the investor might be invested in a competitor and the founder doesn’t even know it), but odds are the investor is not stealing your idea.
For more by Ben, subscribe to his free newsletter:
Join 6K+ people learning about product, growth, and company building. Free for now, not forever.
(#2) The value of building slowly
Sticking to the above theme of somewhat contrarian advice: shippingfast is not always the best move.
And here’s why:
The popular belief system still centers around the “lean startup,” A/B testing, and shipping quickly. There are two reasons why I don’t think that’s necessarily the ideal approach.
Firstly, teams tend to underestimate the gravity created by shipping their first product. Once you share something with customers, you naturally start to think in iterations of that product; it becomes infinitely harder to change direction and climb a different mountain entirely. Shipping too quickly can become a prison – a team can get trapped, iterating on something far longer than they should.
Secondly, moving too quickly can limit the benefits of product-led growth. As advertising has become more expensive, having a product that customers talk about is critical for acquisition. One of the key principles of product-led growth is to “surprise and delight” – to build something that customers will talk about with their friends. It’s easy to forget that people don’t tell their friends about a product that does exactly what they expected; they talk about products that surpassed their expectations.
If you need people to be talking about your product, you shouldn’t just ship a minimally viable product. On the contrary, you should polish and push beyond the core requirements to create something customers don’t expect and that can grow on its own.
This bit is a little more along the lines of “how to get more technical”. If you’re not a PM, or founder, or just not interested in unpacking the journey of how data moves around…feel free to just hop to the next bit.
Still with me?
Cool. As you know, data is good and it helps us with all sorts of decisions.
What’s also good, especially as product managers looking to develop our technical chops, is having a better understanding of what’s going on under the hood, and how the data sausage is made. If we run to someone on the data team and ask, “Can you pull a report on X quick”, it’s helpful to know (at a high level) what we’re asking for.
And a good place to start is by looking at The Modern Data Stack — a term coined by Justin Gorge. As he describes it, the MDS is “a new-ish set of tools that data teams are using to collect, transform, explore, and make use of their company’s data.” In other words, it’s all the stages and machines along the sausage factory line for business intelligence, from raw data to clean charts that you stick in your decks to pitch new products.
In Jorge’s words:
There are a million ways to cut the data stack, but generally, it will fit into a few categories:
Something to pull in data from where it’s generated
A place to store your data
Something to transform your data with
Something to visualize and analyze your data with
Here’s a summarized rundown of each:
1) Something to pull in data from where it’s generated
Problem number 1 when you want to analyze data is that the data is nowhere to be found. Typically, analytics questions like “how much revenue did we do this month?” require integrating data from multiple sources – perhaps in our case Stripe and our production database with user information. More generally, important data gets generated in a ton of tools your company might be using:
Salesforce
Hubspot
Stripe
Facebook Ads
Zendesk
And to analyze that data alongside other data, you need to get it out of there and into your data warehouse. You’ve also probably got data that your company’s application is generating – like who your users are and what they’re doing – that you’ll want in there too.
You need somewhere to put all of that nice, useful data we’ve been talking about. The simple answer here is a database: but what kind of database? Generally, there are two categories:
OLTP databases: made for applications, small and quick queries
OLAP databases: made for analytics, long and multidimensional queries
You don’t want to use the same type of database for your application and you do for your analytics, because your queries for each are so different
The data you’re pulling in from your systems is rarely (read: never) in the exact format you want it to be in. From the Technically post on ETL:
Here’s what a typical transform workflow might look like:
Remove dollar signs from the “order_value” column (clean) →
Fill in missing values in the “username” column with “anonymous” (clean) →
Aggregate orders on a monthly basis (transform) →
Join order data to user data to get shipping location (transform)
Typical ETL workflows can have tens or even hundreds of these kinds of transformations per dataset.
You can transform your data with SQL, Python, or any other language – no matter what you use though, you’ll need some sort of system and server for running this stuff, notifying you when it fails, debugging, etc.
4) Something to visualize and analyze your data with
Once your data is in the format and place it needs to be, it’s time to analyze it. There are a lot of different types of analysis:
Exploratory, open-ended analysis
Ad hoc question answering (“can you cut the data this way for me?”)
Dashboards and regular reporting
Building ML models
Building data apps
Each requires, or at least benefits from, some degree of specialized tooling. Data Scientists need somewhere to write one-off SQL queries, but also a place to build and maintain charts, which might be a separate place from where they share experiment results, and so on and so forth.
(#4) Monetization lessons from growing revenue from $10M to $50M
Dan Layfield was the head of the growth team at Codecademy for 3 years. As a product manager, he helped the learn-to-code platform grow from $10M to $50M ARR+ before it sold for $525M.
From his journey in scaling Codecademy’s revenue by 5x, Dan recently shared a few lessons he’s learned from growing a recurring revenue business.
TL:DR: Setting up the basics of a monetization system early on makes a world of difference as your product grows. Simply, the folks that sign up and you don’t monetize early are likely gone forever, so it pays huge dividends to set up a strong foundation. If you can get to a place where you have a strong checkout page, good pricing structure (not just copied), paywalls, payment processing, and a process to manage churn, then you’ll be better off than 90% of early-stage companies.
Let’s go a bit deeper. ⛏️
Recurring revenue businesses are basically structured like this diagram.
Many companies go wrong because they only focus on making acquisition cheaper and faster when you should have been systematically improving LTV to afford higher acquisition costs.
There is a Dan Kennedy quote, which is something like:
“The business that can pay the most to acquire the customer will win.”
Assuming that you don’t have a bunch of VC money light on fire (and even if you do), the best chance that you have in the long term is figuring out to better monetize each monthly cohort of users and increase your overall LTV, which will allow you to spend more to acquire more customers profitably.
So, with that helpful context, here’s Dan’s advice for reliably making improvements to your monetization system. 💸
Figure out monetization early in your product/company’s life
Everything gets more expensive to change the longer you wait. It involves convincing people who may be used to free value, changing more code, retraining more sales/customer service people, etc.
Every cohort you under-monetize during your early years is money you never get back.
While speed is essential in all businesses, it’s extra important in subscription businesses
Subscription businesses are slower to scale than most B2B businesses because most of your customers will pay incrementally across their lifecycle, and you are not likely to close a big enterprise account that allows you to collect a lot of cash upfront.
Because of this, every missed cohort of users you didn’t monetize well is lost forever. The faster you get the best practices running, the more revenue you’ll have to compound in the following years. Don’t overthink the fundamentals.
Rule of thumb: work from the bottom of the funnel upwards
Your active paying users are hands down the most valuable to you. You don’t want to lose them for things like payment failures that could have been prevented.
If you are in a company that drives decisions based on A/B tests, you will be beholden to a concept called minimum detectable effect (MDE).
MDE is the smallest lift you can measure with statistical significance (which basically translates to confidence).
So if you have a high MDE, say 20%, and you ship a test that improves something by 19.99%, you won’t be able to measure with statistical significance. There are ways of compensating for this, but this makes testing hard.
The worse your overall conversion is, the larger the MDE will be, which makes A/B testing harder.
But the upside is that improving things at the bottom of your funnel will lower (a good thing) the MDE, which raises the accuracy of your ability to measure things above it in the funnel.
It’s hard to convince people to pay you money, so start by finding all the people who are trying to pay you, and it’s not working
I love this advice.
It’s similar to the idea: “A bird in the hand is worth two in the bush”.
In practice, this means finding all the dead ends, points of confusion, and areas of friction that people who are already willing to buy are experiencing.
These people don’t need carrots or sticks to move them along, they’re already there.
One way to do this, as Dan says: “Ensure the checkout page error states are clear, that any payment integrations aren’t broken in specific browsers, etc. Are the bugs that happen during certain edge cases in important parts of the app?”
Focus where most users are and focus on improving clarity
Try to find the places in your product that most users are converting from and ensure that you’re setting context correctly the step before.
One of our most successful tests on our homepage changed the primary CTA from “Start Coding” to “Sign Up.” Most of the time, we were cute with copy or messaging; it hurt us.
(#5) The LinkedIn algorithm, explained
Looking for ways to boost your LinkedIn reach and get the most juice out of your LI content?
Same. 😔
Well, this infographic could help. Building on research conducted by LinkedIn expert Richard van der Blom last year, the Creativity and Innovation Network has published some new findings on key LinkedIn algorithm recommendations, based on an analysis of 2,000 posts published between February in March this year.
Image credits: Fatima Khan
But, emojis, format, and time of day—as seemingly important as they are—are never a substitute for quality, value-adding, content.
🌱 And now, byte on this if you have time 🧠
We encounter friction every day— in all its forms— as we brush our teeth, go for a jog, or argue with a friend.
In an NPR episode of TED Radio Hour, speakers explore how this force can be dialed up or down to improve our lives.
For builders, there’s a lot of wisdom in here. Often, it’s not about convincing people to do something (like buying our products). They are already convinced, and instead, it’s about finding and removing less obvious barriers.
As always, thank you for reading and giving me some of your time today.
If you learned something new, or just enjoyed the read, the best way to support this newsletter is to give this post a like, share, or a restack — it helps other folks on Substack discover my writing.
Or, if you’re a writer on Substack, enjoy my work, and think your own audience would find value in my various series, I’d love it if you would consider adding HTG to your recommendations.
🌱 5-Bit Fridays: Startup misconceptions, why to build slowly, the Modern Data Stack, monetization advice, and the LinkedIn algorithm explained
Thanks for sharing!
Great one, I really loved #2 and #4 because they offer some great insights.