How to Build a Better SaaS Product (and Business) with User Stories – with Matt Genovese [326]

[00:00:00] Omer: Welcome to another episode of the SaaS Podcast. I'm your host, Omer Khan, and this is a show where I interview proven founders and industry experts who share their stories, strategies, and insights to help you build, launch, and grow your SaaS business.

In this episode, I took to Matt Genovese the founder and president of Planorama Design UX and UI design firm that helps to get complex software projects to market faster.

In this episode, you're gonna learn how to build a better SaaS product and business with user stories. We'll cover the fundamentals of user stories. In other words, what are they, and why do you need them? And then we'll teach you step by step on how you can go about implementing effective user stories while avoiding the most common mistakes.

By the end of this episode, you'll have a solid understanding of user stories and know how you can start implementing them in your SaaS business to build a better product. So I hope you enjoy it.

Matt, welcome to the show.

[00:01:10] Matt: Thank you. It's very good to, Very good to be here.

[00:01:12] Omer: Do you have a favorite quote, something that inspires or motivates you that you can share with?

[00:01:17] Matt: I do, I, I don't know if it's a quote, but I, it's one that I've heard enough that I, I take it to heart. It's great is the enemy of good enough. I know that probably sounds a little strange from somebody coming from a design firm, but you know, realistically there are more variables when it comes to what you're creating, what you're designing then just the design itself, and if you're a perfectionist like I am, we have to take that into account and know when to stop, know when good enough exist. So we can move forward and, and do other things that are also important.

[00:01:47] Omer: I know exactly how that feels, and I have to remind myself about that as well. When I'm sitting there spending hours on little, tiny details that actually no one cares about.

So tell us about Planorama Design. What does the business do? Who do you help?

[00:02:07] Matt: Well, I'll start off by saying our, our mantra is time to market accelerated by design. And so we focus on, on designing software complex software. We scope it, we design it we make it intuitive and simple and easy to use.

But we also know that a dev team has to build it, and at the end of the day, they have to know where to put the buttons and know how to code it. And so we deliver everything that they need in order to do that. And that includes, as it turns out, user stories. So we, we try to give dev teams what they need to execute and they can do so efficiently and get it out to market faster, which is why we have that tagline.

[00:02:44] Omer: Right. So in the next, you know, the rest of this episode, we are going to tap into your years of UX and and UI design experience, and we are going to teach our listeners on how they can start using user stories to build a better SaaS product and business. So why don't we just dive into that and let's get started and tell us like exactly what is a user story.

[00:03:11] Matt: So a user story is just a, a natural language description of what a user is trying to do in your product. It's nothing more than that. It's written in English or whatever language you happen to write in it. It is meant to prompt discussion, and that's a little bit different. You know, when you're writing a user story, you're doing it because you're trying to describe what a user wants to accomplish in your product, but you're also trying to get discussion from your team.

To solidify those requirements to, to make sure that everybody understands what the user's trying to do. And if you do it right, your internal sorry, the user story becomes your internal product documentation. It's a way for documenting how your features work and you can keep that as part of your product legacy, your product documentation and, and use that in the future. And there's a lot of value in doing so.

[00:03:59] Omer: The term user story is sometimes confused with use cases and they are two very different things. So can you just, again, help us understand just the basics in terms of the difference between a user story and a use case?

[00:04:18] Matt: Sure, sure. The use case you'll find that many times. First of all, you'll find it used on websites and that's not the, the kind that we're talking about. Sometimes on a marketing website, they'll talk about a use case. And they're really just trying to show how customers were successful with their product. That's not the term that we're talking about. We're talking about use cases that are written by business analysts. And so it just to differentiate a use case is completely describing the interaction between a user and the product, the software, and they're talking about the back and forth. So it's still about a user trying to do something, but they're kind of, if you look at it from the top down, imagine a user at the computer or a user on the phone and they're showing that the user's doing something and the software is doing something in response, and then the user does something and the product does something back.

It says back and forth they talk about actors, they talk about pre and post-conditions. There's a lot to it. But this is a, it, the end of the day, a use case is very valuable to developers to know how to go and build the, the feature.

[00:05:25] Omer: Can you just explain like, like how that's different from a user story?

[00:05:29] Matt: Sure, Sure. No a user story by contrast, if you imagine that same point of view where you're looking down from the, the top and looking at a user and looking at the computer or the phone. A user story is written from the user's point of view. So imagine that, yeah, you're kind of dropping down in and you are that user and you're interacting with the product.

You're writing it from that almost like a first-person point of view, and you're not so concerned about what the software. Is doing under the covers or under the hood use cases get into that quite a bit. But you don't need to worry about that. You're just looking at what is the, what is the, the response from the system as you are a user using that system.

So in both cases though, whether you're doing a use case or a user story, there's a lot of value in that process of writing them. Because it causes you to think, and I know for myself, and maybe it's the case for you or others, that when I actually have to sit down and describe something, it gets the gears turning in my head and I have to really start thinking through different scenarios and how things might work.

That's the value. These user stories have a lot of value and just being a tool to start sussing out this information. But what we're gonna be talking about more is the user stories. Those are a lot easier to write and I, I think they're gonna provide a lot of value for your listeners.

[00:06:50] Omer: Do you have to pick one or the other? Can you use both two companies, you know, use a combination of use cases and user stories as part of the development process?

[00:06:59] Matt: They can, and in fact, what I've, what I've seen, and I can, I can speak to my own experiences that if you start with a user story, they're a lot easier to write. Again, because you're looking at it from the user's perspective, from the customer or user, the person using this.

And eventually when you start filling in the information and especially the information with the, from the team as they're helping you to put this together because you're gonna have people from UX and people from development involved as they are helping to provide that information. Your user story starts kind of transforming into a use case because eventually the, the information about what the system is doing under the hood is gonna come out. Developers are already gonna start thinking about that. And so even, you know, in some ways your us, your user story may transform into a defacto use case.

[00:07:49] Omer: Okay? So we've defined what a user story is. We've explained the difference between user stories and use cases. And the two types of use cases. That was a good distinction for you made there, because I'd completely forgotten about the use cases that sit on, you know, tons of different SaaS product websites telling you, you know, hey, there's a use case for marketing, there's a use case for engineering and so on. And that's a completely different thing there.

[00:08:13] Matt: That's right.

[00:08:13] Omer: So let's talk about why do we need user stories? Like we, we've kind of set out the promise here that, you know, you can, you can build a better SaaS product and business if you use the user stories. That explain like why we, we need user stories or why somebody who isn't using user stories today should be seriously thinking about using them.

[00:08:35] Matt: Well, especially if you're building a new SaaS. If you're starting a new company, you're doing something like this you're gonna be working with a development team and probably a design team as well, at least a designer and developer. It's the modern way that agile development teams are accustomed to receiving requirements.

So if you write user stories and you learn how to do it, and it's not terribly difficult to do, so you're, you're already allowing yourself to interface with designers and developers who are already accustomed to this format. So you're, you're, you're kind of impedance matching with the, with the other people you're gonna be interfacing with, and it's just gonna make things a lot smoother.

Secondly, the, the beauty of a user story is that it, it maintains focus on the user, right? You're looking at it from the person's perspective, who is gonna be using your product and you're figuring out how is your product going to solve a problem for them? Or the other way of looking at it is, how is this user going to engage with your product to solve a problem?

That typically is a primary focus for a SaaS application and a business for that matter. So it kind of keeps your eye on the ball in terms of solving problems, right? Another thing it can do for you is that it can promote collaboration among the team. You know, once you start with a user story, you'll find, as we talk about it later, you don't have to sit down and write a, an essay like you were in high school.

It's nothing like that. You sit down and you start writing and you only need a, a, a kind of a small set of of work done in a user story to bring other people in and start creatively solving that problem and working towards it. So it really does promote collaboration among the, the key people on the team.

Couple of other things. You know, first of all, it'll identify feature gaps. And this is something I found quite a bit and I kind of mentioned it before. When you start writing, a lot of times your brain has to, to think about it in a different way, cuz you have to put words on paper, and you, as you think about the different scenarios of a user story and different things that can happen, You might sit back and it's like, Oh, wait, wait.

This could happen too. Oh, I need to think about that. And it causes you to, to start at least making notes about other things you have to think about which is really important. And then finally, they help you avoid what I'll call surprises. And, and you know, I many, I, I tell people sometimes, like surprises are for birthday parties, but they're not great in business.

And if you can avoid a surprise later on by, by smoothing out the development process, if you can identify things that you realize now, oh, we're gonna have to, to think about this more. We're gonna have to develop maybe a proof of concept or do something else that will evaluate some technology dependent needs or whatever.

You get that done now and out of the way, and that will help you determine paths in the future so that you don't have to be surprised later when something comes up and then you're like, Oh, no wait this API is not performing the way I thought it was, or this you know hardware is not doing what I thought it was supposed to do or, or whatever it is.

The more of that work you can do upfront and as you think about user stories, you start thinking of these ideas and concerns, you, you solve those, now you avoid surprises later on.

[00:11:48] Omer: Okay, great. So what I heard was that you need user stories. Number one, it's, you know, it's the modern way to, to gather, communicate requirements. It lets you really focus on the end user. You're able to have more of a collaborative environment you know, as you work through these things and potentially you, you have this opportunity to identify gaps in features or product design as you are going through this process, which ultimately will save you a lot of headaches in the future.

[00:12:18] Matt: That's right.

[00:12:18] Omer: The, the thing that hit strikes me most is this focus on users. I think that. As we get into this and we explain more about, you know, some practical examples on, on using user stories, it, this will become a lot clearer, but this focus on users I think is super critical because having worked, both you and I have, you know, showing our age, like spent decades working with product teams, engineering teams on software, and I've lost count the number of times that the conversations go off track.

People are talking about whether this should be on the left-hand side or the right-hand side, or whether the, engineering work required to do this on the back end of that and, and so many times what the user is trying to do. It is kind of there, but it's not at the forefront. And, and, and sometimes it even gets forgotten about.

[00:13:14] Matt: It gets lost in the shuffle, you know, And then people say, Well, this is how I would want it to work, or, This is what I think it should do. And, and, you know, and sometimes the, the other quote that comes up is, you know, your opinion is interesting, but it doesn't matter, right? We gotta focus on what the user's trying to do and what they're, what problems they're trying to solve.

And not go on tangents and start trying to solve pet projects or, or pet features that they want to execute on themselves.

[00:13:42] Omer: Yeah. Now, when you, you and I were talking about user stories. One important thing that you pointed out to me was, you know, user stories are not just there to help you build a better product.

In business, well, better product, but there's also ongoing value of having these user stories, which helps you build a better business. So can can you explain a little bit about that? Like how, how do user stories get used beyond just building the product?

[00:14:11] Matt: Sure, sure. This is something I think many businesses and certainly startups too can, can miss out. And they, if you, if you kind of make the decision early that you're gonna use user stories and do them in a certain way. You can reap a lot of benefits later on that may not be obvious right now. So, for example, if you write user stories and you, and you kind of keep them together in a, in documentation, very organized documentation, it allows you to bring on new people fairly quickly when you wanna onboard a new team member eventually. The documentation is there to see how the product works. I mean, yes, you could go in and say, well, here, go, go muck around in the product and, and and see how it works. But when you have the user stories, time and time again, I've seen where people gets onboard a lot more quickly because they have all this documentation ready at their fingertips.

The second thing that, that I, again, if you keep your user stories together and organized, you have this flexibility with your development team. Usually as businesses evolve over time they decide, Well, we're gonna do software externally first, and we're gonna bring it in house. Or they want to bring in an external team to do some special projects or things like that.

Maybe they, they have a development team and they're not happy with how they're performing, and they wanna swap out that development team, maybe an external team and bring in somebody else who's outsourced, whatever that is. If you have the user stories, if you own those and keep those as part of your assets with your company again, bringing on an entirely new development team becomes a lot easier.

And, and the onboarding process is just much more smooth because again, they, they're used to absorbing, they're used to receiving, user stories. And when you have those well organized and delivered to them, they understand how your product works very quickly.

[00:15:57] Omer: And there's value there as well in terms of whether you are, you're a solo founder and you're outsourcing your development offshore somewhere, or whether you are the founder of a, you know, a hundred plus person company with your in-house dev team. Having, using these user stories gives you a, a consistent language that you can use to communicate requirements clearly and you don't need to train people on how to understand them.

[00:16:30] Matt: That's right. That's right. It's a, it's a well understood format and yeah, it's gonna allow you a lot of flexibility later on if you have, if you retain those, if you don't treat them as throwaways or treat them as tickets that go into the, the jungle of finished tickets that eventually, you know, you, you may want to go and parse through at some point.

If you put a, you know, an ounce of prevention, an ounce of, you know, organization and management. You're gonna reap a lot of benefits later on. You know, two other things I'll mention about just the ongoing value of, of user stories. So another value of user stories is it may not be completely obvious, but if your business is gonna go through an M and A somebody's gonna come through and wanna look at your software.

They're gonna wanna look. It's called due diligence. They're gonna review your software. They're gonna look to see, is it well written? You know, what is the, the acquiring company getting for their money? And if you can hand them, you know, a well-documented product book effectively, right? Of your documentation for your user, stories that bode well for your overall evaluation you know.

If you don't have any documentation, if you just kind of throw your hands up and like, well we, we've got tickets and Jira and we've got other things here and there, ah, it's, it's not gonna leave the best impression. Right? And so, you know, realistically, the, if you treat user stories as a business asset instead of a throwaway and you put in that, that effort up front again, you're gonna reap rewards later on.

[00:18:00] Omer: Okay, great. So let's, let's get into the meat of, of this content here and let's talk about how to structure user story. So maybe if you can just give us an overview of the, the general structure of framework that we we're gonna use here. And then maybe we can just talk about some real world examples that will really kind of drive the point home.

[00:18:24] Matt: Sure, sure. So usually a user story has, I would say, at least two sections. And if you think of it as headings in your user story the first one is gonna be a narrative. And so the narrative is, is just a, a section that describes the user's needs and what they're trying to achieve in terms of an objective and their reason and motivation for doing so.

So, for example and it's usually written this way, by the way, so that the words I'm using are very specific. You're gonna have, think of it as three lines and as, as a, and then a type of user or a type of persona. Then I want to, and then there's an objective, what that user's trying to do. And then there's a third line so that I can, or so I can, and it's a reasoning or motivation behind it.

It's the why, why are they trying to accomplish this thing? So it's the, as a type of user, I want to, an objective so that I can, and then the, the, the reasoning or motivation.

[00:19:22] Omer: Can you, can you give us a couple of examples on, on how we can use this?

[00:19:26] Matt: Sure. So for example as a cook, I want to see their recipe ingredients so that I can tell if I currently have enough ingredients to make the selected dish.

Right? That's, it's, it's very easy to read. It reads in English. It doesn't look like code or anything like that, you know, Here's another one. As a motorist I want to see my current speed so that I can make sure I'm not driving over the speed limit. So that's, that's one, again, natural language. And it, it really does state who we're talking about, what they're trying to do and why they're doing it, and each one of those parts are very important.

Third one, Let's see, as a jogger or runner, I want to be notified on my watch of important messages so that I can respond only to the pressing requests. You can see in each one of these cases you're, you're kind of painting a picture, right? You can almost see the jogger running through a park and they, they have a, a, some kind of digital watch on that that can send them messages, but they only want to respond to the ones that are most pressing, cuz they're out running, they, they're doing their thing and they don't, they're kind of trying to get away from the world.

But they do need to know if if their partner can't get into the house because they lost their keys, right? So, This kind of thing. It starts to paint a picture that really is specific about what problem is trying to be solved. And it does keep the focus on the, on the user.

[00:20:51] Omer: Yeah. And I think that's, that's the, the thing that really is, is kind of critical, you know, for me to make the point here that by, by thinking about, by structuring it this way, you are very clearly focused on those three things, right?

The type of user, the objective and the reasoning or, or motivation. That first example that you gave about, you know, as a cook, I wanna see the recipe ingredients so I can tell if I have enough to, to make the dish. I mean, it's kind of a silly example, but you can, you can easily imagine a situation where, without that, where a team of designers and engineers are sitting around a table thinking about how to design a webpage to show recipes and ingredients and someone saying, Well, the ingredients, there's kind of a lot of clutter there, and if we kind of hid them or collapse them, that might be nice because it would look like a better design page or something like that.

Right? And it would be just like completely like going into different directions. Whereas if you keep coming back here and saying, This person wants to do this so they can achieve this outcome, or this, you know, this motivation. It's a great way of making sure that people don't go off the reservation, and really stay true to what the product is supposed to do for that user.

[00:22:07] Matt: And, and many times that motivation, you know, sometimes that motivation, people kind of leave it often and, you know, like, well, I, I want to do the thing so I can do the thing. You know? Yeah. That's kind of lazy and what you're, what you're getting with a really well-written user story, including that motivational part, that third line.

Can manifest later on when UX design or developers of the team kind of gather around it and realize, Oh, you know what, because of that person's motivation, right? They want to make that dish, they want to cook it, versus they wanna see recipes, ingredients, because they want to go out shopping and buy the ingredients, right?

It's a different motivation. It's the same person. It's the same objective. They wanna see the ingredients, but if I know they're gonna. Not make it right now, but they're gonna go shopping and go, go to the store and want to find those ingredients. Then it changes the way you may design your interface. So every one of those parts, they, they, they play a role in the later work that comes from the UX team, from the design or from the development team as they create a solution to solve that particular problem.

[00:23:13] Omer: Yeah. That's great. Okay, so that was the, the first part of the user story, which you described as the narrative. Right. And we, we talked about this, this format of, you know, as a type of user I want to. Achieve X objective so that I can, whatever the reasoning or motivation is. Okay. So that's great. What's the second part?

[00:23:33] Matt: Yeah, there's one more. And, and they usually call these acceptance criteria. And so these are the conditions that need to be satisfied when the feature is, is considered complete. Right? So if you think about it, you're kind of fast-forwarding to the end. Once the feature has been implemented, however, it is implemented, right?

We're not really sure yet because we've only written about the user and the objective and what they're trying to do and why. And now we're fast forwarding, looking at the end saying, Well, when it's done, how do we know it's done? How do we know this feature's been implemented? Right? And so it can be, you can write those in two different ways.

You can write them they call them rules based. So you could say like, for the jogger, one for instance. We say what the user can do after the story's implemented. So in this case, maybe the jogger must be able to see the currently unread notifications right as they're running. And you could list those out, you know, kind of in a, just a numerical list.

The jogger must be able to do this, the jogger must be able to do that. The jogger should be able to do this. Right? And, and you're kind of formulating, Okay, well this. This is what it's gonna look like when it's done. This is what I can do. This is what the promises are effectively of the, of the user story when it's implemented.

The other way you could write them are as scenarios where it kind of shows the user's path that they take in order to accomplish that objective. And, and those could be a little more tricky to write. It depends. It can be a preference of people to, to use those. We actually use both of them when we write our user stories for Planorama, but we use them for different reasons.

But the way scenarios are written in a given, when then format, so you might think you write it this way, like given a new priority message is received. When the jogger taps onto watch, then they see the new message. So you can see it follows this format similar to a narrative, but it's called given when then, and so it's given something happens when or given a state, when something happens, then the, the system's gonna respond or that person can, can see something or do something. So it's, it's a little bit different way of writing. A lot of times it's preference, but regardless, you're talking about what happens when this feature is implemented. What, what will we see? What is the user going to experience from that?

[00:25:45] Omer: Yeah, and I like the, this concept of like the narrative and the acceptance criteria. It's kind of like a nice way of sort of book ending. The work that's going on, the product design or features design, that the narrative almost sort of sets the direction and keeps everybody focused on what the user's trying to accomplish.

And then the acceptance criteria is basically making sure that, you know, you stayed true to that and actually delivered on, on what you, you set out to do with, with helping the user solve whatever problem.

[00:26:13] Matt: That's right. That's right.

[00:26:14] Omer: Great. Okay. So that's narrative acceptance criteria. And so we've kind of gone through and, and provided a good overview on, on how to structure a user story. The other thing you, you touched on earlier was, was about how user stories promote collaboration.

[00:26:31] Matt: Right.

[00:26:32] Omer: And I want to kind of dig into that a little bit more. So we've sort of touched on this about, you know, how teams can work and it can guide. There's a little bit more to that. So again, just help us understand like the value here around collaboration.

[00:26:47] Matt: Well, user stories, you know, as I said, somebody is usually the person starting to write them, right. Many times. That's a product manager or a product owner on the team. And the thing is, I think, not to get caught up, you know, one thing we that.

Product managers or people who have to write user stories may get a little bit of stage fright, right? Or writer's block. And the idea is that it's not, You don't have to sit down and write an essay, right? The narrative and the acceptance criteria, usually you can get those out pretty quick. And so, you know, don't go into this thinking that you need to write again, pages and pages of text.

It can be daunting, right? Target getting a minimum user story written quickly, you know, with the narrative and some acceptance criteria. You have a great starting point and, and the starting point can be, by the way, not only a conversation with your internal team, but also with users. Potential users, potential customers.

There's a lot of, you know, it's, it's a very free form tool that you can use in a variety of different ways, but it doesn't have to be fully baked, you know, to, to begin having these conversations. It's, it's valuable to just start setting the, again, painting the picture, setting the stage for conversation and collaboration within the team.

You know, another thing to think about and, and again, it, I think people have preferences on this wire frames can help but they're not necessary. You don't need to be a designer. You don't necessarily have to come up with an idea for what the screen looks like. I, if you have one, that's fine, and if you can draw it out or use, you know some rudimentary program to draw diagrams, all you're trying to do is get what's out of your head on paper.

Go into it knowing that eventually UX is gonna figure this out. But if it helps you to communicate the concepts, Or the, the items and the story better than, than get it outta your head, put it on paper. You know? But you don't need to do that. You don't need to be an artist to write user stories.

[00:28:36] Omer: I've seen that a lot with wire framing tools and especially the high fidelity type tools that yes, almost look like a real, you know, web app or, or iOS app or whatever. Yes, it looks great, but there's so much danger in that. Whether it's your team or customers or stakeholders, people actually think that that's what it's gonna be like.

[00:29:02] Matt: It's a problem.

[00:29:04] Omer: Yeah. The other issue with that I've also seen is that when it's a really high fidelity design, you put that in front of customers or, or stakeholders and, and they, they spend less time thinking about the functionality and what they're trying to achieve and suddenly start talking about the little details of, you know, the size of the button or something like that, which completely, you know, is, is irrelevant at that point. And so I think I completely agree with you. I think the idea of like these really low fidelity things, you know, like a balsamic type app or even just on paper with a marker, is probably gonna avoid a lot more issues than trying to come up with something that looks like a real application.

[00:29:46] Matt: That's right. That people get distracted and remember what we talked about in the beginning, that great is gonna be of good enough. And the perfectionism that can come with this, it really does play a part because I've had that same instance where the, the user or the, the customer is, is picking apart the colors used instead of talking about the flow.

And you know, it's like if I, if I go to talk to my three-year-old daughter and I, I can sit down with her and have a conversation, or I can sit down and bring a cookie and have a conversation. I can tell you that that second scenario, she's gonna be laser-focused on that cookie and not even understand what I'm talking about, right?

It's a complete distraction. And you know, when you're writing a user story, if you have an idea for how they should look, get it outta your head as fast as possible. Don't worry about pixels, don't worry about alignment. Don't worry about where stuff is on the page. Just get the concept out so you can start communicating.

And then it realized that, again, UX design will eventually be responsible for how it's gonna look and how the workflow's going to be put together and let them do that. Right. But in, if you're writing the story, just get it outta your head. I'll give you a couple more things that I think are very useful around you know, user story and collaboration.

UX design, and I kind of mentioned this before, UX really does play a part. There's this problem that you have and it happens on when you're writing on paper, we call it writer's block. It's the same idea when you're writing a user story. You can get a point where you're like, Boy, I can't imagine how this is going to work.

And sometimes UX design can get you past what I call the blank sheet of paper problem or the blank page problem, right? They can come in and say, Well, let me, let me see what you're putting together. Okay, I have some ideas and many times if they just put together some ideas themselves, it causes us to start looking at it and say, Okay, now I can visualize where this is going.

And with a little bit of effort you may start finding other acceptance criteria, other exception cases. Other things that you need to think about. And so UX design during the process really does play a part in the user story development in the, in the creation of the user story. So it doesn't, again, it doesn't have to be that you sit down and write the user story and you deliver it, and then everybody executes sequentially afterwards.

If you bring in people. You know, in the process they can help flush out that user story, bring up other ideas again design will, will often do that and allow you to, to think more holistically about the problem and how you need to, to, to solve other issues that come up. And in fact, development does the same thing.

And that was really the fourth point I wanted to make. You need to have development involved in this process too, because as they're looking at the user story, Like, you know, I'm an engineer. I, I, it's very hard for me not to, you know, when somebody talks about a problem, start coming up with solutions and trying to see what's happening under the, under the hood.

And know, know how, you know, what data structures to use and, and what APIs to call and things like that. That's what they do. And so they're looking at whatever you write in that story. They're looking at it from the development perspective. We have to build. And so they may find that there are some decisions that you're making or some problems that you need to solve as part of the user story that may seem trivial, but are really actually, they're, they're technically hard to, to, to do.

And so you wanna have that information earlier. The more you have that information earlier, they're less surprises. You're gonna have. Maybe there is some decisions you can make that will. Help you decide if that user story is something that is gonna be much larger or much smaller than you thought. So again, it's, it's a collaborative effort.

I think if anything that you're listeners can take away from, from this conversation, it's that user stories don't just belong to one person. It's the entire team coming around them and, and figuring out creatively how to solve that problem so the user can get value outta your product.

[00:33:42] Omer: Okay, so, we have covered, we've talked about what a user story is. We, we talked about the differences between user stories and use cases, and we've gone through and you've explained like why you should use user stories as you're building your SaaS product, but also the ongoing value of having user stories in terms of, you know, helping to, to manage your, your business.

And then we went through how to structure a user story. And you just sort of hit the points home about the, the sort of the value around collaboration and, and some of the benefits associated with that. So I think we provided a lot of general guidance and I think the, the whole idea of using a user story actually isn't that hard.

It's a very simple framework that you can sit down and as you think about a particular feature, As you said, you don't have to write, you know, a book on this. It could be a simple one page listing out some of the key things and you've listed out your user story so that on its own, I think hopefully we've convinced people, but there's value there in using user stories.

And secondly, we've shown that actually you can get started pretty easily. But let's talk about some more practical steps, like, what, as if someone's listening to this and saying, Okay, Matt, you saw me on. I'm gonna start using user stories. I can see the value, I figure I get how to use them. What are some of the things that they should also consider?

What are some potential mistakes people make when they start to use user stories that you can help people potentially avoid making?

[00:35:14] Matt: Well, you know, there are probably some rookie mistakes and even some, you know, not even just rookies, like mistakes anybody can make really. And even if you've been writing user stories for a while, it's good to remember some of these things.

So the first thing I'll mention is that focus on the story that you're telling and not the solution. What can happen many times is that if you're writing a user story, you've already got an idea what the solution needs to be, and so you end up almost writing a solution instead of writing a story.

So if you begin with the narrative, you get the problem out on paper. Almost pretend that you're explaining the problem verbally to somebody. You know, focus on the who, the what and the why, right? That narrative of the user story. Don't try to focus so much on the where and the how on the design and the, and the development and the technical, you know, capabilities required underneath.

Just focus on getting that problem out on paper. Its gonna do a, it is gonna be very good for you because you may have a solution in mind. But you know, there are probably other ways to do this other than just that one way. And if you bring the team in, they start, they may start thinking of other ways to solve the problem.

And if you write it as a story, you leave it kind of open ended so they can, they can contribute in that way. Another thing to do is, is avoid development thinking too early. And again, like I mentioned, I'm, I have an engineering background. If you have a tech background at all, you, you may start getting into implementation details, right?

And you wanna avoid that. You want get in, you don't want get into, you know what, we're gonna use this database and these tables and we're gonna, you know, use this API as like, oh gosh, no, you know, it doesn't matter. Right now, it doesn't matter what's gonna happen in the front end or the back end.

That's for developers to decide later on. It's a, it's a trap because it will distract you from coming up with other creative solutions. The third thing is using UX design prototypes to test before development is a fantastic idea. Design prototypes are something UX designers create all the time. They don't require any code.

They, they kind of look like the end of product, depending if they're done in any, you know, low fidelity or high fidelity. They cost next to nothing in terms of, I say next to nothing, but they cost time, but not as much time as it does to develop the feature. So if you use this design prototype, you can get questions or ideas or things on in these prototypes.

Tested with users, tested with stakeholders evaluated internally before any piece of code is written. And it's a fantastic way to, to frankly save money and time during the process. And so if you're gonna be writing user stories instead of just moving to development, consider, you know, if there are open ended questions in your user story, use a design prototype to help you answer them. That it's a, it's a tool in the arsenal.

[00:38:04] Omer: Are there any products that you, you, you think people could look at.

[00:38:07] Matt: At Planorama, we use Figma. Figma is a UX design tool. It's it's a wonderful tool and, and it has prototyping built in, but there are many other ones. I think Balsamic and Adobe XD and many other tools that are out there.

Some are free, some are are, you know, rather inexpensive to, to get started. So you, you don't need to You know, necessarily spend an arm and a leg on it. Most, if you have a UX designer involved in your project, they're probably using one of these tools already, and it has the, the prototyping built in. So it's a, it's a wonderful tool if, and it does it for web, you know, website or web apps or mobile apps.

In fact, it even can draw the phone around it. So it looks like the phone, it looks like a mobile application. Yeah. It's just, it's a wonderful way to, to experience it in your hands before development has to go and build it. Right. And you spend the time and you invest that capital in having developers go and build something that may not be the right thing.

Right. Couple other things I'll mention, you know, as I, I kind of stated before, but keep those user stories. Try to maintain them in a way that you can refer to them later on. In fact, I'll talk about it. In fact, it's one of the things I'll bring up now. I was gonna bring it up in a second, but I might as well just pull it together.

Stories, store them as documents. Don't store them as tickets. If you're using systems like Jira or or other project management systems, oftentimes you end up putting your stories into a ticket and that ticket moves through the board and then gets pushed out the other side. And the problem is it's all kind of random access.

It's very difficult to, in my experience, to organize these according to Sprint because who, who really keeps track of features by sprints? You know, most times you look at features in terms of how they're grouped naturally in the product. And so if you can write them as documents, And then just use the tickets to manage the process of design and development.

But don't put the content in there. Put it into a document. You're gonna be much better off, and it's much easier to keep organized. And I, if there's anything I've harped on during this conversation, it's that organization and that little bit of effort to, to keep your ears as stories, you know put together in a, in a, almost like a product book is, is, has a lot of value later on.

And so I certainly suggest that. So the final item I wanted to talk about is, is about dev shops. Dev shops typically make most of their revenue on developer hours. Sometimes they provide UX design services. Sometimes they'll, they'll help you with honing your requirements, but the end of the day they want to get you to development quickly because that's where they make their money.

So you may have to put the breaks sometimes or slow down or write your requirements or get your requirements figured out and, and take the time to do so, because again, they have invested interest in getting to development and you have invested interest in building the right features for your customers, and those interests are not always aligned.

So it's important that you make sure that your user stories are, are well thought out, that you bring in the people from the team, you, you work on a basis that is going to again, add value to your SaaS and to your business. And then when it's ready to go to development, then go to development and know that you're investing money and time into building features that customers actually want to use and they're gonna bring value to your, to your company.

[00:41:38] Omer: Great. So I think we have covered quite a lot in the last 45 minutes or so, and hopefully, we have delivered on the promise on how you can build a better SaaS product and, and business with user stories.

So thank you for, for taking us through that process and educating us on, on, you know, not only what user stories are, but how to implement them, how to, how to write them in a meaningful way, and then also how to go about avoiding some of the common mistakes that that people make when they try to do this.

I think that's probably a, We can call that a wrap here. We should move on to the lightning round. And I can ask you seven quick-fire questions. So just try and ask them as quickly as you can.

[00:42:24] Matt: All right.

[00:42:25] Omer: What's the best piece of business advice you've ever received?

[00:42:28] Matt: Always think about how to unwind contracts.

[00:42:31] Omer: I haven't heard that one before.

[00:42:33] Matt: I know. If you, if you're gonna get into business with somebody, you better know how you're gonna get out of it just in case things go badly. Nobody wants to think about that, but you never know. Right. What book would you recommend to our audience and why? The Blue Ocean Strategy it's been around for a while, but I, I still get a lot of value from that and I always keep it in mind to see if, if I'm doing something that's unique or I'm just competing against everybody else.

[00:42:55] Omer: What's one attribute or characteristic in your mind of a successful founder?

[00:43:00] Matt: I would say being married to the problem and not the solution. Therefore, you know, be willing to uproot your own well-thought-out guesses when the data or your users, or customers say otherwise.

[00:43:11] Omer: What's your favorite personal productivity tool or habit?

[00:43:14] Matt: I use Trello and kind of mix that with the getting things done philosophy, you know, more or less it's how I keep track of everything I need to do and move things through my own board so I don't lose track of something important.

[00:43:28] Omer: What's a new or crazy business idea you'd love to pursue if you had the extra time?

[00:43:33] Matt: Oh boy. I'll tell you I don't wanna be a Debbie Downer here, but, you know, tackling loneliness I think. People in the US and, and abroad we have been Guinea pigs for the social media movement, and we kind of figured out that maybe it turned out we're not as good off as we thought we were and we're maybe even worse off.

So I, I'd love to, to see a way to, to help tackle I think an epidemic of loneliness that is that has spread for the past 10, 10 years or so.

[00:43:58] Omer: What's an interesting little fun fact about you that most people don't?

[00:44:01] Matt: Let's see. I grew up on a farm in upstate New York among corn and cows and and cats and dogs. And, and I'll tell you, if it wasn't for my Commodore Vic 20 and then Commodore 64 that my parents bought me for my eighth birthday, I probably wouldn't be in this space today. That was where I learned everything. Also, I love to cook. My mom taught me as a kid, and that has really paid off.

[00:44:24] Omer: Finally, what's one of your most important passions outside of your work?

[00:44:28] Matt: I love tutoring and teaching. You know, we learn so much in our lifetime, especially when we get to the age where you and I are Omer and, and I wanna be able to find ways to turn it around and pass it on to other people and get them excited about the things I'm interested in, like technology and engineering and so on.

[00:44:45] Omer: Great. Well, if people want find out more about Planorama Design, they can go to planorama.design and if folks wanna get in touch with you, what's the best way for them to do that?

[00:44:55] Matt: Well, they can can get in touch with me on again, planorama.design. They can also reach me on LinkedIn. This just Matt Genovese they can find me on there.

Also, I wanted to mention that we're, we're building and, and launching. By the time this podcast goes out, we'll have a tool that we're we created called User Story Generator. In fact, you can get to that website by userstorygenerator.ai, and we just talked a lot about user stories and why they're important, but you can still get writer's block.

You can still sit down and like, Boy, I know I don't, I just need to, to get past this blank sheet of paper. And so we, we've been building, we have a, an arm of Planorama called Planorama Labs where we, we do our own development, we do our own research and, and one of these areas is using AI to help get past that blank sheet of paper problem and, and help you write user stories to start with a product idea and then move into other ideas for features and help you write user stories.

So it's a free tool. That'll be out there by the time the podcast goes out. So please, I, I hope your listeners get, get value out of it and I'd love to hear their feedback as well.

[00:46:03] Omer: Great. Sounds good. Thank you, Matt. It's been a pleasure. Thank you for taking us through and educating us on, on user stories and appreciate the time and enjoy the rest of your day.

[00:46:14] Matt: Thank you so much. You have a great rest of the day as well.

[00:46:16] Omer: Cheers.