0:00 Brad If I'm going to give people a sales pitch on SpecKit, I'm going to say like, hey, as a tooling, one of the things it's really good at is it's really good at surfacing the ambiguities. Welcome, everybody, to another episode of the How Many CTOs Does It Take podcast. My name is Brad Hefta-Gaub, and my trusty co-host is Scott,
0:32 Scott Scott Porad. What's up, Brad?
0:35 Brad my friend, how many CTOs does it take to get product owners to actually care about spec-driven development?
0:45 Scott Snap. So what everybody needs to know who's listening today is that Brad and I are doing this podcast, Raw Dog. We have not discussed in advance what we were going to do. That sometimes we're just like, let's just go for it and see what happens. And Brad's like, I got a topic, Scott, I'll just get us going. Okay, well. I don't know the answer to that question, but I just want to read you a text message that I had with one of the engineers in my life that
1:13 Brad Wait,
1:14 Scott it's
1:14 Brad are you saying this is hitting?
1:16 Scott hitting. Let's see here. Having a text exchange with an engineer who I've worked with for 25 years, 20 years, think highly of him. We were texting last night about AI and blah, blah, STD and all this nonsense. And he said he said he sent this to me. A product has always been the hardest part of software. Product has just been able to hide behind a long dev cycle. And now that the dev cycle is collapsing, product is just what's left.
1:47 Brad Yep,
1:48 Scott And I thought that was very astute.
1:51 Brad yeah
1:51 Scott And it gets and it's interesting because I was talking just. find out this week to some product managers and I was just trying to get product managers to sit down with engineers to do spectrum and development to use spec kit because it's really a product management tool.
2:08 Brad Yeah, it
2:08 Scott Now
2:08 Brad is.
2:08 Scott you need the partnership. We need our product managers to realize that spec kit or spectrum development is a product management tool, not an engineering tool.
2:16 Brad Well, okay. So first of all, that's landing for me. Sure. I actually, so let me tell you why I thought I wanted to bring this topic. Okay. So first of all, you know that I am a, I work with, you know, a handful of different teams and I've got several of them that are. are really really accelerating their their development because of ai and they're just like crushing and so your comment that like you know it's like the speed with which we can build software is just collapsing right it's like we're building software so fast you know partly inspired by you um i was like okay let's look let's really look let's really interrogate spec kit like because a couple of teams i work with they're not using anything like that they're going really fast their product owners are in love with of what the products and progress are making they're all plan mode they're definitely like they're definitely like doing all the things that i say is the right way to do to get like still high quality engineering best practices you know they've got clean you know quality gates they've got you know great cicd they've got you know really good you know real user monitoring and like telemetry and all the stuff that we think of as like real you know quality engineering we're not just like vibe coding this this shit right
3:25 Brad right so i was floating with them like hey why don't why don't we try to use spec kit here and i one of those teams has a product owner that is on the cutting edge of like using you know using ai agents to just build software for them and the team's got enough like quality gates and infrastructure around them that they're like yeah sure go for it like you got an idea fire up the agent make it build something and it's okay it's nothing's going to get through our quality gates so we're fine with that with you kind of running with this so i was like hey why don't you try using spec kit like i think like you know they would hand me some stuff every once while i'd look at it i'm going like oh you know there's some ambiguity in your request here and i bet and like they would come sometimes come to me and be like yeah my agent's really struggling with this one i was went back around and around circles and i was like
4:12 Brad Like, well, yeah, that's because this particular task has got a little bit of ambiguity to it. And I think if you give it to one of your engineers, they'll instinctually know how to get around that ambiguity. But if you really want to do this, then you need to have a more structured spec. And try spec kit. It's going to be a way to get you that. Okay. Sounds
4:31 Scott Mm
4:31 Brad like a
4:31 Scott -hmm,
4:31 Brad plausible like response, right?
4:33 Scott mm-hmm, mm-hmm.
4:34 Brad And the reaction was, oh man, it wrote so many words. I didn't want to like have to read through all that.
4:42 Scott Interesting.
4:43 Brad And I was like, what do you mean it wrote so many words? It gave you like five, you know, six, a dozen user stories. Like that's what you should have been doing anyway. And it was like, nah, you know, I look, I just feel like I can go fast. faster if I don't have to give it all that if I don't have to read all those words so
5:01 Scott Yeah. I, it's funny, this is so germane to a conversation literally I had 30 minutes ago.
5:09 Brad the stars are aligning
5:10 Scott We have a repo for one of our systems that has excellent test coverage. 100% unit test coverage, 500 acceptance tests, very, very good test coverage. One of our most experienced engineers. using spec kit submitted a 60,000 line pull request and
5:28 Brad Nice! I love it!
5:32 Scott I was saying to this to the kind of other this not to the engineer but to this other person I was like I don't really know how I feel about a 60,000 line pull request that's going against my training and experience and he said to me well this is how you have to think about it so i'm sorry take a step back really quickly we write in python and i'm sorry not in python in a typescript imagine if instead of committing your typescript to the repo you committed your assembly code to the repo and you could not instead of in addition to the typescript you committed the assembly code
6:11 Brad Mm-hmm.
6:11 Scott You wouldn't review the assembly code, which would be thousands and thousands of lines. You would just review the TypeScript.
6:17 Brad Yeah.
6:18 Scott And the spec for this thing, it was a little long. It was about a thousand lines long, a little. It was 1,100 lines long. But that included the user stories, the plan, all of it. And the point was you review the spec, not the code. And that's how, if you have the right. Quality gates in place, that's how you use this and can be comfortable accepting a 60,000 line pull request. And then that led into another subsequent conversation about some observations we've made in our organization of when people use spec kit, just kind of accepting the defaults of what it produces.
7:04 Scott because this person or the same person I was talking to was pointing to something that somebody else did and this other particular person was frustrated because SpecKit used Bash to create something, not whatever he wanted it to do, Python or TypeScript or something. And the person I was talking to said, I went and looked at the spec and the spec says I'm going to write this in Bash. Like you asked, you gave the agent a bunch of stuff. I thought it gave you a plan, which is this is what I'm going to do. He's like, I think this person didn't quite understand that their job was to review this plan, just to read this,
7:39 Brad Read the spec and read the plan.
7:41 Scott read it really carefully. And that led to a subsequent conversation. All these parts are tied together so in ways I hadn't really understood before. We had a conversation. Okay, well, let me. interrupt myself I'll skip I'll tell you about the conversation I had with my team earlier this week but I'll just skip to the end of it there's this aspect of software engineering that's changing you're kind of going from a coder to a reviewer and it's like It's a different muscle, and
8:11 Brad Mm-hmm.
8:12 Scott for a lot of us, it might, like the coding muscle is a really fun muscle. Look, I can type, I can do this sorcery and a magical thing happens.
8:21 Brad Right.
8:22 Scott And the reviewing muscle is maybe like different. It's like a book author versus a book editor. But those are different skills, and
8:32 Brad Yeah.
8:33 Scott different people gravitate towards them, and some are good at one or some are good at the other, but they're different, and kind of in some ways the job is changing.
8:41 Brad Yeah.
8:42 Scott And I bring that up, I want to mention this one meeting we had this week,
8:45 Brad Yeah.
8:45 Scott this one discussion we have every week at my company, we have an engineering roundtable where anybody from product or engineering can come and we discuss anything anybody wants to discuss. This started out as an office like an office hours with the CTO, but then it was just people asking me questions that felt very much like I was on a pedestal and I didn't really want that. So I was like, no, let's just let's just have conversations about stuff. Who wants to talk about what? less. And lots of times nobody wants to talk about anything. They want to see the other stuff people want to talk about. And this week, nobody had anything. And I often keep a few questions in my back pocket just to get a conversation going. And I asked the question this week, I said, if with all these AI tools, everybody can code now, why don't we just let anybody in this whole company submit pull requests? Why is it only engineers that are allowed to submit pull requests?
9:31 Scott And there's a lot of resistance and a lot of questions. questions but there was support also there are a lot of concerns but one of them was about like well we'll just be overloaded with code reviews so
9:42 Brad Yeah, right.
9:43 Scott back to the original question how do we get product owners to care
9:47 Brad Yeah. Well, and let me, so first of all, everything you just said 100% resonates with me. And I think that that is 100% like. This is like squarely in the drop zone of the question I'm asking, right?
9:59 Scott Mm-hmm,
10:00 Brad I want to introduce a couple other things to this conversation to see if they also resonate with you.
10:07 Scott mm-hmm.
10:07 Brad So. First of all, you made the point that like the developer job becomes like really reading the spec and the plan and really interrogating that. So that's that's great. Here's what I'm saying. I have some product owners I work with and I. and and and as i think about this this is not new this is actually how a lot of the product owners i've worked with for my my entire career they my current product owners they are kind of like look don't I don't really know what I want. Don't make me describe exactly what I want. Like, this is kind of what I want. I can kind of tell you what I want, but I won't know if I really want it until you build it and let me play with it.
10:52 Brad And so that flies in the face of spec-driven development. Or at least, at least I'm going to say spec kit. I think spec-driven development is a broad sort of like broad terminology, right? And I think that some of the people I'm working with are like, oh, yeah, I was always giving you specs and you guys were always building against those specs. Speckit produces some very detailed specs.
11:17 Scott Mm-hmm.
11:18 Brad And so maybe this is less of a comment on spec-driven development and more of a comment on. spec kit and what the reaction i'm seeing is product owners who are like they don't want to read the spec either they sure shit don't want to write it but they don't even want to read it
11:36 Scott okay i got someone in so many thoughts it's just like it's all in the zeitgeist it's like we are living on the edge of the zeitgeist right now it's so crazy and we're not even i mean the only reason i would have an interest in going to work at a company like anthropic right now It's just to really get to be on the edge. I mean, it's just like it's changing so fast.
11:55 Brad Yeah.
11:55 Scott I think I posted on LinkedIn a while ago, it's a good thing technology isn't changing fast right now, otherwise we couldn't keep up. I mean, it's just it's moving, it's moving so fast. Okay, so an engineering manager on our team this week in that same conversation we had made this comment. She said, you know, Scott, most of the time isn't spent coding. Most of the time is spent having a back and forth conversation with whoever is requesting the work to clarify exactly what they want.
12:26 Brad Yeah.
12:29 Scott But that's not happening like in one meeting where you sit down, like the engineer starts coding away and is like, oh. I wonder if they want me to have a limit on this thing or if we could just if I need to design it to be unlimited you know or something like that right and so then they go they send a slack message over to the PM like hey do you think there might be a limit to this like should we
12:49 Brad Right.
12:49 Scott cap it or should we make it unlimited like what do you think we should there's that back and forth and so it it feels lighter weight and when you try and specify it all up front it starts to feel pretty heavyweight
13:01 Brad Well, and the good news is that, again, as a tool, SpecKit. we'll ask you a bunch of questions right
13:06 Scott Mm
13:07 Brad and-hmm. we'll sit and we'll kind of like make a bunch of assumptions describe stuff and then kind of say hey is this what you wanted right and there even of course spec kit even has this like mode where you like uh after you specify then you can run clarify and clarify will basically kind of go look at the code look at your spec and then further come up with like ambiguity and say like hey you didn't really you didn't give us an answer on this and this and this and as a case in point one this product owner that i've been working with where i was like hey why don't you try to use spec kit on this and um he was a little reluctant so i was like hey how about this i'm going to take your next i'm going to take the next card i'll i'll go ahead and run spec kit on this thing and i'll see what it does and and i'll show it to you and and you know this was like something that
13:54 Brad When Speckett got a hold of it, Speckett did a great job of writing Speckett and came up with some very, very real questions that were under specified and said, well, you didn't say anything about this. You didn't say anything about this. You didn't say anything about this. So I went back to the product owner and I said, hey, by the way. came up with a great spec and it it clarified the following questions that you had not mentioned to me at all what do you think and the product owner was like i don't know what i don't i i i didn't specify that because i didn't even think about that like i don't know what to do about that i don't what do you suggest i do about like like they were basically like um completely stymied by the the area of ambiguity was like they were completely oblivious to it and so that like sent them into a uh not a tailspin necessarily but at least they were like
14:45 Brad dazed and confused and we're like yeah i don't even know what to do about that right so
14:49 Scott Well, first of all, I'm going to say we might spend 10 hours talking about this. This is going to be a great podcast. If those five questions existed in reality, but we were unaware of them because the spec. Spec kit doesn't surface them. So we're in the old world. We're in the pre-times, right? What would have happened? I'm going to speculate something.
15:09 Brad I think I know what would have happened. Go ahead, tell me what you think would happen.
15:11 Scott Of those five, this is how it would have happened. One of them, the developer would have just decided on their own. Another one, the developer would have asked the product manager or whoever the requester was, the product owner. One of them would have ended up as a bug and have to get fixed later, and the remainder would have somehow gone unanswered or
15:36 Brad And been tech debt.
15:38 Scott product debt, or maybe it just ended up not quite working the way we wanted it to, and people just accepted that or something. Or maybe the software just wasn't written quite as well because it didn't consider some situation.
15:52 Brad Yep.
15:53 Scott That's kind of what would have happened. And now SpecKit is demanding. On the one hand, AI is an eager intern. And on the other side, it is demanding, demanding.
16:05 Brad Yeah.
16:08 Scott boss i'm not sure what the right word to use is exacting the the spec is demanding that we answer these questions that before we could have kind of gotten away without answering
16:19 Brad Yeah, and that actually is kind of like if I'm going to give people a sales pitch on spec kit, I'm going to say like, hey, as a tooling, one of the things it's really good at is it's really good at surfacing the ambiguity that. otherwise your agents just because the answer is without spec kit and you just give it a basic plan and then you say run with it or you're totally on the other end of the spectrum vibe coding the agent is that developer and it's just making those decisions for you right
16:46 Scott That's right. I got a few other answers for it.
16:49 Brad Okay.
16:50 Scott I got a bunch. I mean, I've been taking notes. I got lists of things to talk about now. I think your pitch on SpecKit is good. I think I'd add one other thing to it. It makes, I've always believed, and I'm not like a revolutionary in this regard, that test automation is extremely valuable. And spec-driven development makes test automation both more valuable. than ever, and cheaper than ever to create.
17:21 Brad Yeah.
17:22 Scott And so overall, it is creating, it's putting us in a position to create better software and move faster, better software. Like previously, test automation was expensive to make. It was time consuming. And now it's just like lickety split. So that's another pitch I would put there. But I want to come back to your product owner thing for a second. Okay. And the product owner said, I don't know, I just want to see it and get a reaction. Now we're back to agile. Now we're back to scrum. Now
17:51 Brad Yeah.
17:51 Scott we're back to where the sticky note on the wall is only supposed to be enough to remind you of the conversation that you wanted to have with the product owner about what they wanted. To me, the promise of spec driven development is that instead of having two week sprints, we can have two hour sprints right we can be highly iterative about okay you only know you want these four user stories let me go let's here we go we'll just let the agent do it and we'll come back and take a look what do you think and that's not what i wanted all right but let's do another spec let's revise it right and we can get into these crazy cycles i was just again i mean this is so crazy how relevant it is today one o'clock today having a conversation with our engineering and product leaders about our org and i was kind of saying again i'm not the leader on this thinking but like i can see this world which is not that far away where like the ideal thing is like a team of like three
18:49 Scott three engineers and a designer and a product manager literally sitting around the same computer and just
18:54 Brad Yeah.
18:54 Scott like doing it and like just getting work done because they're all right there and just iterating iterating iterating iterating like these sort of strike teams that might be the future we're headed toward and so coming back to your product owner question well they don't have to care they don't have to throw a spec over the wall they're sitting at the desk with the engineer and the designer they don't have to think about the whole thing they can just say well let's just start start with one of your story i want a dating app right
19:18 Brad Right.
19:20 Scott as a dude i want to meet girls i want a dating app so i can meet girls or guys or whoever i want to meet right so like i don't know and i wonder if even just the well this is a whole other thing we wrote this down too the roles are all changing
19:34 Brad Yeah. Here's the reason I wanted to throw this topic out.
19:38 Scott Mm
19:38 Brad I
19:38 Scott -hmm.
19:38 Brad wanted to throw this topic out because I think that like right now I see in the engineers that I work with this, the ones that are really effectively using AI, they're the ones that are even more worried about the implications of AI because they, they're really strong engineers and they're seeing how powerful it is. And they're kind of like, wow, like this. changes everything okay to
20:01 Scott Are you talking about like the Claude mythos implications or just like the implications of the industry or their jobs? Like what do you, what implications
20:08 Brad their
20:08 Scott are
20:08 Brad jobs
20:08 Scott you referring
20:08 Brad to
20:08 Scott to?
20:09 Brad their jobs and
20:10 Scott Yeah. Okay.
20:10 Brad yeah that's that's that's what i mean like they're like you know gosh like it ranges it ranges from like gosh this turns me into just doing code reviews i don't have to write code anymore that's the fun part you kind of already mentioned that to the gosh like even novel stuff that i used to be an expert at is is not that hard for this thing to do like it actually does it as well or better than me in many cases right so what's what am i left to do right and so what i'm saying is like i used to feel like oh used to like six months ago i used to feel like oh well if you're really worried about ai then it's maybe because you just haven't learned how to use it and you're maybe weren't that good of a developer anyway and so you're seeing that it's taking away you know boot camp style coding jobs and you you know if you had computer science fundamentals and and understood architecture you wouldn't be as concerned about it fast forward six months the people that have those strong
21:04 Brad computer science background so they're the ones going man this thing's getting pretty damn good it's like kind of going to take my job too so that's like this backdrop so then i think to myself well the thing that you're good at engineer senior engineer is you're so good at teasing out the ambiguity from your product owner like that's actually what they value in you you know sort of what your your engineering manager said to you you know like hey it's not the writing the code is not the hard part it's the back and forth to get to figure out what you want to build it's the hard part OK, so that first of all, I agree. I believe that like I believe that like being a strong engineer with a with a clear understanding of the business needs and understanding like how to map business needs into technical solutions like that's fundamentally what I think is the definition of a strong engineer.
21:56 Brad But I'm having this kind of. frustrated reaction to multiple product owners I work with saying things like I can't be I don't know they didn't say I can't be bothered but gosh you're asking me too many questions I don't know what I want right like so to me that's like wow man like I think you said it really well like It used to be that product owners could be wishy-washy, could be like, I don't really know what I want. Here's some ideas. And it would take the engineers long enough to develop the implementation that.
22:35 Scott Mm-hmm.
22:36 Brad By the time the implementation was ready to be criticized, the product owner would have, you know, grown their thinking about it and they would have been kind of to the point, well, now I kind of know what I want. Now I can critique what you've given me based on what I want.
22:47 Scott Mm-hmm.
22:47 Brad Right. Well, if the time it takes to build something has been has shrinks to zero, then it puts this massive pressure on you better fucking know what you want.
22:59 Scott Yeah, that's right. It's crazy times, man.
23:02 Brad It's crazy.
23:04 Scott Yeah, you know, how do you think we get the product owners to care? Like my hypothesis is we get them to pair program. Sit down side by side with engineer and designer and do it together. That's how you get them to care. It's the only way that I can see it. But there might be others. How do you think you get them to care?
23:22 Brad I like that one. OK, what I'm about to say, I don't think is an answer to your question, but I want to I want to I don't want to like avoid your question, but I'm more like I don't have an answer that yet.
23:34 Scott Brad's an avoider. Brad is
23:35 Brad I
23:35 Scott an avoider.
23:36 Brad know I'm avoiding the answer. I'm avoiding the question. But I think that one of the other patterns that we know exist, right, like I'm sure you've seen this many, many times in your career, right, where product owners. don't actually ask for what they want. They don't tell us the problem they want solved. They tell us the solution they want. Right.
23:57 Scott Mm-hmm, mm-hmm, mm
23:59 Brad And that's like, that's like, that's such a trope, right? Like that's, that's existed forever. Got nothing to do with AI and, and the change there that, you know, it's such a trope that like, you know, people, you know, come up, come up with their little colloquialisms, you know, make sure you bring me the problem statement first. Like, we're not going to talk about any solutioning until you, until we clearly agreed on what the problem statement is, you know? you know like that's it's funny that that many of the product owners that i've worked with um have been trained on that right especially if they were ever at the you know the the the mag seven or whatever they get trained on this notion of like really understand the problem statement you know before you come up with solutions and yet they're pretty bad at it like they're
24:44 Scott Because it's
24:44 Brad everyone
24:44 Scott pretty hard.
24:45 Brad everyone i've ever worked with is bad at that Because they want to build stuff too. They want to be like, I want to just, hey, I just want to, I have this idea of what I want you to do. Please, I want you to, I want you to, you know, make a, you know, replace the horse with an internal combustion engine. That's what I want.
25:06 Scott What listeners of this podcast might not know is that earlier in my career, so my career roughly went like this. I spent four years as an engineer, four years as an engineering manager, four years as a product manager. Then I got a job leading kind of what we would call now something like cloud infrastructure or something, but then we called it operations and we had our own data center and stuff like that. the product management it's hard it's really hard i mean this is go back to that i mean we i didn't plan to focus this whole chat on a text message i see received yesterday but product has always been the hardest part of software that's what my friend said and it's hard it's hard to describe the problem sometimes and you often peel it back so many layers that it becomes a very generic problem right and so it's tough you
25:55 Brad One of the things that I think the Lovables and the sort of like rapid vibe coding tool sets might might cause is
26:06 Scott Mm-hmm.
26:07 Brad it might do more damage than good, not just because like API keys and stuff like that are going to leak and there's going to be security problems, but it may like exacerbate the notion that. As a product owner, you just you don't have to you can you can manifest the the implementation you imagined very quickly and that will make you that means people will avoid the hard part of product, which is understanding the problem.
26:39 Scott they're just doing self-design in some previous episode we talked about Jacob Nielsen and the five levels of design and they're just doing I'm the customer I'm going to design it for myself
26:48 Brad Yeah.
26:49 Scott I talked to some guy this week. He's a friend of mine I've known for a long time and we were at a birthday party for a different friend of ours and I saw him and hadn't seen him in a while. He's in real estate. He raises, he's got a real estate investment fund kind of thing. And he told me, he's been super fired up about AI and he told me he used Lovable or Claude or something to make. like a tool for tracking the progress on like raising money and you know all those kinds of things and i just kind of thought to myself like you made a crm system like why did you do that you know i
27:24 Brad And what did he say?
27:26 Scott didn't say it i mean i was he was being enthusiastic and telling me about what he was doing and i was you know just being supportive i wasn't going to insult his having fun but i just thought to myself like why would you make i mean what's so now every little investment The fund is going to make their own CRM system. I didn't want to rain on his parade. I was just like, that's cool, man. I'm glad you have fun with it.
27:47 Brad Well, I think there's a very real there I mean uh the the stock market thinks that every little customer is going to stop using sass and start building their own i mean you know a work day is down like i mean you look at these things like a bunch of these companies are down like 60 50 50 60 on year
28:05 Scott let's go buy them i'm gonna go buy them we should turn this into a stock picking podcast well i don't mean buy the whole company i mean buy the stock anyway the point is well these
28:13 Brad i
28:13 Scott are get right
28:13 Brad that but i'm just saying like I
28:16 Scott Maybe
28:16 Brad mean,
28:16 Scott they're right. So he could build his own CRM exactly the way he wanted it, the way his mind and his company's hive mind visualized managing customers,
28:24 Brad self
28:24 Scott I guess.
28:25 Brad -design, like you said.
28:26 Scott Self-design. Maybe so. Look, okay, well, here's an interesting question. Imagine a world where way back in. good old 77 or whenever when Bill and Paul started Microsoft imagine if we had AI back then and everybody could have just made their own software like
28:47 Brad Right.
28:47 Scott are people going to write their own word processors what if that was the thing that Bill and Paul had invented which is everybody could just make their own software now well
28:55 Brad What
28:55 Scott I don't
28:55 Brad do you think?
28:55 Scott know but well
28:56 Brad I mean,
28:56 Scott I don't know
28:57 Brad I think it would be radically different.
28:58 Scott it'd be radically different but maybe we wouldn't the whole the whole reason we're anchored in software cost software or SaaS software is because the only way to make it at scale was to have it be the only way to make it cost efficiently was to make it at scale.
29:14 Brad Yeah,
29:14 Scott And
29:14 Brad that certainly is.
29:15 Scott so
29:15 Brad I think that's a safe argument.
29:18 Scott maybe this rejection at least that I'm having of like, oh, this is crazy that people are going to build their own software for themselves. Actually, I'm just anchored in the economics of an olden time. And if we had started out that way, we would have never gotten to this situation.
29:29 Brad I think that might be true. I mean... You know, what's interesting is the thing that's powerful about self-design, if it is really just like I'm building it for myself, then the spec questions become a lot simpler.
29:43 Scott Totally.
29:44 Brad You know, you know exactly what you know what you want. You want exactly this.
29:49 Scott I want this. You don't have to think about these unusual cases.
29:52 Brad Yeah, I mean, like, I think there's plenty of little things that. where it's like you know i wish that my you know hey look i just we got to we got to schedule a call with an interview you know an interview you know guest for the podcast and it's like man you know like how many how many different production level software packages are out there to try to get multiple people to agree on a time slot right so many right but they're all like over they're all like designed for like one was originally designed because someone is trying to uh plan potlucks or something or like
30:30 Scott Yeah,
30:30 Brad who's
30:31 Scott totally.
30:31 Brad right and so then it got more from potluck planner to you know like calendar picker you know and it's just like it's a hodgepodge mess where it's like no i just want a a potluck picker you know app it's going to be super simple and it's from all my friends in in you know in seattle they're coming to the potluck and i don't need like i know exactly what i need it to do boom custom bespoke Boom. My friends like click a thing and it's done.
31:00 Scott I was just laughing about that because a while ago, I mean a long while ago, some friends and I made a Zoom-like product. And it never got off the ground. I mean, when I say it never got off the ground, like we worked on it for two days, like that's how far it got. But I was just shuffling because what happens if everyone just starts making their own video conferencing software?
31:24 Brad Right. Well, that's a good example where you require the ability to have the person use the software, you know. that's i mean honestly that's one of the reasons zoom zoom is such so entrenched right it's like fuck i already installed it like there was the great like migration away from uh what was it before zoom it was the big one um i can't even remember it anymore skype
31:48 Scott Skype.
31:48 Brad yeah skype was dominant before zoom before that wasn't it like cintrix or something like that there
31:58 Scott Oh,
31:58 Brad was like a
31:58 Scott Citrix.
31:58 Brad one the
31:59 Scott Yeah.
31:59 Brad tricks
31:59 Scott Or
31:59 Brad or something
32:00 Scott it was
32:00 Brad like that
32:00 Scott called web. It's called web something.
32:02 Brad yeah
32:03 Scott I don't know.
32:04 Brad that
32:04 Scott There's one. something called.
32:06 Brad and those things those things basically like They were all predicated on don't make me install a new application just to make a do a video phone call with you. Right. And so it's just like that matters. Right. You know, standardization matters.
32:22 Scott Can we go all the way back to the original question?
32:24 Brad Yes. Let's do it.
32:26 Scott Because there was something that I didn't say earlier that I'm wondering about. Okay, so your original question was, how do we get product? owners to care about spectrum and development and as we were discussing one of the things I wrote down that I thought about was and this is a little bit of a small business idea not that but I mean not is there a market out there to do training for product owners about how to use a tool like SpecKit like should we be going and pitching to companies you need to hire us to do a two-day workshop with your product owners to teach them how to use this thing because in an AI world it will give your company an advantage.
33:13 Scott And I understand there is a lot of it's easy to train oneself on this.
33:18 Brad Mm
33:18 Scott Right.
33:18 Brad -hmm.
33:19 Scott But, you know, to some sometimes you've got to leave the horse to water.
33:22 Brad Yep.
33:22 Scott And I'm just wondering if it's both a need and an opportunity out there. And I want to say one little wrinkle before you answer that. I've said a few times. Having the product owner and the engineer and the designer sitting down next to each other doing spec kit. Some people say, well, why do we need the engineer anymore if the designer can just do spec kit? Well, I think I used an example earlier in this call where someone was using spec kit and the AI decided to use Bash instead of Python or whatever.
33:53 Brad Right.
33:53 Scott You need both sets of eyes reviewing the spec. They both people bring some expertise. One brings the expertise of this is our customer need. The other brings the expertise of this is how you build technology, good technology. These are the right tools for the job. We both
34:10 Brad Yeah.
34:10 Scott and maybe the designer, I don't know, I actually don't know how design fits in with spec kit to be perfectly honest with you. So I'm going to lied over that for a minute. But you need both sets of eyes to look at that spec.
34:22 Brad Yeah.
34:23 Scott So anyway, I'm just wondering if like as an industry we actually need to go out and proactively train people
34:30 Brad Well, first of all, I think your characterization of like you need somebody that understands how software is built correctly. And I think you're, you know, bash versus Python is a great example of like something that I wouldn't expect a product owner to be able to pick up on. I think you're right about the idea of them there being important skills that that AI development and spec kit and specter of development does not obviate. Right. As far as training them as to why this would be useful to them.
35:03 Scott Well, not even why, here's how you use it,
35:05 Brad Here's right? how to use it. Well, I think that's the challenge, right? The challenge is that I feel like I'm not sure. what the average product owner i think that i i'm a little worried that the reaction i've gotten from the average the product owners i've worked with will be that the reaction from the average product owner which is that's too much that's too much too many words tl tl dr too long didn't read
35:32 Scott so we don't we don't really want to do the work that's what you're saying we just want the engineers to take care of of course we thought just engineers took care of this hard part We've got to go do the fun part, just dream up of things.
35:44 Brad Uh, that's on brand. That's on brand for many, many product owners I've worked with in my career. No offense, guys, but yeah, that's that's on brand for what I've heard from most of them.
35:55 Scott I haven't really surveyed them, so I don't know. And I generally speaking, haven't had too many product owners I've worked with in the past that are just like you guys figured out.
36:05 Brad Well. I mean, again, like I think that we've had a look, all the jobs are changing, like like you said
36:11 Scott All
36:11 Brad it right like
36:12 Scott the jobs
36:12 Brad you
36:12 Scott are
36:12 Brad said
36:12 Scott changing.
36:12 Brad all the jobs are changing. And I think that like there's no doubt in my mind that five years ago, if I had brought a product owner in the room, an engineer in the room, a designer in the room, and I was to say, OK, who has the hardest job here? Right. Every single one of them would have raised their hand.
36:32 Scott Mm-hmm.
36:33 Brad and you'd be like okay cool uh product owner like what's what's why is your job the hardest job and their answer would basically be like well coming up with the ideas is the hard part right and the developer would say well of course my job is the hardest job because like actually taking your idea and making it work that's the hard part You Mm know, and
36:55 Scott -hmm.
36:56 Brad the designer would say, well, I have the hardest job because making your idea actually something people can use is the hard part. I do think there's a little bit of a everyone wanted to think that the part that they thought was the most fun was the hard part and the other parts of the job were not the hard part. And that's why it was OK that the other people were doing it.
37:21 Scott Absolutely.
37:22 Brad But I think that what we're really saying here is the reality is all three of those jobs matter. And they have to and they and they and so there so if you if you basically compress all three of those jobs into one job, that's a really hard job.
37:38 Scott an impossible job okay
37:40 Brad And Speck, it doesn't actually make it any easier. It just exposes how hard it is.
37:48 Scott now this is interesting so just maybe it was yesterday i kind of had this idea in my mind for like a it's just a version of spec kit as something fancy but imagine like a user interface that has like three panes i'm not sure if this is the right user interface we need a designer but so what i was trying to do is create an ide for spec driven development and i had in my mind i had this picture in my mind they have three panes three three think of it essentially as three text boxes but it's just three panes it had the designer pane the engineer pane and the and the product owner pane right and so that in my mind it was a little asynchronous like the product owner could go do their part and it might send them then the engineer could go put in some everybody could sort of do
38:34 Scott do parts asynchronously and there might even be sort of messages going back and forth between these different I guess each pane is essentially just a chat you know a GPT chat kind of thing right so like like so that it was a tool for this like really brought this collaboration into one window like we all have to do a part of this to come out with ultimately the the main or the single spec that we then give to the robot because all three parts are important man you've really flummoxed me today on this one lots
39:04 Brad Let's
39:04 Scott of times we talk about stuff and i feel like oh i know the answer to this but today
39:10 Brad I think that it's a wild world out there, Scott. It's getting wild. It's getting wilder by the minute. And I think that a lot of, you know, as the kids say, a lot of work was being done by the structure that we have grown up in the last couple decades. And that work was hiding the complexity. of really knowing how to build software and
39:40 Scott Mm-hmm.
39:41 Brad you know the fact that writing code took time a lot of time and that time has now evaporated has exposed the fact that the other parts of the disciplines need to catch up and isn't and it's hard They need to catch up or it's like just putting stress on a different part of the system.
40:04 Scott Okay, fine. Yes, both. It's putting a stress. The stress used to be, right? Like the pressure used to be the writing of the code was the hardest part, was the most expensive part, was the slowest part. That's not the slowest part anymore. By a long shot.
40:24 Brad Right. Now the slowest part is, well, it was the slowest part and the most valuable part. And that's why people are paid what they're paid. And now we're going to maybe see that shift.
40:34 Scott Yeah, there you go.
40:35 Brad Everything's a K-shape.
40:37 Scott Everything's a K-shape. Well, maybe the answer, by the way, to my original question, I'll just posit this is how do you get product owners to care about spec driven development? Maybe the answer to that is because the AI is coming for their job too.
40:54 Brad Ooh, is that another episode or give me a preview on that episode.
41:00 Scott I mean, the fact that SpeckKit already comes up with the user stories that the product owner didn't even think of and comes up with the. uh gaps in the in the plan that will create ambiguity down the road like on its first cut that means like it's not far from coming up with those ambiguities and coming up with the best answers to those ambiguities it already recommends the answers to the ambiguities
41:28 Brad Yes, but I would actually go one step further upstream. Recently, I was chatting with a former colleague and friend who has spent a lot of time working in the tech incubator world and in a variety of different aspects. And he was talking about how AI is changing everything and he wants to start a company and blah, blah, blah. And I said to him, I was like, well, how can we get AI to give us the ideas?
41:56 Scott Oh,
41:57 Brad like
41:57 Scott yeah.
41:57 Brad the the core nugget like once you say like hey we're going to go into the business of making ballpoint pens like then the user stories flow from that inspect kit can help us make the user stories better but somebody had to have the observation in the first point first place which is like these fountain pens are really messy
42:15 Scott Yeah.
42:15 Brad And...
42:16 Scott Well, didn't like, I mean, Pioneer Square Labs, right? And our friend Kevin, right? Like they, they did a bunch of work, they've done a bunch of work where they, they were just like idea generation, and they had a pretty good formula for both idea generation as well as like idea market. fit evaluation you know is
42:37 Brad They
42:37 Scott it a practical
42:37 Brad were doing that with AI?
42:38 Scott um i yeah they uh yeah they they think they announced this like six months ago they built a little website like just go in there and just like click a button and it comes up with a bunch of ideas and then does a market fit analysis and and things like that so yeah
42:50 Brad I vaguely remember that.
42:52 Scott and i think there's i mean i think that's for sure coming Right. Like it's for sure the case that you can evaluate ideas pretty aggressively about like, you know, how big their market, how big the market is, how big the TAM is, you
43:08 Brad Mm
43:08 Scott know, what
43:09 Brad hmm.
43:09 Scott the likely price sensitivity will be, you know, that stuff I think is, how do I say it, like formula like formulizable, you know, it's.
43:18 Brad Yep. Yep. Can be formalized. So then then you have to go. upstream one more level and say okay we've got all these ideas across all these different industries all these different categories all these different it's all these different geographies at some point well i have a hypothesis which might not be true and i'll tell you the false statement at some point there has to be a human insight to the world something that we see about the world that is not visible to the computers computers that
43:49 Scott Yeah.
43:49 Brad can help us see, oh, people need software to solve this problem. And if you want it to be a business, and they'll pay me money for that software, okay?
43:59 Scott Yeah.
44:00 Brad That's fundamentally it. Now, that's my hypothesis, which is that has to be true. Otherwise, if it's not true, then the robots are taken over.
44:10 Scott Some would say that's going to be the outcome.
44:12 Brad Right. So it's like it's getting it's getting all the way to that point, which is I know something about Seattle or I know something about real estate agents or I know something about baseball cap manufacturers that the none of the rest of the world either understands or knows.
44:27 Scott Well, this is the argument that I made. This is the argument I made, and this is not a novel idea. Plenty of people are saying this, is that it's the entrepreneurs, people who are entrepreneurial, who have a unique insight into a particular target customer because of their entrepreneurial founder market fit, they are the ones that will be able to use this. these technologies to essentially build you know like the there's the concept of the one person unicorn company right like there's like that's you know there's a whole bunch in you know on call she and polymarket there's like current like over under on like when will the first single person unicorn billion dollar company you know exist
45:15 Brad Mm-hmm.
45:15 Scott right and so people are for sure calling that as a trend that they think is going to happen and it's going to be someone who has a someone to your point who has this unique insight into the human condition and the desires of humans to spend money on on something on software and then boom Having it built and then the argument goes something like and the second that that product is released There will be a dozen copies of it. So it will be difficult to to be defensed to defend that or
45:46 Brad So that product has to have a network effect.
45:49 Scott some other some other meaningful moat that protects its You know market share All
45:58 Brad So
45:58 Scott right.
45:58 Brad what does this mean for guys like me? I'm not good at that, okay? Let me tell you something. There have been a few times in my life where I've had an idea for something and I didn't follow my gut. And I was wrong and I was a fool because
46:16 Scott and someone else made it so then you maybe we're good at it you just didn't follow through maybe that was because you didn't have the tooling necessary but now you do you
46:24 Brad Well, okay. I'm not gonna I'm gonna toot my own horn for a second Spotify
46:29 Scott invented led light bulbs yeah I mean,
46:35 Brad in
46:35 Scott who didn't see that
46:35 Brad about
46:35 Scott coming?
46:35 Brad 1996 or so i
46:37 Scott Yeah.
46:38 Brad just got my first broadband internet i just got my first whatever it was back then napster limelight or another thing i was getting music off the internet right because like you i was really into music i was trading grateful dead tapes i was doing all that stuff right and like i got this thing and i'm getting music off the internet and i'm burning it to cds right and i'm out of the ball i'm at a bar with some of my friends with my friend serena her boyfriend Brett and another friend of ours Ariel and I'm like guys I don't think anybody's going to buy CDs anymore they're
47:07 Scott Right.
47:07 Brad just going to get their music over the internet they're like how are they going to listen to it I'm like well they're either going to listen to it from their computer or they're going to like burn it to a CD and then they're going to listen to it in their car
47:19 Scott Right.
47:19 Brad and this was at a bar in Fremont Seattle it's not around anymore dad Watson's and they talked me out of it they were like that's crazy nobody's gonna do that and I was like I was trying to convince them like guys I've been doing this I've been downloading all this music it's amazing like you get everything what you want it's all going to be like right here this is how it's going to work and they were like that's you you were What are you on? What are you smoking, Scott? And then I walked away from that and we were just hanging out at the bar one night and I was like, oh, maybe they're right. Maybe nobody will do this. Anyway, the point I'm trying to make is I'm not really that guy who has the insight. I've always been the guy in my career where when somebody has an insight, I've been like, oh, I know how we could make that. Like I know how to do the engineering. I know how to build
48:02 Scott Yeah,
48:02 Brad that.
48:02 Scott yeah
48:02 Brad Right. Gosh darn it. Are we all after all the builders effed?
48:07 Scott I mean, I don't know how I say that, but I'm saying like, I'm saying the entrepreneurs, yeah,
48:14 Brad Or
48:14 Scott I'm saying
48:15 Brad not
48:15 Scott like.
48:15 Brad yet. That's
48:16 Scott how much a good drink
48:16 Brad corduroys
48:16 Scott yeah
48:17 Brad are not asked.
48:17 Scott yeah i mean like the idea of streaming was something that obviously i you know that's like near and dear to my heart that's what i was working at you know real
48:26 Brad Yeah, Warner
48:27 Scott networks
48:27 Brad networks.
48:27 Scott in 1994 and and we built that and it was very very expensive to build what build what we built and you know eventually and i would argue that we were you know we're kind of like i mean did did fine right and built a cool product and helped lay the foundation for stuff but But, you know, it was early. We had to build a lot of stuff that now, you know, it's just like we had to build stuff that like is just doesn't matter anymore because the technology of Internet has the Internet has changed and, you know, YouTube.
48:55 Brad Invented.
48:55 Scott Well.
48:56 Brad What were you going to say about YouTube?
48:58 Scott I was just going to say, like, you know, YouTube, Real Networks had a secret project that they were working on that was effectively YouTube about five years before YouTube. But the hard part was that at the time, Real Networks was already pretty well established with media companies. They were already doing licensing with media companies. And the thing that made YouTube take off, of course, was the fact that users uploaded.
49:23 Brad Mm
49:23 Scott copyrighted
49:23 Brad -hmm.
49:24 Scott material right and it you know and so you know there was a that was a challenging time for real networks because we knew we had the idea we're like people definitely are going to want to do this like this is something that people are going to want to do but we couldn't bring ourselves to do it because we had business relationships with all the the media companies we were selling digital rights management software to them and and things like that so it was like we know that like We couldn't be the rogue actor that was going to disrupt
49:48 Brad Mm
49:49 Scott things because of our existing business relationships,
49:51 Brad -hmm.
49:51 Scott right?
49:52 Brad You're the man to YouTube, man. That's awesome.
49:55 Scott Yeah, we did. Not really, because it was like five years later and somebody that wasn't as encumbered as us did it. But we knew we could see it. We could see clearly people wanted that, you know. And
50:06 Brad Yeah.
50:06 Scott so I guess to my to to finish this out, to go back to the original, right, I think that the the the core issue here is that knowing what you want, having a vague idea of what you want. want was never sufficient to build a business and
50:24 Brad Mm-hmm.
50:25 Scott if you were better at describing what you want or you had people like you and I that were really good builders that would were able to kind of riff off of what you said vaguely and build something quickly that you then could criticize like that's been the way of the world for the last 20 years plus okay that way of doing things is not going to work anymore because it's even faster to build things it's no longer and it's no longer a moat to have built something and so it's all going to come down to are you actually good at describing the problem that you really want and is the problem you want to build actually a useful problem so maybe The answer to the question of how many CTOs does it take to get product owners to care about spec kit is it's however many it takes to convince the product owners that getting their definition correct is the most important thing for them to keep being able to compete.
51:23 Scott with their competitors, with upstarts, and the AI that will come after their job too.
51:31 Brad It's wild, man. I don't even know what to say. It's wild. Okay. What do we say for the four people who listened all the way to the end of this episode? Cause we've been talking for like 90 minutes. What do we say, Rad?
51:45 Scott We say smash that subscribe button. Rate and review.
51:49 Brad Thank you for listening. We appreciate you and don't hesitate to leave us a comment or shoot us a note if you want.
51:56 Scott Yeah. All right. Next week, we'll talk to you again soon, Scott.
52:01 Brad Adios, Brad. Adios.
52:03 Scott This episode of the How Many CTOs Does It Take podcast was produced and edited by Safran Heptacow. Our theme song was AI Generated by Brad. Please follow us on all the social media platforms at HowManyCTOsPod. You can find us on YouTube, LinkedIn, Instagram, Facebook, Threads, X, TikTok, and Patreon, or at our website at HowManyCTOsPod.com. dot com and remember to rate review and subscribe on the podcast platform of your choice thanks for listening
