User Stories

[00:00:00]
>> Product, so we've talked a lot about everything around being a product manager, how to be an effective product manager. Now, I'm actually gonna talk about the product portion of it. As you can see, a lot of product management, I don't know, 25% of it is actually the product, and 75% about it is talking about the product.

[00:00:17]
It's just the nature of moving organizations together. And if you're at a startup, it might be the opposite way. It's probably 75% product and 25% getting people on the same page. You can see that I'm very colored by the perspective of working in large corporations, where most of my job is just communicating.

[00:00:36]
But I think this is the fun part. It's also the most intuitive part. I imagine many of you as engineers, QA engineers, designers, project managers, operations people, all those kind of people, you probably have a strong sense of your product or product senses as the industry likes to call it.

[00:00:55]
And so I don't wanna spend a bunch of time trying to explain to you to have product sense when most of you probably are into a lot of this stuff. Also, I just wouldn't know how to explain it to you as well, right? But let me give you some of my processes that I use to get to good product.

[00:01:16]
So the first one is user stories. And I used to kinda hate this term, but now, I realize that I use it everywhere in my head, and so it actually is a pretty useful thing. So this is forcing you to flip the way that you're thinking about a product.

[00:01:34]
Rather than saying, as a product manager at Microsoft, I want you to use Office, right, that's my user story. That's very based on me and my company, and it's not at all how you should be a product manager. You should be thinking about this as a professional, I need to write memos, right?

[00:01:59]
And you think about it, I'm a user, I'm a particular type of persona, and I have this particular type of problem. That is a user story. It typically comes in the shape of, as a blank, I need to blank, right? When you're starting to write product specs, or tasks, or whatever you wanna think about, write down your user stories first.

[00:02:21]
If you write down your user story first, that forces you to be grounded in a user's perspective. And instead of trying to seek, what am I trying to get you to do, you will think about it as, what can I do so that my user can accomplish their intent?

[00:02:41]
I think you'll end up with a much better product. So as much as you can specify what type of user they are, a customer, a shopper, an admin, a moderator, an athlete, a chef, whatever, right? As a student of Frontend Masters, I wanna learn how to be a better developer, right?

[00:02:59]
Or as just someone that's learning in the industry, right, I wanna learn how to be a better Frontend developer, would be a kind of a higher level of Frontend Masters user story, for example. So and again, I'm just gonna invite you to be careful that these are just not reframing.

[00:03:17]
Don't work backwards from what you want them to do. I'm exactly trying to get you to work forwards, not backwards. So as a worker with frequent users, I want to be able to use the metaverse to take meetings. I feel like that's the user story behind Facebook's metaverse.

[00:03:33]
They have this thing, the metaverse, and they're trying to work you into being in the metaverse instead of thinking about our users have a problem and the metaverse solves that, right? So yeah, as a worker who takes frequent meetings, I want to have a more personal experience with my co-workers despite a remote culture.

[00:03:56]
Would probably be a closer user story that might be better for Facebook, I don't know. As you can see, I'm not a big fan of the metaverse. [LAUGH] So think about that story a little bit. As a worker who takes frequent meetings, I want to have a more personal experience with my co-workers despite a remote culture.

[00:04:18]
One, do you think that's true? Do you think that everyone wants to have personal experiences with their co-workers? I'm gonna say, not everybody. Some people do, some people won't. The question is what's the mix of that? So as a product manager, it forces you to go and then figure out how true is this user story?

[00:04:43]
I'm perfectly happy having a professional relationship over Zoom, and I don't need anything more professional than that or more personal than that, so. And I don't think the metaverse solves that, personally. But that's my biggest criticism of the metaverse is it feels like a product in search for a problem to solve, as opposed to here's a problem and we made a product to solve that problem.

[00:05:08]
Do we see kinda see why I like phrasing things as user stories? It forces you to make a true, false statements that I can prove users do have this problem. Users don't have this problem, but in any case, I'm very user grounded in things that I end up thinking about.

[00:05:21]
Your users can be internal, by the way. If I'm an infrastructure team, as a product engineer, I want to be able to deploy my infrastructure faster, right? And then you can go talk to your product engineers like, hey, do you wanna deploy your stuff faster? Of course, they're gonna say that, but how much of a problem is that for you is probably a better way to phrase that.

[00:05:45]
Yeah, we as product managers, as you may or may not believe, are mere mortals and we don't have all the answers. We frequently make guesses and they're wrong. And we make bets that don't come up the way that we want them to. Our product sense, right, can intuit some of the answers, but a lot of them we're gonna get wrong.

[00:06:10]
That's why it's good to phrase these things upfront, write down all of our assumptions about our users and the problems they have, and then go validate that. So put enter research. Once you have all of your user stories written down, my user has this problem or it's like, as this user, I have this problem, as this user, I have this problem.

[00:06:32]
This is where you wanna go talk to your users and figure out like, hey, I think you have this problem. Do you have this problem? And actually, the better way to phrase that is, hey, user, what kind of problems do you have? And what would you expect a problem to do?

[00:06:46]
And then see if your guesses line up with what your users say. Cuz typically, if you say, hey, user, do you want free thing? And they'll say, hey, product manager, give me free thing and then later, they'll just never use it. One thing you need to do when you have all of your user stories written down as a Nike user, I'm not finding all of my products that I want.

[00:07:09]
So I would need to be, or I want to be recommended products to buy, I don't know, that might not be true. But actually, the problem would probably be a pretty good one to research, right? So there's your user study or user story, and then you should go do some sort of study to figure out if that's true, and there's a bunch of ways to validate this.

[00:07:26]
You can just do kind of passive ways of look at forums like Reddit, Twitter, all of those, Stack Overflow, if you're doing technical stuff. Wherever your users congregate, go look there and read a bunch of the posts, see if those are coming up. You could make your own posts like, hey, I'm a PM at Nike, what do you think about this?

[00:07:49]
We at Streamlit have forums, which is super useful. We just pop in there and say, hey, Streamlit forum users, what do you think about something like this? And we will get very strong feedback of like, that's very dumb, you shouldn't do that, or that's great, we would actually use that.

[00:08:08]
A word of caution, UX research is an art. And there's a reason why it's a whole degree for someone to go get a research kind of background. Because if you phrase questions the wrong way, you strongly bias your answers, right? So if I say, hey, if I did this for you, would it solve your problem?

[00:08:32]
A lot of times, no matter what this is, people are like, yeah, if you do something for me, I like that, so therefore, yes, do that for me. And you'll bias your results towards what you're asking. It's much better to phrase those questions of what problems do you have, and how do you currently solve them?

[00:08:48]
And what do you wish you had to solve them, right? So that you're letting the user kind of come up with their own answers and see if it correlates to what you're doing. Go all the way down that pathway, and then kind off lightly lead them into, well, what about a solution similar to this, so you can kind of get a more direct answer.

[00:09:06]
I'm not the best at it. I always work with a UX researcher whenever I'm doing any of these things. So just be cautious that phrasing becomes critical on the surveys and on forum posts and in interviews. So before you get too far into your user stories, validate the problem, validate the solution.

[00:09:30]
And then, you come up with an experiment that you can run, right? So let's say you've validated that, now you have a user study. And you'll come up with 30 user studies, or sorry, user studies, I keep saying studies, user stories. At this point, which of them do you work on?

[00:09:52]
Well, this is an exercise in prioritization, and there's a whole section on it coming in here in just a little bit. So hold on that thought for just a second. Generally, when I have a validated user story, I will generally try and turn that into some sort of product spec.

[00:10:09]
Even if I'm not going to immediately work on it, even if it's just kind of a bare bones product spec, but I'll say, we validated this problem, we validated a solution to it, and we have this hypothesis about this. That if we do this, that we will solve this problem, or improve this metric, or capture this kind of user, those kinds of things.

[00:10:32]
Those product specs become useful even if you don't work on them right away. They are like, you'll get two quarters down the line and you'll realize, this is actually a much bigger problem. Good thing we already did a bunch of research on this and we already have a bare bones starter spec for this, you kind of save that knowledge.

[00:10:49]
So in any case, keep your users in mind, that's my plea to you. I think that makes the best product manager. I think that alone will give you a leg up on a lot of other products managers. I do think your product specs and your tasks that you're gonna work on for a quarter, or whatever your unit of work is, should typically either be backed one to one with a user story, or at least ladder up into a user story that you have acknowledged as a company that is important to you.

[00:11:20]
Your product should solve problems. I think, that's basically what I'm saying. So when you're validating feedback and turning that into a user story, be careful about phrasing your user stories with solutions. And I'm trying to think of a good example of a way for me, as a power user, I want this feature, it's a bad user story.

[00:11:47]
What you should look to is, why do they want that feature? What problem are they solving with feature, right? What you wanna phrase that user story as is, a power user, I have this problem. And then your solution is the proposed, I want this feature, but you should also look at the other features in there as well.

[00:12:05]
When they're telling you, I want feature, what they're telling you is I have problem, right? And you wanna get to the core of the problem, and then you wanna look at all of the solutions. This has happened to me a lot in VS Code, because you have a lot of very different personas using VS Code.

[00:12:21]
You have everyone from accountants to English teachers to developers, they're all using VS Code, because it's a very useful tool. And they will tell you, I want this because Excel has it. It's like, no, you actually just want to, you don't wanna have some fancy CSV processing, you just wanna get to Excel, right?

[00:12:38]
And so when we build all these CSV things for them, they're like, well, this is dumb, why would I stay in VS? Because I don't know, you asked for it, right? It's like, well, I actually just wanted to get this into Excel. It's like, why didn't you tell me that, right?

[00:12:51]
And so when we made an Explore to Excel button, all of a sudden, all of that feedback just went away. So listen to your users and be very judicious of how you interpret their feedback, because they will tell you things that's actually not true. But there's always a core of it, there's always a reason why they're telling you that thing.

[00:13:14]
In which case it's like, I have a problem and they think they know the answer, when in reality they have no more ability to solve their problem than you do, right?