Ep. #1084 - How to Build Software Faster

Matt Watson 0:00
And we’re back for another episode of the Startup Hustle. This is your host today, Matt Watson. I’m excited to be joined by David Subar and his company Internet. Today, we’re gonna be talking about how to build products, engineering, product management, how to build things better, faster, maybe cheaper as well, I guess save a lot of time, it will be cheaper. So excited to talk all about that today. Today’s episode of Startup Hustle is powered by FullScale.io, hiring software developers is difficult Full Scale can help you build a software team quickly and affordably and has the platform to help you manage that team. Visit FullScale.io to learn more. David, welcome to the show, man. Let’s maybe we can build something in this episode. I’m excited.

David Subar 0:39
Let’s do it.

Matt Watson 0:42
So you, you started this company? And in turn, what time did when did you start this company?

David Subar 0:49
About nine years ago? Okay, so 2013 ish.

Matt Watson 0:53
Okay, so So tell me kind of, you know, your guys’s expertise as being, you know, the chief technology officer or chief product officer or getting ready to work together. So, obviously, you must have a lot of background in that before you started this company. So tell us a little bit about your background before you. You started internet.

David Subar 1:12
Yes. So I started my career out doing research and development in AI machine learning in the military and think tank, DC. Wow. So we were

Matt Watson 1:23
now. Yeah, and then like, I don’t I don’t want to date you or anything. But that was a while ago, right? And now chat. GBT is all the rage. And that’s like, there’s been a lot of time between that. So you were doing this a long time ago was the point.

David Subar 1:39
That’s right. Well, so a couple. Yes. And like I was born a nerd, like I’m congenitally a nerd. Like, I can’t escape it if I want to. I don’t want to like if I wanted to, I could. Yep. And so I thought doing research and development in AI, and ml was gonna be really cool. And it turns turns out that doing the research for me, that’s so cool. Because when you do research, you’re writing papers, and you’re presenting the papers at a conference. And then you’re hoping the world is going to like, absorb that. Yeah. And it’s going to have some impact. And, and it’s not tangible for me. Like, I want to build things. Yeah, have an impact on mark. So that’s right. That’s exactly what I want to say. And so I went from there. And I was just like, not happy. You know, it’s like, I wasn’t engaged with what I was doing. And so I realized that there’s a big difference between science and engineering. Yeah. Right, I was doing

Matt Watson 2:42
you are, you’re way ahead of the curve right before where we are today. Like, what was? What was capable, then is nothing compared to what’s capable today.

David Subar 2:52
Right? That’s exactly right. And so I went from there. And I went to an AI tools Firm, where we’re actually building real products. And that was, for me, much more engaging, much more compelling. And so I was an engineer, then I managed groups, and I was director then I became CTO at a couple of different companies. And so like, I was like, on that path for building something that I could go, Hey, mom, like, this is what we did to change the world. And then I realized that product, the envisioning of what you’re going to build, and the actual building of it, those two things go together important in order to like, have that impact. So I went, I switched from there to product. And then I ran product teams, everyone product and engineering teams. And that’s kind of what got me to intern up because like, I got really engaged in what we build and how we build it. But at some point, like, it’s about building the team and the process, and the organization and getting people engaged in who we serve. And that’s what got me the term because I did that a bunch. I was like, that’s what I really like doing is building the teams that don’t progress to have that impact. And so that’s an internal like, that’s what we dive into companies, and we help them be more effective at building proximate move markets.

Matt Watson 4:12
So that’s, that’s why we’re lucky to have you here today. Right? You’re the expert at going into these companies and reluctantly was joking before we started I’m like, people must call you all the time and their common is always going to be please come to fix this shit. Like that’s, that’s the that’s the conversation right? And, and you have to go in and help them figure out okay, why aren’t they being innovative? How are they doing engineering? How are they doing product? How do we get everybody to work together and so excited to talk a lot about that today and hopefully he’s everybody’s getting some really valuable free lessons today. So, I guess, what, what are the what are the the biggest issues that you see like, you know, you get those phone calls and you you, you know, you talk to this you know VC back have, you know, Series C Company, whatever. And they have all sorts of issues with with building products? Like, is it usually the same pattern of problems? Or is it you know, three or four most common issues? Like where does this usually start? You know, when you dive in?

David Subar 5:15
Yes, so there are symptoms and problems. And those are different, so that the symptoms will get a call from like a CEO, who will say, you know, I keep putting cap on the property engineering and things aren’t getting out faster, or we’re just hitting scale. And we cobbled this together, it’s not never going to scale the way. So help us understand. And those are the symptoms, you know, sometimes the symptoms are, I don’t understand what CTO is saying, or we don’t get along, or product and engineering don’t get along. Those are the symptoms. And but we really tend to see the problems are is how are people focused? And what are they talking about. And so, oftentimes, engineers are focused on my job is to write really great algorithms that are, you know, scale login, and really elegant algorithms. And my job is to put out code for product managers might say, we do you know, we work with the UX people, we do specifications, we do user stories, and we have roadmaps. That’s what we do. And that’s where the problems often start. Is that, what who’s having what conversations about what, and one of the things that we typically have to say is, your job is not to build software, your job is not to build your store, your job is to ship a product. And so let’s focus on who we serve, and what they need, and how we’re going to ship the smallest iteration as quickly as possible. So we can start delivering value. And so typically, like agile development processes, think about this and talk about this really well. But very few people actually know how to do that. And very few people have the right conversations, not other, and then the conversation with the CEO, goes to, here’s who we serve, here’s what we’re going to build. And here’s why it makes sense for our company to do that. Here’s how we go the next step. And it seems like that’s not an engineering problem, to understand that, but the engineers can write code multiple ways. And if they have the context, they’re likely to pick the right ways consistently, they don’t have the context, which is I’m gonna build a code. I’m a feature factory, you told me what to do, I’ll get it done. Then they’re disconnected.

Matt Watson 7:49
So you think getting people, so so a lot of times it is you think it’s just a breakdown in collaboration and priority, like, amongst all the stakeholders, and the engineering team of just been really focused on like, what really matters and the order of importance and iterating to it?

David Subar 8:07
That’s right now, that’s easy to say. But then

Matt Watson 8:11
That’s it. We’re done. We figured it all out, guys.

David Subar 8:14
Awesome. Everyone’s got a unicorn now. Wonderful. Yeah. But it’s about: do you have the right people in the room? Are they organized correctly? Are their processes correct? Does the architecture support that? There’s a staple of team topologies that talks about organizational design around architectures, and that’s half the battle. But architectures have to support what you’re trying to do; that has to support who your users are. There’s this whole kind of a pyramid that goes from delivering value to execution And that’s what we think about that’s, that’s what often breaks down.

Matt Watson 8:54
Well, and in all of this, there’s, there’s some magic and having somebody that understands, like how things are supposed to be done. And like for example, if you ask me, like, how long is it going to take to build the Empire State Building? And how would you do it? I’d be like, I have no idea. Forever, it’s gonna take literally forever and billions of dollars, I have no idea. But if you have somebody that has done this kind of stuff before, they tell you like, Oh, don’t do this, you’re gonna save a lot of time, skip these steps, focus on this thing, get the thing done first, boom, boom, boom, boom, boom. And you all of a sudden, it’s like, oh, this seems easy. Now we know exactly what to do. And but most corporations like struggle with that is when I feel like like, it’s, it’s more along the lines of like, we need to build an empire state building, and nobody’s really sure how to do that. And we all just run around in circles. Instead of having somebody that understands, like how to cut through all of it and figure out like, No, this is exactly what we need to do. And we need to stop worrying about all these things.

David Subar 9:49
Yeah, and it’s that but it’s also going like, you know, we don’t know exactly what we need to do, but we know we’re directionally correct. Right, let’s build this small thing. Let’s let the market Tell us what it’s I forgotten the guy’s name? Who said this, and I apologize to him every year since it’s like, Don’t worry, be crappy. Right? It’s like, build something, get it out there. The advantage of building software versus building an empire state building is, you’ve got to get the design for the Empire State Building. Exactly right. Right. Build the foundation. Yeah, before you start, we can release fast.

Matt Watson 10:24
Software is much more forgiving,

David Subar 10:27
much more forgiving. So let’s take advantage of that, right. And let’s not assume our product managers are all geniuses because they’re not, right, it’s not a job, you can be perfect. So let’s ask them to be directionally correct. Let’s build quickly tasks quickly. And let’s build a team and organizational design processes that support that quick learning.

Matt Watson 10:48
So I, I do some consulting for a company that I’m a shareholder, and I sort of work like a fractional CTO for them for basically a few minutes a week. But I kind of felt like a fight with the product manager all the time, because he’s always trying to overcomplicate things. And, like once worry about every edge case. And we need to handle every scenario today. And it’s like, very frustrating for me, I’m always like, let’s just make this shit work and ship it, and then we’ll just keep improving it. But it’s like he is I feel like he’s putting like the Iron Dome over the top of it and trying to just overcomplicate everything, and just slows it all down. It’s like a never ending fight. I feel like it’s the it’s the it’s why they had this little bitty company, but they have the exact same problem you described. And they have one product manager, but it seems like he’s just always putting up these barriers and problems that prevent the team from just quickly iterating and learning.

David Subar 11:43
Right, right. And so here’s what I would say that personally, I don’t know who this person is, but it’s like, oh, you have this exactly right. Like, do you know this exact right? We’re gonna do this is gonna take us three months to build. But it’s exactly right. Let’s not waste the time. Let’s build it exactly right and be done. If you’re not sure. here’s the here’s the smaller case that the MVP often right. But here’s the smart case, I can get built in two weeks, or in two days. And we can get out and work it out. Well, we do that.

Matt Watson 12:15
Well, and that’s where I started with this thing is, the team originally thought it was going to take like five months to build. And you know, me and a couple other developers we all looked at, and like, you know what it seems like there should take like four weeks to do. And, and we’re actually doing really good, actually, the project’s almost done. But it’s very easy to actually see when you go through it, how people continually interject things that could slow it down. If you don’t have somebody experience that keeps like preventing all those roadblocks and distractions.

David Subar 12:45
That’s exactly right. That’s exactly right. And that’s, you know, this is where That’s where, being knowing how to cut, where to cut. Having some idea of being smart with the technology, and the market, and the business becomes really helpful. When I started my career, I was also the Maven perfect, right? Well, because I was an engineer, when I started, like, I just like, here’s everything, I just need to understand everything because engineers are really good at understanding data. But it’s really the information like, what do we really need to do?

Matt Watson 13:21
What we can do, you know, and as, as I’ve done this, you know, for 20 years now, and I feel like I’m working on a potential new startup idea now, and, and I don’t beat myself up about too much of it. Because I know that in the back of my head, I keep reminding myself, it’s like, it doesn’t matter what I decide to do now. It’s wrong. And I can spend forever thinking about it. But it is wrong. And we will learn what the right way was. But we will not learn that until later. And I think that’s the mistake that most people make is they get so paralyzed about trying to handle every single thing that they don’t allow themselves to learn later.

David Subar 14:00
That’s right. That’s right. They write they fall, they believe, believe the myth of every Apple product was perfect the day it came out. They believe the myth and so I have to be that way too. They believe the myth of I can just extrapolate everything and know what the market wants. The market hasn’t seen what you’re doing. They’ve never seen this before. So as soon as you put something out there, it’s changing what they want anyway. So if you’re, if you’re going to what the market currently wants, as soon as you release, they want something else because you’ve changed the market. When the iPhone came out, it didn’t have an app store. They only discovered one and after because someone hacked it and put apps in the iPhone. That wasn’t part of the plan. That was something Apple learned.

Matt Watson 14:55
Well, their feedback is going to pull them 100 different directions right and so Yeah, that it’s it’s a never ending journey of building software and and, you know, one of my favorite quotes from the movie The Social Network and I don’t know if Zuckerberg ever said it was like software is like fashion, there’s no final version. Right? And which is, which is totally true if it needs care and feeding forever. Once you go to build something it’s like adopting a puppy, you got this thing for a long time.

David Subar 15:27
That’s right. That’s right. And, by the way, congratulations, it’s always changing because then the market, you change the market, and it’s learning and it’s adapting to you and you have to adapt again, entrepreneurship is really hard. Right, all the easy stuff is already been done. There’s no value, and it’s all that’s left is the hard stuff. It’s gonna be hard, and the markets gonna change and you’re gonna have to change that if you don’t change, someone’s gonna do it. So expect like, you have to have an adaptive learning, product management engineering organization, by the way, adaptive learning product, major engineering, adaptive learning company, not just profit.

Matt Watson 16:06
So tell me this. You mentioned agile development earlier. Are you a big fan of of Agile? Like, don’t tell us more about agile?

David Subar 16:15
Yeah, so, So short answer is yes. I’m a big fan of sound. The short answer is yes, I’m a big fan of agile development. And, but there are many different methodologies. There’s Kanban, there’s Scrum. There’s, there’s, you know, there’s scrum bond, there’s XP, there’s, and you’ve got to pick the right tool set for what it is you’re trying to do. And what the point of all of these is, build and adapt. And these are different ways of building and adapting. And depending on what you’re the kind of thing you’re trying to do. It’s like, I don’t always use a ratchet wrench when I’m fixing something. And sometimes I need a screwdriver, someone’s the hammer, you need to know when you pull the ratchet wrench out which one you pull out, I want the metrics that I want that I want to the Imperial set, right. And so that’s, I’m a big fan of agile methodologies. But I’m also kind of picking the right one, but you need to learn the methodologies, the need to adapt it for what you’re doing.

Matt Watson 17:24
And part of that is you don’t need to do Agile, exactly the certified way that you know, agile is supposed to be done or whatever, which I don’t think most people do anyways, they have their own Frankenstein version of it, which is okay. But at the end of the day, whatever you call it, it’s all just about iteration, right? It’s whatever you call it, whichever the method is, you don’t need to do any of it perfectly. The thing that matters most is iterating. Quickly and getting feedback and just continually trying to improve.

David Subar 17:51
That’s right. And to your point is, people don’t use the Orthodox agile methodologies. Actually, every Agile methodology I know about you’re supposed to adapt it as well to your circumstances. Right? So even if you start at the Orthodox, Scrum or XP, or whatever you choose, you’re meant to adapt it to your business. And if you’re not doing that, you’re not doing it right.

Matt Watson 18:17
Well, since we’re talking about agile development, didn’t remind everybody that finding expert software developers doesn’t have to be difficult, especially when you visit full scale.io, where you can build a software team quickly and affordably. Use the Full Scale platform to help you define your technical needs and see what developers are available to join your team today visit full scale.io to learn more. So what are we talking about product? I want to talk about products and more. So some people may not really realize like, Okay, what does the product team do versus what does the software development team do? And maybe you could give us a little insight for those who are listening that or maybe we’re not experts on all this like, Okay, what does a product team do? What is the what is their role in this and how they work with engineering?

David Subar 19:02
So the the very shortest answer is product is what you’re going to do. And engineering is how you’re going to do it. The slightly more, the slightly more nuanced or detailed answer is product says, here’s the people we’re serving. Here’s the problem they have that needs to get solved. Here’s how we can solve it. And I’m going to say what the interaction I want to use just to have with the product. The engineering team then and I’m saying is if they’re two separate teams, the engineering then team says I understand what you’re saying the product needs to do. I’m going to write the code to make that do it. And I’m going to ship it, and then I’m going to put it up in for instrumentation it so we see it people are actually doing product manager what you said they’re going to do. Product is the what engineering is that the actual implementation now product needs to say, not just here’s the next feature. But here are the next three features report features, here’s the order we’re going to put them in. Because here’s what we think the market needs, here’s what our competitors are doing. I’m the CEO of owning value creation, for the market that we’re serving, but in fact, they’re there together. Because right, we ship a product together.

Matt Watson 20:27
So you think a lot of companies do you think a lot of company early stage companies struggle with? Maybe they don’t even know they have a product team? Like the CEO is the product owner, like the original founders of the product owner, or do they just rely on one of the developers to basically be the product owner? Like, what what kind of challenges do use Have you seen from that?

David Subar 20:47
So that absolutely happens a lot. And what often gets missed is the broader vision, it’s do this feature, do this feature, do this feature, do this feature. Without a, here’s the direction we think we’re heading. And here’s the features that we think we need to go, it’s, oh, I can just close the sale, if I just had this feature, or someone just asked me, I just had this idea. And it’s the the constant drip drip drip of a new idea, new idea, new idea. You want to have a theory of what you’re going to do now that that roadmap is going to change as you release, the market is going to tell you what you got what you got, right what you got wrong. So it’s okay to to not have the roadmap planned out for three years in advance with high levels of precision actually don’t want that. But you also don’t want, just, here’s my smart idea of the day, I just make the engineering team do that.

Matt Watson 21:49
So I think a lot of early stage companies fall into that trap that you just described as being like a feature factory, right, they just keep adding more features over and over. But they don’t really focus on what the customer wants, they don’t really plan them out. They don’t really prioritize them. They don’t use any kind of feedback, they, they just keep building features, because they think that is that is the solution. And you know, I’ve my first company, I would say we were almost guilty of that, like, we just build all sorts of stuff, we just kept doing all sorts of things. But we were fairly lucky, you know, it all worked out for us in the end. But to some degree, the products also get like really overly complicated. Because of that. I’m sure you’ve seen that a few times, too.

David Subar 22:32
Absolutely. Everything on the roadmap should every major feature in the roadmap should have an epic statement, we believe we believe this user exists. And we believe by doing this feature for this user, they’ll get this kind of value. And we’ll know it when we see this metric move. You have to have a thesis for why you’re building something. If you have an infinite amount of revenue or an infinite amount of capital, then you can just try to build every feature randomly anytime you want. And the world eventually will come to your door. It turns out that I know of no startups that have an infinite amount of capital. So you need to make some bets on the roadmap, you need to learn from it.

Matt Watson 23:21
Well, you have to figure out how to differentiate yourself. I was on a Facebook group last night and this guy has some kind of invoicing software. And he’s like, Oh, I can’t figure out like how to make Google Ads work and sell my product or whatever. And I go to his website, and I’ve hit does invoicing. And my feedback for him was like, Okay, why wouldn’t I just use QuickBooks Invoicing? Like what is different about your product? You do invoicing? So what like how do I know that I should be your customer? And that you’re better than every other alternative? There is? Right? And I feel like that’s, that’s always the missing thing in early stage startups is thinking about their product and trying to figure out like, how do we differentiate ourselves from other people. And that may mean like, turning away a lot of business like we, we turn away a lot of business. But now the customers that are a perfect fit for us know exactly that we’re a perfect fit for them. So like, maybe we’re only a perfect fit for 1% of the market. But that 1% the market knows for sure we’re the perfect fit, instead of us basically being a bad fit for 100% of market,

David Subar 24:22
right? Because then you’re differentiated. So if you have a heart attack, you’re going to find a cardiologist, you’re gonna find a general doctor’s like, I’m going to find like, I want to find the guy or the woman who could solve this problem for me, right now. I’m going to seek out not the general person but the one that solves his problem. That’s why the internal what do we do product management engineering, making them more effective if you say, could you coach our sales leader? No, we can’t.

Matt Watson 24:54
Right.

David Subar 24:55
Right. It’s not what we do. We’re specialized in this the problem There’s two problems like, not going fast enough, put keeping capital and not getting more out or, or hitting scale, those are problems we can fix for you. We do them again and again, we learn from them, we can speak to our market, every company needs to be able to say, here’s whose problem we solve. Here’s the problem we have, here’s how we’re gonna solve it.

Matt Watson 25:22
So is that a common you could have a conversation? I mean, is that a really common, you know, problem or symptom that you see when when people call you in for help is like, they’re, they’re not as focused as they need to be there, they’re kind of all over the place. Like they don’t understand their, you know, perfect customer, and what the product, what the customer needs, all that kind of stuff.

David Subar 25:41
That is a very common problem. It’s not the only kind of problem we see. But it’s very common. It’s like, can you tell me in two sentences, who you work with, and who solve the problem? If you can’t, if it takes you, if you takes me you two pages to describe that to me, you got a problem?

Matt Watson 26:04
So what other what other kinds of problems do you see on the product side? Like, if you’re given advice to people, like how to be better at product? How to run a product team? And what are the kinds of advice you have? I

David Subar 26:18
refuse to be an order taker. Like this thing of feature factory, people get pushed into it. Don’t engage in the conversation of what do you want? I’ll get it done for you. It gauges in the conversation of it’s the same thing really engaged in a province conversation is, what problem are we solving? And for whom? It’s, it’s, oh, I’ve got this great idea. We should do X. Oh, great. Who’s Who needs that? How big is that market? Do is that protectable? Is there is a moat around that market? That if we do this, that five other companies can’t do it? And, and, and reduce our margins? Do we have some kind of differential value? That’s protectable. Facebook, I could, you know, I could rewrite all the code of Facebook and make software just as good as Facebook, because no one’s ever going to use mine. Because what Facebook has has protectable is hundreds of millions of users. So what I want to do, if I want to attack Facebook, I’m not going to build their Facebook, I’m going to build tic tock. I’m going to build Snapchat, I’m going to build be real, right? They’re solving slightly different problems. But they’re also protectable.

Matt Watson 27:45
Yeah, a good example of that is all these potential competitors to Twitter, right, but they they sign up. They’re like, Oh, we signed up, you know, 2 million new users for Mastodon or whatever. And it’s like, and that same month, Twitter signed up more than that and more new users. That’s right, right. It’s so hard to compete when you have like that massive user base.

David Subar 28:12
Right? It’s not like the network effect of user base is one protectable. Difference differentiator, it could be laws and regulations, it could be cost to getting into it, it could be, it could be a whole lot of things. It’s rarely ever software. Because given enough developers, someone can recreate someone else’s software, the product manager needs to be attached to who we serve, and how’s that protectable, and needs to be able to explain it to the engineers and everyone else in the company, by being able to say, here’s the stuff we’re putting on the roadmap, and here’s why. And here’s how that creates value for customers. But here’s how that creates predictable value for us. Now, the product manager is escalated to being strategic and having a seat at the table with the CEO, and the chief revenue officer and everyone else, because they’re providing value to the company.

Matt Watson 29:10
So I have another topic that I’m hoping that you can tell us about today. What can you tell us about product led growth? Is that something that you you spend time on?

David Subar 29:20
Yes, yes, yes. Yes, it’s all the rage. But for good reason. Product led growth is just to continue on to saying, we’re going to release something and see how people consume it. And then we’re going to iterate. And we’re going to do that without this intermediary of a salesperson. But you need to think this is where agile really is important. Where a bunch of small tests and putting things out there and being able to see where things were things consumed. And this is where Northstar metrics become important. Here are the metrics we’re going to look at to see users are using this and how we get growth. But the thing about Northstar metric people say you accomplish one Northstar metric and should align everything to that I actually think you probably have a small handset and a handful. 234, not 10. But often, but you need to be thoughtful about them. And often these Northstar metrics are trailing metrics, oh, people bought more. And this is where product management really is important is here, our goes back to the epic state, we believe by doing this feature for this user, they’re gonna have this value, and we’ll see it we see this metric, it’s What things does user have to do to make them compelled to keep using our product. And so you need as a product manager, you need to think about some, some leading metrics, not just not just lagging metrics to do that. And that’s, that’s really where we’re the product manager needs to do and think about and where they really haven’t seen the payment. And product like growth is great, because you can expand your revenue without nearly as much cost of direct sales team and inside sales and all that other stuff.

Matt Watson 31:13
Well, product, lead growth is really important for companies that have a very low price point, right, like Slack or Jira, or Basecamp, or, you know, these these kinds of products that are $50 a month, $100 a month, stuff like that, you can’t afford a salesperson to sell them. And so you the product has got to sell itself. And my last company stock fi, we really focused a lot on this, you know, we had free trials and then getting people to download the product and use it and getting them to that aha moment, right was super critical for them to see value, and then hopefully, they would use it and then hopefully, they would tell other people,

David Subar 31:50
right, and then you got to appeal to a company that also has outbound sales, like AWS. If you’re, if you’re Netflix, believe me, they’ve got a sales rep, when they’re when they’re using, you know, cloud computing and AWS. Sure, but a startup doesn’t really have a right to your points that the unit cost is small. And it’s just, you know, getting them in and using the product. And so you need to think about that.

Matt Watson 32:19
Yeah, product product usage becomes really key. So what other tips do you have for getting the product team and the engineering team to work together?

David Subar 32:31
I want the engineering team to ask why are we doing this? Why are we doing this? As a matter of fact, I want to I want the manager of engineering or the product manager to say, tell me why you think we’re doing this, I wanted to make an incumbent on the engineers to understand why. And I want to make it incumbent on the product managers to understand how so I want the product managers to know something about the architecture we’re building. They don’t have to know algorithms. And they don’t have to know we’re building this to know a lot of high note or build it with language. But the low level details, but they need to understand the architecture, because they’re going to make choices that are easy or hard. And to the extent they know the architectures, they’ll make better choices, to the extent the engineers know why they’re going to also make better choices. And so it’s about focusing the conversation on once again, from the epic statement to every user story has value described in it. And then when when a product manager says I’d like you to do this, I want the engineers to come back and say, We can do that, that’s going to take three weeks. But I could do this other thing that’s going to get 80% of your value. This is how you know, if you’re winning, I can do something that’s gonna take 80% of the value I can get done in two days, by the way, you get this other side effect, isn’t that a better choice? So that’s how you know if

Matt Watson 33:56
you’re winning? Well, and I think the product team definitely needs to understand the level of effort versus the level of value, right? Like that’s, that’s really important for product understand, like, this one little feature you want is going to take a day to do or a month to do and is it worth doing it? Like? I think a lot of companies struggle because the product team doesn’t have that level of understanding, and also doesn’t have the understanding of what you just described, right of the developers knowing like, why are we what are we really trying to accomplish? And is there an easier way to do this? That is 80% of the solution.

David Subar 34:31
So the so I think product managers should say that’s gonna take three weeks can you explain to me why that’s going to take two weeks? If I only if I wanted something in in five days, what can you get me of high quality? Right? Don’t don’t have crap together. What can you get me of high quality and what features can you get out? That’s the kind of conversation they should engage in. Not like, it shouldn’t take three weeks. That’s not helpful. It’s like, what could you get to me in three days or? And then then the engineers can say I can only get you that. Does that make sense? Does that help? Tell me why it’s engaging his peers on that level that you get to rapid velocity releases.

Matt Watson 35:12
So how often do you come into these organizations? And it seems like the development, the development team is just getting absolutely nothing done at all. It’s just things are just take forever, there’s very little output of the team. Like, is there a common reason for that? Is it a talent issue? Is it a product management issue? Or, you know, what, what do you what do you see in those scenarios?

David Subar 35:39
So that does happen. Sometimes it’s happened because they’ve been a feature factory. So long, and they’ve been pressure for running software song, they’ve written a bunch of crap. And it’s just the molasses of moving the next thing power gets really, really slow sometimes. Sometimes, it’s, it’s because they’re not engaged. Like they’ve been told, shut up write code. And we’ll get it out. Sometimes it’s low quality people like you just don’t have good people on staff. Yeah. So right. Sometimes it probably it could be any number of those things that could be a mixer. And that’s when the evaluation of meeting the people and understanding and understanding why they’re here. Do they even measure velocity? Do they think about the end of a sprint? How can we increase our velocity? What can we do? Are they allowed to spend a certain amount of their time refactoring all of the time? Are they never allowed to refactor? These are all things, you have to jump in and see what’s really going on. It’s, you know, the thing about engineering is if all they’re doing is responding to requests, then eventually, it’s like renting a car and never going to the gas station. For the first tank of gas, you’ll get farther, if you don’t fill up, you just don’t get to get the second time. So there needs to be a time for the engineers to be able to fill up the gas tank and Steven Covey talks about sharpening the saw. Right, right. You need to be able to sharpen the saw to do tooling. So you can write code faster, to refactor things that need that is part of a good engineering process that the engineers need to be allowed to have to do.

Matt Watson 37:30
So let me ask you this What? What about requirements? What are your thoughts about what level of requirements developers should get? Because I’m the kind of I’m, I can work as, basically the product manager and the developer both. So the requirements are always kind of in my head, and I kind of know what needs to be done. But I’ve also worked in teams where the product owner provides such granular level of requirements that I feel like they’re paralyzing to the developer, because they’re just so complicated, that they struggle, like there’s no TL Dr version of any of this, right? There’s like, hundreds, like, pages of stuff. So I’m just kind of curious what you see and what you recommend on like, the right, like level of requirements to give a development team that works? Well, unlike an agile way.

David Subar 38:21
Yes. So um, I think the short answer is the least amount of requirements that can that can show the value you’re creating, I got that dog and repeat myself. But gee, it’s good to the extent that you can give them a UI UX specification, to find out what to tell that’s good. They might divert from that. That’s good. But don’t tell them how to do their job. Tell them the output you want their job to do. What you want that what you want the product to do, and no more and be and be willing to have a debate or discussion about it. So I’m a big believer in user stories. I’m bubbly believer acceptance criteria. And I’m a big believer in only doing the minimum of those of you need to get the next iteration. Oh, I’m not sure about yet your question completely. But

Matt Watson 39:19
yeah. So I think, you know, like this one company that I do this work with, I feel like part of their problem is the requirements are so overwhelming to the developers that what they really need is to have like, daily stand up kind of meetings that are less about status and more about debate about like, what are we doing? How are we doing it? What do you need to know? What questions do you have? Let’s talk through what we’re trying to work on right now. So make sure you understand the acceptance criteria. Let’s make sure you understand the requirements all this stuff right? On a daily basis, but I feel like in some companies, instead of doing that, they just write down a whole bunch require minutes and just throw them at the developers and then just like expect them to follow all the

David Subar 40:05
requirements. Yeah, and that’s poison, right? If it’s like, that’s, that’s, you know, just do this Shut up, get it done is poison, because people will tend to do what you ask them to do. But it’s like you say it’s overwhelming, I will get this all done, this is all going to take me three months. Don’t by the way, please don’t bother me between now. And then. Because you’ve just given me so much. So, so much. Give them the minimum amount of documentation to get the next increment done, including but also given additional to the line. Right. So that daily stamp daily standup is meant to be 15 minutes, you eliminate a bunch of other meetings during the day, where you talk about, here’s what I got done? Yes. Here’s my thoughts get done yesterday, here’s what I actually got done. Here’s why I have a delta. Here’s what I think I’m gonna get done today. Here’s where I need some help, in small increments, consistently, talk about it, and then release as early as you can. And something I’m a fascist about is MVP, minimum, minimally viable product, people go, here’s the MVP, but it’s not really the minimum set of things. It’s the things I want. It’s like, could we can we ship any less and still add value? Constantly ask the question of, can we ship less, and still add incremental value?

Matt Watson 41:31
Well, and to me, it’s the reason that you do those iterations and you ship something, even if it’s not done yet, you’re like, hey, we wouldn’t even release this the customer jet. It’s like an I have an MVP yet. But every couple of weeks where we are releasing it internally, people can play with it. It builds competence in the team. You know, it builds confidence in the whole organization, where, you know, if if, if everybody in the company thinks like, man, the development team never gets anything done, we ask them for things, we never see anything. And then like, miraculously, like nine months go by, and they finally do something. Like, that’s, that’s not a good, that’s not a good environment. And, you know, even if the team is shipping something every couple of weeks, and maybe it actually sort of sucks. It just feels like we’re accomplishing something, and it builds confidence in the in, you know, throughout the rest of the organization.

David Subar 42:20
That’s absolutely correctly in the beginning of my career, I was willing to do something in nine months, don’t bother us. Until then, believe me, we’re gonna get it nine months. So we everything you want, it’s gonna be great. But if you bother us between now and then it’s gonna be disruptive, it’s gonna take longer. And what happens? Exactly what you said, is people like they start wondering, is it really gonna get nine months, nine months is a long time. I don’t know, I can’t see I don’t know where it’s at. And by the way, because it’s something you’ve never done before. It doesn’t really take nine months, it ends up taking 10 or 11. People really a small incremental work, demonstrate that people on a regular basis, lets them know where you’re at, and also engages them with the process of, Oh, I know, I asked you for the blue dot over there. Now I see it. No blue dots out, right. Can we have a red rectangle here? And here’s why. And now, engineering is engaging with the rest of the couple of your things actually, right. Even when my wife was pregnant with three kids. When she was pregnant, I got to see the progress. Oh, look, her belly is getting bigger. Baby’s gonna be okay. Right. It’s helpful. Is it as expectant father, you’re nervous, it’s helpful as expected. colleague and accompany to know how the baby’s coming.

Matt Watson 43:35
My wife is, is pregnant with baby number five right now. And so I definitely see it and hear it all day long.

David Subar 43:46
Fives a lot. By the way, I got three. So you’re up on me by 66%?

Matt Watson 43:50
Yep, five, five is fun. My fifth one is a girl all the rest are boys. So it’s a whole new world. In this household.

David Subar 43:58
My wife we have three girls though. I said to me, the fourth one might be a boy. I’m like or not.

Matt Watson 44:03
Or twin girls. That’s right. Yeah. That’s that’s the way it would. That’s That’s what I always joked was gonna happen to me. Well, if you need to hire software engineers, testers or leaders Full Scale can help we have the people on the platform to help you build and manage a team of experts when you visit full scale.io. All you need to do is answer a few questions and let our platform match up with our fully vetted, highly experienced team of software engineers, testers and leaders. At Full Scale. We specialize in building a long term team that works only for you learn more when you visit full scale.io Well, David, this has been a great conversation about building software and engineering and product and all these things. As we wrap up the show, do you have any final final thoughts, you know, tips for entrepreneurs listening today?

David Subar 44:47
I would say this is when I kind of said what we do. Let me just give it two seconds about that. But we evaluate Product Manager engineering teams we coach CTLT product officers. We do interim CTO Chief Product For your work, we do diligence. If people have questions that we didn’t cover, they should just reach out to me. I’m glad just to answer questions, right? If they want one of those services, let’s do that too. Of course, that’s how we make money. But people should just reach out and ask questions. And I do this all day like, I’m glad to get free advice.

Matt Watson 45:19
Awesome. Well, that that is a great offer. And again, this is David Subar. You can find him on LinkedIn. It’s David and his last name is S-U-B-A-R. And reach out to you and your guys’s website interna.com that’s i-n-t – r-n-a.com. So Well, David, thank you. Thank you so much for being on the show today.

David Subar 45:41
Thank you, Matt. Congratulations five children, man. I envy you or not? I’m not sure.

Matt Watson 45:47
You know they always joke that, you know, nine pregnant women can’t have a baby in one month. But when when your wife was is the one that’s pregnant, you sure wish that that could be the case. So all right, thank you.

David Subar 46:02
Thank you, Matt.