Scaling Session: Product Development Lifecycle with BV Satyaram

Welcome to the Founder Insights Podcast from the Founder Institute. I'm Jonathan Grecian, co-founder of the Founder Institute, and on these podcasts we try to bring you useful startup insights from our global network of entrepreneurs and mentors. Today you'll hear from BV Satyaram, founder and CEO of CodeAstro, which is a software development house that works with tons of small businesses across the world to spec, design, and build software products. He's going to be discussing every stage of the software development process and how entrepreneurs can work with developers to create products and products that are done on time and on budget. This interview was done by Mike Struppovici, who's an EIR at the Founder Institute and the leader of our grad support group. Enjoy.

All right. Hello, everyone. It is my pleasure to introduce you to BV, who has a lot of experience in the software development world. So why don't you go ahead and maybe introduce yourself?

Hi. I'm a founder and CEO of Codastro. So we do software development for startups. So I've been into the software world for about 10 years as of now. So yeah, awesome, awesome.

And, um, you know, BV has also helped, uh, uh, graduates on a variety of different projects, and as well as the Founder Institute, uh, with our website and other things like that as well. So he has a lot of experience on the end-to-end, uh, product development lifecycle. So I thought it'd be really good for us to discuss that on this call. So what we're going to be talking today is about the product development lifecycle from the perspective of software development. So we're going to go through end to end, you know, everything from scoping to scheduling, some best practices on that, you know, as well as, you know, how to iterate quickly on your product and so on. So again, This is designed to be a highly interactive session, so any questions that come up, this is, you know, feel free to go ahead and put them into the chat and we'll go ahead and answer them for you. So, you know, the product development lifecycle essentially has, you know, 5 or 6 or so stages depending on who you talk to. But what we want to focus on today are the scoping part, the scheduling part, as well as the iteration part, and how to use various tools to do that. If we have time left over, we'll discuss your launch and other things as well. Why don't we go ahead and start with the scoping session? BV, from your perspective, how would you define scoping of a project and what is that from your perspective?

Uh, all right, so, um, let's say you're an entrepreneur and you would like to have a product built, uh, the number of features you would like to have. You're a visionary, you would like to have a lot of things done. Um, so if you want everything that's in your mind to be done, it's going to take a really long time before you reach the market. So it's a good idea to define what is the minimum, uh, the first set of features which needs to go and touch the customers, uh, so that you can reach the customers earlier and not wait longer before you get the feedback from to the users. And even after that stage, I mean, even after you reach the customers for the first time, even going forward, I mean, you always have a lot of things to do. So you need to see about what needs to be done, what can be pushed later. So I mean, that kind of gets into the prioritization, but when you talk about scoping, I would say what needs to be done now. And what can be done later. So that is what I would say is scoping, right?

So, you know, why don't, why don't we just talk about, you know, some steps to that? So how would you, how would we begin scoping? Maybe we should use an example. Let's say we're trying to build like Slack or something like that. How would you begin like, you know, scoping that?

Okay, so Slack is a very simple application, and I think the feature set is quite simple to compare to most of the other applications, but it's very, very useful. So the most important feature in Slack is messaging. So I would say, so you have organizations and you're part of an organization and you can chat directly with the person. You can have groups, you can have ad hoc groups, you can add a couple of people and make a group. So this is, this kind of summarizes what Slack does. But of course on top of that you have a lot of things. So for example, when you share a Google Doc, it tries to render a preview of the document So these are kind of nice-to-have features, but when you're first going and touching the market, the first— I would say the first thing I would start with is personal messaging. Forget about grouping, forget about Teams, just have organizations and people chat within the organization one-on-one. That is where we could actually start, and then probably you could go with channels. I mean, it all depends who your customers are. And you see what is the most important for them and what is the minimum set of features which you can go to the customer so they can have some meaningful feedback.

Yeah. And one of the things that we recommend that you do as well is, is kind of, you know, if you have like all these features that you want to develop, go ahead and list them out, put them in a spreadsheet. Right. And then why don't you go ahead and assign to them kind of a scoring system. So priority one being absolutely critical, the product can't live without it. Priority 2, it's like it's important, but it could probably wait. And 3 is kind of like a nice to have. And then, you know, just sort it by 1s and then really then do that same exercise again with the 1s one more time, possibly twice, right? So that you can really get down to the core of what's the one important feature that really makes sense potentially. And then, you know, another thing that you may wanna do along with your customers is to create some level of like a, you know, of a user story, right? Like, how would your customer use this product? Because then you can use that to efficiently communicate with vendors or with your co-founders and things like that, so you can actually start to build your scope. Do you have any, like, thoughts on that as well? Like, user stories?

That's very true. So when you're talking about scoping, you generally try to think on a higher perspective. You talk in terms of the epics. So, I mean, I generally— I mean, at least when I'm defining scope of my first version of the product, I just try to stay at the epic level. Where it really, really highlights what needs to be done. It just has a title. I mean, you don't have to talk about user stories then. And then, as you said, among the epics, we are going to prioritize them and we are going to pick what epics are most important. And once we pick these epics, that is when we are going to split these epics into multiple user stories and then once again prioritize them. So let's say we have a priority 1 epic and priority 2 epic. Some of the stories, user stories in priority 1 epic might be priority 2. So it's not, it's not that all, I mean, the whole epic should be done at once. I mean, a part of the first epic can be done first.

Got it. So, you know, maybe we can back up for a minute. You know, you, you're using a lot of like agile terminology, epics, meaning these are like big features, right? From your perspective.

Yes.

Okay. So that's, that's what that's, and agile is, is a way to basically build your product very rapidly. It's a format. And this is just some of that terminology. Again, we're doing this for you and, you know, we really love to kind of hear what your questions are, what you're struggling with with regards to product development and things like that, so that we can address those. So, you know, if you see on the, on the right-hand side of your screen, there's a chat room. Feel free to use that chat to go ahead and, and, and add any sort of questions that come up, and we'll definitely get to it. We'd love to be— for this to be really, really interactive. Uh, but in the meantime, I'm, I'm gonna continue to keep, uh, you know, asking BV questions and, and, and kind of riffing through this, but would love to get your thoughts in here as well. So, okay, you've kind of, you've got some user stories, you figure this out, you've kind of what this would look like at least on a high level, you've maybe picked one epic to kind of focus on, all right. Now, right, like what is like the process like in your, from your perspective as an engineer, as a developer, what's kind of like the ideal process, you know, for you to get this get some sort of like a communication or document or anything to kind of like to be able to efficiently start to build something?

Okay, the first step is the user validation. So I would generally start with interaction design first. Given a feature, I first try to understand what the customers want, and then probably I might talk to a couple of customers and then try to understand what they want, and we'll come up with um, rapid prototypes. So, um, first, uh, we're going to, uh, I mean, it could be a rough sketch on the paper, on the whiteboard. You're going to brainstorm, come up with several versions, and then you, you, you narrow down to one single version of them. Um, and then if you have a designer, probably the designer can pitch in now, and that's when they design. Uh, so this is the design phase. I would say the first part is design. And then develop, uh, and then validate, and I would say repeat. So this is the kind of cycle. So once again, I'm going back to agile. So when you are talking about software development lifecycle, it's very, very close to tight, tight to agile these days. I mean, if you're following agile methodologies, I mean, everything goes to be quite smoother than otherwise. So as I said, there are 3 phases: design, development, uh actually 4 phases: design, development, validate, and repeat. I mean, repeat. So we first had the designer do the designs and then we start developing. So that's when— I mean, I don't want to get into the details of the engineering part.

I hear you. But, you know, before we move off this, you know, scoping topic, you know, let's just kind of like break this down for, for, for a founder that's building maybe their first or second product. This doesn't need to be like, you know, super detailed, like technical spec or anything like that. It's more important that from you, like, to see what, what are some of the things that you really care about as an engineer in order to be able to build something?

Uh, yes, I'm personally against detailed documentation. I mean, there are a few, uh, I mean, there are a few engineers who insist on page-long documents of what needs to be done, but I think a lot of times you get more information when you actually sit down and talk to people. So what I would say is whatever you want to discuss, I mean, after discussing, if you finally put down onto the mockups or even wireframes on the paper, I think that should be more than— that is what I would call a scoping document.

So basically, some— a basic user story, maybe some wireframes that you could probably draw out. You might not even need to use some fancy software like, you know, Balsamiq or InVision or anything like that. And then, you know, you're pretty much like ready to go.

Is that how you see it? Yeah, that's true. I generally use a white paper and then draw using pencil.

Got it. That makes a lot of sense.

All right.

So now we have this document, you know, kind of set up. We're kind of ready to go, right? And then, you know, how do, how do we schedule this, right? How do we schedule this project? Like, how do we go from like, you know, paper, uh, maybe a Google Doc, right, to like something in reality? We probably have to schedule some tasks or something like that. What are your kind of thoughts on that?

Or how do you think about this? I would say this is the most complicated part, or the toughest part for a beginner engineer, actually. So I mean, as you keep, uh, working, uh, for longer years, um, I mean, you get used to that. And by the look of the story, you know how much it might take. But essentially, this is what is going to happen. You have a design. Let's assume it's not just mockup. We also have the— I mean, it's not just the wireframe. Let's assume the mockup is also ready from the designer. And that's when the software development starts. You try to break the major story into smaller user stories. Everything should be Related— always think in terms of the customer. I mean, if you're not adding value to the customer, let's not deliver it. So I mean, everything you do should be focused on what the customer is going to get out of this.

So how would we, you know, how do you look at like prioritization of like features, what to build first? You know, like how do you look, how do you think about that?

So for this, we use a Kanban model. Okay, you can use Trello for that matter. So you actually, as I said, you break down the task into several parts and then you create a card for each of the tasks or the user story, and then you're going to prioritize saying, okay, which is more important.

So let me just talk about this. So basically you create like a, you know, you can use Asana for this, you can use Trello, you can use a spreadsheet, whatever tool you want, but basically You create, let's call it like a feature that's important in a product. Within that feature, if you're using a Trello card, you can open it up and actually add a user story that becomes almost like the spec for that particular feature or so. Then the first step you do is you just throw them all in there. I assume you have some column set up for them called backlog or something like that.

Yeah, so essentially what we have, we have several columns. So I mean, the most commonly used is where you have several columns. The first one is icebox, where anytime you have a new request, anytime you want, you think of a new feature or user story, you just dump into the icebox. And then you're going to pull them and put in a prioritized order in another column called backlog.

Got it.

So if you look at backlog, backlog is always in a prioritized order. So the top, the story on the topmost is the most important one. So if I'm an engineer, if I don't know what to do, assuming I don't know what to do, all that I do is just pick the top card from backlog and start working on it.

Got it.

So it is the responsibility of a product manager to make sure that the backlog is always up to date in the priority order.

Got it. I got it.

And Yeah, so after backlog, I mean, then it comes to the execution part, right? So we make sure that everything is prioritized. And when you're prioritization, another thing which you need to take into the mind is dependencies. Sometimes a feature sounds to be extremely important, but there is a dependent feature which needs to be done before that. So that's when you need to actually pull in engineers and probably a designer too, and then discuss what should be the dependency tree. And then finalize the prioritization. So generally when you're talking about prioritization, it's generally sprint planning meeting where you do all this and then you have all the key people present in the call and you prioritize their tasks.

Yeah, I would assume that that actually gets rid of a lot of communication issues, right? Because if you can kind of see how these cards are tracking across the project, then you know where everything's going. So let's just kind of review kind of like some ideal columns that you should have in whatever project management tool you use, whether it's Trello, Asana, or whether you use a spreadsheet. You know, one is icebox. This is kind of where everything just goes in there, right? Backlog, that's kind of where you are, the things that you're going to try to do maybe this week or maybe in a couple of weeks, depending however you set it up, right? In progress.

Yes. So as I said, stepping back a moment, backlog is where you have all the stories, priorities in the order. I mean, different people have different perspectives. You know, people say that, okay, my sprint is 2 weeks long. So I will have 2 weeks long stories here. But few other people, what they say is, okay, I'll try to keep the backlog as updated as possible all the time. So I don't want to have any task in the icebox unless it is like, okay, let me do it next year.

So a backlog has a list of all the tasks for this particular upcoming sprint.

No, I mean, I said there are 2 thoughts. The first thought is where you have tasks only for the upcoming sprint. Okay. And the second thought is where you have a lot of tasks.

Got it.

And then you estimate each of the tasks. I mean, once again, estimating, estimation is a different, uh, which we can discuss a bit further. You're going to estimate each of the tasks, and then, uh, we have a pointing system. So let's say I'm an engineer, you can consider me as 1 point a day, and there are 10 engineers in the team, so it's essentially 50 points a week. So if your sprint is 2 weeks long, you're just going to count 100 points and then have a breakpoint there. So you can have a dummy card there which says, okay, this is going to be the sprint, uh, end for our sprint target for the upcoming sprint.

Yeah, so makes sense. You know, the, the first one is a little bit easier for most people, particularly if this is the first time you've managed a project or a second time. Just use the backlog column to just clarify what's going to happen in this next week or two-week sprint. I recommend that you don't go beyond two weeks because that's, that's just, it's just hard to manage. It's much easier to manage if it's a smaller sprint, right? So okay, you've got whatever, 5 cards or 5 tasks or 5 features, whatever, in, in, in the backlog for this upcoming sprint that we're we're going to do next week.

Yes, right.

You start working on it, and then what, what are the next columns, right?

How do we communicate? So, uh, the next column is in progress. I mean, you can call it by a different name, but I prefer calling it in progress. So, um, we have tasks scheduled for this, uh, upcoming sprint, and they're also assigned to engineers most of the times.

Yeah.

So if I'm done with the task which is in my hand right now, so I want to start a new task, all that I do is I go into the backlog, I look at the topmost task which is assigned to me, I just put it on to the in progress and I start working on it. I mean, and once again, it's a good idea to have smaller tasks so that we have quick iterations.

Sure.

So once you are done with this in progress task, you move it to testing. I mean, once again, after in progress, different people have different things, but sure, but let's keep it simple.

So testing.

You pull it to testing where the test engineer, or sorry, even before testing, sometimes you might want to have review. I mean, when you have multiple engineers, you always want to have peer reviews when you write code, right?

But for most people here who have very small teams, you're probably just going to be working with one engineer, maybe two at most. You know, you're looking at just go put it, just put it in a testing. That's going to make it a lot simpler for you, right?

So I mean, whoever is going to do the testing, it could be the product owner, owner, or it could be a dedicated QA engineer. So they're going to test the feature, and then if it's not up to the mark, I mean, if something is wrong, they once again put it back to in progress. And if it's okay, then the next column is ready to deploy, right? So you push it on to deploy. And so as you keep working, the story's progress from backlog to in progress to testing to ready to deploy. And now comes the deployment strategy. If you're agile, I mean, you generally prefer deploying as often as possible.

I mean, just push stuff in production.

Exactly. I prefer deploying every day. I mean, when you're making incremental changes and when the stories are pretty well defined, I mean, if— I mean, it might break system, but if it breaks, I mean, I can always easily roll back.

Got it.

A single deployment.

Yeah.

So I have ready to deploy features. And then what the— I mean, if you have a QA or a test engineer, what he does is once again deploy all this ready to deploy changes into a staging environment. By staging environment, what I mean is a server which is very, very close to production. Production is the live server, what the end users see. So you want to have another server which is used within ourselves, which is as close as possible to the production, the live server.

Yeah, this way you can kind of test it and have everybody involved test it before you actually push out like any kind of user, any person, right?

So you deploy to the staging server, you make thorough testing, and once everything is done, then you deploy to production.

Got it.

And that's when you move the task from ready to deploy column. To deploy.

Another column that probably makes sense, we use it here at the Founder Institute, is have, you know, some sort of like questions or unclear or something like that.

Or yes, this is very beneficial for remote teams.

Yeah, exactly.

So I mean, if you have a daily scrum and you're sitting together, I mean, things are quite easy to be covered, but when you're remote, I think, which is the case for most of the startups, we call it blocked or clarification needed or something like that.

And we just throw the cards in there or or you can create a spreadsheet.

So I'm an engineer, I am working on a task and I'm not sure about something that needs to be— I'm not very clear about one of the minute details of the task. Then I would just add a comment there and pull it to the backlog, pull it back to the blocked column.

Got it.

And then the product manager is— I mean, his task is to make sure there is no task in the blocked column.

Yeah, makes sense. I see there's some questions related to this topic here. So Anita asked, having a development team remotely, uh, it's hard for, for, for you to understand what's, uh, what's going on, especially when, uh, on the backend side. How do I tell what I have asked for is actually being done, uh, other than a PM assuring me, uh, that everything's okay? I mean, look, you really, really should, should use some sort of, uh, tool that both of you can access, kind of like what we've just discussed right now. Asana is really good for this. Trello is really good for this, or just any, anything like spreadsheet. Uh, you know, is there other tools that you've seen? The Pivotal Tracker or things like that? There's, there's various tools out there that kind of help you through this, and you basically have to get buy-in from everyone involved that that's what's going to happen. And you can actually like literally watch like how the project is progressing. Like I wake up every day and I kind of see changes in this board every single day. And because, you know, we work with remote folks as well. So that's the number one thing I would say right now. And you got to make sure that you get buy-in from the team as well. If you're not getting buy-in from the team as well, then that's a bigger issue in itself. And you probably need to start thinking about, you know, looking for other folks or other strategies to kind of mitigate that. Hopefully that answers your questions.

I think there's something to add to this. I think the question is about the visibility of the progress of the task when you're working. So I mean, for every feature you work on, you have a front end part and a back end part. Yeah, so the front end part, it's very clear. I mean, you, you know, okay, we have added a button, I click on that, a form is being submitted and the data is available somewhere else. So this is something which is quite visible for you, but a lot of times when you need to do the for the front end to work, you need to do a lot of back end to get working. And when you're working on back end, the product owner doesn't have a visibility on what actually is happening. Yeah. So it might take a week, it might take a 2-week cycle generally when the work required is pretty hard.

Right.

So I think the question, if I'm not mistaken, is about how do I get a visibility into that when back end is being worked on.

So what are some of the best practices that you would recommend?

So there are a couple of things which I would say. Every sprint, right, have something which is delivered to the customer. So if there is a task which is going to take a really long time, when, as with the backend, try to also have another feature which is frontend or which can be easily deployed. This kind of gives us a happiness. Okay, I delivered something this week. And the second thing is when you're talking about backend, this is when the estimation comes into the picture. When we are talking about, when we do the initial estimates, we are going to break down the task into multiple stories. We can say, okay, the front, this task is a huge one. I'm going to break that into 4 small tasks. Of that, probably 2 of them could be completely backend tasks which don't have visibility for you. As being a product manager, but we have an estimate for that. So probably for one of the tasks, I estimated it to be 4 points, for that other task I estimated it to be 2 points, so it's 6 points. So at this daily standup, probably being a product owner, what I could just do is, okay, this is supposed to take 4 days and it's been 2 days, so I'm assuming it's 50% done. I'm having a confirmation here. It kind of gives you information. And in addition to that, you should always have access to the repository of the codebase. So I mean, most of the startups use GitHub these days.

I mean, you use Git repository, um, you can use, uh, so the only thing with that is you probably want to have some communication with the team to, to make sure that when they, they check code in that it kind of makes sense what they're checking because it's easy to say, well, update to blah, blah, blah, blah, blah, jargon, jargon, jargon, and you're like, what is this? Like, especially if you're not a developer yourself. So maybe another thing too, Anita, is just having some sort of understanding of like at least making some sort of comment in the check-in message that they, when they submit the code, that of what exactly this was done, that could be helpful.

Yes, so that's what we do actually. So we have issues created for each of the stories And then when we are making a check-in to Git, we always reference the actual issue which we are working on. So that kind of gives you what we are working on. And once again, going back, when you're talking about backend, probably you won't have much to comment on the check-ins. At least, you know, some activity is going on.

Yeah.

I mean, you know, something is— I mean, it kind of gives you comfort that something is happening. They're not sitting idle.

Makes sense. GitHub has a project product management tools now as well. Uh, you know, Prasad also mentioned here Jira is good for another good tool for Agile. I agree, that's also a really good tool. Uh, you know, uh, if at the very minimum, Anita, just use GitHub, right? And, and just use, and then just use that to manage, manage your process. You know, here we use GitHub and Asana. We take like every single GitHub, uh, issue, we put it in Asana. That, that kind of creates that story that we talked about, and then we watch it kind of move across the timeline. Ray has a question here. Hey, Ray. What advice would you have for moving from a scrappy prototype you validate on a small scale to creating a more commercially viable MVP? Emphasis on design, infrastructure choices, et cetera, et cetera. Well, the first piece of advice I'd have for you personally is that it's okay for your product to have bugs. You know, consumers, consumers, you know, are okay with bugs as long as it's solving a problem. And it seems like, you know, you've been able to get to that level. So don't get too, you know, crazy about building, you know, Battlestar Galactica here. You know, you just want something that works with a small subset of users. The other thing I would say is that you know, uh, you always want to cohort, or you want to create like user cohorts, right? So rather than launching this to like, you know, 5,000 people, one, you know, launch it to like 100. And I'm saying this because you say, uh, you know, more commercially viable. Start with 100, right? Fix some things, improve that, then launch it to another 100 or 200, right? Track NPS scores. Ask questions like, you know, um, how would you feel if you no longer could use my product? Uh, and you know, if, if, uh, 40% of your users would say, uh, that they would be very disappointed in not having it, then you are pretty well on your way to product market fit. Uh, just as a reference point, Slack right now is at 51%, right? If, if, if users aren't able— if it's only like 20 or 30% of those folks then I would say, you know, you've got a little bit of work to do and then you can ask follow-up questions to help. You know, Mark, this is a good time to add that link I sent you. We have a pretty good article on how to kind of track all this and it answers a lot of your questions about some of the stuff that you should be measuring, Ray, as you go through this as well. Mark just put it in the chat room here for you. Vivi, do you have any comments or questions?

Well, we're pretty much—

Yeah, got it. So, you know, Ray, let me know if that answers your question about that. You know, you said here emphasis on design infrastructure choices. Maybe I can like drill in on that a little bit. You know, the design has to be able to be decent enough so that people can actually do what you want them to do, right? Like if they can't log in, and then you can't test any of these other assumptions that you have. And I'm just, you know, obviously that's a broad question. So it has to be, you know, has to be able to let them do all those things. And it turns out that the best design is the simplest design. So if you see that there's like 5 steps to get to where you need to get to, ask yourself, how can we get this into 1 step or maybe 2 steps or something like that? And that will really kind of help you get to the things that you want to test out. You know, as far as like infrastructure choices, This is actually probably something we should probably talk about a little bit, you know, and maybe we can kind of talk, you know, go into a little bit of the next topic here that we kind of talked about, which is, you know, like the construction and iteration of the product since we're kind of going into that right now, right? Like, you know, how do you think about like developing like the code so that it is like scalable and can be iterated quickly? What are some best practices or thoughts you have on that?

Uh, so, um, the first and foremost thing, I mean, when you, when you're just getting started, as most of the entrepreneurs do, you need to define an MVP and then take it out to the customer and test it with the customers. Always have the customer as one of the key decision makers in your decisions, right? Um, so as you said, uh, one of the Agile manifestos is that it's okay to ship a buggy product to the customer As long as it's functional, that is good. I'm not asking you to deliver a suboptimal product, but something which actually delivers what you want to deliver. So basically, whatever you want the user to perform, as long as that's done, that's good. So what we do with most of the startups is we have a set of smoke tests. Smoke tests are the bare minimum scenarios which needs to pass all the time. Nothing about design, it's functional. So as you said, login should be working. So login, sign up, and probably if there is a payment system, yes, the payment system should work. And let's say if it's Slack, a user should be able to send a message and the notification should be received on the other end. So these are like kind of the basic smoke tests. And some of the other features are like, okay, as once again, as I said, when you share a Google document, you see a preview. That is a good to have, but it's not one of the most important features. It's okay for that to kind of fail sometimes. So that is the first, if you would say.

You could argue the same thing with the Slack example too, right? Like, is notifications really necessary? Yeah, we all internally think that, but if people are using the product without notifications and they're still using it a lot because it's solving some really important problem, then you know, then you know you're onto something. And all notifications are gonna do is just really increase the engagement. Like dramatically, right? So like, that's another way to kind of think about that, you know.

And another thing which we need to accept is that the engineers are going to come into the product development and go out of this thing. So people are going to change. So when a new engineer comes in, it should be very easy for him to adapt to the code base and get started with that. So for that, it's a good idea to follow style guides. I mean, it depends on what language and what framework are using. Every language, every framework has a style guide these days.

What is it? What is a style guide? A style guide is like, okay, let us say you're writing codebase in Ruby.

Okay. So each line asks you to have an indentation, a 2-space indentation, whenever you get into a block. I don't want to get into the technical realities, but I mean, when you're defining something called a hash, there's a couple of ways in which you can define. It says, okay, go with this because it lets you type a few number of keystrokes and easy to read.

So these are some common best practices of how to basically organize the codebase in such a way that it's, you know, easy to use and it's basically easy. The most engineers would be able to just be able to understand exactly what's going on very quickly without having to—

So it not necessarily means that the code is going to be more efficient, right? But it will be easily readable. And when I say style guide, there's not a single style guide.

Sure.

Once again, every language has multiple style guides. Your team has to pick one style guide and stick to it. And whenever a new engineer comes in, you just need to say, okay, we are following this style guide. and the engineer is going to first go through this style guide, and once he gets in, yeah, it's done. So this helps in two, two processes. One, when a new engineer comes in, it's easy for him to pick up, right? And the second thing is, uh, after a while you, you come back and you, you have a bug, or you, you want to add some additional functionality to a part of the module of code, right? Uh, you are going to come back to the code after a few months and you don't have to remember what you actually wrote some time ago. And if it's following some style, it's going to be much easier for you to once again read and just add.

Nice.

So it's going to add a little bit of time into the development.

Like setup time, essentially, right?

Not, not, not just setup time. Yes, setup time. Yes, it does add a lot of time. But even every time you add some piece of code, you need to make sure that it confines to style guide. It's going to add a little value. But on the long run, it's going to add a lot of advantages, right? Maintainability.

No, it makes a lot of sense. You know, another process along this as well happens on the user interface. So for those of you that are developing, for example, iOS apps, Apple literally provides like a, almost like a storyboard feature where it almost locks you into like the basic user interface guidelines that most iPhone apps use. So for example, at the bottom, there's like a navigation menu that, you know, there's at the top right-hand corner, you can put a button in the top left-hand corner, you can put a button. And the advantage to this is that every user knows how to use this, right? Like, because they've been using multiple apps and things like that. And there's similar, you know, style guides for user interface for like web design and for various other products. So You know, for— this is especially true of MVP where the whole goal is to, you know, to get enough adoption so you can actually test out like core assumptions or invalidate those core assumptions, that you try to use as many of these like generally known things as much as possible. So, you know, hopefully that answers your question. You know, Dennis asks, Ray, by the way, if you feel like you want us to keep answering that question, just add some follow-up in the chat room. Dennis asks, what's a good example of a user story? There's lots of different ways to do this. In my opinion, you basically start with the customer archetype. So the customer archetype generally is the person that's going to pay you. Generally, I mean, let's just use a B2B product for the sake of this example. Dennis, if you're doing a B2C product, feel free to kind of like, uh, talk and put it in the chat room. We can address that maybe, uh, as well. Uh, but if it's like a B2B product, you start with the, the customer archetype. This is the person that pays you, right? And, and, you know, how would they use that? Um, and you said you literally write it out. Uh, meet, you know, uh, you know, uh, Jessica, right? She's, uh, age you know, 34, she's a product manager at Google, and, you know, she, every morning she goes and, you know, accesses feature X to address this thing. After she addresses X, then it notifies other stakeholders in the organization that feature X has been used via email, via text message, whatever. And, you know, then once they receive that, then they let her know in exchange. So I just made this up right now, just kind of riffing off of it, but basically that's the level you want to get to because then it eliminates any sort of communication issues potentially with the, uh, with the developer. Also, this is a good opportunity for developer to ask you more follow-up questions that you can answer, right? So if you could just if you could just basically kind of like write out like literally like the story of how this would work. Um, I, I like, you know, like bullets, like step by step, like step 1, step 2, step 3. But, you know, it's up to you, like if you prefer to just kind of write a block text of what that would look like, that's a really good way to, to kind of show how that, how that would work. Uh, if you have screenshots or anything like that, this is a good opportunity to use that. Or, or like we talked about earlier, you know, like take a picture of the wireframe that you, that you wrote out and just throw that into the Google Doc that both of you are sharing or whatever tool you're using. So do you have any—

Yes, adding to Dennis's question, so when you talk about user stories for a product, it makes a lot of sense to always define personas. So you see what all are the, what do you say, customer segments you have and try to define a persona in each of the segments. You build a story around them. So as you said, So there is a person called Adam who is working at Sensor Company and he does this. So you define, you imagine the entire life of the person and you make sure that this is communicated to all the users. So, I'm sorry. So if everybody in the team knows who Adam is, Everybody in the team knows who John is.

Got it.

And now when you're defining a story, a user story, you're going to say Adam should be able to send a message to John. So that actually gives you a lot of context into what you want to do. So there are two ways in which you can define user stories. One way which most of the people do is something like, as a user, I should be able to do something. This is a standard template which most of the people do. So you're defining what is the role of the user who is doing the task and what needs to be done. And sometimes you also add what is the value you're getting out of that.

Got it.

So the task could be, as an administrator, I should be able to invite a user so that they can come and join the system. So here you're defining the entire story. This is one way of defining user story. And another way of defining users, which I generally prefer, is using personas. So when I say Adam should be able to send a message to John, everybody in the team knows exactly what is happening. And just imagine you're having a discussion sometime after a couple of months and you're talking about the issue and you don't have to say, okay, let's log in as user 1 and see his login, then send a message to user 2. And you have real people in your minds. You say, okay, John has come, he is logged in, now he has sent a message to Adam. It will be much more easy to communicate about this. So I would say personas add a lot of value when it comes to the user stories.

Yeah, got it. Rafael asked the question, what evidence do you want to collect to measure customer satisfaction in your MVP? Rafael, please take a look at the link that Mark shared in the chat room. You know, we'll reshare it again. This is like very detailed about how to think about getting to product-market fit, and this is— they actually use an example of a company, but generally, you know, you want to ask questions like, how would you feel if you could no longer use my product or product X? You know, you would be like, you know, upset or unsatisfied, that would be answer A. Answer B would be indifferent and maybe C, I wouldn't care or something like that. Right? And then if, unless, you know, 40% of users would be like very disappointed that they don't, they can't use your product any longer, you still have work to do. Now, there are other questions that you could ask to try to better understand it. So usually I would send this out as an entire survey with 2 or 3 other questions such as, you know, how likely are you to recommend this to a friend? That's a classic NPS question. I would also ask another question such as, you know, what type of, you know, user or what type of customer would use this product? And the good thing about that is, is that they're either going to tell you that it's their kind of business, or their— which is, that means you're at least on the right path. Or they would tell you that something completely different, which means that you're completely on the wrong path. So that also, you know, is another helpful thing. And Uh, you know, there's various other questions as well, but if you could just start with that and also read the article that we shared in the chat room, I think you'll be like really well on your way to, to, to making this better. The, the most important thing, Rafael, is to, is to just try to do this in cohorts. Um, because once you basically surveyed like the 50 people that are using your product, 10 people, whatever it is, you don't want to go back to them and resurvey them again. You want a fresh set of data so you can see that you can, uh, if you're doing, if things are going better for you. Another thing that you can learn as well from asking that first question is like whether you'd be disappointed or not, um, is, is kind of like, uh, who exactly the customer archetype actually is. Because you'll be able to see that, oh, uh, you know, if I was to segment down this even further, uh, you know, right now only 15% of people are answering that they would be disappointed. But if I segment down this even further to project managers at Google who work on that, uh, you know, on AdSense, then maybe that number will grow to like 35% or something like that. And then all of a sudden you're on your way. So maybe that's the kind of customer that you should be focusing on. So there's like really interesting things that you can do with, uh, with that data. So hopefully that answers your question. Feel free to follow up. Uh, Mariah asked question is like, you know, what are some of the best practices for, uh, you know, like a documentation? And I assume that you mean by documentation for like a product spec or a feature spec? You have some thoughts?

I'm not sure if he's referring to documentation, I mean a feature spec or the code documentation. Okay. I think we better cover both of them.

Yeah, let's do that. Let's go start with the code documentation. Amraya, feel free to let us know if you want to chat about the code documentation or if if you prefer, about like the actual project documentation.

So there was a time when people always wanted to have thorough documentation of each of the functions you write, what this function does, what is the— what are the arguments going to be, what is output going to be. So it used to take a lot of time, and finally, if you take about 5 minutes to write a method, you're going to spend another 5 minutes in documenting the method. So long gone are those days. Now, if you're actually following a proper style guide, there is minimal need for you to actually document. So I generally, I mean, if you're properly following the style guide, that should save a lot of your time. And sometimes some of the modules might be really complicated, which are hard to understand. In such case, it doesn't harm in adding a couple of comments there, like why you created like this query and what is it actually querying.

For or something like that.

Exactly. And coming to the project documentation, as we discussed earlier, first the title of the spec, if it refers to personas, that actually gives you an idea immediately after you read the title. You don't have to go into the details. But once you go into the details of the document spec, it can be as detailed as you want. Like you said, if it's a bug request, a bug fix request, you can have a step-by-step process of reproducing the bug. And if you have a new feature request, you can just draw on paper and just attach the screenshots.

Yeah, I generally like to add, you know, at the top of the document kind of why we're doing this and what it is that we're doing, kind of like a brief almost. And then I like to— then I'd like to kind of define maybe who the actual, like, archetypes or the user archetypes or, you know, and so on. And then I'll go into the actual spec using, you know, different— using screenshots and/or pictures of wireframes and things like that. So those are just some of my best practices. Mariah, let us know if you'd like us to elaborate anymore. We're happy to do that.

It's a very valid point, actually. I missed that. I think that's the most important thing when you're writing a spec. It's really important that you communicate why building a particular feature. People know what, uh, I mean, why we're doing that.

Yeah. And, and, you know, and this is especially true with like remote teams, uh, because, you know, a lot of them want to help and they want to know and they want— they're pretty creative people and they want to be involved in how to do that. And maybe the solution that you may have thought about initially, uh, you know, could actually be optimized or improved in a different way. And so this is a good— the why really, really helps with that. That, you know, with that as well. Okay, so, you know, we've covered some of this, some of the construction part of the process, and then, you know, maybe we can talk a little bit about the iteration cycle here. We've got about 10 minutes left, you know, out of respect for everyone's time. This is, you know, we are going to end here at the top of the hour, so if you have any more questions, this is the time to ask them. So that, you know, we can get through them now. So maybe we can talk a little bit about like the iteration process and how do you look at it? Like what's the, like a typical iteration cycle from your perspective?

So it depends from team to team. I generally define something called a sprint. Sprint can be 1 week long, it could be 2 weeks long, it could be 1 month long. I mean, the team agrees to a timeline. And so every, at the start of every sprint, you have a sprint plan meeting where you have the— you look at the— so, okay, you see the availability of all the team members. Let's say there are 10 engineers in the team, which means we have 50 points a week. And if your sprint is 2 weeks long, as I said, it's 100 points sprint. However, a couple of engineers are off on for 2 days, and generally we have some urgent requests which takes about 1 day from each of the engineers. We account to all of them and try to see how many points we can take up the sprint. That's what we start with in a sprint planning meeting. And now we are assuming that the backlog column is already prioritized. So we start from the top, we start estimating.

So let me just stop right there. So that's your job, right? Like it's your job to prioritize what the backlog column looks like. So put at the very top, like the most important, what you believe is the most important feature that needs to get shipped, because that's going to be the number one thing that, that the, the development team will take up.

Yes, and the next step is you start from the top task and you start estimating. And when you start estimating, it's not one person who should estimate. The engineer shouldn't come and say, and say that, okay, this is going to take so long. A lot of, I think if there are 4 engineers, I think everybody should be given an equal weightage. Even if there is an engineer, one person shouldn't dictate. So one common practice we use to give equal weightage to everyone is placards. You have numbers in your hands, uh, 1, 2, 4, and 8. Generally, it's not a good idea to have any task which is 8 points. 8 points is 8 days, 8 man-days. Okay, so you have numbers 1, 2, 4, and 8. Uh, so when you see a task, you give some time for each of them to try to give an estimate, and then at once everybody should show a placard like this. So I show to you, show to, and probably Mark shows too, and we are in agreement. So no more discussion required, you just mark it as 2. And let's assume I say 1 and you say 4, and then we kind of try to discuss what's the difference, and probably I'm missing something, and probably you're overestimating something, and then we try to come up with something, probably you're right. So after discussion, we set up the estimate there. So this is how we keep estimating, and we keep estimating a task after task till we reach the total we wanted to achieve this month. Sprint.

Got it.

And that's where we are going to say, okay, uh, this is a cutoff for the sprint. The sprint planning is done. And, uh, yeah, and the work starts and the engineer starts working.

Now, now, you know, before we get into like the kind of work and all that, one thing that, that I recommend, at least from the product management's perspective, is, is that you buffer all those estimates. So if, if, uh, your, your engineer says it's going to take a day to do this, double it, you know, that way, you know, you know that you're going to be like at least buffering it enough so that all the stuff can get delivered on time, right? So if you're doubling the stuff and you realize that this feature is going to take 10 days, oh, maybe I should deprioritize it because of, you know, where we are in a project planning phase and things like that. So, you know, you know, make sure to buffer, you know, any sort of estimates that you get.

Yes, and once the sprint planning is done, then we are going to have a daily standup. So people keep working, every day we have a specific time where everybody is going to come down at one place and they're going to update. It's not just like, okay, I worked on this and I'm going to work on this tomorrow. So it's an open discussion where we would like to share what we did. So there are 3 things primarily which we would like to discuss. The first The work. Second is blockages, and the third is learning. So the work— what have we done yesterday and what are we planning to do tomorrow? So this is a general update which everybody should—

I mean, this happens every day.

Yeah, it should happen every day. So, and we want all the stakeholders to be in this meeting because you should have a visibility of what's happening everywhere. So this is about the work update. The second is blockages. And while I was working yesterday, probably I was blocked on something which took a while for me to figure out, or there was one particular piece of code which took a lot of time for me to figure out. So if I discuss now, probably I'm saving some time with the other developers, and probably if it's a serious issue, we'll schedule a fix for it probably next sprint.

Got it.

So these are the blockages. It's not just about coding, it's also about the customers. Probably, uh, you're working with an external API, you're not getting response from them, you're blocked on their response. So that's the time when you need to escalate. So product manager now comes in and escalates the issue with the third-party client. So that's the blockages. And the third and the most important thing, which I think is the learning part— every day people keep learning something or the other. I mean, it could be a smallest thing, uh, but sometimes if it's going to save me 5 seconds every minute, it's going to be huge for the entire team. So there are some— sometimes there are certain hacks which we learn and we share with the team. So these are the 3 things which I think should definitely happen over the standup. I would strongly discourage having any planning-level discussions here, and if you are getting in-depth into discussing any of the topics, you can say, okay, let's discuss after the meeting. Because stand-up is for everybody to be, and if it's longer, people are not interested, right? So you want to make it really, really quick. And any follow-up, any deeper discussion, you can have it as a follow-up discussion. So this keeps happening till the end of the sprint. Sometimes you can have a mid-sprint checkpoint where not all the engineers, but maybe the lead engineer and the product manager sits down and then have a mid- sprint checkpoint. That's completely optional. If you have a large engineering team, this is something which you should be doing. And towards the end of the sprint, you do, what do you say, a demo to the customers. I would say, okay, you do a demo to the stakeholders. It could be a product owner. You also want some of the customers to be in these demos. So you demo what all has been done in the past sprint and you collect all the feedback. It's very important to collect the feedback. Yeah, and this feedback is going to be the food for thought for the next sprint planning. So that is what we do. So first is demo and then you do a retrospection. So is there something wrong which happened last sprint? I mean, is there any way in which we can avoid such things? I mean, it's not a blame game, but it's a constructive thought process where you try to avoid whatever to happen now in the following sprints.

Got it. Uh, you know, Duncan asked the question, you know, any advice for non-technical product managers to plan the development roadmap and manage a team? And is there a software process to manage not just the technical aspects of the product but also manage the design and business size too, and to make sure everything correlates with each other? Well, I think, uh, you know, part of— if you follow some of the things that we discussed in this session, I think, uh, you know, you don't necessarily need to be very technical if you were able to communicate well. The problem that happens in most projects is that there's really bad communications, and as a result, there's, you know, timelines are not correct. So, you know, the first thing to do is, I would say, communicate often. At the very minimum, every day with your development team. Ideally, you know, possibly even a little bit more. More. Second thing is make sure you set up a tool or process like Asana or Trello or anything like that, just so you can be able to have visibility into what's going on. And then if something gets delayed, which inevitably happens in software development, you need to understand why, right? And over time, you will get better at understanding how legitimate that why is, you know, as you continue to keep doing this. Like Is that true or not? Because of that, you can then start to estimate, okay, well, this is going to take an extra 10 days to do this. I'm going to deprioritize this feature and maybe do something else because our goal is to basically ship this on time. Those are some of the things you want to think about when you do that. In regards to a lot of the design and the business stuff, again, You know, uh, the— we, we kind of talked about the business stuff, right? Like, the, the business stuff is to try to get the product out, uh, usually quickly so you can get— it can get validated, um, right? And so, like, you know, you essentially have, like, a few dials that kind of work off of each other, right? Like, you have the time dial, right? You have, like, uh, you know, like, the— I guess they want to call it, like, the quality, uh, like, the quality— the quality dial. As well. And, and, you know, the more time you put in, right, the, the, the higher the quality. But if you want to like reduce the quality, you can like, you know, reduce the, reduce the time as well, right? And so those are the business decisions that you can make using this framework, if that, if that makes sense, you know. And, and real quickly, uh, you know, the design— I mean, the design and, and the software development should be kind working together all the time, all the time, right? Like, you bring this out, you put it in front of a customer or two or multiple, you figure out what's wrong with it. It's like, oh, they're, they're touching this wrong button, they're not, you know, this is not working correctly, right? Uh, you know, you can use analytics tools like Mixpanel and so on, and you can literally track like all the button clicks. And so you as a non-technical person can just open up Mixpanel and be like, okay, the, the user is going through this flow, they went and logged in, they went to this screen, they went to this screen, and then they, for whatever reason, it fell off. Then you take, you know, then you go back and say, okay, what's wrong with why they keep kind of falling off? So, you know, then you can use those decisions to, to kind of help, uh, you know, guide the development team and do that, right? And so, like, you know, back to the business stuff, ultimately the goal is for you to get this in front of customers and ideally have them get you to— for you to pay them or for them to pay you, right? Uh, and so, uh, you, you know, you need to get this out as quickly as possible, uh, so that you get to the point where they will do that. Hopefully that answers your question. So we've reached kind of the top of the webinar. If there's like any other last final questions here, we can answer another question or two. If not, we will adjourn. So I'm going to give you all maybe like another 5 or 10 seconds to see if there's any other questions that we can answer. And if not, if you have other additional questions, that we haven't been able to answer, then feel free to email grads@fi.co and we can definitely help you. And, you know, if you need, you know, technical resources that can help you as well, you know, BV's firm Codestra does a really good job at that and we can make an introduction as well. They have worked with a lot of grads as well, so we're happy to do so. Well, BV, thank you so much for taking the time out of your busy schedule [FOREIGN] To the Founder Insights podcast.

If you want to learn more, check out fi.co/podcast or sign up for our newsletter at fi.co/subscribe. Thanks.