(0:01) I don't think that the long part for me was making the skill. (0:04) I think it took me five minutes to make the skill. (0:06) The long part for me in the last month (0:08) has been enforcing the skills at a scale globally (0:15) and building a user experience for developers (0:20) that supports it without any instruction from a human. (0:23) That's the hard part for me. (0:25) That's been the hard part for me. (0:36) I've got 16 different skills buckets (0:47) and I had Quad do all the formatting for me, (0:54) but I looked at resources that helped me (0:57) to actually build these in a very detailed way. (1:04) And then I gave it the format of this. (1:06) So I said, your template has to include, (1:09) why does it exist? (1:13) The workflow, before you can call it done, (1:17) what do you need to actually have in it? (1:21) There are all the reference files. (1:23) There's like different files that are under a skill for me (1:27) for all this stuff. (1:30) And then what's the, (1:31) what is the way that you build the receipt (1:35) when you are checking the quality of this? (1:39) And then I might have sources to stuff. (1:43) So that wasn't the first iteration of skills. (1:45) That was the third for me. (1:51) Okay, this strawberry is gonna teach you product management. (2:02) Here's the FigGen link. (2:09) Raise your hand. (2:10) Raise your hand if you are trying (2:12) to get into product management. (2:18) Raise your hand. (2:25) Okay, raise your hand if you're trying to get (2:26) into UX design or UX research. (2:35) Okay, that's right. (2:37) Raise your hand if you're trying to be a developer engineer, (2:40) like technical person. (2:53) You're not gonna believe me when I say this, (2:54) but everything that I'm teaching you (2:56) in this lecture tonight, (2:58) you can do in under two hours with Cloud. (3:01) And I can prove it to you (3:03) because I did it this weekend in an hour. (3:05) Not because I know 10 years of experience. (3:10) It's because all the above counts. (3:14) It's because the templates and cloud code, (3:20) cloud correct in this case, (3:24) make it possible to do so fast. (3:27) So we have to talk about non-engineering things (3:33) before we can engineer things. (3:36) What you're gonna do this week, (3:38) can everybody do me a favor (3:39) and can you go on mute if you're not talking? (3:43) Just for the sake of the recording, (3:45) we have like clean audio. (3:48) Do you all mind if you mute your audio? (3:58) Thank you, just for the sake of the recording. (4:04) Appreciate you all. (4:06) Before we hop into coding, (4:08) we have to give the coder or the person (4:13) or the designer the specifications. (4:19) And there's so many different types of ways (4:22) that this could go wrong. (4:24) So many different areas where (4:27) what you want to build in the end (4:29) and what you wanna ship (4:30) and what you wanna launch and maintain in the world (4:33) doesn't become a reality for so many different reasons. (4:41) And I'm gonna talk about all the standards that, (4:44) yes, we still do. (4:45) We don't abandon any of these standards (4:48) because we have an AI tool involved. (4:52) A lot of people might make you think like (4:54) we don't do requirements anymore because we have AI. (4:56) We can just bang away at a computer. (4:57) That's not true because what are the risks (4:59) of banging away at a computer and vibe coding? (5:03) We talked about them last week. (5:05) Everything will go wrong (5:07) if you don't align with the people around you (5:11) and the robots around you (5:12) and all move toward the same direction at the same time. (5:15) So the process is still very much so the same. (5:21) It's very fast compared to what it was (5:26) maybe before we used AI to produce things. (5:32) But the process is not dead. (5:34) The work is not dead. (5:36) Nothing changes in terms of the need for the work (5:40) and all of the things that need to happen (5:42) before you get into development and design (5:44) and product launches, they don't go away. (5:49) AI development has to have that as a precursor. (5:55) If you want to build something that is enterprise ready, (6:00) you need this. (6:03) And there's a lot of it. (6:05) What we're about to go over. (6:07) The green circles, I tried to make it (6:12) I'm doing this visual stuff of this circle stuff (6:16) for the first time. (6:17) Last week I gave you the whole thing. (6:18) What are all the green circles in the class? (6:22) And now, and I also gave you all the deliverables (6:26) in the class. (6:26) And now I'm gonna show you what each week (6:29) we are going to learn. (6:32) So if you want to read about this stuff, (6:37) there is a fantastic resource called (6:40) the Skills and Practices Framework in TechFleet (6:42) that you can learn all about this stuff. (6:46) I'm gonna go through an entire course (6:49) worth of material in 40 minutes (6:53) to get you what you need to be able to actually produce (6:58) enterprise ready development. (7:00) When you get out onto teams, (7:03) you might not be the people doing it. (7:06) Directly. (7:08) But you have to be able to know the fundamentals (7:11) and these are the fundamentals in a huge way. (7:15) These are the fundamentals of making enterprise apps happen. (7:21) So get ready. (7:23) Are you mentally ready? (7:25) Let me see the emojis that aren't just thumbs up (7:28) that show me that you're mentally ready (7:30) for this strawberry to talk at you for 45 minutes (7:34) and to give you an entire course as I dance. (7:38) That's not enough emojis. (7:39) I'm gonna keep dancing until you give me enough emojis. (7:43) This is called the strawberry patch. (7:49) The best strawberries are at the back of the patch. (7:52) You have to go to the back of the patch. (7:58) Okay, so I expect you to, if you wanna learn about it, (8:01) if you wanna dig into these materials, (8:04) dig into them outside of class. (8:06) This class's scope has to cover just enough for you (8:08) to be able to make specs that are enterprise ready. (8:11) And I'm gonna do that. (8:15) We're gonna cover an entire course in 45 minutes. (8:23) What happens when you don't have this stuff? (8:28) Well, there's a pretty famous meme that talks about (8:35) the lack of shared understanding that happens (8:36) when you don't have these specifications (8:39) in the process of making things (8:43) and whether you're even solving the right problem (8:45) in the first place. (8:45) And I made a version that has to do with cake. (8:49) So here it is from the perspective of cake. (8:53) A customer could come to you and be like, (8:55) I want a cake that's strawberry icing and yellow lemon. (9:02) And I want a candle on it because it's my anniversary. (9:06) And the chef, the waiter's like, got it. (9:10) And they write it down, but they don't got it. (9:13) They have a different understanding (9:14) than what the person who thought they had described it said (9:19) because there were things that they weren't describing (9:22) that didn't really tell the whole story. (9:24) And there was a misunderstanding (9:27) when words weren't even exchanged to that level. (9:31) And so the waiter walked away with a different understanding (9:35) about the cake than what the customer described. (9:42) And so the waiter goes to the chef and is like, (9:44) we need this and that and this and that (9:47) and this and that and this. (9:48) And the chef is like, got it. (9:51) But he doesn't. (9:54) They have a completely different understanding (9:57) about what's being produced. (10:00) They have their own vision about it (10:01) and they envision something completely different (10:04) than what has been passed along, (10:07) which is completely different than what the waiter said, (10:09) which is completely different than what the customer said. (10:11) And the customer really doesn't have any good idea (10:14) about what they actually need. (10:17) And yet here we are, a giant game of telephone (10:20) in the style of cake. (10:23) Meanwhile, the restaurant thinks (10:26) that they're on some completely different level. (10:30) They don't actually think that the people (10:33) in the restaurant are building a cake at all. (10:34) They think they're building a pie. (10:36) They have a different understanding of it. (10:38) Like, oh yeah, it's gonna be a great pie. (10:40) It's a cherry pie. (10:42) It's gonna be great. (10:45) Meanwhile, Evil Cake Corporation is sitting over there (10:48) with their evil demons and their voodoo dolls (10:51) and their poison. (10:53) And they have a completely different picture (10:55) of what that cake should be (10:56) because they're trying to put plague into the cake. (11:01) And when the chef made it, (11:03) of course the chef didn't follow a recipe (11:07) because everybody has a different understanding (11:08) and nothing is shared between everybody. (11:11) So they winged it. (11:15) And then the cake turned out like a mangled piece of mess, (11:21) not like the original, not even like the chef envisioned, (11:25) not like the waiter talked about (11:27) or the customer envisioned, (11:30) but the customer was definitely billed for a lot of money. (11:35) And when they needed support, (11:38) they were supported in a completely different way (11:40) than what they needed (11:43) because there was no shared understanding (11:45) between everybody. (11:47) And guess what? (11:49) None of that would have solved the problem (11:51) that the customer didn't even think about describing (11:54) in the right way. (11:56) We'd be on a completely different playing field (11:59) of delivering the right thing (12:01) to the right people in the right ways (12:03) if we had only looked at past what the customer was saying (12:09) and got everybody on the same page (12:12) about what are we committing to? (12:14) What's happening right now that needs to change? (12:17) How do we know that we're done? (12:22) You can translate the software team or UX team, whatever. (12:26) How many people have faced this scenario before? (12:31) Raise your hand if you've been on a team (12:33) and everybody has a different understanding (12:35) about what needs to be done (12:38) if you've ever been in that situation before. (12:43) Me, I definitely have. (12:48) It's extremely easy for that to happen. (12:53) This is why we need requirements. (12:57) Whenever you get into a room (13:01) and you hear from a client, (13:03) we need to build this app that does this. (13:07) Guess what? (13:08) You're not order takers. (13:12) You're not completely taking the order (13:14) and delivering what was ordered (13:16) because is that actually gonna solve the right problem? (13:20) Probably not. (13:24) If we're UX people and product people and researchers (13:27) and even developers, we're problem solvers. (13:31) We're not deliverers of the work. (13:34) We're engineers. (13:36) We are problem solving at the heart. (13:41) So we gotta get on the same page (13:43) about what problems we're trying to align to. (13:46) There's not just one. (13:48) There are hundreds and hundreds and hundreds of them (13:52) in a single app, in a single solution. (13:58) We have to be able to take that request (13:59) and break those things down into a common language (14:02) around what's happening right now (14:05) and what are the goals that we need to achieve (14:06) and what are the expectations. (14:10) That is what is called requirements. (14:14) Requirements are the instructions for delivery (14:22) to produce the best version of the work (14:26) that solves the right problems in the right ways. (14:28) There are different types of requirements. (14:30) There are what's called research requirements, (14:34) which is everything that a researcher needs to do their work (14:38) to solve the right problems (14:40) and solve the problems in the correct ways. (14:42) That might include market analysis. (14:46) That might include personas, vision, scope (14:51) or a backlog of questions that you want to know. (14:55) There are also the requirements that a designer needs (15:00) to do their work and solve the best problems (15:03) in the right ways for the right people (15:05) for the right reasons. (15:09) Those might look like what's called user story statements. (15:15) They might look like scenarios that we give people (15:18) and walk them through a scenario. (15:21) It might look like a task flow. (15:23) The end result of that is gonna be (15:25) a designer produces the right experience. (15:31) And then there are development requirements. (15:34) That's everything that the developer needs (15:36) to do their thing and solve the right problems (15:39) in the right ways and align everybody else to the outcome. (15:45) That will include design specs, design systems, (15:51) prototypes that are high fidelity, annotations, (15:55) flow charts, and written instructions. (16:00) Might be technical scenarios, technical architecture. (16:05) It's whatever the developer needs to do their thing. (16:10) And here's the kicker. (16:13) None of that ever. (16:17) No matter how confident you are, (16:20) no matter how much someone's pushing for something, (16:22) no matter how much research you have collected, (16:25) none of it is gonna be the truth (16:27) until you build at scale. (16:32) Everything that you do, all the design decisions (16:36) that you make, all of the product decisions that you make, (16:40) all the things that the boss is shoving down your throat, (16:42) all the things that the client wants to do, (16:45) all the strong opinions that your designers have (16:48) or your developers have about, (16:49) well, this is the right way to do it. (16:51) None of that is the truth. (16:53) Everything is an assumption. (16:56) We agilists operate in that mindset. (17:00) We do not seek validating the truth. (17:03) We seek validating assumptions, (17:07) collecting data, forming new assumptions (17:10) after we test those assumptions. (17:13) We're scientists. (17:15) We have ideas and we learn. (17:19) And we might build, and that might be, (17:21) after launch, we might learn as well. (17:24) We might take both paths from idea to learn (17:27) or ideal to build to launch to learn, both ways. (17:32) Everything that we do in this part of the work (17:38) is not the truth. (17:42) The vision is not a final piece of material. (17:45) The research analysis that you have (17:47) is not a final piece of data. (17:51) The release scope that you might make that says, (17:54) here's all the features that we want to build, (17:56) your roadmap, they're all assumptions. (18:02) They have to be shipped and validated (18:06) and tested and challenged. (18:10) And the sooner we do that as agilists, (18:13) the sooner we can learn (18:14) how does that assumption need to change? (18:17) What assumptions now need to go into the vision (18:19) that wasn't there before? (18:22) And those aren't the pieces of truth. (18:24) Those are not anything related to the truth. (18:28) They're new assumptions. (18:32) We have to operate in this way. (18:34) We operate in the cycle that everything gets produced (18:38) and put into the hands of people quickly (18:39) because we are always learning, (18:47) always, always, always, always learning (18:49) what is going to be the new assumption (18:53) that we need to validate. (18:55) So this whole life cycle happens as quickly (18:59) as it needs to happen. (19:01) It's continuous because we operate off of the notion (19:07) that everything that we do is an assumption. (19:14) That doesn't mean that we freeze. (19:17) We haven't done any research. (19:20) It means the opposite. (19:21) It means that we're producing requirements (19:23) like personas, competitive analysis, problem statements, (19:29) even before we might have research (19:31) because then those will be the grounding for research (19:36) to validate the assumptions (19:37) that we put into those materials. (19:40) Have you ever heard of proto-personas before? (19:42) Has anybody ever heard that term, proto-personas? (19:46) Raise your hand if you've heard the term proto-personas. (19:52) A traditional persona is made from a lot of research. (19:58) You do a lot of research and you have to finish that phase (20:01) before you do your persona. (20:03) A proto-persona is made by complete guesses (20:07) and you use it as a grounding for research. (20:11) That's the way that you're gonna treat anything (20:15) that comes with requirements, (20:18) anything that comes with product vision and product scope, (20:21) all of it is assumptions (20:23) that the sooner you get to some type of usable result (20:27) in the hands of people, (20:29) the sooner you can validate the assumptions. (20:34) We live on a continuous cycle of every decision (20:39) that we make is an assumption (20:41) that we bring to research somehow, some way. (20:45) So this week, all the things in green (20:48) are gonna be the things that we're gonna do (20:49) that are assumptions that serve as requirements (20:57) for implementation work. (20:59) Implementation work will be research, (21:02) design, development, content, (21:05) whatever production work you can think of. (21:07) There's also research that happens (21:10) in that process called discovery that never stops. (21:15) But even after research, those are still assumptions. (21:20) The analysis of this is not the formation of truth. (21:25) It is the formation of more confident assumptions. (21:32) I want you to come off mute and repeat after me, (21:37) everything in product requirements (21:40) is an assumption that we test. (21:42) Say it. (21:44) Everything in product requirements (21:47) is an assumption that we test. (21:50) Nothing is the truth. (21:52) Say it. (21:53) Nothing is the truth. (21:55) Everything is an assumption. (21:57) Say it. (21:58) Everything is an assumption. (22:02) What are your beautiful prototypes? (22:04) What are they? (22:06) Assumptions. (22:08) What is that product vision? (22:10) Assumptions. (22:11) Assumptions. (22:13) What is that code that you just produced (22:14) that you're about to launch? (22:18) Assumptions. (22:19) They're certainly not the truth. (22:21) The only time you'll ever get to the truth (22:23) is if you have millions and millions and millions (22:26) of people using that thing that you're producing. (22:29) It's called representative of the population. (22:34) If you have millions of data points, (22:37) yeah, you have something closer to truth than anything, (22:42) but I would argue that it's a state that you always seek (22:47) and you never really get to. (22:48) Everything is an assumption all the time, no matter what. (22:51) No matter what you're producing, (22:52) no matter how strongly someone feels about these designs (22:55) or this decision that you make in the product, (22:58) it's not the truth. (22:59) It's an assumption. (23:01) You, as shippers of the work, (23:04) have to get that thing into the hands of people (23:06) as quickly as possible to validate all the assumptions. (23:13) If you can solidify this mindset in your mind, (23:16) this is probably the biggest mindset that people that, (23:20) I had to get untrained this way too. (23:23) A lot of people in school get trained in waterfall (23:28) where you have to get it perfect. (23:30) And once you do research, it's considered the truth. (23:33) We did research. (23:34) We don't need to do research anymore. (23:36) We already did it. (23:39) Yeah, you do still need to do research (23:41) because why? (23:43) Tell me class, why do we need to do research after research? (23:48) Why, why, why? (23:49) Tell me. (23:50) They're all just assumptions. (23:51) They're all just assumptions. (23:54) Everything is an assumption. (23:56) If you can stick with that in your mind, (23:58) you will become a person that has an agile mindset (24:02) in the way that you approach the work. (24:05) Here's the other thing that we have to understand (24:08) when we approach the work in an agile way. (24:11) There are no titles on agile teams that are cross-functional. (24:18) You have different types of responsibilities, (24:21) different types of things that you might commit to. (24:24) And those are called duties. (24:26) But one person could have a single job title (24:29) and have many duties and those duties might change. (24:33) So when you try to answer the question, (24:35) who writes requirements? (24:37) You might have a person that's in a job title (24:41) called a business analyst, maybe. (24:45) That duty writes requirements, gathers requirements. (24:49) But guess what? (24:51) There could be no person called the business analysis person (24:56) and the person called the product designer might do it. (25:00) The person called the product manager (25:01) or the product owner might do it. (25:03) The person called the UX designer might do it. (25:05) The UX researcher might do it. (25:07) The CEO might do it. (25:10) It's just a duty. (25:11) You'll see different things happen in the world. (25:14) How that's all set up is up to the company. (25:18) It could change. (25:18) It could be fluid. (25:23) On the level of this class, (25:26) this is a breakdown of, (25:27) we use the term like the metaphor of hat in tech fleet. (25:33) This is you as when we call you an AI developer. (25:40) Well, it's actually everything but development. (25:44) Maybe we shouldn't call it AI developer (25:47) because you're wearing the following hats. (25:51) The product manager hat, the QA hat, (25:55) the technical architect hat, (25:58) the business analysis hat. (26:01) You're gathering a ton of requirements (26:03) and collecting a ton of requirements. (26:05) You're also the information security analyst hat (26:10) and you might handle a lot of operations (26:14) and you might run the product team called the product owner (26:19) and you're gonna make cakes. (26:21) And whether you have a human or a bot producing code, (26:32) Claude will be the actual developer (26:36) but you could have a human. (26:39) Claude's a teammate. (26:41) Claude is going to be responsible for development, (26:46) the decisions of technical architecture with you. (26:49) So you're both technical architects. (26:52) You're both gathering requirements and writing requirements (26:56) and you're both trying to secure the apps that you built. (27:02) And Claude could also produce UX designs (27:08) and you definitely don't want a robot performing research, (27:14) making it up, but other humans could be researchers as well. (27:20) And Claude becomes a contributor on your team. (27:24) But these hats are fluid. (27:26) You could take hats away from Claude. (27:30) You could break these hats up (27:32) and have them change every two weeks, (27:35) just like a cross-functional team (27:37) might have different people that changes every two weeks. (27:42) Whatever that setup is, (27:44) that's what's called product operations. (27:47) That is gonna change based on what makes sense to the team (27:50) and what they can decide. (27:54) But I think it's worth breaking down. (27:56) What are the responsibilities of Claude? (27:57) What are the responsibilities of you? (28:01) The human in the loop, when we say that word, (28:05) we actually mean that you're responsible (28:07) for a lot of things. (28:09) You could be responsible for development too. (28:12) If you were actually coding, (28:14) you'd wear the developer hat. (28:16) But you don't need the developer hat to be a developer. (28:19) You need to be able to orchestrate whoever the developers are. (28:25) So what do you call that job title? (28:26) I don't know. (28:28) I guess 10 different people are gonna call it (28:31) 10 different things. (28:32) I'm gonna call that a product manager (28:34) if I was hiring someone these days. (28:38) This is heavily under, (28:39) it's all under the territory of a product management. (28:44) And I don't wanna give a job title to it (28:46) because it might put an idea in your head (28:47) that, oh, that's product management. (28:51) Product management looks different for every single company (28:54) because they all define the hats (28:56) that they want product managers to wear. (28:59) So you can't look at the job title. (29:00) You gotta look at the hats. (29:02) The hats that you're gonna wear in this class are these. (29:05) You're gonna be doing these duties. (29:07) If you wanna know what these duties are, (29:09) there's a ton of resources (29:11) that you can learn a lot more about them. (29:14) You can ask Fleety about them. (29:16) There's a framework called the Skills and Practices Framework (29:20) that you can go wild learning the rigors (29:23) of all these hats. (29:27) When we talk about requirements, (29:30) we are not building what's called the PRD. (29:35) That is extremely waterfall. (29:38) That is extremely contract-based. (29:43) Raise your hand if you've heard that word before, PRD. (29:55) Okay. (29:56) All five of you who raised your hand, (29:58) I want you to metaphorically throw that word out the window (30:01) because it's gone now. (30:03) And I'm gonna show you how real agile people do it. (30:07) They don't build one doc before they get everything ready. (30:10) They build things in iterations. (30:12) They build backlogs that have the understanding (30:16) that builds on itself because everything is in, (30:21) answer that question class, fill in the blank. (30:24) Everything is a what? (30:26) Assumption. (30:27) Okay. (30:28) And then the sooner that we validate assumptions, (30:31) the sooner our backlog is gonna change. (30:33) The sooner our requirements are gonna change. (30:35) So I'm not gonna waste time building a giant document (30:38) that changes all the time. (30:40) That's a lot of energy waste that I don't want (30:42) as an agilist. (30:43) So we do not make a document that's 30 pages long (30:48) that details 10 years worth of plans. (30:52) That's a huge waste of time and a huge waste of energy (30:55) if we're gonna ship early and often. (30:58) We don't gather all the requirements upfront. (31:00) We don't need clarity before we start the work. (31:04) We don't build a contract before we start the work. (31:09) We don't need to know the answers before we start the work. (31:12) We follow the Agile manifesto. (31:15) We collaborate with people to figure it out. (31:18) We interact with people. (31:20) We ship and learn and we respond to change. (31:24) And your requirements have to follow all those two. (31:27) So everything is a draft because everything is a, (31:31) fill in the blank. (31:33) Assumption. (31:34) Assumption. (31:36) So I don't spend a lot of energy doing requirements. (31:39) I just get it to good. (31:40) I get the assumption up and out, (31:42) get an alignment and agreement, (31:44) ship it and learn what I need to adjust. (31:47) We gather requirements all the time. (31:50) We might just focus on the most important requirements first. (31:55) We do requirements and development (31:57) and design work in parallel. (31:59) And we release continuously, constantly, (32:02) day in, day out, producing, producing, producing. (32:06) Here's what it might look like. (32:08) You create some type of idea for a release. (32:12) I'll show you what that looks like. (32:13) Called a vision. (32:16) And a paired item for that would be called the scope. (32:21) They're all assumptions. (32:23) So everything is in draft all the time (32:26) because they're not final. (32:28) The sooner I get to some type of delivery, (32:31) the sooner that thing's gonna change. (32:32) The sooner I do research, (32:34) the sooner that vision and scope is gonna change. (32:36) I look at them as assumptions. (32:38) I look at them as drafts. (32:40) Then I will break down categories of work (32:45) to build a backlog. (32:47) And I don't put all the work in the backlog. (32:49) I just put just enough work (32:50) to deliver the first two weeks worth of work. (32:55) And then I get the development into the hands of people. (33:01) I start the design and the development work. (33:03) I might need to get like some instructions (33:05) to get that going. (33:07) And I deliver, and then I keep adjusting. (33:10) Keep going back to the vision, (33:12) adjust the scope, so on and so forth. (33:15) This is what it might look like. (33:16) This is called a vision board. (33:19) This is what you usually start with (33:20) when you are trying to gather (33:22) the most important things at a release level. (33:27) The pieces of information that you need (33:30) are who are you building for? (33:34) What's happening right now that needs to change? (33:38) What outcomes are you trying to achieve? (33:43) What value are you going to provide (33:46) when you solve those problems? (33:49) What makes you unique on the market? (33:53) What are the barriers that stand in your way of succeeding? (33:59) What are the costs that go into the release? (34:03) How are you going to measure success? (34:06) And what are the scenarios that you're going to support (34:10) in the release? (34:12) You start there. (34:14) You might build two of these. (34:16) You might build one board for the first release (34:19) and one board for like a market release. (34:23) The first release is called MVP1. (34:28) And there's an unlimited number of MVPs. (34:34) MVPs are also features. (34:37) Just think of it as minimal usable testable valuable. (34:42) Whatever the minimal usable testable valuable thing is, (34:46) that's an MVP. (34:48) I'm going to build some type of vision board for that first. (34:51) And then I'm going to build a vision board (34:52) for the long-term release that goes to market (34:56) maybe because everything is a, say it class. (35:03) Assumption. (35:04) Assumption. (35:06) So what is the definition of the market release? (35:10) Is it the truth? (35:13) It's a fancy assumption. (35:15) It's a very fancy assumption. (35:18) It's a really tantalizing assumption (35:25) because it's got a lot of fancy things (35:27) that might be maybe released, (35:29) but we're not relying on that as the truth. (35:31) We're relying on it as a draft. (35:34) And we are focusing on the first release (35:38) that the sooner we ship it, (35:40) the sooner we learn if the assumptions are wrong. (35:43) Then you can break this down at a release level to say, (35:48) we will produce this value in the world (35:53) by achieving these outcomes. (35:55) I do not want to see solutions in this. (36:01) You are not the determiner of solutions. (36:05) In order for you to avoid the cake catastrophe (36:08) where everybody's got a different idea in their head, (36:11) you don't want to limit the producers of the work (36:15) to any given solution. (36:17) You want to give them outcomes to achieve. (36:21) That's the same if you're working with a human (36:23) or you're working with Claude. (36:27) I'm going to show what we want to achieve, not how. (36:31) So here's the example. (36:32) We will build a framework for agile product development (36:36) that's a value by helping people build knowledge (36:41) about agile methods and philosophies. (36:44) How? (36:46) Well, I might sit in a rocking chair in their living room (36:49) and tell them a story about agile. (36:50) That's a solution. (36:51) I might send a carrier pigeon (36:53) to their porch every day for a week (36:56) and have a gauntlet carrier pigeon, (37:00) just like an email campaign that you received, (37:02) but a pigeon. (37:03) That's a solution. (37:05) That's a viable solution. (37:07) Nothing is the truth. (37:08) So all these ideas could be possible (37:09) and we won't learn until we ship them, (37:11) but I'm not putting solutions in the release plans. (37:17) I'm putting outcomes. (37:19) These are the outcomes we want to achieve. (37:22) Then you would break those things down (37:25) into pieces of work that could be handled (37:29) and organized cleanly (37:34) called epics and features and tasks. (37:37) And I will explain the difference. (37:41) When you are designing a kitchen, (37:48) let's see, Joe, the last time you had to figure out (37:52) what goes into a kitchen, (37:54) like you moved into an apartment, (37:56) tell me how you approached it. (37:58) How did you approach designing your kitchen (38:00) and organizing your kitchen? (38:03) I looked at the storage that was there (38:08) and then looked at the existing storage that I had (38:13) and then did like a base comparison of like, (38:17) is there more storage or less storage? (38:21) Okay. (38:23) And then you organize based on that? (38:27) Yeah, everything. (38:28) So the organization, (38:29) things have places that they go in already. (38:32) So I saw if there was enough space to put the places, (38:35) the stuff and the places that they're supposed to go (38:37) and there was not. (38:39) So I had to make adjustments (38:42) but the things are organized, (38:44) it's like plates, sauces, I don't know. (38:48) Yep, okay. (38:50) So I did mine based on location to other things. (38:56) So like a location, (38:57) closeness to the stove, (38:58) I put things that I need for the stove close to the stove (39:02) and closeness to the blender, (39:04) I put things or closeness to the dishwasher, (39:07) I put cups near the dishwasher (39:09) because I knew I was gonna use cups (39:12) and the dishwasher on a constant basis. (39:15) So that's how I decided to organize my kitchen. (39:19) How Joe organizes his kitchen (39:21) or Xiao, you organize your kitchen (39:23) or Bachia, you organize your kitchen (39:25) and how I organize my kitchen, (39:26) all of that's gonna work differently for each of us (39:30) and we make the call. (39:32) That is a backlog. (39:35) When you manage a backlog, (39:38) the ways that you manage the backlog (39:41) are what works for the team. (39:44) So when you make a bunch of work (39:46) in these epics and features and tasks, (39:49) you're gonna have to organize and categorize them somehow. (39:52) Whatever you name this category of work (39:56) that has a bunch of work under it, (39:58) that's gonna be what's working for you (40:01) and that's gonna be based on the release scope. (40:04) But what works for me doesn't work for everybody else. (40:07) So we make judgment calls about how that might happen. (40:11) There are boxes in the kitchen that go into the cabinets. (40:14) Those are tinier pieces of work called features. (40:18) Features might have 20 different types of pieces of work (40:23) that go into the box (40:25) and you could have two or three features (40:27) that go into an epic. (40:31) Because they fit into the epic. (40:33) And in that box, you could have utensils (40:38) and those small little pieces are what's called tasks, (40:44) independent pieces of work. (40:45) So how I choose to organize my boxes (40:49) and how I choose to organize my cabinets, (40:53) what goes into the cabinets, what goes into the boxes, (40:56) how many items fit into a box, (40:59) that's a decision that I make. (41:01) As a backlog owner and it's based on the release. (41:06) And if the vision and the scope (41:10) is always changing based on research, (41:14) is the backlog gonna stay the same (41:16) or is the backlog gonna change? (41:23) Which one is it? (41:24) Is it gonna stay the same or is it gonna change? (41:29) Change. (41:31) Yeah, it's always gonna look different. (41:33) So I'm not gonna spend the energy (41:34) filling that thing out with 100 tickets (41:36) because those 100 tickets (41:37) could be invalidated the next day. (41:41) But I have my draft plans of the release (41:45) that until they become invalidated, I'll keep them. (41:50) And when I populate the kitchen, (41:52) I'm only putting what's good enough in there. (41:55) What's near term delivery of good enough. (41:59) Because as soon as I ship that good enough, (42:02) the whole thing is gonna potentially change. (42:04) The vision is gonna change, the scope might change, (42:07) the backlog items might change, (42:09) the way I organize the epics might change, (42:12) the way I organize a roadmap might change. (42:15) I don't even do a roadmap as a product manager. (42:18) I update that thing every quarter. (42:22) And as soon as I make it, it becomes outdated. (42:24) I don't maintain it. (42:28) It might be for other people. (42:30) You might need to like put together (42:32) some type of forecast for other people. (42:34) But I, as a product manager, (42:37) I do not need a vision of 12 months from now. (42:41) I need a vision of three weeks from now, (42:43) six weeks from now, 10 weeks from now. (42:50) That's the backlog. (42:52) And then there's all the things that go into the backlog. (42:54) When you're building a new application, (42:57) by the way, this is, I mentioned before, (43:01) this is like an entire class in one lecture. (43:06) So we might go like 20 minutes over. (43:12) I'll keep it recording. (43:13) If you have to leave, it's all good. (43:15) But I do want to finish in this one recording. (43:18) Is that cool with you all? (43:20) We go a little bit extra. (43:26) And if, like I said, if you have to leave, it's all good. (43:29) I'll keep posting the recording and stuff. (43:35) We're almost done. (43:36) Actually, it might be like another 10 minutes or so. (43:41) When I'm putting together a release, (43:43) there are different types of instructions (43:46) that I need to put together. (43:47) There are the prototypes and the flow charts (43:52) and the things that represent what users do. (43:55) And that's called functional requirements. (43:59) That is not the first piece of details (44:03) that I need to put together. (44:06) Before you can put the siding on a house, (44:09) you have to build the foundation of the house underground. (44:13) That foundational work is called non-functional requirements. (44:18) We have to build that stuff first (44:20) before we get into the functional requirements. (44:24) So this deliverable that I'm calling a build plan, (44:30) it's just what I call it, (44:32) is an order of the work that you're going to need (44:37) to include as far as a developer understanding (44:42) what are the first items of work that you need to build, (44:45) non-functional requirements that you need to deliver (44:49) before you can build functional requirements. (44:52) And from a technical standpoint, (44:54) there could be certain features, functional requirements (44:58) that you want to build before others. (45:00) I will leave that to a developer. (45:03) In my build plan, (45:06) it will build certain clarity and pieces of clarity (45:09) about what are the first items to deliver first, (45:12) what's the foundational stuff, non-functional, and functional, (45:16) and which are what's called the dependencies. (45:21) When you use that word in product, (45:24) it means work that has to be done before other work. (45:29) There's a dependency in the work, (45:33) meaning I have to do work piece A (45:35) before I can do work piece B. (45:37) I will go to a developer, go to engineers, (45:40) and say, give me the tool selection. (45:46) Give me the servers you want to use. (45:49) Give me the database that you want to use. (45:52) Give me other tools that we need to buy and set up. (45:55) There could be a tool for sending emails. (45:57) There could be a tool for sending text messages. (46:00) There could be a tool for connecting agents together (46:03) or automating workflows, and you want to use that. (46:06) And those are part of your non-functional requirements. (46:10) Those get decided before you build. (46:14) And if they don't work out, those are assumptions too. (46:17) If they don't work out, great, (46:19) you just swap them out and migrate to another tool. (46:22) But they get delivered in non-functional requirements (46:25) before you code functional requirements. (46:30) You have to design the data. (46:34) It's called database architecture. (46:37) You have to architect the database (46:39) just like you architect screens. (46:43) And that is part of what's called (46:45) non-functional requirements. (46:48) A developer needs to do that. (46:54) Sometimes there's, you know, if you're at a fancy company, (46:57) sometimes there's a person that's dedicated to that. (46:59) They're called a database architect. (47:02) They don't code, they just design databases all day. (47:04) That's what they do. (47:09) Either way, someone's got to do it. (47:13) Someone with the expertise and the knowledge has to do it. (47:17) So in this case, it's going to be cloud code. (47:23) System architecture is how do the servers (47:27) talk to each other? (47:29) So how do I need to set up the web, (47:32) my own web server, database server, email server? (47:41) How do I need to structure that? (47:43) How do I need to build this? (47:46) That is its own responsibility that gets decided (47:51) before you start functional requirements. (47:54) That's called system architecture. (47:58) It could also be called network architecture. (48:03) It's part of non-functional requirements. (48:06) There could be rules that you have to put in place (48:09) called security protocol that could protect user data (48:14) or it could protect the application from getting hacked. (48:18) That's called security protocol. (48:21) You are going to learn database architecture in week four. (48:28) You're going to learn about it. (48:29) You're going to learn about system architecture in week three. (48:33) You're going to learn about tool selection in week three. (48:37) You're going to learn about security protocol in week five. (48:40) And you're going to learn about development operations (48:43) and quality engineering in week six. (48:46) If you want that written down, here it is. (48:50) Follow me in Figma. (48:51) Here it is. (48:52) This thing right here is going to show you (48:55) what I just talked to you about. (48:59) All the weeks you're going to get this stuff. (49:02) I'm just talking to you about it (49:04) so we can understand it for the first time. (49:08) Development operations are the ways (49:10) that you gate check the cake. (49:14) When you come from the bakery into the factory (49:16) and oh golly, the master baker is like, (49:18) fail, pass, fail, pass. (49:21) That is called development operations. (49:24) That is the quality check that happens without a human. (49:30) And every time I introduce a new piece of code (49:33) to the code base, (49:35) every time I introduce a new recipe of the cake (49:38) to the factory, there are checks. (49:43) There are also checks that happen to assess the quality (49:49) of what's been produced. (49:51) Has it broken anything? (49:52) Is it going to break something? (49:55) Does it actually revert to a worse functionality (49:58) than before? (49:59) Those all have terms. (50:01) Those all have processes. (50:03) That's called quality assurance. (50:06) The overarching topic is called quality engineering. (50:10) You're engineering quality (50:12) and you are designing purposefully making decisions (50:15) around how you do that in a code base. (50:19) That happens in non-functional requirements (50:21) before anything gets built. (50:22) People don't wing it. (50:24) All of them are assumptions, (50:26) but we got to pay careful attention to that stuff (50:30) because if you build the foundation wrong, (50:33) you might be destroying the whole house, (50:36) ripping it apart and putting that whole house (50:38) back together again. (50:39) And it's going to be a huge lift. (50:44) Are you all with me? (50:47) Am I putting you to sleep? (50:50) Give me a thumbs up if you're still with me. (50:55) Cool. (50:58) The whole rest of the class is going to be (51:00) non-functional requirements. (51:03) Functional requirements are all the things (51:05) that we all know and love. (51:09) Prototypes, design systems, (51:11) task level instructions called acceptance criteria. (51:17) Use case scenarios. (51:18) You might not have ever heard that term before. (51:20) It's just scenarios that people need to rally around (51:23) to support a user. (51:26) Flowcharts. (51:28) There is something called behavior-driven development (51:31) and I'll teach it to you. (51:33) It is a list of things that talk about (51:41) the precondition, the event and the expected result (51:45) so that you all can understand without a prototype (51:49) what's expected of an experience. (51:52) So all of these are called functional requirements. (51:56) All of these other technical doodads (52:00) are non-functional requirements. (52:03) I'm just going to blow through the functional requirements (52:06) in this class and focus all of the time and energy (52:11) that we have on non-functional requirements (52:13) for the rest of the eight weeks together. (52:16) So I am going to blow through (52:18) the functional requirements this week. (52:20) You are going to produce the functional requirements (52:25) in one week with all of the templates (52:31) that we have here technically. (52:34) And they are what class? (52:38) What are functional requirements? (52:41) They are all- (52:43) Assumptions. (52:44) Assumptions. (52:45) So they don't need to be perfect (52:46) and they don't need to be right. (52:47) They just need to be good enough to ship. (52:50) And then you're going to learn what needs to work (52:51) and what doesn't work and how it needs to change. (52:54) So you will, you'll change it. (52:56) You'll do good enough this week. (52:59) You'll ship it next week. (53:01) And then you're going to learn what doesn't work, (53:04) what did work, what needs to change. (53:06) And you'll keep doing functional (53:09) and non-functional requirements from there. (53:11) That's going to be the process. (53:14) So like I said, there is, (53:18) there's literally an entire eight week class (53:21) that you can learn just about this thing right here. (53:26) I'm going to go glance over these. (53:30) You're going to get the must have information (53:33) so that you can produce and practice this stuff. (53:37) But when you're on a team, (53:38) you might not be the one doing it. (53:40) You might be the one that is responsible (53:42) for other things in other ways (53:43) because you might be wearing different hats and that's okay. (53:47) But in this class, you're going to do it (53:49) so that you experience it. (53:51) If you want to know about all of these, (53:54) they are in TechFleet's training materials, (53:58) the skills and practices framework, (54:01) and Fleety, which uses the skills and practices framework. (54:04) You can have a conversation with Fleety (54:06) about all of these deliverables (54:08) that I'm going to show you right now. (54:12) When you put utensils in your kitchen, the tasks, (54:19) there is such a thing as too much work in one single ticket. (54:23) Those are like the tickets in the backlog. (54:25) There's such a thing as too much work. (54:28) If it's not a single independent piece of work, (54:32) meaning it's not blocked by any other work, (54:35) if it's not able to be adjusted, (54:39) if it doesn't bring usable functionality to people, (54:45) for instance, if usable functionality (54:49) means that I can put it into the hands of a person, (54:51) if I build a database, that's not usable functionality, (54:55) that's partial functionality, that's not done. (54:58) That is not a single task. (55:01) A single task would be, (55:04) give it and put something into the hands of a person. (55:07) In order for me to do that, I need to build a database (55:10) and then I need to make a bunch of screens. (55:13) That's what we call valuable. (55:15) If it's usable, it's valuable because we can learn from it (55:21) because we're all always validating an assumption. (55:25) And the more people can use it, (55:26) the more we can validate that assumption. (55:28) The more it's actually used. (55:32) The more valuable it is to us. (55:36) Estimable, it's able to be sized (55:39) with level of effort by the team. (55:43) Small, it's able to be completed in one week or two weeks. (55:48) And testable, I can put it into the hands of a person (55:50) and I can use it. (55:52) They can use it, I can use it. (55:56) If pieces of work don't meet these criteria, (56:00) they're not good enough to go to design or development. (56:03) So you can follow this, it's called the INVEST acronym. (56:06) You can follow this to make decisions about, (56:09) how do you know too much or too little work (56:12) is in your ticket? (56:13) Well, here you go. (56:14) Here's how the product teams of the world do it. (56:16) This is one of the ways that they do it, (56:19) that they make sure things are right-sized. (56:21) There is a, (56:26) all of this stuff that I'm about to show you (56:28) is called acceptance criteria. (56:34) All of these instructions, (56:37) user stories, acceptance, use case scenarios, (56:42) task flows, behavior-driven development, prototypes. (56:48) Those go into either the drawer, (56:56) the cabinet at the Epic level, (57:00) or they could go in the box level, (57:04) or they could be written at the utensil level. (57:09) So these are not just for tasks. (57:12) You could write details of explanation about an Epic (57:15) that you're building and put the user stories for an Epic (57:19) or a feature or a task. (57:22) Any of them, any of them can be done. (57:25) The user story is one of the pieces of work (57:28) that's the hardest thing to write ever (57:31) because it requires you to build one sentence very clearly (57:34) and very simply. (57:36) And there's formula to it. (57:39) As a audience, I want to user goal (57:47) so that describe a problem or describe a business value, (57:54) not the solution. (57:56) So you do not wanna say, (57:58) as a user, I wanna see a report (58:01) so that I can see how much money I'm making. (58:03) No, no, no, no, no, no, no, no, no, no, no, no, no, no, no. (58:10) You're limiting a person (58:11) who's building the solution to a report. (58:12) What if the report's not the best way to do it? (58:15) What if a report is not actually solving the right problem (58:17) in the first place and you're back to square one (58:20) once you build that thing and you do it wrong (58:21) and you limited someone in the solutioning (58:24) before they got to actually build (58:26) the best thing for the problem. (58:29) As a business, I want to track my revenue. (58:33) Now, that is an outcome (58:36) so that I don't go out of business. (58:40) That gives me empathy about why, so what? (58:44) Why am I building this thing? (58:47) Well, it's so that users don't go out of business, (58:50) you jerk, so you better build it (58:52) because if not, our users are gonna go out of business. (58:57) If you don't have a good, clear one sentence user story, (59:03) nobody can get on the same page about anything. (59:06) Everybody's gonna build a different cake (59:09) and everybody's gonna be misaligned (59:11) and you're not gonna build the right thing in the right ways. (59:16) So you do have to make sure your user story is one sentence (59:22) and it justifies why, so what? (59:29) And it tells a story, it gives people empathy (59:31) when they read it. (59:33) It is not the solution, it describes a goal (59:37) and it always has a so that part. (59:38) You don't ever wanna say, as a user, (59:42) I want to track my business revenue, period. (59:47) Because the people picking up the work (59:49) are gonna be like, this is silly. (59:52) I don't think they need to track revenue, (59:54) we already have this other thing in here. (59:56) And so let's just throw this in the backlog and never do it. (1:00:01) If you don't build empathy in your sentence (1:00:03) about why it's worth building, (1:00:07) you cannot align other people into the work. (1:00:10) You have to have the so that part. (1:00:13) That's one of the hardest pieces of requirements (1:00:15) you could ever write. (1:00:17) Below that, in a single ticket, (1:00:20) could have that you have multiple user story statements. (1:00:27) You might have background that explains the work. (1:00:32) You will have, this is another piece (1:00:35) that's really hard to do. (1:00:37) I'm not gonna train you on problem statements in this class, (1:00:39) but you're welcome to melt your brains on it. (1:00:43) Problem statements are not what you think they are. (1:00:47) These are describing scenarios that happen in the world (1:00:51) that need to change. (1:00:53) And there's hundreds of them in a single product. (1:00:56) But you need to have an accurate understanding (1:00:59) of what's happening in the world right now (1:01:01) before you can understand what you're changing. (1:01:03) So this is how everybody gets on the same page. (1:01:05) You have the statement that shows (1:01:07) what's happening right now that needs to change. (1:01:09) You also have, what are the outcomes (1:01:11) you're trying to achieve in the piece of work? (1:01:16) What are we expected to deliver at the end of the work? (1:01:20) How do we know we're done? (1:01:23) What are the things that we need as criteria (1:01:26) that says we are finished? (1:01:31) That doesn't happen by someone guessing. (1:01:33) That happens by someone making purposeful decisions (1:01:36) about what's called scope, definition of done. (1:01:41) The list of things that you need to do (1:01:43) to consider that thing finished, (1:01:45) that design, that development, that research, (1:01:49) that content, whatever you're producing. (1:01:51) There is someone that has thought about that for you (1:01:56) in your acceptance criteria. (1:01:59) That's an extremely important piece. (1:02:03) And then you might have different types of instructions (1:02:05) or considerations that go into the ticket (1:02:11) that are called acceptance. (1:02:12) I will show you all this stuff in real form (1:02:16) when we do the working sessions. (1:02:17) I want to get through this first. (1:02:21) We're almost through the hardest part of this stuff. (1:02:25) But I will show you real examples. (1:02:27) I'll show you the backlog that I maintain (1:02:29) and we'll actually do this stuff this week. (1:02:34) How are y'all doing? (1:02:35) Y'all good? (1:02:37) We're probably going to go another 15 minutes (1:02:40) just so I can like finish it all on the recording. (1:02:46) Nobody's falling asleep yet? (1:02:52) You're still looking at me as a strawberry, probably. (1:02:54) That's cool. (1:02:56) Use cases are scenarios that you decide to support. (1:03:02) They're usually just one statement. (1:03:05) And so they might, the use case might look like this. (1:03:10) The overarching scenario might be an admin (1:03:14) that logs into the system (1:03:16) and you would build flow charts and you'd build QA tests (1:03:20) and you'd build prototypes that all here (1:03:23) and you'd build acceptance criteria (1:03:24) that all gear around the scenario (1:03:28) of an admin logging into the system. (1:03:31) You would prioritize this in your release. (1:03:33) You'd say, we are going to support admins (1:03:37) correctly entering their credentials, (1:03:39) but we are not going to support admins (1:03:42) getting locked out of the account. (1:03:44) We're not going to put that in the release. (1:03:46) It's not a use case that we're going to support. (1:03:48) And you make a purposeful decision that says that. (1:03:53) To play out the scenarios, (1:03:55) you would put together a flow chart that says, (1:03:59) here's the start of the scenario, (1:04:01) and then here are the steps. (1:04:03) This happens, and then this decision happens, (1:04:06) and then this and this happens. (1:04:09) Here's an example. (1:04:10) The use case of a parent filtering by price. (1:04:14) They log in and then the system says, (1:04:18) has the preference been set yet? (1:04:21) Yes or no? (1:04:22) If no, there's some type of experience (1:04:25) that lets them choose the price. (1:04:28) If yes, the dashboard shows the price already filtered. (1:04:34) And then the user can go to, (1:04:37) they can click on a dashboard and see the housing options. (1:04:40) Or they can go to the explore page (1:04:43) and they can see the pricing filter if it's already been set. (1:04:49) And this is called a flow chart. (1:04:51) This is called a task flow. (1:04:53) It's a flow for the task. (1:04:55) There might be one flow chart (1:04:58) that you put together per use case. (1:05:02) And each ticket might have one to three or four use cases. (1:05:10) The other way that you can write this (1:05:11) is called behavior-driven development. (1:05:14) And I actually have, (1:05:17) I've built workflows that have AI build these for me. (1:05:23) And I review them. (1:05:24) And this is how I sometimes do requirements with AI. (1:05:30) The behavior-driven development (1:05:32) is actually a type of QA test. (1:05:37) When you have these, you can automate these tests (1:05:41) in the form of these words here. (1:05:43) So as an admin, given that I am not logged in (1:05:50) and I go to the login page, (1:05:52) when I enter my credentials and I've entered them correctly, (1:05:55) then I should be redirected to the homepage (1:05:59) and the session in the browser should start. (1:06:03) That's a baseline that you can test against. (1:06:06) If there's any broken functionality, (1:06:08) you can follow this behavior-driven development (1:06:13) for this particular use case scenario. (1:06:16) And then you can turn that into an automated test (1:06:21) that your system checks for. (1:06:23) So anytime you build a feature or a task, (1:06:27) you might have 30 of these in a single ticket. (1:06:30) Each of those things, the behavior-driven development, (1:06:33) that turns into an automated QA test. (1:06:39) I'm not talking about AI right now. (1:06:41) There's no AI involved in the running of the test, (1:06:46) but you can have AI make these (1:06:50) to then put into the form (1:06:52) where you would actually run the test. (1:06:54) They're extremely important. (1:06:56) You absolutely should have this in your requirements. (1:07:01) Every single thing that you put together should have these. (1:07:05) Before AI came along, we would write these manually. (1:07:11) Developers, QA people, we'd write them. (1:07:14) We had 20 per ticket. (1:07:15) We'd write 20 of them in a single ticket. (1:07:18) And they were grueling. (1:07:21) They've saved us so much time (1:07:22) by having an AI model do this. (1:07:26) If it has all the other requirements, (1:07:27) if it has all the acceptance criteria (1:07:29) and all the context and the vision, (1:07:31) it does a really good job. (1:07:32) It doesn't really make things up in this (1:07:35) if you have the data. (1:07:40) The other piece of writing instruction (1:07:45) that could go into one of thousands of tickets (1:07:48) in your backlog is called technical requirements. (1:07:54) Technical requirements are how to design the database, (1:07:59) how to flow the data, (1:08:00) all the stuff that a developer needs to decide (1:08:05) or an architect, if the developer is architecting, (1:08:11) the developer needs to decide that. (1:08:14) If there's an architect, that's what you call them, (1:08:18) solutions architects, technical architects. (1:08:23) Those are the people that are designing technical solutions (1:08:28) from the technical side. (1:08:29) And you want them to do that. (1:08:33) So if you're Claude is going to be (1:08:36) the technical architect with you, (1:08:39) you're gonna have Claude produce all of these. (1:08:42) And then you would obviously want to learn. (1:08:46) That's why you need to know what it takes (1:08:48) to build good software, (1:08:49) because you gotta orchestrate that. (1:08:52) And you gotta quality check Claude. (1:08:55) But Claude is the architect (1:08:56) and you are the product manager in that. (1:08:59) In that flow. (1:09:02) You ask the other people that are experts (1:09:05) to produce what you don't produce yourself. (1:09:09) So if you're a product manager, (1:09:11) you don't produce technical architecture (1:09:13) unless you're wearing that hat. (1:09:16) If you are wearing the hat, (1:09:18) then you would actually be designing this stuff. (1:09:22) Most of the time, it's someone who's in a technical role, (1:09:26) most of the time. (1:09:27) Well, I'm gonna teach you how to orchestrate it with Claude. (1:09:31) Then functional requirements. (1:09:34) These are actually part of functional requirements (1:09:37) because they're going into how potentially (1:09:42) an applications feature needs to be built. (1:09:49) Or it's like paired with functional requirements. (1:09:52) They're still non-functional requirements, (1:09:54) but they're backend to the features (1:09:58) or like the space between in the cloud of the web. (1:10:06) And then prototypes. (1:10:07) You all have probably lots of experience with prototypes. (1:10:13) Most AI tools are really horrible (1:10:16) at providing accessibility standards. (1:10:19) Most AI tools are extremely horrible (1:10:20) at producing anything that's visual. (1:10:23) Most AI tools are extremely horrible (1:10:25) at producing really basic information hierarchy (1:10:27) and producing scannable interfaces. (1:10:31) And most AI tools produce visual crap. (1:10:36) Unnecessary tool tips, random call-outs, (1:10:39) putting pills of information, (1:10:42) stacking labels next to each other. (1:10:44) I would call that visual crap. (1:10:46) It takes away from the readability (1:10:50) and the scannability of the interface. (1:10:54) You are welcome to explore this. (1:11:00) Please do. (1:11:03) I think that the best way for you to learn (1:11:05) what Claude is and is not good at (1:11:08) or even other design tools that are AI based (1:11:10) is to see what happens (1:11:14) and see how your skills could get involved (1:11:17) and see how your prompting could change (1:11:19) to make that better. (1:11:23) There often comes a point where I'm like designing things (1:11:26) and I'm like, this is too much work to ask the AI to do. (1:11:29) I'm just gonna do it myself. (1:11:31) So that happens a lot for me. (1:11:33) I just do things from scratch (1:11:35) because it's faster for me to do it from scratch. (1:11:40) And who am I answering to? (1:11:41) Who am I actually doing that? (1:11:44) There's some like overlord that's pointing to me (1:11:48) and be like, you better use AI tools. (1:11:50) There's some like hidden expectation (1:11:51) that society's putting pressure on me for it (1:11:54) that says you need to know how to use AI tools. (1:11:57) Well, I'm gonna use the tool that's the best (1:12:00) for what I'm trying to do. (1:12:03) And AI is clearly not there yet. (1:12:06) So if I'm trying to build like some type (1:12:08) of low fidelity wireframe, (1:12:11) yeah, I might start with Claude, maybe. (1:12:15) I'm probably just gonna decide in the moment (1:12:17) what's good and what's not good. (1:12:19) But I definitely will need these instructions (1:12:22) before I give it anything prototype related (1:12:26) because I'm not gonna waste my time. (1:12:28) I'm not gonna go back and forth and be like, (1:12:29) no, Claude, do this. (1:12:30) No, Claude, do that. (1:12:31) No, Claude, do this. (1:12:32) No, wait, don't do that, do this. (1:12:34) That's a waste of time. (1:12:35) It's a waste of money. (1:12:36) It's a waste of my energy. (1:12:38) And I'm not gonna go down that road with Claude. (1:12:42) I'm gonna make it more efficient for me (1:12:44) and more efficient for Claude (1:12:45) and more efficient for my team. (1:12:47) And that means I'm gonna produce these instructions (1:12:53) for delivery before any type of design comes into play (1:12:57) so that we all know what we're moving toward (1:12:59) and we have a shared understanding about it. (1:13:04) When you get to the point of managing the operations (1:13:06) of your team, again, there are tons of different ways (1:13:12) to learn about this stuff. (1:13:13) These are called methods. (1:13:14) You can learn all about them in Tech Fleet. (1:13:16) I'm not gonna teach a class on methods. (1:13:18) I'm not gonna teach a class on process (1:13:20) or operations of teams, (1:13:23) but I'm just gonna talk about it for a little bit. (1:13:26) You can learn on your own. (1:13:27) It's out of scope of this class, (1:13:29) but you're gonna be exposed to it (1:13:31) so you need to know the basics. (1:13:34) But the processes and the steps that you go through (1:13:36) are called methods. (1:13:39) There's two main kinds of methods out in the world (1:13:42) with Agile. (1:13:43) There's more than two, (1:13:45) but there's two big ones. (1:13:46) One's called Kanban and the other is called Scrum. (1:13:53) And when you join teams in Tech Fleet, you do Scrum, (1:13:56) which is that we have these rituals. (1:14:02) We call them cadences. (1:14:04) So we have a process for requirements. (1:14:08) We have a process for reviewing requirements. (1:14:11) All the stuff that I just went over with you is requirements. (1:14:18) There's a process of reviewing requirements (1:14:20) and making sure that we're all aligned (1:14:21) and that we all need adjustments to those things (1:14:23) and then you can plan the work. (1:14:25) And then you do the work. (1:14:26) If you do the work in increments called sprints, (1:14:29) the sprints could be one week or two week or three weeks. (1:14:33) When you're done, (1:14:36) you demonstrate the work that you achieved. (1:14:40) You plan the work ahead of time. (1:14:42) So you know what you're doing before you begin. (1:14:44) You demo what the progress was. (1:14:47) This is a form of assumption collection. (1:14:50) You'd be like, hey, we thought we were on the right track. (1:14:53) Are we on the right track? (1:14:53) Because this is all an assumption. (1:14:55) Give us some feedback, client. (1:14:57) This isn't done. (1:14:59) It's in progress, (1:15:00) but we don't really care that it's not done. (1:15:03) We care that we want to validate what class? (1:15:08) Tell me. (1:15:11) Assumption. (1:15:12) More than anything. (1:15:15) So we're going to demo things that are half finished (1:15:17) and messy and looking really dirty (1:15:19) because I don't care about perfection. (1:15:21) I care about validating assumptions. (1:15:24) We're also going to have flows for reviewing (1:15:28) how the work went, what could go better. (1:15:30) That's called a retrospective. (1:15:32) And you check in with people. (1:15:33) You might work across different types of functions, (1:15:36) different types of teams. (1:15:38) So you check in typically every day on the daily standup. (1:15:42) When you manage a board, (1:15:44) when you manage the work, (1:15:46) the board of the work could be on the wall, (1:15:52) like literally on the wall. (1:15:53) I've had countless amounts of backlogs on a wall (1:15:57) with sticky notes. (1:15:59) They could be in Figma like this. (1:16:02) They could be in different tools. (1:16:04) The tool doesn't matter. (1:16:05) What matters is these things, (1:16:09) the status so that you can see (1:16:12) what work is right now in requirements. (1:16:15) What work is ready? (1:16:17) What work is in progress? (1:16:18) What work is demoed? (1:16:21) The status is the things that give you visibility (1:16:24) into what's happening on your team. (1:16:27) These are called swim lanes on a Kanban board speak. (1:16:33) In order for you to understand what your statuses are, (1:16:37) you have to build with your team an operational process. (1:16:42) You have to agree with your team and decide together. (1:16:46) How does work happen? (1:16:47) When work comes in, (1:16:50) you go through a process of requirements. (1:16:51) What does that look like? (1:16:53) You might gather requirements before you write requirements. (1:16:57) And then you would refine requirements. (1:16:59) And then you'll go through a sprint planning (1:17:03) and you'll go through the actual doing of the work (1:17:14) after you're done with sprint planning (1:17:18) and your sprints in progress. (1:17:19) And all of this stuff is going to drive (1:17:21) what you put onto your backlog statuses. (1:17:29) So this stuff you might not really touch (1:17:30) until you get onto teams. (1:17:33) Well, you'll build a backlog (1:17:34) but you won't really do things in a team (1:17:37) until January. (1:17:40) You will need this. (1:17:42) However, you're going to need to understand (1:17:45) how do you populate the backlog? (1:17:47) So in TechFleet, we have this (1:17:52) like a tutorial step-by-step (1:17:54) that shows the steps that you make to build the backlog. (1:18:00) And we'll do this this week. (1:18:02) But here's like a step-by-step tutorial (1:18:04) about how do you build a Kanban board? (1:18:08) I really don't care what kind of Kanban board you use. (1:18:11) You could use Trello. (1:18:12) You could use whatever you want, doesn't matter. (1:18:17) The tool is irrelevant. (1:18:20) I'm going to show you Notion (1:18:23) but you don't need to stick with Notion (1:18:26) if you don't want to. (1:18:30) And that covers it. (1:18:31) That's the whole class, (1:18:33) probably two or three classes worth of content (1:18:37) in one single hour long session. (1:18:42) Holy moly, we did it. (1:18:44) Wow. (1:18:45) So before I let you go, (1:18:47) I have to show you what you're preparing for (1:18:51) in the working sessions. (1:18:54) It's a good thing I'm a strawberry (1:18:55) because otherwise you'd probably fall asleep. (1:19:01) Follow me in FigJam and I'm going to go, (1:19:04) I'm going to go from lecture to this other page that I made (1:19:09) for you to make functional and non-functional requirements. (1:19:16) You all know what I mean when I say that now. (1:19:22) You're going to start with (1:19:25) what teams would do out in the wild (1:19:28) when they're trying to build clarity and gain alignment. (1:19:32) So I'm not going to just have you jump right to tickets. (1:19:35) I'm going to have you produce for the ADHD budgeting app (1:19:43) and premium residents. (1:19:46) You are going to do the requirements for your own app. (1:19:52) Standard residents, you are going to build an application (1:19:55) to help people with ADHD learn how to budget. (1:20:00) This week, you're going to deliver discovery deliverables, (1:20:05) which includes these. (1:20:08) And I will show you them with templates. (1:20:12) You're going to produce vision and scope, (1:20:16) which I will show you what that looks like. (1:20:19) And you're going to produce non-functional (1:20:22) and functional requirements, acceptance criteria. (1:20:27) You're going to build a Kanban board. (1:20:28) You're going to build flow charts. (1:20:29) You're going to build the build plan, the BDD scenarios (1:20:34) and the technical requirements (1:20:37) for whatever is your first piece of work, feature work. (1:20:43) If you want to, if you want to, (1:20:52) and probably everybody in the room is going to be like, (1:20:55) yeah, I want to. (1:20:56) Go ahead and start experimenting with what does it look like (1:21:01) when you have all these things (1:21:02) and you start producing prototypes with AI. (1:21:09) In order for you to build the build plan (1:21:11) and the technical requirements, (1:21:13) you're going to have to have the selections of the tools. (1:21:20) I have as much instructions as I possibly can put in this, (1:21:25) the coding challenges document. (1:21:28) And if it's missing something, then ask me. (1:21:35) What you're going to have to like build (1:21:36) is part of the build plan and the technical requirements. (1:21:39) You're going to have to build (1:21:41) the technical implementation requirements (1:21:44) for the web server, the database server (1:21:50) and all the other technical stuff. (1:21:54) So it's part of your build plan (1:21:56) and it's part of your technical requirements. (1:21:58) I'm going to show you what this looks like. (1:22:00) I promise you, I'm not lying. (1:22:03) I did this, all of the things that you see on this page, (1:22:08) all of them, I did this in 45 minutes. (1:22:12) I'm not lying to you. (1:22:15) I'm not padding that number. (1:22:18) I promise you, I timed it. (1:22:21) I did it in 45 minutes because I used templates (1:22:26) that are available in TechFleet (1:22:28) and I used Cloud Code to fill out the templates. (1:22:32) That's what I want you to do. (1:22:35) And that will be your baseline (1:22:37) so that you can keep going from there. (1:22:39) If humans do this as a team, (1:22:42) wow, does it take like multiple weeks, (1:22:45) multiple sprints of work to do. (1:22:48) However, I want you to get to the other side (1:22:50) of being able to actually get to production. (1:22:54) And so you're going to follow the templates (1:22:57) and you're going to use Cloud Code (1:22:59) to like understand the practice of that process. (1:23:03) Joe, what's up? (1:23:05) When you say you use Cloud Code, (1:23:08) are you, is it just like a plugin? (1:23:12) Oh, sorry. (1:23:14) There's two sides of Cloud. (1:23:17) There's this little chat bubble called Cloud Co-Work (1:23:20) and then there's a little coding bracket called Cloud Code. (1:23:26) Co-Work spawns AI agents that don't code for you. (1:23:31) They build documents, they build templates, (1:23:33) they build slide decks. (1:23:36) Cloud Code can actually produce code for you. (1:23:40) And it integrates with GitHub and pushes code to GitHub (1:23:44) and produces websites, (1:23:48) like just like local hosted website files. (1:23:51) And so this is like your coding partner. (1:23:54) You can use either. (1:23:56) Well, I'm using them interchangeably (1:23:57) kind of when I say Cloud Code. (1:24:00) You can use Cloud Code to build this stuff. (1:24:03) It'll usually produce like a website, (1:24:05) but it'll also produce files for you. (1:24:08) I guess when you said specifically, (1:24:11) it filled out these templates, (1:24:13) like it filled out these templates on FigJam for you (1:24:16) or did you do the content and you copied it in here? (1:24:20) I extracted it from the templates on FigJam. (1:24:23) I fed it to a chat window on Cloud. (1:24:27) And I said, here's the spreadsheet, (1:24:30) fill this template out. (1:24:31) Gotcha. (1:24:31) And that's what it did. (1:24:33) Thank you. (1:24:35) Yeah. (1:24:35) Good question. (1:24:37) I'll show you what that looks like, everybody. (1:24:39) So here's what it looks like. (1:24:41) I did not, I'm gonna actually do the build plan (1:24:44) and the flow charts and the prototypes with you this week, (1:24:48) but I am also going to show you (1:24:50) how I got through this stuff in Cloud. (1:24:56) And I really want you all to practice this stuff. (1:25:02) So again, please follow me in FigJam (1:25:06) and I will just give you some reference (1:25:08) for where it all ties back to. (1:25:12) It all ties back to the product development lifecycle (1:25:18) in what's called the discovery milestone. (1:25:21) You're doing research about users (1:25:23) and research about the market. (1:25:26) Both when you're performing the continuous discovery. (1:25:31) So you might have personas, empathy maps, (1:25:35) customer experience, journey maps, all this other stuff. (1:25:38) I'm not gonna have you do that stuff. (1:25:40) I'm gonna have you do like the stuff that constitutes (1:25:47) the stuff that would, you probably won't get trained. (1:25:54) You probably were not trained in this stuff. (1:25:57) Maybe before this class, maybe you were, (1:25:59) and that's great if you were. (1:26:03) I had to pick and choose which ones would I do (1:26:07) from a product management standpoint. (1:26:09) These are square in the territory (1:26:10) of product management duty deliverables. (1:26:16) So you are gonna produce a deliverable (1:26:19) called product positioning, unique value proposition. (1:26:25) You are not gonna do problem statements. (1:26:28) I'm gonna take that out. (1:26:30) That's out of scope. (1:26:32) You're gonna put that together in the vision (1:26:35) and that's fine. (1:26:37) And you're going to put together audience segmentation. (1:26:40) If you wanna do problem statements, (1:26:42) if you wanna do other deliverables, great. (1:26:45) The world is your oyster. (1:26:47) Go experiment with using Cloud and doing this stuff. (1:26:51) The bare minimum for the coding challenge (1:26:53) is the stuff in green. (1:26:54) Product positioning, unique value proposition (1:26:58) and audience segmentation. (1:27:00) Then you will be able to have information (1:27:02) that you put into your vision, your scope (1:27:06) and your acceptance criteria that goes into the backlog. (1:27:12) These things in green are what you're gonna produce (1:27:15) this week as well as you're gonna produce (1:27:20) the acceptance criteria and your backlog (1:27:26) and stuff like that. (1:27:27) So here's what it looks like. (1:27:30) To do market research, when I say that word, (1:27:35) market research, here's what I mean. (1:27:39) There's a deliverable called a market analysis (1:27:41) where you look at the categories of all the companies (1:27:49) that are doing what you're trying to do (1:27:51) called channels, market channels. (1:27:55) And then there are smaller categories (1:27:57) called market segments. (1:28:00) There's total valuation of all the companies (1:28:04) that are doing what you're trying to do (1:28:06) and that's called valuation. (1:28:07) That's called the market size. (1:28:09) And then your competitors, (1:28:13) what are the top companies in that market? (1:28:16) And is that market expected to grow (1:28:18) or shrink? (1:28:19) That's called CAGR, it's an acronym, projected growth. (1:28:26) That's what a market analysis is. (1:28:29) So I will export this into cloud, (1:28:33) this little example here. (1:28:34) And I'll say, this is what outcome I'm trying to achieve. (1:28:39) I'm trying to build an application (1:28:40) that helps people with ADHD budget. (1:28:43) Fill out the market analysis table for me. (1:28:46) And it will probably do it in like two minutes. (1:28:48) Check its sources. (1:28:50) Make sure that it's not making shit up. (1:28:53) Tell it that you should not be making things up (1:28:56) and prompt it well so that you can make sure (1:29:00) that it's doing a quality job. (1:29:04) It'll look at the internet and it'll do it very fast. (1:29:07) The next piece of deliverable, (1:29:10) it's called a competitor analysis. (1:29:11) You take all the competitors that you learned about here. (1:29:15) I say, all right, Claude, now dig into those companies (1:29:20) and tell me everything that you know about them. (1:29:24) So in the template, there's different types of, (1:29:29) like it literally says question one, (1:29:31) question two, question three, question four. (1:29:33) Make your questions up. (1:29:36) Here's what I came up with. (1:29:38) How do they differentiate themselves? (1:29:41) What are their capabilities and features? (1:29:44) What do they do well? (1:29:45) What do they not do well? (1:29:48) What do their customers say about them? (1:29:51) What market gaps do they have that they haven't filled? (1:29:55) And what's their unique value proposition? (1:29:59) Claude will do that research. (1:30:01) So Claude did that research for me (1:30:02) and came back with this. (1:30:04) And I didn't believe Claude. (1:30:05) So I was like, Claude, prove it to me. (1:30:07) Give me the evidence. (1:30:09) I don't believe you. (1:30:11) Give me your sources and cite your sources (1:30:13) so that I can double check your work. (1:30:15) But it fell out the table for me. (1:30:17) This is my competitor analysis. (1:30:19) Then you take the competitor analysis and you say, (1:30:21) all right, now I want to dig into the features. (1:30:23) What features are we going to actually be considered unique? (1:30:30) And you do what's called a feature analysis (1:30:33) where you have all these features (1:30:36) that you come up with yourself. (1:30:38) So here's some features for TechFleet in this example table. (1:30:43) And here's our company. (1:30:45) And here's some things that potentially compete (1:30:49) with TechFleet, our company. (1:30:51) And the little check is (1:30:53) that this company does have the feature. (1:30:56) And the little bar is the company does not have the feature. (1:31:02) And you definitely want to double check a work. (1:31:06) Double check the work that this thing is producing (1:31:08) because it's going off of its own definition for things. (1:31:14) And you definitely want to make sure that you can prove (1:31:19) that you agree with what it is saying. (1:31:22) So here's what it did with mine. (1:31:24) I'm doing a thing called the job decoder. (1:31:28) I am competing with these companies. (1:31:33) Here's my list of features. (1:31:37) So there's a job description scan, (1:31:39) which is what I'm offering. (1:31:40) How many competitors do that? (1:31:43) Almost all of them. (1:31:44) It's not very unique. (1:31:46) But again, if this thing is wrong, (1:31:50) then I am basing it off of wrong information. (1:31:53) And I don't want that to happen. (1:31:54) And I got to validate that with Cloud. (1:31:57) If Cloud does that, (1:31:58) I need to like validate the information (1:31:59) that it's producing. (1:32:01) Here's all the other stuff. (1:32:03) What doesn't really happen with a lot of competitors (1:32:08) is LinkedIn profile optimization and networking. (1:32:15) These are offered by almost nobody. (1:32:19) And so those are pretty unique features. (1:32:21) In addition to that, (1:32:26) application autofill, unique. (1:32:29) Doesn't mean that I'm going to make a decision to do it. (1:32:32) It's just giving me an analysis (1:32:34) of what are the features that are available? (1:32:38) What's not available? (1:32:40) What's pretty unique? (1:32:41) What are other people not doing? (1:32:43) What are they doing? (1:32:45) So these three things go together. (1:32:48) You definitely don't want there. (1:32:50) I mean, there's going to be times (1:32:50) where you might just do only a market research (1:32:53) and not a feature analysis, (1:32:58) but you do a competitor analysis and market research, (1:33:00) but it's good to do all three. (1:33:04) Yes. (1:33:07) What's up? (1:33:09) I was just wondering the yellow circles. (1:33:13) What did they stand for again? (1:33:16) It's something that Cloud did (1:33:17) and I have to dig into it more. (1:33:19) I was just producing the example for you. (1:33:21) So I think it means maybe, (1:33:23) but I would not rely on that as a source of truth. (1:33:28) It's not validated. (1:33:30) And I don't necessarily know for sure what that means (1:33:34) because I didn't get to that point with Cloud, (1:33:36) but I will this week. (1:33:39) But I'm not sure yet, Dominic. (1:33:41) Just showing the example. (1:33:48) Your deliverable that's called (1:33:50) the unique value proposition, (1:33:52) the unique value prop, (1:33:57) UVP is a complicated deliverable of language. (1:34:03) The thing that constitutes your unique value (1:34:09) is gonna be a combination of who you're serving. (1:34:13) So the target audiences, (1:34:16) what problems are you trying to solve for them? (1:34:21) Which other competitors are trying to do the same thing (1:34:23) that you're doing? (1:34:25) What impact is your solution gonna have (1:34:27) on those people that experienced the problems? (1:34:30) And how is your business impact (1:34:33) different from competitors impact? (1:34:36) What makes it unique on the market is specifically that. (1:34:42) Then you can say, (1:34:44) here's what nobody does on the market today. (1:34:47) So the real gaps in the market are, (1:34:50) no one gives standalone, (1:34:51) does this title match this job description verdict? (1:34:55) I'm gonna do that. (1:34:57) Apparently, if this is true, (1:35:00) it's very unique. (1:35:01) It's a unique value proposition (1:35:03) because nobody else does it. (1:35:05) If that's true, (1:35:07) no one connects the analysis to a targeted interview prep. (1:35:11) I'm also gonna do that. (1:35:13) Apparently, that's very unique. (1:35:14) If that's true, (1:35:15) that's a unique value proposition. (1:35:18) Interview prep is generic. (1:35:20) It's not specific questions, banks and simulations, (1:35:24) not something specific. (1:35:26) If that's true, that's very unique. (1:35:27) That's my unique value proposition. (1:35:31) Title inflation and role mismatch is not addressed. (1:35:34) Well, I'm gonna address it. (1:35:37) So if no other competitors address that, (1:35:41) it's a big unique value proposition. (1:35:45) And there's nobody that tackles the ethical gap. (1:35:51) I wouldn't necessarily be able to make a really concrete, (1:35:55) confident decision about that until I know what that means. (1:36:00) But let's say I do know what it means (1:36:02) and I have confidence in the data that I'm looking at here. (1:36:06) If I decided to adopt that, (1:36:07) that would be a unique value proposition. (1:36:11) Those things are all the things (1:36:15) that you put into your vision board (1:36:18) that make you unique. (1:36:21) This thing right here, (1:36:22) what makes your product unique, (1:36:26) your competitive advantage? (1:36:29) Unlike other orgs that do this thing, (1:36:32) this crappy thing, (1:36:34) our org does this uniquely. (1:36:37) This is what makes us unique. (1:36:39) We have a unique advantage against others because of that. (1:36:43) That's how you get it. (1:36:44) That's how you do it. (1:36:45) You have to do a bunch of stuff before you can do it. (1:36:49) And then you can build this thing, (1:36:50) this statement called a positioning statement (1:36:53) that combines everything together (1:36:55) and you can concretely tell a story (1:36:59) that says for active job seekers (1:37:05) who experience these problems, (1:37:07) our business does this unique value. (1:37:11) And unlike other businesses that do this, (1:37:14) we uniquely fill this gap. (1:37:18) And so you can do it in different ways. (1:37:24) I usually write it like this. (1:37:26) For these audiences, (1:37:27) our product solves the problem and problems (1:37:30) and other businesses in the space do this (1:37:32) and unlike other businesses, we do this. (1:37:36) You would do that for one per audience. (1:37:39) That's called a positioning statement. (1:37:43) And that's just like a storytelling device. (1:37:48) Then this thing right here is called audience segmentation. (1:37:54) This is a little different than personas. (1:37:56) This is not personas. (1:37:58) It's not the same thing. (1:38:00) It is a semantic description (1:38:05) of your population of audiences. (1:38:08) So you're gonna follow this template. (1:38:11) You can do it with a cloud. (1:38:12) It's great. (1:38:14) What motivates your audiences that you know of? (1:38:17) Bam. (1:38:18) What are in the situations in which they live, (1:38:22) when they're trying to budget and they have ADHD, (1:38:23) what are their goals? (1:38:26) These are called situational goals. (1:38:30) And in their life, what are their life goals? (1:38:33) What not in the situation of trying to budget, (1:38:35) but what are their goals in life? (1:38:38) And you can then build this table that shows (1:38:41) here's a problem that they have. (1:38:44) Here's an example. (1:38:45) Job requirements are shifting. (1:38:48) And when does this happen in the customer experience? (1:38:51) This happens when people are trying to apply, (1:38:55) when they graduate, when they're already in a role. (1:38:57) It happens a lot of times. (1:39:00) And then we can identify business goals, (1:39:03) not user goals, business goals. (1:39:05) In what ways does this business wanna change the world? (1:39:12) How would the world be different? (1:39:15) What's the outcome that we want to achieve? (1:39:18) We want people to be able to stand out. (1:39:20) We want people to be able to remain relevant (1:39:23) in their whole career. (1:39:25) These are business goals. (1:39:26) I'm not saying how, I'm saying what. (1:39:30) These go into your vision, your vision boards. (1:39:33) We want people to learn how to tell (1:39:36) the story of their growth. (1:39:37) We want people to fill the gaps of readiness. (1:39:41) Yada, yada, yada. (1:39:43) Then based on the goals, you can then define (1:39:48) what are the scenarios that you're gonna support (1:39:51) to achieve the goals? (1:39:53) We're going to support the scenario (1:39:55) of making decisions on how to focus their training (1:40:00) and understanding the unique value (1:40:01) they bring to the world. (1:40:02) I'm not gonna say how, I'm saying what. (1:40:05) What are the scenarios? (1:40:07) There is an example of the one I produced. (1:40:10) Active job seekers can't tell if they're actually qualified (1:40:15) for a role before applying, (1:40:16) so they blindly apply or self-reject. (1:40:19) And it happens while they're scrolling, (1:40:22) after they're getting rejected, (1:40:25) when a job listing lists more requirements than they have, (1:40:29) and when they're unsure about roles. (1:40:30) This all came from AI. (1:40:32) I would vet this heavily. (1:40:35) Now, like, you know, adjust the narrative (1:40:36) that I want to tell. (1:40:38) This is a draft. (1:40:39) Here are the business goals that I want to put (1:40:42) into my vision that are based on, (1:40:44) if we were to change this problem, (1:40:46) what outcomes would we have achieved in the business? (1:40:49) We want people to know before applying (1:40:51) whether a role truly fits. (1:40:53) Well, that's not, I guess that is a goal. (1:40:58) We want them to stop wasting effort. (1:41:01) We want them to focus their energy (1:41:03) where they can realistically win. (1:41:04) We want them to apply with confidence, not anxiety. (1:41:07) Those are great business goals. (1:41:09) Then I'm gonna say, (1:41:10) what scenarios would support that in the release? (1:41:14) And, you know, again, AI made these, (1:41:17) and I'm gonna tear them apart (1:41:20) because they're not use cases there. (1:41:24) Some of them are not use cases, they're solutions, (1:41:28) but here I have it. (1:41:28) I have it in 45 minutes. (1:41:30) I can work with it in 45 minutes. (1:41:35) So here's what motivates people here on the left. (1:41:39) Here, this little part in green. (1:41:42) This one's called audience segmentation. (1:41:45) And then the last pieces of work that I produced (1:41:52) are vision and scope and epics and features and tasks. (1:41:56) So I'm gonna fill out this board here. (1:42:01) Again, it's one board per audience per release. (1:42:07) So if I have two audiences, (1:42:09) I'm gonna build an MVP for that audience (1:42:12) and an MMP for that audience. (1:42:15) And I'm gonna do that twice. (1:42:18) And so I have three audiences here. (1:42:21) I just produced the MVP. (1:42:24) Here's the text. (1:42:27) Here are the problems that I want to put in there. (1:42:31) Here are the business goals. (1:42:33) Here's the value that if we solve these problems, (1:42:37) we're gonna bring this value. (1:42:39) Here's what makes us unique based on our market research. (1:42:43) Here are the barriers that are gonna stand in our way (1:42:46) that we need to overcome. (1:42:47) Here's what costs we're gonna face. (1:42:50) Here's what KPIs we're gonna put into the release (1:42:53) to measure the goals. (1:42:55) Here's what use cases we're gonna support (1:42:57) for that audience in particular, for career changers. (1:43:02) And the scope is going to be, (1:43:07) we will provide this value by achieving these outcomes. (1:43:15) These are solutions. (1:43:16) These aren't outcomes. (1:43:17) These come from AI. (1:43:18) I'm gonna rip them apart, but I drafted them. (1:43:21) We will show this heelfit for a new role by building it. (1:43:26) This is a solution. (1:43:28) I wanna get rid of this. (1:43:30) This is all solutions. (1:43:33) I'm gonna rip this to shreds and you're gonna rebuild it, (1:43:37) but it would be outcome, outcome, outcome, outcome. (1:43:41) And I'm gonna, I'll adjust it after. (1:43:48) And I have that all for all free. (1:43:51) And then I built the epics and features and tasks. (1:43:55) And so you can put it in visual form (1:43:56) or you can put it in list form. (1:44:00) I gave this to Claude. (1:44:02) I like pulled this information here, this picture. (1:44:05) And I said, here's the sample data about epics and features. (1:44:09) Go make me some categories of work. (1:44:12) So it gave me a build plan. (1:44:16) This isn't in priority order. (1:44:18) So it's not the finished build plan, (1:44:20) but it is a plan of work. (1:44:22) Here's my scope for the release. (1:44:26) Epic one, understanding the job through the framework, (1:44:31) understanding the job, period. (1:44:33) Get rid of the fluff, understanding the job. (1:44:36) And I have three features under that. (1:44:38) And those features have three things each, great. (1:44:41) Epic two, know if you fit the role, great. (1:44:45) Match my experience to the halfs, apply a decision. (1:44:51) Epic three, epic four, epic five, epic six. (1:44:54) So these are very foundational. (1:45:01) This one says, save local and framework data (1:45:04) without an account. (1:45:06) This I would consider in my build plan (1:45:08) to be the first thing that I have to build (1:45:11) because I have to build this (1:45:13) before I can build this other stuff. (1:45:16) So I have not built a build plan yet, (1:45:18) but this is an interesting one that shows me. (1:45:24) It came from AI, but it shows me what eventually (1:45:28) is going to be a dependency to other stuff. (1:45:31) And then I have build plan. (1:45:35) I have non-functional requirements. (1:45:36) I have flowcharts, I have prototypes, (1:45:39) and I'm going to produce it all this week. (1:45:42) Again, everything I just showed you (1:45:43) that I explained for 30 minutes (1:45:46) took me 45 minutes to produce. (1:45:51) And it can take 45 minutes for you too. (1:45:54) Don't walk into the work thinking (1:45:56) that it's going to take you weeks. (1:46:00) Use the templates, produce it with Cloud, (1:46:03) use it as a draft, adjust it as you go. (1:46:06) And this is a whole new way to get to the next step. (1:46:10) I've never taught this before. (1:46:12) I've only done it. (1:46:13) So you, my friends are the first people (1:46:15) that are actually hearing me talk about what I've done. (1:46:21) Stephanie. (1:46:24) This is cool. (1:46:27) Yeah, incredibly cool to see it go fast. (1:46:32) Yeah, yeah. (1:46:33) I was trying to kind of get to that. (1:46:36) Was the audience and motivation goal template. (1:46:40) But I was like, so the question that I have here (1:46:43) is what do you feed to, (1:46:46) do you feed the entire Figma or you just copy paste? (1:46:51) No, no. (1:46:51) If you did that, it would take forever. (1:46:54) It's too heavy, yeah. (1:46:56) Like, it depends on the thing. (1:46:57) If this is a table, I'll feed the table as a CSV. (1:47:01) I'll go here and I'll right click (1:47:03) and I'll say export to a CSV. (1:47:06) Yeah. (1:47:07) That's why I put tables in FigJam (1:47:09) so that they can be exported to CSVs (1:47:13) and then they can be fed to other stuff. (1:47:17) Yeah. (1:47:18) Or it could be a picture. (1:47:20) Stephanie, if you have like a thing in a section, (1:47:22) it could be exported to a PDF or a PNG. (1:47:27) And then Claude will take it. (1:47:30) Claude will digest it. (1:47:34) Here's the thread that I talked about with Claude (1:47:38) and it produced a handoff document (1:47:42) and it produced like for my technical requirements stuff. (1:47:48) And it produced all this other stuff too. (1:47:53) Here, let me just show you the folder. (1:47:55) I think it just puts it all in one. (1:47:57) So here's my spreadsheet of competitive analysis. (1:48:00) And it filled it all out for me. (1:48:07) So it's got all this. (1:48:10) And here's the evidence that it collected. (1:48:14) And I asked it to give me justifications (1:48:16) and sources for stuff. (1:48:19) So it like decided to do this. (1:48:21) Here's the feature analysis. (1:48:24) I guess I could ask Claude right now, what does that mean? (1:48:28) What does a yellow circle mean in the feature analysis? (1:48:35) Dominic, based on your question. (1:48:38) See, I'm just giving this stuff to Claude. (1:48:40) If you did want to have Claude review FigJam, (1:48:47) I'll show you that. (1:48:49) Here's what you have to do. (1:48:54) I would suggest that you export files from FigJam. (1:48:57) But if you wanted it to read the file, (1:48:59) read the FigJam directly or read Figma, (1:49:02) you go to your settings. (1:49:05) Here. (1:49:07) You go to security and you go to personal access tokens. (1:49:14) And you create a new token. (1:49:16) You have to give it permissions. (1:49:19) So check all of these things. (1:49:21) Like this is saying, what can it do? (1:49:25) Basically whoever you give the token to, what can they do? (1:49:29) So I'm gonna give the token to Claude and say, (1:49:32) Claude, here's the token. (1:49:33) Go look at my Figma file. (1:49:34) And this is the scope of permissions (1:49:36) that you could do if I check them. (1:49:38) And then when does it expire? (1:49:40) I'm gonna say 90 days, give it a name, (1:49:43) give it all the permissions, (1:49:46) and then generate token and then copy it. (1:49:53) And you wanna save it somewhere on your computer. (1:49:57) And it can say, Claude, here is a Figma token. (1:50:03) I want you to read the Figma file components (1:50:11) I made and digest them all. (1:50:15) And then build me a requirements spec sheet (1:50:22) with all of the information. (1:50:26) The more you ask it to produce at once, (1:50:28) the more likely it's gonna be garbage in some parts. (1:50:32) Like it's gonna skip over details. (1:50:34) I like to do things piece by piece (1:50:36) because I can control the quality. (1:50:39) But I'm not gonna like blast it out to Claude (1:50:43) and be like, Claude, do this whole thing at once. (1:50:45) Cause that's not gonna be good for, (1:50:47) that's not gonna be efficient, it's not gonna be quality. (1:50:50) So maybe I'll start with like, hey Claude, read this here. (1:50:56) So I'll select the section and say, here it is. (1:51:03) Read this vision and scope and critique it. (1:51:11) And then I have the, it has the token. (1:51:14) It can actually go to Figma's API set, (1:51:17) use the token to make the stuff behind the scenes. (1:51:20) I don't really care what it's doing to do that. (1:51:23) I care about the outcome of it (1:51:24) being able to critique my file. (1:51:28) So it will, whether it does a good job or not, (1:51:32) that's a different story for a different day. (1:51:35) We'll find out. (1:51:37) We will do that in the working sessi