5-Bit Friday’s (#9): Weekly snacks from the startup/tech universe
On Microsoft and the next big revolution, product-led growth tactics, validating consumer startup ideas, dealing with tech debt, and 12 cognitive biases.
Hi, I’m Jaryd. 👋Every other week, I pick one startup/company you probably know, and do a deep dive on how they kickstarted their growth, and drive growth today.
Plus, every Friday — I bring you 5 short-form insights and takeaways from the startup/tech universe. (this!)
If this is your first time reading, join the other folks interested in growing a company and learning about startups by subscribing for free here:
Happy Friday, friends! 🍻
If you missed this weeks deep dive, catchup on our detailed analysis of gaming giant — Epic Games — for a primer on the $200b gaming industry, the power of vertical integration, marketing/product lessons from a video game, and how to grow an ecosystem. In the words of Rahul Krishnan, the author behind Top of the Lyne:“ Jaryd - the Epic Games piece was for lack of a better word, epic.”
Follow the link below to learn about:
A brief history of video games
A timeline of iconic events
The gaming landscape
An Epic beginning — how they started
An Epic strategy — how they grow
Vertical + Horizontal Integration
Epic’s virtuous flywheel
Deeper on: Fortnite, Unreal Engine, Epic Games Store
Microsoft would receive 75% of OpenAI’s income until it has recovered its initial investment. Once they hit that threshold, they would have a 49% stake in OpenAI, with other investors taking another 49% and OpenAI's nonprofit parent getting 2%.
So, why would they be doing this, and what could the strategic value be?
And Microsoft wants a piece of this for a few reasons:
ChatGPT threatens Google’s search engine. Asking Google a question brings you a list of answers, all from different sources. But, ask ChatGPT, and it brings you one answer based on info across sources. And as Microsoft look to gain market share here by beefing up Bing, this is an important weapon.
Microsoft will most likely deploy OpenAI’s Chatbot and ChatGPT across all their office products. With 1.4 billions users across the world, this would be extremely valuable to OpenAI, as well as solve problems for their office users — leveling up the value of their tools which account for 24% of their business.
OpenAI runs on Microsofts cloud — giving them a great platform for integration and collaboration.
And lastly and probably most importantly, in the words of Yesha Sivan of i8 Ventures:
Microsoft is not willing, again, to lose the next revolution. If you look at the last 20 years, they are very good at losing revolutions. The revolution of the internet they lost, of mobile they lost, etc.
You see it in the metaverse with their $79b investment. They are not willing to lose.
Product-led growth, and how to avoid 5 common pitfalls
Product-led growth. I’ve written a lot about companies who use their product as the main way to acquire, activate, convert, retain, and monetize users. For example, when we looked at how Notion grows, or Superhuman’s growth drives, it was clear that their product was an essential part of their go-to-market strategy, and sits at the core of their distribution and growth engine.
Getting PLG growth right can be far more efficient long-term compared to a sales-led motion because scaling growth through sales costs more (i.e new sales reps), whereas once your product is a growth-engine you get a beautiful flywheel effect.
To answer the question — How can I tactically go about implementing a PLG growth motion as a B2B SaaS product? — Lenny Rachitsky collaborated with Hila Qu (a PLG expert) to put together an in-depth guide across 5 core steps. It’s highly actionable and gets straight to the nuts and bolts of it.
Today, I want to highlight one excerpt I found particularly interesting. But first, a quick primer on the sales-led vs product-led growth funnels.
Source: Lenny’s Newsletter
An excellent summary they put together.
Now, as more and more product leaders look to start a PLG motion, Hila has a great piece of advice: Anticipate the most common pitfalls.
Here’s what she says about it:
I want to spend some time sharing the most common pitfalls you’re likely to face when adding a PLG motion, to help you avoid them. Here’s an overview of the most common challenges, how to identify them, and how to address them:
Pitfall #1: Lack of commitment and investment
I often see companies wanting to do PLG but not committing any meaningful resources to give it a chance to be successful. You need to think deeply about why you want to add a PLG motion. What is the problem you are trying to solve, and what is the goal you are trying to achieve, with PLG? Make sure you are considering PLG not because it’s trendy but for a clear strategic reason. Because the investment—and the change required to stand up a PLG motion—is not trivial.
Each of the following is a valid strategic reason:
Efficiency seeker: Improve sales and marketing efficiency and lower CAC via a PLG motion. Many SLG companies add a PLG motion for this reason.
Growth chaser: Unlock more growth and reach new segments, especially SMB. This is why HubSpot went downmarket with PLG.
Disruptor: Use freemium and PLG to disrupt established B2B incumbents that dominate a category. This is how Figma disrupted Adobe.
Defender: An established sales-led enterprise product may want to test PLG on a new product to develop the muscle and defend its position. This is how Gainsight experimented with PLG on Gainsight PX (its newly acquired analytics tool).
PLG native: PLG is a natural fit for your product (i.e. bottom-up SaaS), and the team wants to grow to a large scale via a PLG-native approach. Notion and Canva both fall under this category.
You may need to spend some time to think deeper, conduct research, and collect evidence. But if you build enough conviction and believe PLG is a strategic fit, you should commit to investing in the roadmap, team, and infrastructure for the next one or two years at least.
Pitfall #2: The product is not ready
In order to go PLG, you need to have a product vehicle: a free version or a free trial of your product.
Some companies have these vehicles in place already. At GitLab, we had a free version and a free trial, plus an open source product. I didn’t need to build these from scratch—the product already had a large free user base. In that case, the growth team could start developing usage-data insights and creating a PLG funnel right away.
But there are also companies that enter the PLG era without an existing free version or free trials. For example, when visitors land on their website, the only CTAs available are “request a trial” or “book a demo.”
If that is the case, the first step is to open a free trial experience to everyone or create a free version. Without that, there is no “product” in your product-led growth.
When you’re building a free product for the first time, you’ll need to overcome design and technical complexities to build that free experience. But more importantly, you’ll need to overcome the fear of “losing control.”
For example, a marketing leader from a leading security B2B company shared with me her experience of advocating for the company to move from closed trials to open trials as first step toward PLG:
“The closed trial for us means we only open our trials to end users who are in our ideal customer profile (ICP)—we have lots of resellers/service providers and tech partners who request trials, but we have different processes for those folks. The first step here was to convince the company to open up a little more to end users a bit outside our ICP—for example, we typically have not let in anyone under 100 employees.
While we certainly can’t monetize these folks at the rate we do those in our ICP, we can, however, learn a lot about how they are using our product. And there might be a path to monetize.
The enterprise B2B sales cycle and PLG are inherently at odds—one is a very controlled experience and the other is not. In a PLG motion, your product is shaping the perception as opposed to the salesperson, so I think it’s simply getting used to giving up that initial control.”
Here is a tip: If you face resistance, you can start PLG as an experiment. For example, instead of making a shift to PLG permanently, open a free trial to everyone for some time and see how that impacts your signups, leads, and upgrades. It is much easier to have a meaningful discussion when you can ship the change first and have some real data.
Pitfalls #3 and #4: Lack of data infrastructure and foundation; lack of PLG expertise and talent
These two go hand in hand. Ask yourself this question: Assuming you have a free product, do you have the data to track how many free users sign up, which features they use most, and which usage pattern correlates with a higher free-to-paid conversion rate?
If your answer is no, then you need to first build the PLG data infra foundations. There is no way around it. You have to invest in these areas to enable PLG—e.g. hire the right growth/data leader; commit the resources to collect and analyze the data—and it takes time. The good news is that it’s very common, especially among B2B companies starting with a sales motion. A strong data foundation will not only support your PLG motion but also enable you to take a more data-driven approach in product development and customer success, standing out from your competitors. I will unpack what it takes to build PLG infra in part 4 of this post.
Once you have the data foundation in place, you may ask yourself the second question: Assuming you have the data and metrics, do you know concepts like “team aha moment” and “product qualified leads (PQL),” and do you have frameworks to get users/customers to reach this status?
If you or your team can’t answer these questions, then you basically don’t have PLG expertise and talent in-house. Growth itself is still relatively new, and people with B2B PLG experience are even rarer. Thus, companies often find it very hard to hire PLG talent.
I suggest you take a three-point phased approach:
Hire a seasoned PLG growth advisor, ideally with relevant experience to your industry/segment.
Identify internal talent who may not have done PLG before but have the passion/skill set.
Hire externally for a growth leader or key growth talent as needed.
I recommend starting with (1) and (2), to first validate the fit for PLG. Jump-start the motion and get some early wins. For a recent advisory client of mine, the internal PLG leader I worked with was their former head of investor relationships (who is very analytical and can mobilize resources across the company), and together we drove great success.
As you gain more confidence, move to hiring externally. This way, you know you are not moving too quickly too prematurely, and then you can hire the growth leader/team that is the best fit for your specific needs.
Pitfall #5: Resistance from current teams
This is often the biggest challenge when an SLG company tries to layer on PLG:
Sales teams may worry that PLG will impact their quota and commissions negatively and that it may bring a bunch of “small potato” customers or sell large customers short.
The marketing team may worry that PQLs will take credit from MQLs and, all of a sudden, their existing workflows with the sales team won’t work anymore.
The growth team, as the new kid, needs to understand how to fit into the overall GTM org’s workflow and forecasting, while also building trust with the rest of the product org.
The solution goes back to executive buy-in and commitment, but there also needs to be alignment from functional leaders in sales, marketing, and growth/product to try this out. Initially there will be a lot of ambiguity about how the different pieces fit together and how the new workflow between marketing, sales, and growth should work. But I often see successful teams eventually align on the funnel, metrics, org design, and incentives to make this streamlined and effective.
To read the full thing, follow the link below. And if you don’t read Lenny’s Newsletter and you’re a PM, founder, or marketer — take this as my best advice — subscribe!
Leo Luo, the man behind the Consumer Startups newsletter, set out on a simple goal: To create an idea validation framework for B2C founders based on hundreds of interviews.
From his research, he found there were four main approaches that emerged from his interviews with B2C founders (most of which have gone on to raised venture money and scaled beyond PMF).
Here is a summary:
Signal Aggregation. This approach does not require shipping a beta product (i.e functional MVP), but it does involve lots of market and customer research and running light experiments, such as landing page and social media ads to validate both the viability and demand for the product.
Strong Beta. This approach requires the successful launch of a working prototype. Founders start with a hunch, ideate a solution to a big problem, and then build the simplest version necessary to validate their hypothesis. It’s usually the strongest indication of whether or not the product is solving a strong user pain point, and brings useful insight into user behavior.
True Fans. Similar to Strong Beta, the True Fans approach also involves launching an early product; but main difference is that instead of looking for significant traction in terms of revenue growth and user acquisition, its about finding fanatic users that love the product despite its limited features.
Visionary. This approach features the least amount of research and experiments. It’s built on a clear vision from a founder who has a deep, personal connection to the problem. In these cases, the entire product is often built with minimal hypothesis testing.
Consumer Startups
These four approaches are patterns I have seen from talking to other consumer founders and they might not generalize well to B2B or deep tech. Also, they are not mutually exclusive. For example, it is common for a founder to use Signal Aggregation before launching any product to gain a quick understanding of the market demand and then use the True Fans approach to assess whether or not there is a cohort of users that love the early product.
It is also important to note that idea validation is different from finding product-market fit for this study. Several of the founders I interviewed mentioned that they were yet to achieve product-market fit despite reaching thousands of users. Idea validation empowers the founder to commit to the startup full-time, but product-market fit is a measure that works beyond the viability of a product idea.
Tech debt is bad. It slows down future development and makes it more complicated (or perhaps impossible) to scale.
And much like debt in the real…nobody wants it, but sometimes it’s necessary.
In short, debt usually helps you get something you want or need faster. Everything in life is full of trade offs, and when it comes to building a product to solve a pressing customer problem or to move quickly on a market opportunity — speed often comes as the expense of tech debt.
As a PM, our job is to balance those tradeoffs between getting things done quickly vs taking time and reducing/minimizing debt along the way.
In the words of Aakash Gupta:
It’s so easy to focus on shipping exciting new features that sometimes we forget the importance of completing tech debt stories, and creating minimal technical (tech) debt along the way.
This is true for engineers, designers, product managers and builders of all stripes. In fact, in my experience, it is hardest for CEOs. It is so easy for CEOs to connect the dots between a feature and more growth, a stronger valuation, and greater success for the company.
For the PM specifically, one of the most challenging parts of the job is prioritizing tech debt. Then, protecting it after is nearly as difficult. As one of our primary stakeholders is the CEO, we are constantly trying to build to their vision.
This creates a perceived tradeoff between career growth, impact, and tech debt in the short term.
So, what can you do?
In a great essay by Aakash Gupta and Brennan Decker, they go deep on this topic. And an excerpt I want to pullout is two of the most important things they suggest PMs do to address tech. 👇
As a Product Manager you have to translate the Business needs (and speed) to your engineering team (they don’t usually like Business timelines) and the current state of your tech stack to your Business stakeholders (they don’t usually like technical constraints.). The more excited and aligned that you can get both groups around a shared vision the easier that your job becomes.
All of that being said, two of the most important roles for a PM to address tech debt are: 1) to prioritize it enough, and 2) to understand when to and when not to.
Prioritize Enough
As the ultimately accountable order for what engineers build, it is up to the PM to prioritize technical debt enough. But there is a goldilocks amount here. A PM that over-emphasizes tech debt becomes loved by engineers, but not quite as much by product leadership and executive stakeholders accountable for growing the business.
So how can a PM prioritize just enough, but not too much? One of the first things to do is to properly assess each tech debt element. Is it acute or systemic? Another thing to do is understand its strategic impact. Can leaving it in place enable other, more important features. And what about the impact on eng’s morale?
Also understand the team’s confidence in these claims, as well as the time it will take to fix the issue. After that, try to make an informed prioritization decision.
One can probably not expect to ever get it quite right. Nevertheless, at every planning cycle, PMs should ask the question after evaluating an early draft outcome: “are we prioritizing tech debt enough?”
Then, at the end of each cycle, foster a discussion with the dev team. Ask, “did we address the right tech debt this quarter? Was our focus too much or too little? And what are the top priorities for next quarter?” These questions help teams adjust to the individual level that makes sense for them given their capabilities and business context.
Understand When to and When Not to
These prioritization questions get to the heart of the skill which is to be able to understand when, and when not to, address tech debt. There are a couple key factors to consider:
Developers’ perspectives
Business impact
Tradeoffs on other initiatives
Part of the reason the PM role exists is to negotiate these details at the lowest level of detail. You should roll up your sleeves and write out the thinking. What do devs think? What is the business impact? What is the tradeoff? These things in paper help everyone on the team make a better decision.
The PM should also develop their own perspective. The goal should be to, as always, drive business outcomes by solving user problems, creating growth levers, and keeping the team happy. If the team is unhappy, that might mean prioritizing tech debt more than normal. If the business outcomes are critical, then it might have to wait.
To get more into the tactical, in-the-weeds, strategies on addressing tech debt, follow the link below for their full piece.
While we all love to believe we’re rational. Sadly, a lot of the time we’re not.
Extremely simply put — a cognitive bias is something that clouds our rational judgement. We observe something, and unknown to us, it leads us to create a subjective version of reality. We then go out into the world and behave against that reality.
But, we make mistakes all the time.
I saw a thread by Ben Meer where he laid out 12 important biases that affect us, and argues how being aware of them can improve out thinking at work, and just life in general.
So, here they are:
1. Fundamental Attribution Error
We judge everyone else on character but blame our shortcomings on the situation. Example: If Jane is late for work, she’s lazy. If you’re late for work, it’s because of traffic.
2. Dunning-Kruger Effect
Novices experience overconfidence due to quick progression on the learning curve. While experts’ confidence drops because they realize what they don’t yet know. Paradoxically, the more you become an expert, the more you may feel like an imposter.
3. Confirmation Bias
We seek out (and retain) information that confirms what we already believe. Example: Flat Earthers base their beliefs on a feeling, ignoring all evidence to the contrary.
4. Curse of Knowledge
We believe that everyone knows the same things we do. Example: Jane gets frustrated with her son for not understanding multiplication right away.
5. Availability Heuristic
We make snap judgments based on the most recent information. Example: When an airline reports a crash, ticket sales go down until people forget about the incident.
6. Automation Bias
We put too much trust in automated systems to fix our mistakes. Example: “Grammarly suggested it; therefore, it’s correct.”
7. Law of Triviality
We spend inordinate amounts of time and effort on trivial issues while ignoring the ones that matter. Example: The mayor devotes an entire committee to keeping the sidewalk clean but does nothing to help the homeless.
8. Survivorship Bias
Focusing on successes and ignoring failures. Example: You assume entrepreneurship is easy because all you see are successful founders in magazines.
9. IKEA Effect
We tend to value things more when we have a part in their creation. Example: “Isn’t this a beautiful coffee table? I put it together myself!”
10. Third-Person Effect
We see ourselves as more immune to media than others. Example: “See how brainwashed you’ve become?!”
11. Zeigarnik Effect
We tend to recall interrupted tasks more than completed ones. Example: Despite earning perfect marks in his annual company review, Bill fixates on that one project he dropped the ball on and feels guilty every time he comes to work.
12. Spotlight Effect
We think people are paying far more attention to us than they are. Example: Josh is worried everyone at work will notice he needs new shoes.
Stuff to be mindful of…I’ve literally committed offenses against every single one of those. 🙃
If you enjoy getting these weekly insights and takeaways from the best entrepreneurs, writers, investors, product/growth experts, and operators — perhaps you know someone else who might 🫶.
