🌱 5-Bit Fridays: What to do when VCs say "no", reverse interviewing, traits of great PMs, The Ladder of Evidence, and positioning
#25
👋 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 🍻
First up, I just want to say a huge thank you. On Monday this little side project crossed 5K subscribers. That happened way sooner than I thought it would, and I’m incredibly grateful you read this newsletter every week, support it, and give me some of your time. And for the deep dives…a lot of it. 👀
Thank you. 🙏
While chatting about this newsletter still, if you missed Wednesday’s deep dive, be sure to catch up: 👇
How Duolingo Grows: If Angry Birds taught you French
Insights on crowdsourcing, product principles, gamification, personalization, storytelling, ruthless A/B testing, duel flywheels, community, finding new ways to reaccelerate growth, and more.
In other news this week…AI chatbots are being used to create dozens of fake news content farms, flooding the internet with bullshit, and showcasing one of the biggest risks of AI: The rampant spreading of misinformation and the inability to know what’s true. On a more positive AI note though…the latest plugin by OpenAI, Code Interpreter, is truly revolutionary. It accepts files (like a CSV) and quickly becomes your co-pilot data analyst, visualizing huge volumes of data and even extracting insights. This is a game-changer. Just watch this video demo to see it in action, and if you’re impressed, and haven’t yet, join the ChatGPT plugins waitlist for access.
Ok, onto what you came here for
Here’s what we’ve got this week:
When the VCs say “no”: How to peel away at the onion
How to know if you’re interviewing at a product-led company, and why PMs and leaders should care
10 traits of great PMs
The Ladder of Evidence: Get more value from your customer interviews and product experiments
Positioning: Are you thinking about what you REPLACE?
Small favor: If you enjoy today’s post and wouldn’t mind ❤️’ing (or Restacking/Sharing) it in the header above, it helps more people discover my writing. Thank you!
(#1) When the VCs say “no”: How to peel away at the onion
Not all startups decide to take the venture-backed route to be funded. One reason is, being a VC-funded startup doesn’t make sense for every business model or founder. And, there are lots of other ways early-stage companies not looking for rapid scale can pay their bills.
However, in the world of tech startups with founders who do want to raise money this way, the odds of getting cash from a venture capital fund are super slim.
In normal times, a VC fund like Andreessen Horowitz looks at around 3,000 companies for every 20 they invest in. That’s less than 1%. Right now though, these are not normal times, bringing the number of deals, deal size, and total VC funding way down.👇
Regardless, entrepreneurs press on and startups are still being founded every single day.
So, with venture capital being harder to raise at the moment—and just being hard to get in the first place—this first bit today is timely, yet evergreen, for the founders.
We’re going deep into the archives of some of Marc Andreessen’s best work, and tackling the question…”How do you raise VC capital when you keep getting turned down?”
Let’s start off with how to internalize a “no”, in the words of one of the most legendary entrepreneurs and investors:
One “no” doesn’t mean anything—the VC could just be having a bad day, or she had a bad experience with another company in your category, or she had a bad experience with another company with a similar name, or she had a bad experience with another founder who kind of looks like you, or her Mercedes SLR McLaren’s engine could have blown up on the freeway that morning—it could be anything. Go meet with more VCs.
If you meet with three VCs and they all say “no”, it could just be a big coincidence. Go meet with more VCs.
If you meet with five, or six, or eight VCs and they all say no, it’s not a coincidence.
There is something wrong with your plan.
— Marc Andreessen, founder of a16z + a lot more
To add to what Marc says, if you’re not getting any meetings…there is also something wrong with your plan.
Now, meeting with more VCs after a bunch have said no is probably a waste of time. Instead, Marc’s advice is to “retool your plan”.
Sounds obvious, no? If you’re going to battle and you keep losing in one territory using the same strategy…of course you change it.
But, in startup land, Marc notes this happens a lot less than you’d think with fundraising. So, let’s break down one of Marc’s essays and unpack what to do if there’s something wrong with your plan.
How to retool your plan
In this context, your plan contains all the things you’re trying to do. What you want your startup to be when it’s all grown up, facts about your market, cash, team, etc. The main artifact at this point is your pitch deck or business memo.
So, “retooling it” means changing the facts of your plan and what you are trying to do, to make your company more fundable.
Nobody said this would be easy. 🙂
But, Marc provides a handy framework to approach it:
To describe the dimensions that you should consider as you contemplate retooling your plan, let me introduce the onion theory of risk.
If you’re an investor, you look at the risk around an investment as if it’s an onion. Just like you peel an onion and remove each layer in turn, risk in a startup investment comes in layers that get peeled away—reduced—one by one.
Your challenge as an entrepreneur trying to raise venture capital is to keep peeling layers of risk off of your particular onion until the VCs say “yes”—until the risk in your startup is reduced to the point where investing in your startup doesn’t look terrifying and merely looks risky.
Great, so what are those layers? As Marc describes them:
The different layers of the risk onion
Founder risk—does the startup have the right founding team? A common founding team might include a great technologist plus someone who can run the company, at least to start. Is the technologist really all that? Is the business person capable of running the company? Is the business person missing from the team altogether? Is it a business person or business people with no technologist, and therefore virtually unfundable?
Market risk—is there a market for the product (using the term product and service interchangeably)? Will anyone want it? Will they pay for it? How much will they pay? How do we know?
Competition risk—are there too many other startups already doing this? Is this startup sufficiently differentiated from the other startups, and also differentiated from any large incumbents?
Timing risk—is it too early? Is it too late?
Financing risk—after we invest in this round, how many additional rounds of financing will be required for the company to become profitable, and what will the dollar total be? How certain are we about these estimates? How do we know?
Marketing risk—will this startup be able to cut through the noise? How much will marketing cost? Do the economics of customer acquisition—the cost to acquire a customer, and the revenue that customer will generate—work?
Distribution risk—does this startup need certain distribution partners to succeed? Will it be able to get them? How? (For example, this is a common problem with mobile startups that need deals with major mobile carriers to succeed.)
Technology risk—can the product be built? Does it involve rocket science—or an equivalent, like artificial intelligence or natural language processing? Are there fundamental breakthroughs that need to happen? If so, how certain are we that they will happen, or that this team will be able to make them?
Product risk—even assuming the product can in theory be built, can this team build it?
Hiring risk—what positions does the startup need to hire for in order to execute its plan? E.g. a startup planning to build a high-scale web service will need a VP of Operations—will the founding team be able to hire a good one?
Location risk—where is the startup located? Can it hire the right talent in that location? And will I as the VC need to drive more than 20 minutes in my Mercedes SLR McLaren to get there?
So, with an understanding of the different layers of the onion, put yourself in the VC’s shoes and start to ask, “What could this startup do to minimize or eliminate enough of these risks to make the company fundable?”.
And, as you start to go and do those things, consider this advice from Marc on how to reduce the risk in each of those vectors:
Making your onion less risky
Founder risk—the tough one. If you’re the technologist on a founding team with a business person, you have to consider the possibility that the VCs don’t think the business person is strong enough to be the founding CEO. Or vice versa, maybe they think the technologist isn’t strong enough to build the product. You may have to swap out one or more founders, and/or add one or more founders.
Market risk—you probably need to validate the market, at a practical level. Sometimes more detailed and analytical market research will solve the problem, but more often you actually need to go get some customers to demonstrate that the market exists. Preferably, paying customers. Or at least credible prospects who will talk to VCs to validate the market hypothesis.
Competition risk—is your differentiation really sharp enough? Rethink this one from the ground up. Lots of startups do not have strong enough differentiation out of the gate, even after they get funded.
Timing risk—the only thing to do here is to make more progress, and demonstrate that you’re not too early or too late. Getting customers in the bag is the most valuable thing you can do on this one.
Financing risk—rethink very carefully how much money you will need to raise after this round of financing, and try to change the plan in plausible ways to require less money.
Marketing risk—first, make sure your differentiation is super-sharp, because without that, you probably won’t be able to stand out from the noise. Then, model out your customer acquisition economics in detail and make sure you can show how you’ll get more revenue from a customer than it will cost in sales and marketing expenses to acquire that customer.
Distribution risk—this is a very tough one—if your plan has distribution risk, which is to say you need a key distribution partner to make it work, personally I’d recommend shelving the plan and doing something else.
Technology risk—there’s only one way around this, which is to build the product, or at least get it to beta, and then raise money.
Product risk—same answer—build it.
Hiring risk—the best way to address this is to figure out which position/positions the VCs are worried about, and add it/them to the founding team.
Location risk—If you’re not in a major center of entrepreneurialism and you’re having trouble raising money, you probably need to move. You can start a company wherever you want, but you may not be able to get it funded there.
Last thought from Marc…
You’ll notice that a lot of what you may need to do is kick the ball further down the road—make more progress against your plan before you raise venture capital. This obviously raises the issue of how you’re supposed to do that before you’ve raised money
Try to raise angel money, or bootstrap off of initial customers or consulting contracts, or work on it after hours while keeping your current job, or quit your job and live off of credit cards for a while.
For more incredible insights from Marc Andreessen like this one, check out Pmarchive.com where many of his older essays live.
Further reading: 🧠
(#2) How to know if you’re interviewing at a product-led company, and why PMs and leaders should care
If the last bit was specifically for the founders, this one is for the product managers. However, leaders and operators, if you want to build a company that attracts great PMs, it’s worth paying attention here.
Let’s start with the bottom line: You want to be thoughtful about where you choose to invest your time. Life's too short to build things that don't matter, or you don’t care about.
For product people, that loosely translates to working at a strong product company. One with great product leadership, principles, process, and vision.
Now, PMs know all about research and user interviewing. We start with some internal research questions. Then, we form a bunch of external interview questions to go and ask people with the goal of uncovering actual past behavior, rather than speculative or aspirational future behavior, to help us answer our research questions I.e:
Research question: What is unique about playlists that have high retention rates?
User interview question: Tell me about the last playlist you discovered that you really liked.
When it comes to our careers and picking a team to join, Andrew Skotzko argues we should be running the exact same process. He calls it “reverse interviewing”, and simply, it means we should take one of our research questions—“Is this a place that empowers product people/teams”—and assess a given job opportunity by asking 5 of our own product-focused questions.
Since every company we talk to will say they're a good product company, we need to dig deeper. Just as with users, we can't take them at their word. We need evidence from real behavior.
What we're really assessing with these questions is the strength of the environment for product people. Creating this environment is the responsibility of product leadership. We're assessing the quality of product leadership through the lived experience of the product teams.
— Andrew Skotzko
So, let’s take a look at the snackable version of Andrew’s reverse interview questions that will help us go deeper, cut through the BS and noise, and figure out which ponies we want to hitch ourselves to.
1. What were the last few things your team built and shipped? How did you decide to do those?
Why ask it: You want to get a sense of how actual work gets done. Are they building real products and features? What’s the process for deciding priorities? And who’s involved? This is key, so listen closely and pull on threads to go deeper.
What you’re looking for: You want to see there are clear objectives and goals from leadership — customer or business problems to solve — and an empowered team that comes up with solutions themselves. You want answers involving data, regular customer contact, rapid/iterative discovery practices and collaboration, and insights from experiments/prototypes being used to drive product strategy.
2. When was the last time you talked with your customers? How often have you done that in the last month?
Why ask it: Good product teams are constantly engaging with and talking to their customers. They are not just doing one-and-done product discovery for initiatives, but continuous user/market research.
What you’re looking for: You want to hear that they've talked with their end users very recently and that engaging with customers weekly is a regular part of their culture/process. As Rich Mironov says, if you don't do the work to deeply understand user needs, you lose the right to make decisions on their behalf.
3. What was the last feature or product your team killed? How and why did you decide to kill it?
Why ask it: “Most ideas don't work at all, and those that do almost never work right the first time. It takes iteration. We also want to understand the decision-making process used to build/launch/kill features, and any weird power dynamics going on.”
What you’re looking for: You want to understand how they build things. Again, is the team addressing product risks early, before building it? “Good teams kill way more ideas than they build”, and in asking what they killed look for thoughtful reasoning behind why it didn’t work.
4. Can you describe your product vision?
Why ask it: On a good product team, everyone knows the direction and is able to see how what they’re working on contributes to the big picture. Crisp answers on product vision show an aligned team.
What you’re looking for: “We want to see energy when we ask this question. We want to see eyes light up, people get more animated, talk faster, get excited. We want to see that this vision exists, it's alive in the culture, and that people care deeply about it.”
5. Tell me about the last coaching session you had with your manager. How often did that happen last month?
Why ask it: “Coaching is the number one responsibility of managers. A manager's job is literally to help the people on their team succeed. They succeed when their people succeed. This means that those people need to be growing.”
What you’re looking for: The main thing you want to know, simply, is that coaching is a thing. Are 1:1s happening? Are managers using that time to develop people?
When you zoom out and review what you learned in the reverse interview process, look for teams that:
are small, cross-functional, and durable
address product risks early with collaborative product discovery, and regularly "kill their darlings" en route to ideas that work
are accountable to delivering results rather than output
are guided by an insight-rich product strategy
have a regular, ongoing cadence of lightweight research directly with their user/customer, rather than handing this off to a research group
connect with the product vision in a visceral, energetic way
have managers that are proactively and regularly coaching and developing team members
serve customers in ways that work for the business, rather than being subservient to the business stakeholders
And for the founder/leaders, if product is integral to your company, make sure when people are interviewing to work for you…that’s the org you’ve built.
For more by
, check out his newsletter, .Further reading 🧠
(#3) 10 traits of great PMs
And now that we’ve looked at what makes a great product-led company, let’s consider what makes a great product manager.
According to Noah Weiss, the current CPO at Slack, there are 10 commonalities. I’ll let Noah explain:
Great PMs live in the future and work backwards
They immerse themselves in research, feedback, data, discussions, and the market. They craft thoughtful, inspiring narratives for where the product should go — and the best path to get there.
Great PMs amplify their teams
They listen well. They infuse urgency. They foster collective creativity. They build consensus by default, but can drive hard decisions when they have to. They take blame and pass on praise.
Great PMs focus on impact
They constantly fine-tune product strategy to maximize business impact, so their teams never worry about whether their hard work will matter. They don’t care about accolades from peers, Apple design awards, or press write-ups.
Great PMs write well
They are succinct, structured, thorough, and persuasive.
Great PMs drive a fast pace of high-quality decisions
They make two-way door calls quickly, and help the org make one-way calls judiciously. They care about getting to the right decision, not whether they are right. They are the ultimate facilitator.
PMs should lay out well-researched tradeoffs, set timetables, and structure great discussions. Only in rare situations should they actually “make the call.”
Great PMs optimize for learning
They voraciously seek out insights about customer needs and pain points through research, experiments, and cross-functional partners. They course correct constantly.
Great PMs execute impeccably
They say what they’ll do, and then do what they say. Their follow-through is impeccable, and they don’t let details slip. When they join a team, quality and pace seems to dramatically improve overnight.
Great PMs apply product taste
They have a well honed sense of what a well crafted product experience feels like. They smartly balance quality with the demands of time and scope.
Great PMs exhibit data fluency
They define and track the key metrics that matter, and align the whole org around them. They know how to design and analyze solid experiments — and know when hill-climbing isn’t worth it.
Great PMs immerse themselves in the tech
Though they may not have CS degrees, they are effective collaborators and sounding boards for their engineering partners. They can help weigh complex technical tradeoffs and design decisions.
Further reading 🧠
(#4) The Ladder of Evidence: Get more value from your customer interviews and product experiments
I love frameworks that are packaged into analogies, like icebergs, racecars, and Blue Oceans vs Red Oceans.
So, here’s another one: The Ladder of Evidence.
Basically, it’s a systematic way of moving towards the highest level of data/validation during research.
At the bottom, you have the quickest learning along with the least amount of value. At the top, while gathering that info takes more effort, you get the most credible insights into whatever you’re trying to figure out. This is a delicate balance though. You want to learn as much as you can, while moving fast, and continuously shipping value to your customers. You don’t want engineers sitting around while you conduct perfect research, but you also don’t want to build the wrong functionality because you got unreliable feedback. Instead, you want to climb as high up the ladder as you can, given your time constraints.
This is what it looks like:
For example, it’s super easy to ask a binary question like “Would you use this feature?”.
But, instead of asking what they would do in the future, ask people about what they’ve done in the past. A bit more work and threads to pull on, but, past behavior is a better indicator of our future behavior than our speculation about future behavior.
You can climb higher though…
If you are going to ask about my past behavior, you might as well climb one more rung and ask me for specific stories about my past behavior. Here’s why: If you ask me if I work out regularly (a question about my past behavior), I will say yes. If you then ask me what I do, I would say yoga, CrossFit, and running. You might also ask how often I work out. Again, I have quick answers. I do yoga twice a week and CrossFit three times a week. But all you are doing is collecting facts. Insights are rarely generated from simple facts.
Rather than asking me for facts, ask me for specific stories about my workouts. Stories convey context like where the workouts happen, with whom, the emotion associated with the workout (did I love it, was it a grind), how I felt beforehand (was it hard for me to go, was I excited to go), how I felt afterwards (was I glad I went, did I regret it), and so much more.
— Teresa Torres
But no matter how good you get at collecting specific stories, you still have to test those insights. And that leads us to the top two rungs of the ladder.
Watching them show you what they did, or simulating a new experience
Watching them during a real-time instance, or live test of a new experience
Ultimately, the closer you can get to actually simulating and observing users doing the real thing, the more you’ll learn.
(#5) Positioning: Are you thinking about what you REPLACE?
Positioning defines how your product is a leader at delivering something that a well-defined set of customers cares a lot about.
— April Dunford
A positioning statement sets the context for a product and conveys some valuable info about what your product will, and perhaps won’t, do for someone. It should hold a powerful set of assumptions about who your product competes with, what features your product should have, who the product is intended for, and even things like what the product should cost.
So, generally, a positioning statement is made up of a few common components. Namely:
Competitive alternatives
Differentiated “features” or “capabilities”
Value for customers
Target customer segmentation
Market category
Now, while scrolling through Substack Notes the other day, I saw a post by
that had a very catching rubric. As she describes:I’ve seen hundreds of (painfully long) positioning guides, but despite the word count, most are missing something obvious: "What does your product REPLACE?"
By making it clear what your product is positioned against, it's much easier to explain what your product is and why it's better for your audience.
According to Emily’s new concept, think about bucketing your product into one of the below 4 product types. 👇
[Double click/tap on the image to see it nice and big]
Further reading 🧠
🌱 And now, byte on this if you have time 🧠
If you have time for just one more read this week, I highly suggest this one on the power of defaults. The underlying question here: Are network effects overrated?
Julian gets into atoms (hardware) vs bits (software), nudges us to think in layers, outlines what the Google and Apple stacks look like (and how they win by owning multiple layers), and ultimately argues network effects are just a means to an end: Defaults.
This was one of my favorite long-form essays I read this week.
READ: The power of defaults
Cool, I think that’s it guys.
Thanks a ton for reading today, I really really appreciate all your support. If you learned anything new and feel like spreading the love, feel free to hit the like, share, or restack button below. Thank you. 🙏
Until next time.
— Jaryd ✌️
thanks for the shoutout! Great recap 🙏