Omer (00:09.280)
Welcome to another episode of the SaaS Podcast.
I'm your host, Omer Khan, and this is the 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 talk to Matt Genovese, the founder and president of Planorama Design, a UX and UI design firm that helps to get complex software projects to market faster.
In this episode, you're going to 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?
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.
Matt Genovese (01:11.130)
Thank you.
It's very good to.
Very good to be here.
Omer (01:13.770)
Do you have a favorite quote, something that inspires or motivates you that you can share with us?
Matt Genovese (01:18.090)
I do.
I. I don't know if it's a quote, but it's one that I've heard enough that 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 realistically, there are more variables when it comes to what you're creating, what you're designing, than 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 exists, so we can move forward and do other things that are also important.
Omer (01:50.970)
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.
Matt Genovese (02:04.170)
Yeah.
Omer (02:06.170)
So tell us about Planarama Design.
What does the business do?
Who do you help?
Matt Genovese (02:11.130)
Well, I'll start off by saying our mantra is time to market, accelerated by design.
And so we focus 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.
Omer (02:51.470)
Right.
So in the next, you know, the rest of this episode, we're going to tap into your years of UX and UI design experience and we're 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?
Matt Genovese (03:18.340)
So a user story is just 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 is meant to prompt discussion.
And that's a little bit different.
You know, when you're writing a.
A user story, you're doing it because you are 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 make sure that everybody understands what the user is 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 use that in the future.
And there's a lot of value in doing so.
Omer (04:09.910)
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?
Matt Genovese (04:29.730)
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 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 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's this back and forth.
They talk about actors, they talk about pre and post conditions.
There's a lot to it.
But this is the end of the day.
A use case is very valuable to developers to know how to go and build the feature.
Omer (05:38.410)
Can you just explain how that's different from a user story?
Matt Genovese (05:42.810)
Sure.
A user story.
By contrast, if you imagine that same point of view where you're looking down from from 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 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 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 response from the system as you're a user using that system.
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, 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.
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 in just being a tool to start sussing out this information.
But what we're going to be talking about more is the user stories.
Those are a lot easier to write and I think they're going to provide a lot of value for your listeners.
Omer (07:07.540)
Do you have to pick one or the other?
Can you use both?
Do companies use a combination of use cases and user stories as part of the development process?
Matt Genovese (07:16.340)
They can.
And in fact, what I've seen, and I can speak to my own experience, is 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 information from the team as they're helping you to put this together, because you're going to 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 information about what the system is doing under the hood is going to come out.
Developers are already going to start thinking about that.
And so event, you know, in some ways your use, your user story may transform into a de facto use case.
Omer (08:08.490)
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 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 thing there.
Matt Genovese (08:32.650)
That's right.
Omer (08:33.370)
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 user stories.
But 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.
Matt Genovese (08:55.610)
Well, especially if you're building a new SaaS, if you're starting a new company, you're doing something like this, you're going to 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 already allowing yourself to interface with designers and developers who are already accustomed to this format.
So you're kind of impedance matching with the other people you're going to be interfacing with, and it's just going to make things a lot smoother.
Secondly, the beauty of a user story is that it maintains focus on the user, right?
You're looking at it from the person's perspective who is going to 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.
And 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.
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 kind of a small set 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 key people on the team.
A couple other things.
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 think about it in a different way because you have to put words on paper.
And 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 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.
I tell people sometimes surprises are for birthday parties, but they're not great in business.
And if you can avoid a surprise later on by smoothing out the development process, if you can identify things that you realize now, oh, we're going to have to think about this more.
We're going to 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 hardware is not doing what I thought it was supposed to do or whatever it is, the more of that work you can do up front.
And as you think about user stories, you start thinking of these ideas and concerns.
You solve those now, you avoid surprises later on.
Omer (12:20.450)
Okay, great.
So what I heard was that you need user stories number one.
It's, you know, it's the modern way 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.
Matt Genovese (12:52.850)
Right?
Omer (12:53.410)
The, the thing that strikes me most is this focus on users.
I think that as, as we get into this and we explain more about, you know, some practical examples on using user stories, 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 because people are talking about whether this should be on the left hand side or the right hand side or whether the, the engineering work required to do this on the back end of that.
And so many times what the user is trying to do is, is kind of there, but it's not at the forefront and sometimes it even gets forgotten
Matt Genovese (13:49.390)
about, 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 you know, sometimes the other quote that comes up is, you know, you're opinion is interesting, but it doesn't matter, right?
We got to focus on what the user is trying to do and what problems they're trying to solve and not go on tangents and start trying to solve pet projects or pet features that they want to execute on themselves.
Omer (14:19.530)
Now when 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 for, to help you build a better product and business, but 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?
Matt Genovese (14:50.670)
Sure, sure.
And this is something I think many businesses, and certainly startups too, can, can, can miss out.
And if you kind of make the decision early that you're going to 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 kind of keep them together in documentation, very organized documentation, it allows you to bring on new people fairly quickly when you want to 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 muck around in the product and see how it works.
But when you have the user stories time and time again, I've seen where people get on board a lot more quickly because they have all this documentation ready at their fingertips.
The second thing that 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 going to do software externally first, then we're going to bring it in house.
Or they want to bring in an external team to do some special projects or things like that, or maybe they have a development team and they're not happy with how they're performing and they want to swap out that development team.
Maybe an external team brings 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 the onboarding process is just much more smooth because again, 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
Omer (16:43.450)
works very quickly 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, 100, 100 plus person company with your in house dev team.
Having using these user stories gives you a consistent language that you can use to communicate requirements clearly and you don't need to train people on how to understand them.
Matt Genovese (17:18.819)
That's right, that's right.
It's a well understood format and it's going to allow you a lot of flexibility later on if you retain those, if you don't treat them as throwaways or treat them as tickets that go into the jungle of finished tickets that eventually you may want to go and parse through at some point.
If you put an ounce of prevention, an ounce of organization and management, you're going to reap a lot of benefits later on.
Two other things I'll mention about just the ongoing value of user stories.
Another value of user stories is it may not be completely obvious, but if your business is going to go through an M and A, somebody's going to come through and want to look at your software and they're going to want to look at, it's called due diligence.
They're going to review your software, they're going to look to see is it well written, what is the acquiring company getting for their money.
And if you can hand them a well documented product book effectively of your documentation for your user stories that bodes well for, for your overall evaluation.
If you don't have any documentation, if you just kind of throw your hands up and like, well, we've got tickets in JIRA and we've Got other things here and there.
It's not going to leave the best impression.
And so realistically, if you treat user stories as a business asset instead of a throwaway, and you put in that effort up front again, you're going to reap rewards later on.
Omer (18:54.980)
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, you know, the, the general structure framework that we're going to use here and then maybe we can just talk about some real world examples that will really kind of drive the point home.
Matt Genovese (19:21.950)
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 going to be a narrative.
And so the narrative is just 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.
For example, and it's usually written this way, by the way, so the words I'm using are very specific.
You're going to think of it as three lines and it's as a.
And then a type of user or a type of Persona.
And 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 action.
As a type of user, I want to.
An objective so that I can.
And then the reasoning or motivation.
Omer (20:24.050)
Can you give us a couple of examples on how we can use this?
Matt Genovese (20:28.370)
Sure.
So for example, as a cook, I want to see the recipe ingredients so that I can tell if I currently have enough ingredients to make the selected dish.
Right.
It's very easy to read.
It reads in English.
It doesn't look like code or anything like that.
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.
Right.
So that's one again, natural language.
And 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.
The 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 kind of painting a picture, right?
You can almost see the jogger running through a park and they have some kind of digital watch on that can send them messages, but they only want to respond to the ones that are most pressing because they're out running, they're doing their thing and they're kind of trying to get away from the world.
But they do need to know 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 user.
Omer (21:58.300)
Yeah, And I think that's the thing that really is kind of critical for me to make the point here, that by thinking about, by structuring it this way, you're very clearly focused on those three things, right?
The, the type of user, the objective and the reasoning or motivation.
And that first example that you gave about, you know, as a cook, I want to see the recipe ingredients so I can tell if I have enough 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 web page 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'd 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, it's a great way of making sure that people don't go off the reservation.
And that's.
Right, really stay true to what the product is supposed to do for that user.
Matt Genovese (23:16.260)
And many times that motivation, you know, sometimes that motivation people kind of leave it off and you know, like, well, 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 or 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 want to 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 want to see the ingredients.
But if I know they're going to not make it right now, but they're going to go shopping and 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 play a role in the later work that comes from the UX team, from the design, from the development team, as they create a solution to solve that particular problem.
Omer (24:23.000)
Yeah, that's great.
Okay, so that was the first part of the user story, which you described as the narrative and 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?
Matt Genovese (24:43.710)
Yeah, there's one more.
And they usually call this acceptance criteria.
And so these are the conditions that need to be satisfied when the feature is considered complete.
Omer (24:55.620)
Right.
Matt Genovese (24:57.220)
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, 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 has been implemented?
Right.
And so 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 is implemented.
So in this case, maybe the jogger must be able to see the currently unread notifications as they're running.
And you could list those out kind of in 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.
And you're kind of formulating, okay, well, this is what it's going to look like when it's done.
This is what I can do.
This is what the promises are effectively 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 those could be a little more tricky to write.
It depends.
It can Be a preference of people 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 on the 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.
And so it's given something happens when or given a state when something happens, then the system is going to respond or that person can see something or do something.
So 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 will we see?
What is the user going to experience from that?
Omer (27:02.360)
Yeah, and I like this concept of the narrative and the acceptance criteria.
It's kind of like a nice way of sort of bookending the work that's going on, the product design or feature design, that the narrative almost sort of sets the direction and keeps everybody focused on what the user is trying to accomplish.
And then the acceptance criteria is basically making sure that, you know, you stay true to that and actually delivered on.
On what you set out to do with.
With helping the user solve whatever problem.
Matt Genovese (27:29.750)
That's right.
That's right.
Omer (27:31.350)
Great.
Okay, so that's narrative acceptance criteria.
And so we've kind of gone through and provided a good overview on how to structure a user story.
The other thing you touched on earlier was, was about how user stories promote collaboration.
Matt Genovese (27:48.750)
Right.
Omer (27:49.390)
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 them, but there's a little bit more to that.
So again, just help us understand, like the value here around collaboration.
Matt Genovese (28:04.740)
Well, user stories, as I said, somebody is usually the person starting to write them.
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 one thing that product managers or people who have to write user stories may get a little bit of stage fright or writer's block.
And the idea is that 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 don't go into this thinking that you need to write again, pages and pages of text.
It can be daunting target getting a minimum user story written quickly with the narrative and some acceptance criteria, you have a great starting point.
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.
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 to begin having these conversations.
It's valuable to just start setting the, again, painting the picture, setting the stage for conversation and collaboration within the team.
Another thing to think about, and again, I think people have preferences on this.
Wireframes 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.
If you have one, that's fine.
And if you can draw it out or use 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 going to figure this out.
But if it helps you to communicate the concepts or the items in the story better, then get it out of 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.
Omer (30:04.580)
I've seen that a lot with wireframing 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 because whether it's your team or customers or stakeholders, people actually think that that's what it's going to be like.
Matt Genovese (30:30.970)
It's a problem.
Omer (30:32.250)
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 stakeholders 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 balsamiq type app or even just on paper with, with a marker, is probably going to avoid a lot more issues than trying to come up with something that looks like a real application.
Matt Genovese (31:15.280)
That's right.
People get distracted and remember what we talked about in the beginning, that great is going to 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 user or 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 3 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 going to 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, when you're writing a user story, if you have an idea for how this should look, get it out of 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 realize that again, UX design will eventually be responsible for how it's going to look and how the workflow is going to be put together and let them do that.
Right?
But if you're writing the story, just get it out of your head.
I'll give you a couple more things that I think are very useful around user story and collaboration.
UX design, and I kind of mentioned this before, UX was 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 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 creation of the user story.
So again, it doesn't have to be that ux, you sit down and write the user story and you deliver it and then everybody executes sequentially afterwards.
If you bring in people in the process, they can help flush out that user story, bring up other ideas.
Again, design will often do that and allow you to think more holistically about the problem and how you need to solve other issues that come up.
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 I'm an engineer, it's very hard for me not to.
When somebody talks about a problem, start coming up with solutions and trying to see what's happening under the hood and know what data structures to use 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 this.
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 technically hard to do.
And so you want to have that information earlier.
The more you have that information earlier, the less surprises you're going to have.
Maybe there are some decisions you can make that will help you decide if that user story is something that is going to be much larger or much smaller than you thought.
So again, it's a collaborative effort.
I think if anything that your listeners can take away from this conversation, it's that user stories don't just belong to one person, it's the entire team coming around them and figuring out creatively how to solve that problem so the user can get value out of your product.
Omer (35:16.880)
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, 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 sort of, the value around collaboration and some of the benefits associated with that.
So I think we provided a lot of general guidance and I think 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 that 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, sure, what?
As if someone's listening to this and saying, okay, Matt, you saw me on this, I'm going to start using user stories.
I can see the value, I think 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?
Matt Genovese (36:50.530)
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.
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 development and the technical capabilities required underneath.
Just focus on getting that problem out on paper is going to do.
It's going to 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 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 contribute in that way.
Another thing to do is avoid development thinking too early.
And again, like I mentioned, I have an engineering background.
If you have a tech background at all, you may start getting into implementation details, right?
And you want to avoid that.
You don't want to get into, well, we're going to use this database and these tables and we're going to use this API.
It's like, oh gosh, no, it doesn't matter right now.
It doesn't matter what's going to happen in the front end or the back end.
That's for developers to decide later on.
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 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 kind of look like the end product, depending if they're done in any low fidelity or high fidelity.
And 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 in these prototypes, tested with users, tested with stakeholders, evaluated internally before any piece of code is written.
It's a fantastic way to frankly save money and time during the process.
And so if you're going to be writing user stories instead of just moving to development, consider if there are open ended questions in your user story, use a design prototype to help you answer them.
It's a tool in the arsenal.
Omer (39:46.570)
Are there any products that you think people could look at?
Matt Genovese (39:49.450)
At Planorama we use Figma.
Figma's a UX design tool.
It's a wonderful tool and it has prototyping built in.
But there are many other ones, I think Balsamiq and Adobe XD and many other tools that are out there.
Some are free, some are rather inexpensive to get started.
So you don't need to necessarily spend an ARM and a leg on it.
If you have a UX designer involved in your project, they're probably using one of these tools already and it has the prototyping built in.
So it's a wonderful tool and it does it for 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 a wonderful way to experience it in your hands before development has to go and build it.
And you spend the time and you invest that capital in having developers go and build something that may not be the right thing.
A couple other things I'll mention, as 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 going to 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 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?
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 and put it into a document, you're going to be much better off and it's much easier to keep organized.
And if there's anything I've harped on during this conversation, it's that organization and that little bit of effort to keep your stories put together in almost like a product book has a lot of value later on.
And so I certainly suggest that.
So the final item I wanted to talk about 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 at 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 brakes sometimes or slow down or write your requirements or get your requirements figured out and take the time to do so, because again, they have a vested interest in getting to development and you have a vested 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 well thought out, that you bring in the people from the team 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 going to bring value to your, to your company.
Omer (43:26.330)
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 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, 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.
So 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 answer them as quickly as you can.
All right, what's the best piece of business advice you've ever received?
Matt Genovese (44:18.180)
Always think about how to unwind contracts.
Omer (44:21.700)
I haven't heard that one before.
Matt Genovese (44:23.060)
I know.
If you're going to get into business with somebody, you better know how you're going to get out of it.
Just in case things go badly.
Nobody wants to think about that, but you never know, right?
Omer (44:32.580)
What book would you recommend to our audience and why?
Matt Genovese (44:35.380)
The Blue Ocean Strategy.
It's been around for a while, but I still get a lot of value from that and I always keep it in mind to see if I'm doing something that's unique or I'm just competing against everybody else.
Omer (44:47.080)
What's one attribute or characteristic in your mind of a successful founder?
Matt Genovese (44:51.240)
I would say being married to the problem and not the solution, and therefore be willing to uproot your own well thought out guesses when the data or your users or customers say otherwise.
Omer (45:02.840)
What's your favorite personal productivity tool or habit?
Matt Genovese (45:06.120)
I use Trello and kind of mix that with the getting things done philosophy, 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.
Omer (45:21.180)
What's a new or crazy business idea you'd love to pursue if you had the extra time?
Matt Genovese (45:25.580)
Oh boy.
I'll tell you, I don't want to be a Debbie Downer here, but you know, tackling loneliness.
I think people in the US 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'd love to see a way to help tackle, I think, an epidemic of loneliness that has spread for the past ten years or so.
Omer (45:54.500)
What's an interesting little fun fact about you that most people don't know?
Matt Genovese (45:57.860)
Let's see.
I grew up on a farm in upstate New York among corn and cows and cats and dogs.
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 8th 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.
Omer (46:23.190)
Finally, what's one of your most important passions outside of your work?
Matt Genovese (46:27.030)
I love tutoring and teaching.
We learn so much in our lifetime, especially when we get to the age where you and I are omer and I want to 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.
Omer (46:44.550)
Great.
Well, if people want to find out more about planarama design, they can go to planorama.design and if folks want to get in touch with you, what's the best way for them to do that?
Matt Genovese (46:55.830)
Well, they can get in touch with me on again, Planorama Design.
They can also reach me on LinkedIn.
This just Matt Genovese.
You can find me on there.
Also, I wanted to mention that we're building and launching.
By the time this podcast goes out, we'll have a tool that 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 just need to get past this blank sheet of paper we've been building.
We have an arm of Planorama called Planorama Labs where we do our own development, we do our own research.
One of these areas is using AI to help get past that blank sheet of paper problem 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 hope your listeners get value out of it and I'd love to hear their feedback as well.
Omer (48:09.700)
Great.
Sounds good.
Thank you, Matt.
It's been a pleasure.
Thank you for taking us through and educating us on user stories and appreciate the time and enjoy the rest of your day.
Matt Genovese (48:21.380)
Thank you so much.
You have a great rest of the day as well.
Omer (48:23.940)
Cheers.
