Your Future Customer’s Story

The Answer to Life, the Universe, and Everything

In the previous issue, we discussed the merits of the one-to-many approach.

Reminder: In order to maximize return on time spent, make time for one-to-many sales meetings (like webinars and group demos) before you spend all your team’s time in one-to-one sales calls.

For this week’s actionable framework (and subsequent weekend project), we’ll need to lay some foundation. And we are going to start with a foundational piece.

The end goal here is to have a webinar (or a 1-2 punch duo of webinars) that help convert folks who need your product into paying customers or active trials.

On Friday, we are going to go over the whole thing on a printable one-to-many canvas.

Here’s what that looks like.

Let’s just focus on the top part for now. We’ll get to the rest, soon enough.

You might notice the crooked box at the top. You see it there, right?

The one that says “Future Customer’s Story”. Try to ignore the rest for now.

Dr. Marvin? Dr. Leo Marvin?

What about the rest?

Let’s take this one step at a time and zoom in to reduce distractions.

Huh?

Start with the story of the customer.

“As a [persona], I [want to], [so that].”

Those of you who have spent any time with product teams probably already recognize this as a “user story”. In fact, I grabbed that formula from the Atlassian page on the subject.

Here’s what else it has to say:

Summary: A user story is an informal, general explanation of a software feature written from the perspective of the end user. Its purpose is to articulate how a software feature will provide value to the customer.

It's tempting to think that user stories are, simply put, software system requirements. But they're not. 

A key component of agile software development is putting people first, and a user story puts end users at the center of the conversation. These stories use non-technical language to provide context for the development team and their efforts. After reading a user story, the team knows why they are building, what they're building, and what value it creates. 

You don’t have to be a software developer to get the gist here. This is one of the most foundational components of creating products of any kind.

Today, our product is a webinar (or two). Many marketers tend to start with the product and reverse engineer the copy and/or build the story in the wrong order. I am often guilty of this.

That’s why it’s valuable to get back to the basics of product development and start with the customer’s story.

But what does a story actually look like?

Here’s an excellent <6 minute video from Femke that explains things quite well.

Can’t watch that? No worries. Get back to it after.

Let’s jot it down here fo you to read. Oh, Atlassian said it best so here’s what they had to say about stories:

User stories are often expressed in a simple sentence, structured as follows:

“As a [persona], I [want to], [so that].”

Breaking this down: 

• "As a [persona]": Who are we building this for? We’re not just after a job title, we’re after the persona of the person. Max. Our team should have a shared understanding of who Max is. We’ve hopefully interviewed plenty of Max’s. We understand how that person works, how they think and what they feel. We have empathy for Max.

• “Wants to”: Here we’re describing their intent — not the features they use. What is it they’re actually trying to achieve? This statement should be implementation free — if you’re describing any part of the UI and not what the user goal is you're missing the point.

• “So that”: how does their immediate desire to do something this fit into their bigger picture? What’s the overall benefit they’re trying to achieve? What is the big problem that needs solving?

For example, user stories might look like:

• As Max, I want to invite my friends, so we can enjoy this service together.

• As Sascha, I want to organize my work, so I can feel more in control. 

• As a manager, I want to be able to understand my colleagues progress, so I can better report our sucess and failures. 

This structure is not required, but it is helpful for defining done. When that persona can capture their desired value, then the story is complete. We encourage teams to define their own structure, and then to stick to it.

You probably were looking for some mid-week homework, right?

Let’s dig into your future customer’s story before we head into the weekend.

Can you clearly articulate the: “As a [persona], I [want to], [so that].”

As you might have guessed by now, this will be useful far beyond webinars.

But, we have to start at the beginning.

Up Next

P.S. We’re diving deep into the rest of the worksheet on Thursday. And yes, I will let you print the whole thing out then. Want to bring your team in on this?

🎶 Musical Note: I got a lot of great feedback about the Khruangbin & Leon Bridges (Leon is a Fort Worth, TX native) song I included last time, so I’ll keep on leaving you with the songs that are on as I hit send.

If you found value in this weeks issue, please let me know! Just reply to this email or leave a comment.