Startups & Working with Developers, featuring BV Satyaram, CEO of Code Astra

The following is a transcript from a Founder Insights podcast episode – these transcripts are produced by a third-party natural language processing algorithm, and are not checked word-for-word by humans for complete accuracy—so, there may be some errors or typos. You can listen to the podcast in full, embedded below, or subscribe on Apple Podcasts or Spotify to never miss an episode.

Dustin Betz  0:01 

Alright, thank you everybody for joining us. This is Dustin. I am your podcast host and producer. Welcome to the founder insights podcast, a coach Mike episode. I'm joined here by Mike Suprovici. Hey, Mike. Hello, everyone.

 

Mike Suprovici  0:15 

It's great to be back. Just as a quick introduction for those that don't know me, and if this is the first time you're listening to the podcast, my name is Mike. I lead the alumni success group here at the founder Institute. Prior to this, I was an entrepreneur just like you basically been through all the all the all the worst or worst stories that you probably have seen. I've probably seen them myself. I also manage a portfolio of 4000 companies here at the founder Institute. So it's likely that I've also experienced from a second hand I guess, from a founder some of the challenges that you may have seen so I'm here to share my knowledge in any way that I can. All right, yeah. And we're also joined in the studio today by our expert developer bV Do you want to give a little intro on yourself BV?

 

BV Satyaram  0:59 

Yeah. Hi, Hello, everyone. Thanks for having me, you. I'm BV I'm the founder and CEO of Code Astra. We do software development, predominantly for startups. So before starting this, I mean, I have a software development experience of about 12 years. So I've been full stack development, manage a team of about 40 engineers with a couple of products.

 

Dustin Betz  1:27 

And that's Yeah, and that's what we want to talk to you today about is best practices for basically working with developers. And you know, Bv is sort of our our in house expert, along with Mike who they do a lot of our products and software development work for the founder Institute. So I guess we kind of just want to dive right in and talk about, you know, different development resources. And I think like at the most high level, we want to talk about the difference between working with in house developers versus working with outsourcers, so to kind of cue it up.

 

Mike Suprovici  1:56 

Yeah. So at the startup stage, you know, the whole Entire, like in house first, outsource developer is like an interesting, very interesting like, like kind of like debate and you hear opinions about it all over the place, but just know that there's no one right way to do it there, it just kind of depends on where your businesses and what your abilities are to basically recruit. So in house, the way we're going to talk about in house, like moving forward for this podcast is these, these are folks that you've been able to recruit onto your team, whether it's as an employee as or as a co founder, okay? You know, and we're going to talk about, like, you know, you know, outsource as basically like someone that you've kind of hired on either as a contractor or some sort of contracting firm, and they're not necessarily part of your team. This is just one of the projects that they kind of work on. Alright, so those are just two different, two different approaches, and neither one is better, right? You hear a lot of, you know, information about like, Oh, well, this one's better for It just depends on the company and what you're building. Okay. And in some cases, you know, it does make sense for you to have somebody in house. And in some cases, it's okay for you to basically use use a use a contracting firm, depending on a use case.

 

Dustin Betz  3:16 

Yeah. And so I think we want to kind of go through and talk about the pros and cons of basically working with an outsourcer and talk about it that way. So I mean, to just kind of pose the question, you know, what are basically I guess some of the cons right to working with an outsourced team?

 

Mike Suprovici  3:33 

Yeah, so maybe I can I can start on this. So just a quick background, maybe I should talk about this in my introduction as well. So I I have been leading product development teams for over 10 years, I've launched six successful products before joining the founder Institute. I also lead product here at the founder Institute. So I've kind of seen all of it like whether it's co technical co founders, hiring engineers, working with with with contractors, as well as I've kind of been explosive on All sides of it, right. And so, you know, one of the cons, I guess, of basically using a, let's call it like an outsource, outsource farm is that, you know, they're, they're not there with you necessarily every day, they're not necessarily part of like, the actual, like mission of the company, right? unnecessarily and that's that could actually be okay in some cases, you know and and as a result of that they're also just, you know, going to be basically kind of focused on kind of building their business right and sometimes it's delivering a product for you sometimes they may have other clients that they need to develop, develop for. So things like that, no bvd of any any cause on your end and you can kind of think of,

 

BV Satyaram  4:40 

yes, one of the major things I generally see is different business philosophies. So that that's one of the major things which you need to look at, you need to look into a firm which is in line with your philosophies and they understand your product and

 

Mike Suprovici  4:53 

their life. Yeah, that's a super good point. You know, because if you know if they, if you're basically like, using agile terminology which we'll talk about maybe later, which is essentially iterating. Very, very quickly and generic kind of doing like waterfall or some other type of method. It's just not going to work with, you know, your, your process as well.

 

Dustin Betz  5:11 

Yeah, but there's some upsides as well, right? Especially for, you know, early stage founders or if I'm not technical, right, so like, what I guess there's what are the pros that come to mind of being able to contract with somebody externally? I guess.

 

BV Satyaram  5:24 

Yeah, there are two major pros here. The first is a cost and the second is the ease of hiring. So because you don't need to have an engineer at your place, you can actually hire from a place where it's not very expensive, as expensive as here and probably, you can find better talent there most of the times. So that's one thing and the second thing is when you're hiring someone in house, you need to go through a thorough process, make sure that he's the right person, because you're going to retain him for a while. So all the hiring pain is gone. And you you you can try out someone for a couple of months and if you don't like probably cannot This make a switch of handling planning outsourcing foam.

 

Mike Suprovici  6:03 

Yeah, it's true, it is a little bit quicker from that perspective for particularly for those of you who are working in the United States, but this is also the case in many other countries, right? There's a lot of laws and regulation around employment versus you know, a contractor with the contractors generally a little bit easier to part ways essentially right there's you know, there's there's no severance costs, things like that. Unemployment like things like that, right. So that's, that's definitely that's definitely a benefit. Another benefit to is, you know, just being able to find people to based on their kind of like, their portfolio and things like that and kind of match it with like your, your style, right? Because a lot of folks kind of like advertise for this you can find multiple people that can make sense for what you're doing and you can basically get them to do it like right away, you know, so you know, that's that's also like another pro of using and so you know, the world I would like to Yeah, I tell startups to think about it, just think about kind of like, kind of like the type of business that you're building, right? Like, if you are a purely and I mean purely product business, and everybody thinks that their product, but they're really not, if you're purely product, and the only way you're going to succeed is basically, based on just like the product that you build. Well, it's very likely that that needs to be part of your core competency as a team for the founding team. Like I would say, at the very minimum, you should probably have a product person on staff, ideally, also, like an engineer as well, like that's on working together, probably the same room to try to kind of think through this, right. So what's what's an example of a product product like this, like, you know, a social network, right? Could be one of them, right? Which, you know, you probably want to kind of develop this way, you know, and you're kind of like going to live and die by, you know, your, your, the user, like experience that you're doing, and you're gonna have to iterate on that very, very quickly. But there's a lot of other companies out there that have a product But they're not necessarily like product businesses, marketplaces a classic example of this, right? Like, if you're building a marketplace, and I've used this example, in previous like podcast too, but like, if you're building a marketplace, you technically don't really need, like, a product to even do the marketplace, honestly, right? You can just start facilitating transactions, like, Hey, you got this thing to sell, I go find your buyer, and you go ahead and do that you can do that without a product, you know, I mean, and so that's, that's mostly like an offline business and the product kind of helps, you know, you just need some kind of something to kind of show that you're there. Right? And so in that case, you know, maybe it's not as critical at least at the early stages for it to be like the number one like core competency of the company essentially right. So just just kind of something to think about, you know, as you as you build your business.

 

Dustin Betz  8:47 

So for those kinds of businesses that you know, the core competency is not the product itself right so like like a marketplaces, the example you use, what are the kind of the ways that we can you go about engaging with it and outsourcer development firm, you know, basically like, how does that contract? Come come to life? You know, what is the normal email correspondence that goes back and forth? Or you know, kind of how does setting up that relationship work?

 

Mike Suprovici  9:13 

Yeah, maybe I can talk about sourcing, and then maybe you can come in and talk a little bit about like, the other side. And when somebody like, like me, or someone kind of engages you tries to engage you, right? So, you know, from from a sourcing perspective, it's very, very critical that you use, you know, trusted sources to get in front of people, right, because there is real risk of not only you losing your time and your money with regards to this, but just possibly even some IP related things as well. So you definitely want to come through a trusted introduction, if possible, right. So, you know, if you're a founders to alumni or founder, for example, like we have a series of folks that we know have done extremely good work for our community and we can basically you know, we You know, connect you to those folks. Another way is to use a like, you know, certain marketplaces out there that basically specialize in this. So for example, a good place for this is someone like a top talent, right? What top talent does is that they put engineers through a pretty rigorous process to basically ensure that they're good fit, they actually give you an actual recruiter, and they basically make make sure that this is like a good fit. So, you know, you know, maybe if I was to take a step back, like you should also kind of understand where you are in your, your core competency of as far as evaluating talent, right. So like, if you're a founder that has never built a software product before, you know, I certainly recommend that you basically go through a process like like more like like a top towel or something like that, where you can literally match it with the type of person that like makes sense, or some sort of like a good recommendation of where you can find a development shop or an engineer that has worked with founders that basically don't know what they're doing. This is just like some of the basic founders that don't have never built a product before. Now, if you're like a really good product manager, or even an engineer yourself, and you just need some help to basically, you know, outsource some of the non core work of your, of the things that you're doing, then you have a little bit more leeway there, right? Like you, you were able to better spot and identify talent through resumes and other marketplaces as well. You know, and then, you know, maybe, you know, vvv, can you maybe talk a little bit about like, how you think about, what are some of the things that you think about when you're trying to engage with like a particular person, if this is like a project that even makes sense,

 

BV Satyaram  11:37 

I really like what you said about having a trusted introduction. That's really important because one of the cons which we did not discuss about outsourcing is data theft, which is a big deal for some of the companies. So I mean, of course, you can always have legal documentation done there. But always having a trusted introduction is a good idea. And in addition to that, I going Back to whatever I was saying about the matching of the philosophy. So it's important to find a company which actually is in line with what you think. And also the, what do you say? The technology, the tech stack they're using probably is in line with what? what is needed for the product

 

Mike Suprovici  12:17 

there. So how do you how do you interview the potential customer? Because I'm sure you do a lot of that, too. When you have a lot of potential inbound customers, you want to make sure it's right, the right fit, you don't want to waste resources, because otherwise it could be a big mess. Right? How do you do that? How do you think about like expectations and stuff like that?

 

BV Satyaram  12:34 

Yeah. So that that's one of the major things which we do because generally, we take up about less than 20% of the projects which we generally come across because we we have a limited set of engineers who really good so we want to give prizes, which are really interesting, and which are guaranteed to succeed going forward. So one thing what we do is we try to understand the product, what's the status of the product and do they really need interesting So for example, very recently, we were talking to one of the clients who were like, Okay, I need to be engineers for like four or five months. Let's get it in engagement. It was because she was dirty jumping into the cost. What is it? Wait, hold on, hold on. So let's, let's, what what is the product about what do you need this and then we, we finally understood that she actually doesn't need full time engineers at all. She just needs some Google documents for automating everything. And we ended up with the, I mean, it was a failed relationship where we set up some documents and done. So yeah, so some of the founders, they actually don't know that they need engineers. They just think they need engineers, and they go with hiring. So that's something so we see they actually need engineers, and then what's the product they're trying to build? And so some of sometimes there are few tools which are available on in already, where you don't have to reinvent the wheel again. So if there are tools like the vj can leverage on so probably you can do with that. So going with the marketplace example you're talking about one of my friends wanted to have a car rental product built. And then there was already a service existing for something similar. So we just set it up and it was going well. So again, so what is it is we do full stack development so what we look at is we kind of look at founders who are really passionate who understand the product and who actually need custom product development it quite for them.

 

Mike Suprovici  14:31 

Yeah, that's interesting. You know, I like to also just dive in a little bit more about you met you said this really interesting point around like, you know, is the project interesting enough for like the talent right? Can you talk a little bit about that like, like the talent and like their work capacity and how they engage with the project and things like that based on like, just the type of project it is and things like that and why why that's important.

 

BV Satyaram  14:55 

So to speak specifically about the engineers we have in onboard so all our engineer From IITs which are like, you can consider them as a cream of the talent. So they're quite expensive. And it's really important for us to give them interesting projects to retain them on board and any project you give me, each engineer is equal to like four or five typical engineers, which you find. So forensics become a real big challenge to actually do them interesting projects. So to give an example of a project, which is not interesting, would be a typical project when someone comes in and says, I would like to have a social networking site with no direction actually to be very frank. So a better way to say that is okay, they would like to have a social network which influences ABC, and then you are actually married to the idea so two people actually understand what the product is doing. So we would like to actually take projects where we understand where it's being influenced, and

 

Mike Suprovici  15:55 

otherwise really seems to be like really important also, just for even though it is a contractor. That is So they stopped to want to, like want to work on this. And otherwise, you're just not going to get like as high as high capacity potentially. Right. And so as a founder from a founders perspective, you know, you really need to, like, think through, like, why this is important, right? And why this is valuable, even when you're trying to work with potential contractors for your project

 

BV Satyaram  16:19 

x. That's correct. Yeah. So introduce understanding where the product is being built, that that's really, really important. Actually, that gives the project really interesting. Yeah,

 

Dustin Betz  16:30 

it sounds like from the founder perspective, to like, having a real clarity for what this product actually is, is a challenge that, you know, you see on your end is founders coming in, and it's a little ambivalent are not quite clear, you know, what, you know, they they're in a ballpark of what they want, but it's just not specific enough. So in terms of like, communicating and planning and working with an outsourcer I mean, what are the kind of so I know like, there's things you know, specs wise. frames kind of how can founders help, especially if they're non technical, they don't come from the product management background, what are kind of the tool kit that they can use as non technical people to communicate that vision? You know, to you, and this

 

Mike Suprovici  17:13 

is super important. You know, when I look at the sun, you know, just from our end here is the alumni success group, we work with a lot of founders. And I would say that every single time that a project doesn't work out, and it causes a lot of pain on both ends, by the way, not just the founder, but also the vendor, right where nobody's happy where this is basically a big mess. It's because of this what we were about to talk about right now, you know, because either expectations weren't set correctly by both sides, or the communication, something was lost in communication, or there was a tremendous amount of feature creep that wasn't accounted for and it was expected as part of like the initial bid and all this other stuff. So like if I was to kind of summarize Like the most important thing to like successful a successful relationship with like an outsource or not outsource outsourcing vendor would be like, incredible communication on both sides, really. So that's part of what you should be testing for when you're actually interviewing folks, and they would appreciate it too, for very, you know, for various reasons, right, like, you know, especially if they're like, let's say, let's say, there's a timezone difference, right? If you don't get back to them that day, then that change could take another day or another day after that, to get fixed rights, and all of a sudden, your schedule just slipped by, like two days, because you didn't make that, you know, make that change. So, like, you know, you know, we can talk about some tactical stuff I just wanted to use as an example why communication is extremely important. So, you know, if you take anything away from this podcast, right over communication is key in working with any sort of vendor actually with anybody in your company, but in general with like, especially Turn the remote not with you over communication. That way, you know, the expectations are set correctly.

 

Dustin Betz  19:07 

Yeah, and there's different ways to kind of control your scope, right. There's like time versus project based billing. I mean, what are sort of, I guess, to get a little more in the weeds, you know, what are kind of ways that the non technical founder can be be efficient at communicating in this way?

 

Mike Suprovici  19:26 

Yeah, no, I agree with that. So, you know, we talked about, you know, like, Well, the first thing I would say is, and maybe we should go down in this and talk about this, like tactically, right, like, number one, how do you communicate? Well, you should definitely have some sort of a spec. Right? What spec means is short for a specification for your project, which is essentially what you're trying to build. Right? You know, vv, correct me if I'm wrong, like, how many projects do you start on? I don't have a spec.

 

BV Satyaram  19:53 

Many excellent, but we really help the founders come up with the spec, but that's the first step we need to hear. Okay. As you said, most of the founders come to us without any spec. But we really want to start with that.

 

Mike Suprovici  20:05 

Yeah, you can't. So in other words, you can't start a project without a spec. Right? Yeah. So what are some of the most important things that you like to see in like a spec that will help you kind of really define a project possibly even bid on it?

 

BV Satyaram  20:17 

Yes. So let's look at this in terms of the lifecycle of specification of a project. So first, we start with a documentation of what you would like to have. So probably you you have some inspiration. So look at this could be the product. So that's what we generally start when we write a score, we generally kind of have a screenshots of Okay, we take a screenshot from that particular product, it's okay. It could be something like this. So, I mean, it needs to be on a document per se, it could be new mine too. But you start with documenting what are the list of the features of kind of things which you'd like to have and then you put them into life by drawing wireframes so when you draw by friends, you could use tools like balsamic which is available, or you could even use paper prototype, which is something which I use video Often, which is really fast, you can always discard things and draw something pretty quick. So I always go with paper prototypes. That's the best way of communication. With prototypes. The key is to not have details there. It's all about the user workflow,

 

Mike Suprovici  21:16 

black and white man, black and white. That's what I always tell people to

 

BV Satyaram  21:19 

black and white big boxes, no text, that's all. So that just explains you, what's the workflow going to be for the user. And once that is done, probably you can have a designer or you yourself can act, I mean, you can have multiple wire frames, and then you can decide on one of them and then probably add more details to have some text and property. So then you can add some text. And that's when the development starts. And even when the element says you're not just going to give the entire thing it's okay, this is what needs to be built. You need to break this into bigger features, more user stories. So what I would say is, let's say you would like to build for an example social networking site So if you want to break that into multiple modules, I would say chat is one functionality and user follows a user friend requests is another module, and probably photo album season of the module. So I'm loosely using the term module, but better use I mean, best term to use here is epic. So in Agile terminology, it's called an epic where it's, it's a collection of Biggers. I mean, it's a big feature, which itself could be called as a product. So you divide your product into epics, and then you break down that it is smaller tasks, you call them as user stories. And we are not calling them as tasks. We're calling them user stories, because you really want to understand how the customer is going to use them. So the way you define user stories is, as a friend, I should be able to send a message to another friend something like this. So you You're going to define who is going to use a product? Or who's going to use this particular feature on this beach? And what are they going to do in this speech? So you're going to break that into multiple user stories.

 

Mike Suprovici  23:11  

So let's do that. So let's do it right now. It's actually not about it. That's a really interesting point. So let's take, let's take the login flow, would that be considered an epic walk in flow?

 

BV Satyaram  23:20 

Yes, that's an ideal example. So when you take a login, so first, you can, you can clearly see that that can be broken into sign up in signing and forgot password. These are the three things. So the whole login is going to be an epic, you can call it authentication. And then as a visitor should be able to sign up to the application. That's one user story. And then you can add some wireframes into this user story saying that okay, this is how the page is going to look. You're going to have username password fields Submit. And then if the user enters wrong, password or user resolved any interest system in here does the email, you're going to show us a message. So that is one is a story. And you an existing user should be able to log into the system. And then the vfm, show a username and password, you signed up into the dashboard. And then someone forgets you, a user should be able to recover their password. So these are kind of user stories for authentication. Epic. That's super interesting. And

 

Mike Suprovici  24:23 

that's actually really helpful because many, many applications have this exact workflow right? So you know, in you know, you were talking about communications doesn't like one of the things we do here at a fire and I've basically done throughout my entire career is that I use a some sort of a scheduling tool like in this case, I use like a SATA. And we'll have a column for epics, right and then a column for like, what we call like sprints, which is what we're going to do this week, right? And we basically break down each feature using more or less a user story, more or less, right? It's not it's not a, like a like the classic way But it's pretty much the same concept is what it should happen, you know, things like that, and you kind of see the, the project's progress, because then you know, the next stage of the project is in development, right, then, you know, the next day was what do we have a BVs, QA, I think, right or something like that, then HQ sign off, which is us. And then we basically push it into like, you know, production, right. And, you know, back to like the communication, which is how this started. Everybody that's involved in this project understands where the project is, what the what everybody's working on, and what how things are progressing. And if things aren't progressing fast enough, it gives you an opportunity to figure out why the schedule is slipping. It's like a, you know, Bv, what's going on here. It's like, Oh, we ran into this thing. When we did this, you know, re architecture of this feature. It turns out, there's more complicated and it's actually added another day and a half of development, right? And then you know, what's going on, and then you've kind of like budget, what's going on there? Right? And so that's why it's like really important to use a tool to basically communicate about kind of how the epics are going how to each each user story within that, and so on, you know, so you've got like the spec, and then you basically have a tool to basically kind of try to manage through through that spec, essentially. Right. And then I would say like, the last thing here is, you know, we like to use slack here. But whatever tool it is, one of the things I found really helpful with remote users, remote teams in general is just scheduling a time every single day, we will know that we will be on there and we just talk and we just say hello, even if it is maybe like How's it going? You know, but in general, like, you know, we don't generally talk about features, right? And your goal is to ensure that you answer all those questions at that time. I don't care what's going on. I don't care what's going on in your life. I don't care. Like if you got other things, get that done. Because remember, if you're working with people that are different time zones, and things like that, it could be like a 24 hour cycle. So if you don't get back to people as quickly as you can When we can, then you can introduce a nother day, possibly two days of slippage in your schedule. So you just want to make sure that you answer all the questions as detailed as possible so that things can move forward. You know what I mean? You know, and so just keep that in mind.

 

Dustin Betz  27:15 

Yeah, it seems like that kind of communication is really, really critical, I guess kind of other interruptions can can happen to in Agile development and, and, you know, whether you're testing like some kind of new integration, or there's slow feedback, like all of those things, I mean, it's all comes down to, you know, being able to communicate, yeah, and

 

Mike Suprovici  27:36 

the idea is, is to make sure that you don't have slow feedback, right? Because slow feedback starts to get make it percolate its way through the entire project. And eventually the project doesn't end on time. And everybody's like, Wow, I can't believe this feature got delayed by two weeks. Yeah, because we the the feedback wasn't fast enough, right. And so it's really important for you as a founder. This is how you able to use basically like outsource, develop The team to basically help you get to the product fast it's like okay, I got this build from the developer boom I got to go out and show it in front of a customer like right now and let's go see what happens Oh customer did this at this you know let's go ahead and try to improve this feature and things like that and just kind of get into like the cycle right and the more you scheduled times the faster your cycles are going to be if you know it's every single day you have this one on one with with your developer that means that the first thing in the morning you need to do is you to talk to your customer so that you can get all this information right before your meeting right and and that's how you start to create kind of like this like very rapidly like evolving kind of process with with the team that's maybe not there with you.

 

Dustin Betz  28:39 

Make sense? BB What are we forgotten to talk about? What are there any other best practices that come to mind that we

 

BV Satyaram  28:45 

Yeah, we don't know what's speaking. So we we talked about our break into epics and then introduce the stories. One thing which we missed it somewhere in between is about the estimations. So before we start the development, we really need to estimate each of the story On how long it's going to take. And in general, we need to account for a bit of a buffer in general, because there is always some feedback cycle involved here. So that's one thing. And then we have, what we generally do is going back to what Mike was telling. The workflow varies from team to team. But the workflow which we use is we have a column called ice box, where any new idea we get, we just dump into the ice box. And then any user story which we think is needed, which makes sense, we pull them into the next column called backlog. backlog is always a sorted list of user stories with the highest priority top at the top and lowest burden on the bottom. So in the next story is working on or current activity. So if I'm an engineer, if I don't know what to do if I'm done with a task, I don't, I don't have any condition of what needs to be done next because I just think verbatim from the backlog, just pull it and start working on that. So when we are pulling an item from icebox to backlog, we generally try to estimate the task, trying to see how long it's going to take. And then every week we have a sprint plan meeting where we try to see what can be achieved in this particular week. This could be one experiment could be two weeks, it could be one month sprint, it depends on team and the pace at which the product is moving. We usually have a one week sprint. So let's say there are four inches working on your team. And so for engineers put together it's about 21 days. So you try to schedule 16 days of work here not many days because generally we lose one or two days in trying to communication and some of the what is hybrid bugs which will block the development here. So we from the backlog. We have already submitted the tasks will take the tasks which account to about 16 days of work and Pull them into the current sprint. And then we take task by task. As we keep doing, we move, we move into the current, we work on that. And then we move into QE, where a test engineer looks into that and tests and make sure that everything is according to the spec. And because we work remote, we have one more QA section, where is client Qa? Here we have HQ QA where, once that feature is tested, we deployed to a staging environment and then move into HQ sign off where the client actually or you, as a founder, go through that and then see if it's according to what you wanted it to be. And once that's there, you can say okay, it's alright, it's ready to deploy. Then you move on to the next column called ready to deploy. And then we make it as release and deploy probably once a week or once a day. It depends, again on the pace at which we are moving. That's a cycle

 

Mike Suprovici  31:54 

you're in. I'm really glad you brought that up as far as the estimation because as a product manager, that's kind of what One of the main things that you have to do, and so you wanted to things that the rule of thumb that I generally live by as a product manager here is like, you know, I just generally try to double every sort of estimate that that we get from, you know, from any from the engineering team, mostly because you know, what software, it's just it's it to a certain extent, it's really difficult to estimate things until you really know the case. But it also buys us enough of a buffer to ensure that we reach things on time. And I recommend that you think about that as well as you kind of like start scheduling tasks of you, somebody says it's going to take a day just double that there's going to take two days. And then if you are seeing a lot of slippage, meaning that you know, the team is not making those estimations, so you've already doubled estimations, and they're not making them and then they're not making them on a regular basis, then you basically have a problem. So the way you manage through that problem is first of all you try to find out What's going on and why? Right now, assuming that you're not, you don't know what you're like, this is the first time you've built a product like this, and you, you know, never managed a software project before, what I would do is with those objections that you are getting from your team, is I would go and reach out to several of your advisors or people in the network that you know, or that have managed some sort of project and just say, hey, are these these legitimate? excuses, right? Or, you know, you know, that's kind of like a not a nice way to say it, but you know, I mean, like, these are just not, you know, these are not legitimate objections, right? Or they are legitimate objections, right. So I would do that is the first step. And eventually you will figure out if the if these are better, better, and you'll get your bearings, and you'll start to understand Yeah, this makes sense. This doesn't make sense. Now, if you see this pattern continuing, let's say this pattern continues three or four times, then that's a pretty good indicator that you need to move on. And you need to go on to possibly another resource or things like that, because you know, you if that's the case, if the It's more difficult for you to build even bigger features bigger, bigger, bigger things. And maybe this this person is just not a good, good, you know, fit for for the company moving forward.

 

Dustin Betz  34:11 

All right. Well, I think that's about all the time that we have to talk. But thank you, Mike mbv for talking about product development with us. And thank you to our audience.

 

Mike Suprovici  34:22 

Yeah, that was really fun. Thanks for coming videos. Really great.

 

BV Satyaram  34:25 

Thank you. All right. Awesome.

*  *  *

Graduates of the Founder Institute are creating some of the world's fastest growing startups, having raised over $1.75BN in funding, and building products people love across over 200 cities worldwide.

See the most recent news from our Grads at FI.co/news, or learn more about their stories at FI.co/journey.