Effective Product Engineering and Management Teams

During my appearance on The Startup Hustle Podcast, hosted by Matt Watson, we delved into the complexities of entrepreneurship and software development. Our discussion centered around the importance of building an adaptive learning product management engineering organization, which is essential in a constantly changing market. We also touched upon the value of receiving feedback and iterating on the product to ensure continuous improvement.

To develop a successful product, we underscored the need to stay focused on the target customers and clearly articulate the problem the product is meant to solve. Our conversation also highlighted the significance of product-led growth, which emphasizes releasing products to gauge consumer response and iterating accordingly, rather than relying solely on sales personnel.

Lastly, we examined the common challenges faced by companies when building development teams, such as a lack of engagement, inadequate quality of personnel, and insufficient time for engineers to enhance their skills. I emphasized the importance of using user stories and acceptance criteria in the product development process, as well as holding standup meetings to discuss ongoing work and address any concerns.

Key Moments:

- 1:12 Introduction

- 4:12 Common issues that companies have when building software

- 8:14 It's about getting the right people in the room

- 9:49 Being directionally correct and learning fast

- 14:00 Software is like fashion; there's no final version

- 16:06 Agile methodologies

- 18:17 Product Team vs. Software Development Team

- 20:27 How early-stage companies fall into the trap of being like a feature factory

- 23:21 Differentiating yourself

- 24:04 How to run a product team

- 29:10 Product-led growth

- 32:19 Getting the product team and the engineering team to work together

- 35:12 Why do most development teams produce little output?

- 37:30 What is the right level of requirements for a development team?

Transcript:

00:00.00 - Matt Watson: 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 Subbar and his company interna 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 we' be cheaper I so excited to talk all about that today today's episode of startup hustle is powered by fullscale io hiring software developers is's difficult full skill 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 so you you started this company and in turn a what what time did when did you start this company. Okay, so okay, so so tell me kind of um.

00:41.12 - David Subar: Let's do it it good.

00:48.62 - David: Look about nine years ago so 2013 ish

00:57.48 - Matt: You know your guys's expertise is being. You know the Chief technology Officer Chief product officer getting everybody 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 interna.

01:13.74 - David: Yeah, so um I started my career out doing research and development in Ai and machine learning in the military on think tank and be safe and so we were yeah sounds cool.

01:21.89 - Matt: Wow that um, yeah, and then like I don't I don't want to date you or anything but that 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.

01:35.56 - David: Yeah, that but 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 wanted to don't want to but if I wanted to I could yeah and so yeah.

01:46.60 - Matt: I like it.

01:53.50 - David: I thought doing research and development in Ai and ml was going to be really cool and it turns turns out that doing the research for me. Not so cool because when you do research you're writing papers and you're presenting at the papers at a conference.

02:09.79 - Matt: Yeah.

02:09.86 - David: And then you're hoping the world is going to like absorb that and it's going to have some impact and and it's not tangible for me like I want to build things that have an impact on markets right? So that's that's right, That's exactly right I Want to see it and.

02:20.31 - Matt: Yeah I want to see it.

02:29.40 - David: So I went from there and I was just like not happy. You know as like I wasn't engaged with what I was doing and so I realized that there's a big difference between science and engineering right I was doing science but I wanted to.

02:38.57 - Matt: Yeah, yeah, you were you were way ahead of the curve right before where where we are today like what was capable then what was capable then is nothing compared to what's capable today.

02:46.55 - David: And where exactly that right that's exactly right and so I went from there and I went to an Ai tools firm. We were actually building real product and that was for me much more engaging much more compelling and so I was an engineer than I managed groups then I was director then I became cto. A couple 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 the product the envisioning of what you're going to build and the actual building of it. Those 2 things go together are important in order to like have that impact so I went I switched from there to product and then I ran product teams every and product and and engineering teams and that's kind of what got me to in turn 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 and getting people engaging in who we serve and that's what got me their turn because I did that a bunch I was like that's what I really like doing is building the teams that build proc to have that impact and so that's what.

04:05.90 - David: And internal like that's what we dive into companies and we help them be more effective at building products that move markets. That's a path that.

04:12.70 - Matt: So that's why we're lucky to have you here today right? You're the expert at going into these companies and ah reluctantly ah was joking before we started I'm like people must call you all the time and and their comment is always going to be please come fix this shit like that's that's the that's the conversation right? and.

04:28.70 - David: Step.

04:29.31 - Matt: 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 and hopefully as everybody's getting some ah really valuable free lessons today. So.

04:45.84 - David: Yep.

04:48.52 - Matt: I guess um, what are the what are the the biggest issues that you see like you know you get those phone calls and you you know you you talk to this you know Vc backed you know sirc company. Whatever and they have all sorts of issues with with building products like. Is it usually the same pattern of of problems or is it. You know 3 or 4 most common issues like where does this usually start. You know when you you dive in.

05:14.33 - David: And yeah, so there are symptoms and problems and those are different so that the symptoms we'll get a call from like a Ceo who will say you know I keep putting Caplan's approximately into engineering and. Things aren't getting out faster or we're just hitting scale and we cobbled this together and 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. Ah, 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 um, really elegant algorithms and my job is to put out code or productc managers might say we do you know we work with the ux people and we do specifications and we do user stories and we have roadmaps. That's what we do and that's where the problems often start and. Is that who's having what conversations about what and 1 of the things that we typically have to say is your job is not to build software. Your job is not to build user store. Your job is to ship a product and so let's focus.

06:48.52 - David: 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 know it 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 to 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 of they're likely to pick the right ways consistently if they don't have the context it says I'm going to build a code I'm a feature factory. You tell me what to do I'll get it done then they're disconnected and so getting people done if.

07:47.60 - Matt: So You think it's 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 being really focused on like what really matters and the order of importance and and iterating to it.

08:08.10 - David: That's right now that's easy to say but then there's a lot of like that's great. Awesome. Everyone's got a unicorn now. Wonderful right? But it's about Geo the right people in the room are they organized correctly.

08:11.00 - Matt: That's it. We're done God We figured it all out guys. Ah.

08:15.20 - Matt: Yes.

08:25.73 - David: Are there processes correct does the architecture support that there's this great book 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 thing. Kind of a pyramid that goes from delivering value to execution and that's what we think about and that's that's what often breaks down.

08:54.55 - Matt: Well and in 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 ah forever.

09:10.50 - David: And yeah.

09:10.61 - Matt: It's going to take literally forever and billions dollars I have no idea. But if you have somebody that has done this kind of stuff before they'd tell you like oh don't do this, you're going to save a lot of time. Skip these steps focus on this thing, get this thing done first boom boom boom boom boom and you all of a sudden. It's like oh well this seems easy now we know exactly what to do and but.

09:27.49 - David: Yeah, yeah.

09:29.38 - Matt: Most corporations like struggle with that is what 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.

09:48.16 - David: 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. Let's build this small thing. Let's let the market tell us look. It's I've forgotten the guy's name who said this and I apologize to him if he ever hears this. It's like.

09:54.41 - Matt: Right.

10:07.55 - David: Don't worry, be crappy right? It's like build something get it out there the advantage of building software versus building the Empire State buildings. You've got to get the design for the Empire State building exactly right? You got to build the foundation ba enough before you start we can release fast.

10:17.30 - Matt: Right? Yeah, software is much more forgiving right.

10:25.86 - David: And we could. It's much more forgiving. So Let's take advantage of that 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 at so let's ask them to be directionally correct. Let's build quickly test quickly and let's build. A team in organizational design processes that support that quick learning.

10:48.77 - Matt: So I I do some consulting for a company that I'm a shareholder in I but I sort of work like a fractional cto for them for basically a few minutes a week but um I kind of feel like I fight with the product manager all the time because he's always trying to overcomplicate things and. Like once we're 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 neverending fight I feel like of it's the ah it's we they had this a little bitty company but they have the exact same problem you describe and they have 1 product manager but it seems like he's just always putting up these barriers and problems. That prevents the team from just quickly iterating and learning.

11:42.48 - David: Right? right? And so here's what I would say that person like I don't know who this person is but it's like oh do you have this exactly right? like do you know this exactly right? We're gonna do this is gonna take us three months to build. But if 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, but here's a smart case I can get built in two weeks or in two days and we can get out and work. It. How do we do that.

12:15.47 - Matt: 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 of other developers. We all looked at and like you know what? it seems like this should take like four weeks to do um 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.

12:46.75 - David: That's exactly right? That's exactly right? And that's that you know this is that's where being knowing how to cut where to cut is 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? because I was an engineer when I started life 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 what.

13:04.92 - Matt: Right? Well that that's.

13:21.99 - Matt: I almost you know and as I as I've done this you know for 20 years now and I feel like um 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.

13:22.95 - David: What's the minimum We can do.

13:39.73 - Matt: 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 I get so paralyzed about trying to handle every single thing. That they don't allow themselves to to learn later.

13:59.50 - David: They that's right, that's right, they they right? they they fall they they believe believe the myth of every Apple product was perfect. The day it came out they believed the myth and so I have to be that way too right. Believe the myth of I can just extrapolate everything and know what the market wants the market hasn't seen what you but 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. Ah, 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 they wanted an app store because someone to hack it and put apps in the iphone that wasn't part of the plan that was something Apple learned that.

14:55.59 - Matt: Well and their feedback is going to pull them a hundred different directions right? And so um, yeah, that it's it's a never ending journey of a building software and and you know one of my favorite quotes from.

14:59.90 - David: You.

15:10.23 - Matt: 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. It. It needs care and feeding forever once you go to build something you you. It's like adopting a puppy you you got this thing for a long time.

15:28.70 - David: That's right, That's right? and by the way congratulations. It's always changing because then the market you've changed the market and it's learning and it's adapting to and you have to adapt again. Entrepreneurship is really hard for right? All the easy stuff has already been done. There's no value in it. So All that's left is the hard stuff. It's gonna be hard and the market's going to change and you're going to have to change and if you don't change. Someone's going to do it So be expect like you have to have an adaptive learning product management engineering organization by the way adaptive learning product management engineering but ah.

15:47.29 - Matt: Yeah.

16:04.23 - David: Adaptive and learning company. Not just Proc management engineer.

16:04.96 - Matt: So tell me this you mentioned agile development earlier. Are you a big fan of of agile like tell tell us more about agile.

16:14.10 - David: I Yeah so so short answer is yes I'm a big fan of ah ah, short answer is yes I'm a big fan of agile development. Um, ah and but.

16:17.46 - Matt: Plus the sound.

16:31.31 - David: There's many different methodologies. There's Conbine. There's scrum. There's there's you know there's scrumbon. There's Xp. There's ah and you've got to pick the right toolset for what it is. You're trying to do and. But 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 at home sometimes I need a screwdriver someone the a hammer. You need to know when you pull the ratchet wrench out and which one you pull out I want the metric set I want that I want the the imperial set right? and so that's I'm a big fan of agile methodologies. Um, but I'm also a fan of picking the right one. But you need to learn the methodologies. The need to adapt it for what you're doing and.

17:22.66 - Matt: And 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. Whatever you call it whichever the method is you don't need to do any of it. Perfect the the thing that matters most is iterating quickly and getting feedback and just continually trying to improve.

17:43.19 - David: That's right.

17:53.40 - David: 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 circumstance right? So even if you start at the orthodox. Gum 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? you.

18:15.18 - Matt: Well, since we're talking about agile development I do remind everybody that finding expert software developers doesn't have to be difficult, especially when you visit fullscale io where you can build a software team quickly and affordably use the full skill platform to help you. Ah, define your technical needs and see what developers are available to join your team today visit fullscale io to learn more so what are so we talked about product I want to talk about product some more so some people may not really re even realize like okay. What does a 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 are're not experts on all this like okay, what does a product team do? What is what is their role in this and how they work with engineering.

19:01.23 - David: You 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 so 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 the users to have with the product the engineering and the team then and I'm saying is if there are 2 separate teams. Um. 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 enough in for instrumentation. It. So we see if people are actually doing product manager what you said they're going to do. The product is the what. Engineerings that the actual implementation the how the product needs to say not just here's the next feature. But here are the next 3 features for 4 features here's the order we're going to put them in because here's what we think the 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 they're together because right we ship a product together that helpful.

20:25.79 - Matt: So you think a lot of companies. Do you think a lot of companies early stage companies struggle with maybe they don't even really have a product team like the Ceo is the product owner like the original founders of the product owner or they just rely on one of the developers to basically be the product owner like what what kind of challenges. Have you seen from that.

20:46.58 - David: 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. Oh I could just close this sale I just had this feature or um, ah someone just asked I just had this idea and it's the the constant drip drip drip of a new idea. A new idea. A new idea that 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's going to tell you what you got what you got right? What you got wrong? Um, so it's okay to to not have the roadmap planned out for 3 years in advance with with high levels of precision. Actually you don't want that? Um, but. But you also don't want just here's my smart idea of the day I just didn't make the engineering team do that.

21:47.53 - Matt: So I 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 my first company I would say we were almost guilty of that like we just built all sorts of stuff. We just kept doing all sorts of things but we we were fairly lucky it all it all worked out for us in the end but to some degree. Products Also get like really overly complicated because of that I'm sure you've seen that a few times too.

22:32.41 - David: Yep, Absolutely yeah, everything on the roadmap should every major feature in the roadmap should have ah an epic Statement. We believe we believe this user exists 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 an infinite amount of capital then you could just try to build every feature randomly. Anytime you want and the world eventually will come to your door. It. 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 and you need to learn from them.

23:19.15 - Matt: Well and you you have to figure out how to differentiate yourself I was on a Facebook group last night and 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 and whatever and I go to his website and I'm like hey it does invoicing and my my feedback for him was like. Okay, why wouldn't I just use quickbook 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 orself 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.

24:06.47 - David: Yep.

24:10.24 - Matt: 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% of the market knows for sure. We're the perfect fit instead of us basically being a bad fit for 100% of the market.

24:22.48 - David: You right? because then you're differentiate. So if you have a heart attack. You're going to find a cardiologist. You're not going to find a general doctor. It's like I'm going to find like I've got a heart I Want to find the guy who can or the woman who could solve this problem for me.

24:32.15 - Matt: Right.

24:40.20 - David: Right now I'm going to seek out. Not the general person but the one who solves this problem. That's why it internal like what do we do? product management engineering making them more effective if you say could you coach our sales leader. No, we can't right. It's not what we do.

24:52.34- Matt: Right? right.

24:58.39 - David: We're specialized in this if you have the problems. There's two problems like not going fast enough you put keeping capital in 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 hey. Here's whose Problem. We solve here's the problem we have here's how we're going to solve it for them and then you can have that conversation.

25:21.00 - Matt: So is that a common problem 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. They're they're kind of all over the place like they don't understand their a know perfect customer and. What the what the customer needs all that kind of stuff.

25:40.94 - David Subar: I 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 2 sentences who you work with and who you who you resolve the problem if you can't if it takes you if you takes me you 2 pages to describe that to me i. You got a problem.

26:02.98 - Matt: So what? other what are the kind 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 what other kind of advice. Do you have.

26:17.85 - David: And um, refused to be an ordertaker like this being a feature factory people get pushed into it and don't engage in the conversation of what do you want? I'll get it done for you engage in the conversation. Of course. It's the same theme really engage in a problem conversation is 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. Is that protectable is there is a moat around that market that if we do this that 5 other companies can't do it and and and reduce our margin 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 does no one's ever going to use mine because what Facebook has as 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. And they're Facebook I'm going to build Tiktok I'm going to build snapchat I'm going to build be real. They're solving slightly different problems but they're also protectable. they'

27:45.50 - Matt: Yeah, good example of that is all these potential competitors to Twitter right? but they they sign up. Ah, they're like oh we signed up. You know, 2000000 new users for mastodon or whatever and it's like.

27:57.54 - David Subar: New.

27:59.20 - Matt: And the same month Twitter signed up more than that in more new users right? It's so hard to to compete when you have like that massive ah user base.

28:03.65 - David: The right right.

28:12.18 - David: It right? and it's not like network effective user base is one protectable differentiator. It could be laws and regulations. It could be a cost of getting into it. It could be It could be a whole lot of things. It's rarely ever software because you given enough developers someone can recreate someone else's software. The product manager needs to be attached to who we serve and how is 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 bio africans customers. But here's how that creates protectable value for us now. The proc managers escalated to being strategic and having a seat at the table with the Ceo and the chief revenue officer and everyone else. Because you're providing value to the company.

29:10.18 - Matt: So I have another topic that I'm hoping that you can um, tell us about today. What can you tell us about product led growth is that something that you you spend time on.

29:19.91 - David: It? Yeah yes, yes, yeah, yes, Plj. Yes, it's all the rage. But for good reasons. Um product led growth is just a continuum 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 where things consume. And this is where north star metrics has become important here are the metrics we're going to look at to see if users are using this and how we get growth. But the thing about northst star metrics and people say you I copy shove one north star metric and should align everything to that I actually think that. You probably have a small handset and handful 2 3 4 not 10 but but you need to be thoughtful about them and often these northst star metrics are trailing metrics. Oh people bought more and this is where proc management really is important is that. Here are goes back to that epic statement we believe by doing this feature for this user. They're going to have this value and we'll see we see this metric It's what things does the 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.

30:44.88 - Matt: Yeah.

30:50.57 - David: Some leading metrics not just not just lagging metrics to do that and that's that's really where what the product manager needs to do and think about and where they really have a seatd at the table and practically growth is great because you could expand your revenue without nearly as much cost. Of direct sales team and inside sales and all that other stuff. So.

31:13.79 - Matt: Well product-led growth is really important for companies that have ah 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 hundred dollars a month stuff like that you can't afford a salesperson to sell them and so the product has got to sell itself.

31:20.52 - David: Yep you.

31:30.78 - Matt: And um, my last company stackfi. 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 and getting them to that aha moment right was super critical. Um for them to see value and then hopefully they would use it and then hopefully they would tell other people.

31:49.70 - David: Right? And then you go to appeal a jcomp that also has outbound sales like a ws right? If if you're if you're Netflix believe me, they've got a sales representative when they're when they're using you know cloud computing at Aws.

31:52.16 - Matt: Yes.

32:05.19 - Matt: Sure.

32:08.58 - David: But a startup doesn't really have they like write 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.

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

32:32.15 - David: Um I want the engineering team to ask why are we doing things. Why are we doing this as a matter of fact I want I want the manager engineering or the product manager to say tell me why you think we're doing this. Okay. 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 and know well they probably know they're building what language' building up but that. But the low level deals but they need to understand the architecture because they're going to make choices that are easier 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. Um, and then when ah 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 going to take 80% of your value I can get it done in two days by the way you get this other side effect isn't that a better choice. That's how you know if you're winning.

33:55.50 - Matt: So 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 I 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.

34:29.63 - David: I right? And so so I think prac manager should say that's going to take three weeks can you explain to me why that's going to take 3 if I only if I wanted something in in five days what could you get me of high quality right? Don't don't have to crap together. What can you get me of high quality and. What features could you get out. That's the kind of conversation they should engage in not like it shouldn't take three weeks that's not help looks it's like what could you get to me in three days or and then then the engineers can say I could only get you that does that make sense does that help tell me why. It's engaging as peers on that level that you get to rapid velocity releases.

35:11.69 - Matt: 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 or just take Forever. There's very little output of the team like is there a common reason for that. Um, is it ah is a talent issue. Is it a product management issue or you know what?? What do you?? What do you see in those scenarios.

35:40.13 - David: Um, 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 the molasses of moving the next thing forward gets really really slow. Sometimes that's the cost. Sometimes you. It's um, 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. So right? Sometimes this process could be any number of those things. It could be a Mix. Um.

36:07.47 - Matt: Yeah.

36:17.58 - David: 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? um, are they allowed to spend a certain amount of their time with. Refactoring all of the time or they never allowed to refactor like these are all things that you have to jump in and see what's really going on. You know the the thing about engineering is if all of they're doing is. Responding to requests then eventually it's like running a car and never going to the gas station for the first tank of gas. You'll get further if you don't fill up. You just don't get to get the second tank so there needs to be a time for the engineers to be able to fill up the gas tank and do. Ah, Stephen Cobby talks about sharpening the saw right? and you need to be able to sharpen the saw to do tooling so you can write code faster to refactor things that needs that is part of a good engineering process that the engineers need to be allowed to have to.

37:12.40 - Matt: Right.

37:28.70 - Matt: So let me ask you this. What? what about requirements? What are what are your thoughts about what level of requirements developers should get because I I'm the kind of I'm I can work as as. Basically the product manager and the developer both so the requirements are always kind of in my head and 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. Um, paralyzing to the developer because they're just so complicated that they struck like there's no tl Dr Version of any of this right? There's like hundred like pages of stuff. So I'm just kind of curious. What what you see and what you recommend on like the right like level of requirements to give a development team that that works well in like an agile. Way.

38:22.46 - David: I Yeah 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 feel like I'm repeating myself but um Ge it. It's. Good to the extent that you can give them a uiux specification to fine level toal 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? what you want the the proc to do. And know more and be and be willing to have ah ah a debate a discussion about it. So I'm a big believer in user stories I'm but believe believer in acceptance Criteria and I'm a big believer in only doing the minimum of those that you need to get the next iteration now.

39:17.17 - David: Um, not sure if I answer your question completely. But um, don't yeah.

39:17.53 - Matt: Yeah, so so I I think you know like this one company that I do this work with I feel like part of that problem is the requirements are so overwhelming to the developers that what they really need is to have like. Daily standup 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. Let's make sure you understand the acceptance Criteria Let's make sure you understand the requirements all that stuff right on a daily basis. But. Feel like in some companies instead of doing that they just write down a whole bunch of requirements and just throw them at the developers and then just like expect them to follow all the requirements.

40:05.64 - David: 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 that. Will get this all done. This is all gonna take me three months um don't by the way please don't bother me between now and then because you've just given to me so mu