How They Grow

Share this post

🌱 5-Bit Fridays: What to do when VCs say "no", reverse interviewing, traits of great PMs, The Ladder of Evidence, and positioning

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.
Over 13,000 subscribers
Continue reading
Sign in
5-Bit Fridays

🌱 5-Bit Fridays: What to do when VCs say "no", reverse interviewing, traits of great PMs, The Ladder of Evidence, and positioning

#25

Jaryd Hermann
May 5, 2023
10
Share this post

🌱 5-Bit Fridays: What to do when VCs say "no", reverse interviewing, traits of great PMs, The Ladder of Evidence, and positioning

www.howtheygrow.co
2
Share

👋 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.

I missed it

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:

  1. When the VCs say “no”: How to peel away at the onion

  2. How to know if you’re interviewing at a product-led company, and why PMs and leaders should care

  3. 10 traits of great PMs

  4. The Ladder of Evidence: Get more value from your customer interviews and product experiments

  5. 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!

Welcome to How They Grow! Join 5K+ others to get all my deeply researched content. Free for now, not forever.

(#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: 🧠

  • A playbook for fundraising

  • On presentations


(#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:

  1. are small, cross-functional, and durable

  2. address product risks early with collaborative product discovery, and regularly "kill their darlings" en route to ideas that work

  3. are accountable to delivering results rather than output

  4. are guided by an insight-rich product strategy

  5. have a regular, ongoing cadence of lightweight research directly with their user/customer, rather than handing this off to a research group

  6. connect with the product vision in a visceral, energetic way

  7. have managers that are proactively and regularly coaching and developing team members

  8. 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

Andrew Skotzko
, check out his newsletter,
Make Things That Matter
.

Further reading 🧠

  • What makes a strong product culture?

  • Good product team/bad product team

  • Preparing for a PM interview


(#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 🧠

  • What distinguishes the top 1% of product managers from the top 10%?

  • How to know if you're doing a good job as a product manager


Enjoying this post so far?

Share

(#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:

The Ladder of Evidence

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:

  1. Competitive alternatives

  2. Differentiated “features” or “capabilities”

  3. Value for customers

  4. Target customer segmentation

  5. Market category

Now, while scrolling through Substack Notes the other day, I saw a post by

Emily Kramer of MKT1
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]

Market Positioning

Further reading 🧠

  • Positioning your startup is vital—here’s how to nail it

  • Positioning: The Battle for Your Mind

  • Positioning


🌱 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. 🙏

Share How They Grow

Until next time.
— Jaryd ✌️


Read How They Grow in the Substack app
Available for iOS and Android
10
Share this post

🌱 5-Bit Fridays: What to do when VCs say "no", reverse interviewing, traits of great PMs, The Ladder of Evidence, and positioning

www.howtheygrow.co
2
Share
Previous
Next
2 Comments
Share this discussion

🌱 5-Bit Fridays: What to do when VCs say "no", reverse interviewing, traits of great PMs, The Ladder of Evidence, and positioning

www.howtheygrow.co
Andrew Skotzko
Writes Product Leadership Nudges
May 5Liked by Jaryd Hermann

thanks for the shoutout! Great recap 🙏

Expand full comment
Reply
Share
1 reply by Jaryd Hermann
1 more comment...
Top
New
Community

No posts

Ready for more?

© 2023 Jaryd Hermann
Privacy ∙ Terms ∙ Collection notice
Start WritingGet the app
Substack is the home for great writing