• How They Grow
  • Posts
  • đŸŒ± 5-Bit Fridays: Stop wasting time with backstory, the one thing PMs must do daily, shipping is just the beginning, who owns the context, and why you should test with fewer users

đŸŒ± 5-Bit Fridays: Stop wasting time with backstory, the one thing PMs must do daily, shipping is just the beginning, who owns the context, and why you should test with fewer users

#46

October 20, 2023

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

To get better at product, growth, strategy, and startups
 join 11,602 PMs and founders.

Happy Friday, friends đŸ»

In case you missed it this week:

  • And that valuation multiple looks extra saucy when you look at this data from Sequoia capital, suggesting GenAI has a user retention problem. And low user retention means GenAI products are not yet providing enough value to their core users to reduce churn or to gain much time in product when looking at DAUs and MAUs compared to other apps.

    • This is where and why there will be consolidation in the GenAI space. I expect tons of tools to merge in a few platforms that offer the full studio of Generative AI.

Sweet, let’s get cracking.

Here’s what we’ve got this week:

  • Start right before you get eaten by the bear

  • Your manager owns context, you own the recommendation

  • How am I going to move my product forward today?

  • Why you only need to test with 5 users

  • Learn by making, not talking

(#1) Start right before you get eaten by the bear

A lot of stories, presentations, meetings, and pitches take too long to get to the point.

Why?

Because folks haven’t figured out how to cut non-essential backstory.

They waffle on trying to give enough context, losing people before getting to the juicy part.

wrote a great post on this, and it’s just so damn true.

Question: How many meetings have you been in where someone started off in the name of “giving context”, and either a) got lost on some tangent about their days on a dairy farm, b) gave a long-winding explanation, or c) just went on about stuff you already knew? In all cases, you painstakingly watched as everyone else also waited just to get going.

Another question
do you think you’ve committed the same offense? 👀

I have. and odds are so have you. So let’s go through mastering the art of backstory so we “don’t get eaten by the bear”.

Aim for the minimum viable backstory

Front-loading a story with too much context is a losing situation for both sides.

If you’re doing the speaking, too much backstory means less time to get the feedback you need, hash the issues out, or make the decision.

If you’re on the listening end, you get lost in irrelevant details and zone out while muting yourself and replying to Slacks.

The way to avoid it is to aim for what Wes calls the minimum viable backstory. Ask yourself: What’s the minimum backstory necessary to set the context, so we can spend time on the important stuff?

As she says:

You’ll have to fight your urge to over-explain. You may think your audience needs to know all the details upfront. They don’t. You’d be surprised at how little backstory is needed to dive in. Once you start the conversation, you can always add relevant information later.

When you’re telling a story, it's even more important to remove backstory.

But, don’t let that undermine the value of context. 👇

Useful context vs useless backstory

The takeaway here is not to “be concise at all costs”. And in the pursuit of avoiding context scope creep, concise also doesn’t always mean short.

The goal is to share just enough to get your idea across with “an economy of words”.

Non-essential backstory is different from useful context.

  • Backstory = waffle. It’s the sidebars, tangents, preamble, and background info that’s hardly related to your main point.

  • Context = relevant info to what you want to talk about. It’s part if your actual story.

When we’re not sure what we want to say, we tend to get long-winded. This is because you’re thinking out loud—and it’s hard to think, analyze, and edit what you’re saying in real time. If you’re preparing for an important meeting, it’s worth spending 5-10 minutes to figure out what you really want to say in advance.

As a rule of thumb for myself, I aim for backstory to be roughly 10-20% of the conversation. This leaves 80-90% for what I actually wanted to talk about.

— Wes Kao

Starting right before you get eaten by the bear applies to most situations at work, including Q&A, pitches, all-hands team meetings, 1:1 conversations, and sales calls. People want to hear the juicy part.

It also applies to writing ( 👋), and the stories you tell your friends at brunch.

Here’s one of Lenny lessons from growing his newsletter to an insane 500,000 subscribers:

Before I started this newsletter, I’d never written anything publicly, taken writing courses, or studied writing. But after doing a bunch of writing, and reading three impactful books (On Writing Well, Nobody Wants to Read Your Sh*t, and Several Short Sentences About Writing), the biggest lesson I’ve learned is to cut, cut, and cut some more.

Cut every word that isn’t absolutely necessary. Make your intro 50% shorter. Get into the meat of your post as quickly as possible. As Wes Kao puts it, “Start your story right before you get eaten by the bear.”

So, here’s two action items to leave you with: đŸ»

  1. For the next few meetings your invited to as a participant—watch out for who’s getting eaten by the bear.

  2. For the next meeting you lead—spend time before handcrafting your necessary context.

If you find value in my writing, consider becoming a founding member and supporting this newsletter. It’s the price of a single NYC coffee a month ($7), and would mean a ton to me. Why subscribe?

(#2) Your manager owns context, you own the recommendation

Pulling on the context thread a little more, wrote a great piece earlier this month titled My manager owns context, I own the recommendation.

She wrote about a situation in her earlier career. p.s Note how her manager cut her off before she got eaten by the bear. 😉

When I walked into one of my first leadership reviews, I felt ready. I had gathered all the information and I was prepared to explain it all to my manager so they could make a decision.

I diligently started walking through all the info our team had collected, slide by slide, bullet point by bullet point.

Luckily, my manager took advantage of a pause in my monologue to turn to me and say, “Thanks for all this info.  So, what should we do here?”  I was surprised!  Of course, I had my own opinion about what the right decision was, but I thought my role was just to present all the information.  That way, my manager could understand all the info and make the decision themselves — basically, do my job, but better.

It took me a while to realize — that’s not reasonable or even possible!  I’m always going to be closer to my work than my manager is, so I shouldn’t expect them to understand it the way I do.  Instead, the best service I can offer is to build a clear recommendation, and outline the decision framework for how we got to this recommendation.

At the end of the day, you don’t need your manager or the senior leaders you’re presenting to to understand everything you’ve learned. What you really want is to give them enough so that they can give you complementary and new insights that will help you make a strong decision.

They’re privy to other contexts and know things you don’t. So, set them up with the necessary info so they can help with things like:

  1. More context about what’s happening around the company or the industry

  2. Advanced decision-making frameworks

  3. Pattern-matching based on other decisions and deeper historical knowledge they’ve aware of

  4. Zooming out and helping find other options or logical gaps you’re too close to see

  5. Other ideas and advice around whatever it us you’re talking about

Ami notes how this observation has changed what she looks for in a manager.

I stopped thinking that my manager needs to be good at all the same things I’m good at, and that my job is to give them a deep understanding of everything I’m working on so they can make the important decisions.

Instead, I started asking myself — how can I frame my recommendations so my manager can engage with them and challenge my assumptions, and then I can learn from how they think? Sometimes this means outlining my decision criteria clearly so my manager can disagree with specific ones and I can understand the principles they’re using. Sometimes it means sharing intentionally provocative “hot takes” about things we could do differently so I can hear context I might be missing.

Focusing on getting info and frameworks from my manager that are different from what I already know has been really additive. Not only did it give me permission to own my own recommendations, it’s meant that, no matter what my manager’s past experience has been, I’ve learned unique skills from them that I’d never stumble across on my own.

This is great advice, and as a newly minted manager of PMs myself, this is something I want to think about from the flip side. It reminds me of how to apply maximum leverage as a manager.

For more of Ami’s thoughts, subscribe to

(#3) How am I going to move my product forward today?

The role of a product manager is a broad and ambiguous one.

On any given day, there are a lot of things you could be doing. There’s speaking to customers, looking at data, unblocking engineers, giving designers context, lobbying for resources for a project with leadership, triaging bugs, hearing out customer support issues, writing a PRD up for the next feature, working on strategy planning, updating the roadmap based on new priorities
Yada Yada

Plus there’s the constant invite to meetings from all sorts of teams, the random Slack DMs requiring attention, and the bullshit management that pops up for you to combat.

You get the picture.

It’s easy to become overwhelmed with all these things in your pursuit of being a 1% PM, and it’s often tricky to figure out where you should be focusing your time. When that happens, it can be easy to revert to being reactive and just doing what’s simply the most urgent in the moment.

To help combat this, Sachin Rekhi shares a simple technique that he uses to try to bring some control to his overall day.

We have a saying at LinkedIn that you can’t fix what you don’t measure and I apply that same philosophy to help me prioritize my day-to-day responsibilities as a product manager. I start each day by asking how am I going to move my product forward today?

I detail in my to-do list the top 3-5 things I plan on accomplishing that day. With each item I add to the list, I think critically about how exactly that will result in moving my product forward, how much of an impact it will have relative to previous tasks that I have accomplished, and whether those are the most critical things to accomplish today. Then the next morning I go back through yesterday’s list, check off the ones I actually did end up accomplishing, and reformulate the list for that day.

While this is by no means a comprehensive framework for deciding how to prioritize your responsibilities, I find it an effective means by which to force self-awareness and reflection in less than fifteen minutes each day.

I love how simple that is. The question of how am I going to move my product forward is a lovely forcing function and litmus test for what matters most. The real job of a PM—when they are doing real product work—is making the product better for customers.

If every day you do even one thing that does that, you’re applying your time in the right way.

So, go start your day tomorrow by asking, “How am I going to move my product forward today?”

(#4) Why you only need to test with 5 users

Let’s not get eaten by that bear: Elaborate usability tests are a waste of resources. The best results come from testing with no more than 5 users and running as many small tests as you can afford.

Here’s how Jakob Nielsen described it over 23 years ago. While it might read a little outdated, the crux of his wisdom is as spot-on as ever.

Some people think that usability is very costly and complex and that user tests should be reserved for the rare web design project with a huge budget and a lavish time schedule. Not true. Elaborate usability tests are a waste of resources. The best results come from testing no more than 5 users and running as many small tests as you can afford.

In earlier research, Tom Landauer and I showed that the number of usability problems found in a usability test with n users is:

where N is the total number of usability problems in the design and L is the proportion of usability problems discovered while testing a single user. The typical value of L is 31%, averaged across a large number of projects we studied. Plotting the curve for L =31% gives the following result:

The most striking truth of the curve is that zero users give zero insights.

As soon as you collect data from a single test user, your insights shoot up and you have already learned almost a third of all there is to know about the usability of the design. The difference between zero and even a little bit of data is astounding.

When you test the second user, you will discover that this person does some of the same things as the first user, so there is some overlap in what you learn. People are definitely different, so there will also be something new that the second user does that you did not observe with the first user. So the second user adds some amount of new insight, but not nearly as much as the first user did.

The third user will do many things that you already observed with the first user or with the second user and even some things that you have already seen twice. Plus, of course, the third user will generate a small amount of new data, even if not as much as the first and the second user did.

As you add more and more users, you learn less and less because you will keep seeing the same things again and again. There is no real need to keep observing the same thing multiple times, and you will be very motivated to go back to the drawing board and redesign the site to eliminate the usability problems.

After the fifth user, you are wasting your time by observing the same findings repeatedly but not learning much new.

AKA—with any given design/prototype, you get diminishing returns on your time the more user tests you run. While that curve says 15 people are needed to discover all the usability issues in the design, you’re best off distributing your testing budget over many small tests.

The sweet spot is to test with a handful of folks, make changes based on what you learned, and then go and test with another handful on V2.

Lots of small scale tests >> a single large one. Remember, the goal of getting folks to go through a concept isn’t just to find flaws, but to improve the design. So, on each cycle, you have the opportunity to 1) fix the issues, and 2) improve what you have. The next cycle then builds on something better.

Aim for 3 cycles of tests with 5 folks each time.

(#5) Learn by making, not talking.

Yes, talking to customers and all that good stuff is essential.

But really, great product teams learn by making. And making as fast as possible.

 wrote a great piece on this, sharing an anecdote from this time at early YouTube when he was driving the GTM for their ads product. FYI—he’s the PM who built skippable ads.

In the early days of the project, I toiled over how to deal with the competing opinions while designing a range of solutions with the team. I’ll never forget the nudge I got from my manager, Phil Farhi, at the time. His advice was un-intuitive but masterful, “Just test the extremes. Get the experiment going tomorrow. Then you’ll know how good or bad this idea can be before you have to convince more people.”

So we ran experiments with an enormous ‘skip ad’ button over the YouTube player experience that people couldn’t avoid. And another with a tiny skip button that was difficult to read. The two extremes gave us the data points we needed to understand the best and worse cases, and enabled us to speak intelligently to what we thought would happen.

Phil’s advice was a perfect example of the principle. Stop talking about the idea, just make something and learn something. Then come back and we’ll figure it out.

We could have debated the idea for months, but instead we shipped something quickly and learned.

This rings true for so much, but especially the product function: learning by making, and just doing the thing, is the best validation and iteration loop.

Lane adds:

I’ve learned this lesson the hard way several times throughout my career. One source of inspiration has been outside of technology in other creative pursuits, like art. Painters don’t deliberate on ideas for months or years, they paint. Photographers don’t imagine the perfect shot, they shoot lots of photos. The craft of making product is similar, you have to default toward making.

By contrast, ‘talking’ in the context of ‘learn by making, not talking’ can come in many forms. Sometimes it’s over debating how to handle a complex problem space, sometimes it’s mocking up too many options to a problem, and sometimes it’s analyzing data for too long to gain confidence in a potential path. There are many ways to get in your own way when it comes to getting something in front of customers. Often in these cases — making, prototyping, shipping enables a team to learn significantly faster.

That isn’t an invitation though to just build the first solution you think of. Rather, it’s a good reminder that at some point you have enough intuition or data to get to work and see how your solutions feel to customers.

I love Intercom’s (read How Intercom Grows) mantra: shipping is the beginning of the process

In Paul Adam’s post about how shipping is the start of the learning process at Intercom, he says this: “We ship to learn. We know that we will be wrong more often than we will be right. Because we care most about learning, we prioritize speed to execution.”

And that’s a great nugget of wisdom to cap this week off on. For more of Lane’s work, checkout out

đŸŒ± And now, byte on this 🧠

I absolutely loved this piece on career blues by . Here’s an excerpt:

Career blues leave you feeling tired, unfulfilled, and restless. Could I be doing more? Should I be doing more? Am I missing out by staying where I am? AM I FALLING BEHIND? And the feeling is crushing times, blurring your vision.

LinkedIn does not help. Everyone’s profiles look like rocket ships and the feed is filled with new job announcements and promotions humblebrags. Failures, stress, tears are masterfully omitted.

However, here's a plot twist: Diving headfirst into another role might just set you up for a sequel of the stagnation you're trying to escape from. It's riskier and potentially gloomier than giving your current job a TLC. 

So, if you’re feeling blue
here’s what to do. (sorry 🙃)

And that’s everything for this week, folks.

If you learned anything new, the best way to support me and this newsletter is to give this post a like or share. Or, if you really want to go the extra mile, I’d be incredibly grateful if you considered upgrading. The first 500 folks who become founding subscribers get 30% off this newsletter ($7/m, or $70/year), as well as any other products I sell, for life.

Thanks so much for reading. I hope you have a wonderful weekend.

Until next time.— Jaryd✌

Want to sponsor this newsletter?

Reply

or to participate.