Transcript
0:00 Um I'm we're going to discuss storytelling and presentation building using cloud code. Like you see most of our writing lessons are going to be around cloud code because ye could do so much and it be like um just talking about the theme of things without saying how cloud code does it is not going to complete the loop. So yeah so welcome everyone. Um so just wanted to talk about uh how do you turn your analysis into presentations that actually move decisions forward whether say you're presenting to a VP or your product team or your own squad uh the principles are going to be the same right you basically ensure that um like the message of what needs to be done is uh clear and not just showcasing data in charts. So yeah, that's what we're going to start with.
0:54 Before we go ahead, I have a quick pop twist for you all. Sean and hi, please uh look at the chat. I can't look through the chat right now. So I want you to tell me if this is a good slide or a bad slide or an okay slide, you know. Uh we'll not uh go through the details yet about this slide. We'll get to it slightly towards the end. But I want to know your feedback. What do you think? Good or bad?
1:21 Um, this is like a running overview accusing summary. So, it's pretty clear what this is. >> Alice and Michael say bad. David says barf slide. >> Oh, man. Okay. Confusing. Oh, hi. Hi. Says excellent. All right. Amy Annie, sorry. Says terrible. Bad. Got a lot of bads. Okay. And a barf. >> Okay. >> And a mid. Yeah. Mid. >> Okay. Okay. That's so interesting to know. I'll be honest. In my career, I've definitely seen a bunch of slides that look like this, but we can move on and talk through what do we have today. So, I'm trying this different approach. I want to show you what like basically go to the end and then come back to the first and go through the topic. So, let me stop sharing this part of the screen and I want to show you something that I'll go through today. Man, I have so many of these open. Okay, so this let's say this is the deck. This is the deck that we're going through today and understanding what uh how this deck could be. So, Hawaii tourism analysis at 24 to 825 executive summary for each area. What are the results?
2:40 What are the meth what is the methodology and data sources? How is the visitor distribution overview? The pie chart on the left, what does it say? the big island receives like you know all of this stuff by the way all everything that I share with you today is fully fully generated by cloud code with all the stuff that's already in the analyst and I've created few more agents and skills for this lightning lesson per se average daily spend the line chart what does it show the daily spend for total occupancy the quarterly revenue by island you'll see a lot of charts and a lot of text that explains what the chart is about.
3:18 Okay. What are the key findings and bullet points and what are some recommendations? Okay. And then questions at the end. How do you think about this one? Is it a good slide deck for you all? Before I share what did my a bunch of agents and skills that we created for this actually went and did wait where yep it starts with a title saying what is the deck about?
3:53 It has a graph way more clear and talks about what is it and it goes through like each of these and basically talks about the specific thing and points them to what's happening. Yeah, way less way less number of slides and way more about the recommendation. So this one is specific to the product and engineering teams presentation that we're going to do. We have a similar um you know decks for how would you present the same thing to a VP? How would you present the same thing to your own data team, product team that you are in? So yes, this is what we're going to talk through and discuss how we got from a deck that presented a bunch of charts with a lot of text to how we cater it each of these decks into the, you know, the audience that we going to share that deck with.
4:54 Yeah. So a little bit about um making whatever I have here. So I everything that I shared with you the the the different decks the deck for the product engineering the deck for VP the deck for uh like your team all of those are different agents and skills that I created. Um I'm going to share with you a prompt that you could do it in cla but if you want to build a reusable system including things like that we're going to have a boot camp about it. You could build them yourself based on an open source repo that we already have. Uh you could go to github.com/aianalystlab and/analyst. You get a bunch of these.
5:32 But everything that Sean's creating, Hi creating I'm creating is going to be on top of what is available in the free uh open source and all of that is going to be part of our two-day weekend boot camp. Please uh join our Slack community. We have so many people in there already. Uh where uh we keep sharing our you know videos and um like all the any questions that you have all of those you can share with us.
5:58 Okay. So let's get let's move into the next one. So yeah what's the problem that we're dealing with here? So data presentations that basically you have months of work and if a stakeholder asks for an update you most like I would say they open a blank deck the think through what are the charts and bullets and what's the methodology of how I've created it and let's these are all the findings that I have and then maybe have a set of some recommendations and probably have questions at the end that I would say is like a a a way that you see like I've seen in my career a bunch of people that do it this way and a lot of mentoring from from senior data scientists or senior leaders go through and like hey what is the story that you're going to go through so these are some things that you see are problems with the data presentations not everyone probably does it majorly I would say people who are new to this world or people who who are like younger in their careers you'd see them definitely do this more and more Right.
7:07 And what happens when we do things like this? Stakeholders like literally skims uh skim through them for 30 seconds and you know they ask like what's the bottom line? What do I need to know from this data? I have a bunch of charts and text like but what do I do? Uh all the so what a bad deck lacks is an opinion and is a narrative that you want to share that you want to probably lead with it, right?
7:36 So this is these are the four things that four checks that you want to make sure that are checked for every presentation. The so what can you state your finding in one sentence? It's not a label, it's a finding, right? And what's at stake, right? Does the audience know the why know why they should care? Not why it's interesting to you, but what about it for the audience, right? And this is why it's very important to know who are you presenting and that the the stakes kind of change. If it's a VP, the stakes change. If it's like a the product and development team that you work with, it's going to change. If it's your own team, your own data team or your own analyst team, whoever team you're part of, it's going to change.
8:20 And then uh the evidence, the two three data points, not a bunch of charts that you share where it's pretty hard to find the evidence. Um so the evidence very important and in the end what is the ask now that you know the word, you have the states, you have the evidence, what do we do about it? What is the ask from you to the team? like what is a clear action or a decision request that you want whoever you're you're presenting it with right so so that all of these if all of these are clear that's when the data story is fully intact so if your presentation like fails even one of these your audience probably get confused bored or unsure what to do next and they maybe just move on especially when we are so inundated with meetings and you know information in this world It's very important to share uh you know insights with an opinion with a recommendation.
9:22 So let's have like this quick hack, right? So let let's do this uh check number one. Read only your titles for every slide. If they tell the story without seeing a single chart, I would say that's probably where your deck works. Let's say revenue overview tells you probably nothing, right? But let's say something like revenue dropped 7%. And display ads are the costs. It basically tells you the finding and the magnitude and the culprit. So we could what we could do is the demo today is basically uh we go through the deck that I shared with you first and try to look through all these four different frameworks that I have and see how can we change that deck so that it actually gives the value and if you read through the titles of each slide that basically tells you the story.
10:19 So if it's if all of this sounds like you know try let let's take this framework and try it on your last deck and maybe read just the titles around after this lightning lesson and see if it sounds like a table of content that tells you the story or does it sound like you know a dump of data and a bunch of charts that probably helps you as like a check number one. Okay. So the same checklist but you'll have different emphasis this when it comes to the type of audience that you deal with. Right? So this is what I was trying to get at when I mentioned the different audience in in my previous slides. So the checklist is kind of universal but how you apply it depends on the room that you're in and the presentation that you're sharing with the audience you're sharing with. For VPs you probably lead with the decision they want to say yes or no. mind if it's a the slides we need as less information as out there. So if it's going to be a slide deck it's a four to six slides. If it's going to be a document I would say one pager. That's the reason one pages and two pages are probably the most popular ones these days. Even if you have a long document that contains all the details, you probably need a one-pager that executives spend time on to get the gist of what you're trying to do in the entire doc. Now coming back to the slides, uh we you basically want it in four or six slides of the max. So if they want to debate, talk at the methodology, go on the solution, you can get into like you know some depth um and you could have like you know six to side six to eight slides with some depth for basically your product and engine leads because they want to understand I mean I I gave it as an average obviously depending on the amount of time you get for the presentation you increase or decrease the slides but the intent of what you need to present for which audience stays the VP you do it at a pretty high level and product and engine leads go into some depth and for your own team whichever tier you're a data science team or a data analyst team or product team who whatever uh you know uh role that you play you probably get want to get into the details way more but all three of them need the so what what are the stakes what is the evidence and asking the evidence but the depth and the framing is what it'll change what will In today's demo, I'll I'll go into the product and edge version. Basically, something that's in between the VP1 and your own team one.
13:02 Okay. So, every data story follows four beats. Situation, what's happening, right? Set the context and find and then ensuring that you go into the second one which is finding what we discovered and the your headline. Basically, here's what you did and and then move into the so what and then you have the implication. Here's what it means for us and basically talks about the sticks, the revenue, the risk, the opportunity, what do we want to do and then end with an ask.
13:40 So most bad decks probably the one that I shared, they all are about a situation and no finding implication or ask. They basically do the work of getting looking through a bunch of chart, bunch of data and putting something together about this is what the data is from its face, but they don't talk about uh they probably talk about some findings as well. So I'm not saying that's a common situation, but there's less of the implication more and less of like what does it mean now that you know this?
14:11 That is probably what misses in like most of the presentations. So yeah and the hardest part of any presentation like you know the last mile right presentation is the last mile of a work is basically cutting we need to be brutal about what we cut and the hardest part uh is basically to en to going through stuff all the effort that you put in like I'm sure you might have put in like hours and hours of effort to get the chart right and once you understand the So what behind it? It probably maybe you understand that it does not make sense. It's part of the whole story and you should be brutal uh not thinking through how much time you put in to get the charge from the get- go and like cut it. So but so the whole point is about you even though you spent so much time if it doesn't impact the sword it probably you put it in the appendix that doesn't mean you fully do not talk about it. Maybe someone asks in in the in the in the presentation, what is it? Then you probably go to the appendix and like, hey, I've done this work, but it didn't make sense to be part of the whole story. So, you basically share it.
15:24 Share the the condensed version. And then you probably want to have the type of slides that directly support your finding and strengthen your ask. If it answers an objection, the audience will rise. So, this is where the audience component is important. If something that makes sense for your product and engineering team would definitely not probably make sense for the PVPs. So you cut it for the VP section but you put it in for your product and engineering section. And if it also provides the one member that makes the stakes concrete, you probably keep it. But you want to make sure that there is a strong valid reason for why you want a chart there. a te a bunch of text there and you have to reel it back to the four framework the four slide framework that we had about the so what what are the implications and what is the ask and what is the recommendation that you have now what are we going to do with cloud code because I did give a bunch of theory that maybe some of you already know right so today what I built with cloud code is I built the system where uh we basically We have a deck critique.
16:42 We have a story extractor. We have a dex rescue. We have a slide transformer. I'm not sure if I could I have time to go through all of this, but let's go through one of them for sure. So, I want to move to claw code right now and share with you the architecture in a lot more detail. Let me stop sharing my screen. Sean, hi. Any questions so far uh that we need to address while I keep moving the screens?
17:13 >> I think there's good comments around uh how people have found helpful in their storytelling and presentation journey. Um Greg had a couple that's really cool. Uh one is don't confuse me with the facts and then uh what's the other one Greg? Uh >> answer first not strip te's. >> Yep. >> Awesome. That's sweet. which I feel like is so it's like you put in all this work and you really want to walk people through all the steps that you got to their like so hard to be like >> I don't know no like they don't they don't need to know what I did >> resist the urge yeah >> I know so hard >> exactly wow I'm so glad that conversation's already happening so what's happening here that what are you looking at if you look at my prompt I asked it so this uh on the left you have this giant set of things that we do to do a lightning lesson to you all. It also incorporates a bunch of things for ray analytics for builders and also boot camp stuff. It's huge if we get into the details but um what I'm asking it is to bring me to show me and ask the architecture of uh what does like a bunch of skills and agents that I built like the the regarding today's presentation. So what do you look at? Um my my goal was majorly two things.
18:37 Yes, we want cloud code to do our end toend systems today but probably we are not there fully yet right. So where we want to do the initial like you know get to understand get findings from cloud code and maybe you know put stuff ourselves in a in a deck and come up with like a big bunch of charts and findings that you throw at clot code. Can it take that? Can it take that input? Because it's a lot less work if I mean it it is still a lot of work to get the charts and you know numbers together but it's a lot less work from the standpoint of hey I'm not going to find what is important uh myself. Can I give this bunch of like you know all of this um data dump with charts to claw code and can it do the parsing for me and get me to a place that's right level for my audience. Right. So that was what I was working with as a problem for claw code today. So you give a bad deck prompt. Uh for the ease of use I did the mar markdown file but I have a version that works with Google slides as well.
19:45 uh you basically call presentation doctor that's my agent that went and looks at the deck parser it looks through all the objects and then the deck equity comes in so it scores each slide based on the four framework that I have the so word the stakes the evidence and the ask right it flags antipatterns and it gives the output based on hey this this deck gets this grade and this slide gets this grade and actually adds the critique then what happens Then my story extractor comes in and it goes in and finds one to three stories that are buried in the messy content and it makes the whole judgment if it's going to if is it the signal or the noise what Greg was talking about right uh is it something that uh that we need to add or maybe just remove it and then it does the grade check if it's a higher grade it keeps in the transform if it's not then you know it completes the like you know it just does the transform if it's a grade B or C but if logo grade. It just does the whole thing all by itself.
20:48 So yeah, this is the architecture and this is the type number of the the components that we have. We have two agents and three skills and one helper file to go through these. This is for the markdown files. But if I want this to work with Google Docs or Google Slides, then I have a different set of agents and skills that do that because uh Google Docs uh at least for me uh have been not as easy to work with because it it sometime if you work with it without the agent and skill. It just gets the text and chart on top of each other and you have to work with it a bunch for formatting. So I have a a different set of skills and agents that work to get the Google doc right and the Google slides right. uh right at the right place. But this is for the markdown files in HTML. So yeah, we'll get into depth of how each of these do in our demo probably at the end, but we're getting close to the time right now. Okay, let me go back to the slide deck again. Sorry for the back and forth, guys. I'm trying to share with you uh as um you know, real time as possible as I built this. Okay, cool. So this is like a mini version of what I shared with you of uh what are the multiple agency skills and you know how does the system work under the hood.
22:11 Okay. So uh a quick plug about whatever I shared with you the presentation doctor all of those skills and agents will be part of our boot camp. And if you've come to our lightning lessons before it's not just that it has a lot of other things. It is going to have uh things about how do you do experiments, how do you do experiments with cloud code, how do you do visualization with cloud code. Sean had an amazing session um this Wednesday on it and we have so many other things related to funnels opportunities and root cause and yeah it's going to be a two-day boot camp. Uh we have uh a claw 20 uh discount for the people who attend this. It's going to be a weekend intensive p uh camp. If the timing doesn't work for you guys, you could, you know, look at the recording and join the office hours later that we'll have so that you ensure that you get a place uh for to ask questions and get answers. You could also attend one of our future boot camps if you you know come in for the first boot camp or later because uh we think we are going to keep improving every cohort the analysis the skills and agents that we have. So if you attend one, you could attend one more boot camp later in the course that come through. Okay, let's move on with the content. So if you remember, I showed you the back deck first, right?
23:38 Uh it had 14 slides and it was based on tourism data. It looked professional. I'll be honest, I don't know about you guys, I've seen the decks like that before. Uh it was something that was like a new person in my team created. It could be like, you know, something that I've seen people in other teams created that are part of data or probably something that are um that's not totally uncommon where people have a chart and what the chart says um what the chart shows but not what the chart says as part of the deck.
24:12 So we have something like that we're dealing with as part of this demo. So uh we'll go through this like uh slide by slide in in the cloud code but I want to start sharing with you like uh in in the in the presentation right now but we'll go through this in the cloud code as well. So the bad deck had Hawaii tourism analysis as the title. Does it tell you? Yes, it's a good placeholder or good prompt probably. But does it tell you details about what is the slide deck that's going to talk about? Right. So presentation doctor said that Hawaii tourism analysis a label not a finding. After reading the slide the audience knows the category of data they're about to see. They don't know if tourism is thriving, declining or needs an intervention. Right? So this does not mean probably every slide deck starts with this with the actual finding. It depends on which area, which audience that you're going to share. But if you're going to share from the intent of hey, I want to share this data to make a decision, to make a recommendation, you probably want to have something that is telling a story. And then uh in the bad deck, you'll see that the slides two and three have a wall of text executive summary.
25:38 It basically has eight sentences crammed into one paragraph and a methodology slide which is definitely not what how you want you know things to look like in your main presentation and every chart slide reads the chart back to the audience. Say it's something like the pie chart on the left shows the distribution of visitors by yeah it's kind of obvious uh that the chart already says that. So you don't need text explaining that at all. Right. So the presentation doctor after going through would say every slide shows the same antiattern chart plus bullets they narrate they narrate the chart the pie chart shows is the chart's job. So the bullet's job is to say why it matters not talk uh about what the chart is already you know debating right and what about the next few sides.
26:32 So another example is that the 15 key findings. It had 10 vague recommendations. So this is what the chart said in the presentation. Doctor says 14 slides. Uh overall it gave it a grade D guys. Wow. That's pretty brutal. Uh and it said that zero and four on the checklist. No so what no sticks, no focused evidence. Uh it has 15 slides, eight charts and no ask. Right. And the buried story is that the domestic spend dropped 11% and there's 78% of revenue.
27:05 But it's treated as one of the bulletins, right? So it's cool that presentation doctor picked this up from all the bunch of do like you know uh text and charts that are part of this deck. Okay. So let's try to go. What do I do? So, uh I'll try to do this in a cloud code for you to see if we see the same if if you see the same uh you know recommendations like but live. Okay.
27:41 Hi, I'm Sean. Anything uh in the chat that we want to discuss while I get this? >> Um >> I don't think so. We've been answering the stuff as they come. Oh, >> okay. Awesome. Yeah, let me just start sharing. >> I think we have some questions around like having Google Slides versions versus PowerPoint versions versus PDF versions. >> So, uh maybe I could talk to that a bit before I jump in. So the difference is from the Google slides and the PowerPoint and all of those versions is you just need uh like for example because this is not my corporate account. This is my personal account. Uh Google MCP was slightly hard for me to set it up. So I had my skill some of the context already about my O my authentication and all figured out. That was one hurdle that I had to do when I did Google. And the other hurdle was uh I had to do reviewer agents a bunch for Google doc reviewer agent and Google slides reviewer agent because u clot code doesn't do a great job from the first for the first instance because our goal as part of the boot camp and as part of lightning lessons is a one-stop prompt for clot to do it entirely itself right so for for the markdown it it doesn't need reviewers as much it does a good job right away but for Google slides and Google docs I I have a Google slide exporter creator along with reviewer to make sure that I don't do go and look at every single line if it's aligned with each other or not. So those I would say is the difference between what I my experience was with markdown and uh you know Google slides. But you know what as the new model comes I probably think like the next opus it's going to just like make it a lot more easier for us.
29:38 This is something that we working with right now for the current model, but I can see a lot of these just getting better by the day. >> I just I want to tag on to that a little bit, Stravia. I think one of the benefits of like learning how to build agentic systems that are bespoke to your use case is that like like she just said like the the models that come out again and again and again are going to make things that are not possible or things that are like kind of annoying uh easier and easier. Like where do we store knowledge bases? How do we like make it play well nice with Google or PowerPoint? Those are like obvious um friction points that I'm sure the Frontier Labs are hearing all the time and are well aware of and are going to solve for. What they're not necessarily going to solve for is like how do you set this up so it's customized to make you or your stakeholders get exactly what they want. That's what we are focused on really a lot in like our boot camp and also just in our day-to-day jobs. I think like if you're thinking about like where to invest your time, invest less in like those obvious solutions that someone else is going to solve in the next roll out and solve more for like how do I get this system working on what I care about.
30:59 >> Yeah. And uh by the way, the boot camp's going to have all those as part of it. For this presentation, I didn't use the Google Slides one, but for the boot camp, we are going to have Google Slides reviewer, Google Slides creator, Google Doc creator, Google reviewer, like all of the stuff that I worked with. I actually shared that in my previous experimentation uh lightning lesson. Please check out um previous, you know, uh lightning lessons and stuff. I actually generated a Google doc uh and a Google slide uh for my previous one, previous lesson. Yeah, you could go to a uh Okay.
31:36 >> And one more maybe one more to sort of add is uh there's a leak this morning that uh uh Anthropic has a model called uh uh Mythos or something that is going to be a step change to Opus. Uh and uh so you know it's actually like if if we think about it, it's like well isn't the models getting smarter and stuff? It's actually more important than ever to get in early to learn how to wire these things up so that when the new model drops, you're already you already know sort of like what what the previous what the previous one wasn't able to do and like how do you swap things in and out like quickly and uh to be able to like solve the problem immediately instead of figuring out like oh you know like how where do I even start in the first place. So something to something to think about.
32:26 >> Yeah. Awesome. Thank you so much for the plugs. Uh, hi. Um, so what do I have here in front of you? You just saw me paste this prompt and you saw it give us all these details, guys. It's pretty cool. So, what did I do? Read the file. So, this is a markdown. Like I said, we're dealing with a markdown today. This is a data presentation about Hawaii tourism. Score every slide against a data story checklist. So what stakes uh high you know all of this stuff for each slide give the score by the way all of this is done by the agent by itself but I wrote the uh like I wrote the prompt for you so that you could read it and understand what I'm doing but if I actually call the agent it knows all of this context and it's going to do it by itself anyway but I had it written so that you understand what the agent does it has all of this context along with a bunch of uh other context that I faded And okay, so then find the buried story.
33:27 So look at what it did. It kind of went through each slide. And was there a so word? Was there a stakes? Was there evidence? Was there asked? Yes, it gave it 0 by 12. So I mean this does not fully mean we want 12 x 12 in all the slides because not every slide needs to go through it. But at least it needs to have a passing grade probably. So what's wrong? It talks about what is wrong and it also gives you a fix because it's a doctor guys. So and then executive summary it goes through all of this. It pro it gives the states a one. That's interesting because it mention it gives you also why it gave a one because it talks about mentioning the Maui recovery in passing.
34:15 It talks about what's wrong and what's the fix. And it does the same for slide three, methodology and data sources. And it talks about what's wrong, what's the fix and the visitor distribution overview. Uh it goes through all the soword the stakes, the evidence, and it gave it a 2x12. Yes. So for each of them, it keeps going through this for every slide. Uh so basically you could feed it your slide deck the context and it's going to give this agent's going to run through and give you the score for each of your slide decks.
34:52 So and not just that it also gives the buried story and it talks about which slide does has the buried story right it gives an overall grade of D and average score of 2.1 of 12. Yeah. So it went through and did this entire thing itself. Find went through and found like you know all the nitty-gritty details of where the where the slide deck got wrong and what could be done better. Okay. So now we are 12:40. Uh let me do this. So I'm basically taking it now take that buried story and rebuild this deck. The audience is product engineering leaders and I'm giving it all of this stuff.
35:43 Yeah. So it's basically going through what the presentation do because it has the context. We already went through the doctor. Um it has all the context and hence it's going and building the slides based on what is uh identified as a fix and coming through. All of this could be done in one single prompt. You could give it the and call the presentation doctor with the story uh with the story extraction. All of that happens but I am dividing it into multiple pieces so that makes it easy for you to understand and grock what happens in the background and we are uh going through one after the other.
36:22 So it talks about what the original slide was and what was the verdict cut entirely move the appendix and you know have have this I'll share with you what the final slide deck look like have it handy so it look Okay.
36:58 Yeah. Cool. So, this is the deck that it created. I can I share this with you at the start of our presentation? So, this is literally something it could create in a Google slide as well, but we're doing it over PDF right now, like a markdown on PDF. It went through, it gave a good title. It actually went through and talked to if you look at the number of slides it reduced it down by a lot like until only until seven is what is the actual slides. So it basically cut them uh into into multiple things.
37:33 It added an appendix and it added a bunch of like interesting charts. Like if you look at appendix as well, it removed the uh all the text and it made even the appendix actually have like talk to the actual finding. And the other thing that it did was pretty interesting was it uh added the uh after the key findings because this is to the product and dev engineering team. It basically added the recommendations. This is what I see is lacking. I I have to work with I have to work with my my data science team in my past job uh a lot was to have recommendations in place. Now that you have this data, what is the hypothesis and what is the experiment you want to run and what what happens if you run it like what's the amount of cost, what is the impact that this you know and how confident you are uh about this we might not have all this information but give out as much information as possible but tell them specifically what should happen now that you know all of these insights.
38:38 Yeah. So, I wanted to leave at least 15 minutes for the uh Q&A, but yeah, um this is what we have. And let me just go back to the deck and conclude it. Okay, so yeah, good deck was insiderdriven titles, hypothesis structure, real ask. Uh so it basically the the doctor went and scored through its new deck as well. So it talks about what changed, what was in the bad deck, the title structure, the titles and you know uh the the what is it and what what did the good deck incorporate.
39:23 So yeah uh going back to this chart, I think most of you did say this was a bad chart, but some of you said it was mid. So yeah, uh what do you think about it? Especially after knowing all of does it have the so does it have the asks? Does it have the stakes? It kind of doesn't have any of that in this chart. It just has a bunch of data and it says what the data is. So and it has a super generic title.
39:55 Yeah. So this is what the presentation doctor would score it as the so what don't we don't have it st you know evidence. So now that now the slide tells a story. Uh yeah with this title if we have a title like this. Okay. So there are two ways to do this. Uh we could do this in the cloud web UI as well. Uh I will share this prompt with you. It's even more detailed than what it is here. I could, you know, fit this in my slide deck right now. Um, all the people that have signed up and attended this will get a claude web UI prompt to get the same deck for your decks that you upload to uh, you know, plot web UI. But you want u the like even more detailed input that does it end to end in a reusable system. We are going to teach it as part of our boot camp. And we going to have all these agents and skills as part of the boot camp along with the Google slides reviewer and Google slides you know uh Google deck Google doc reviewer.
40:58 Okay. So this is what you get free today. Uh the deck critique prompt and also the open source repo link and slack. I mean this is what we already have but you if your first time attending us and trying to understand what AI analyst lab does you could look at all of this. You also get the checklist uh about the daily story and how how you uh like you know go about doing good storytelling. Yeah, I think I'm repeating myself but uh no wonder repeating. We have uh uh like a claw 20 uh discount prompt for you guys to get 20% off um because you attended this um lightning lesson. You signed up for it. Uh it's going to have a bunch of things. In fact, I'm getting uh I think we have way way more agents than 80 right now based on every lightning lesson what we're building and what we're building even in general.
41:48 We'll have more all of those shared as part of the boot camp. Okay, let's go to the Q&A. Uh we have around 14 minutes now. Oh, one thing, one question, sorry, more boot camp sales questions. Probably not what you all want to hear, but there was a question around like um yeah, we we had the point around like new models coming out like, oh, should I wait till the the May boot camp? Um so, we actually um in our in our you'll see this on our Maven page, but we actually account for this. So, like we totally get that like material improves, the models are going to change really rapidly. So, uh, everyone gets one refresher cohort to your registration.
42:34 If you say take the April cohort, it includes access to join one future cohort of this boot camp at no additional cost, whether it's May, June, July each month. Um, and then so you can retake it like the next month or a few months later. And then subsequent after like one retake, we do a 50% discount. So, we'll probably be running this like at least monthly while the models are changing so rapidly. Um, yeah, just want to cover that like, you know, we realize in our day jobs that the stuff we planned for a couple months ago has already changed so much. We want to make sure that the content we provide for everyone is as fresh as possible, too.
43:20 >> Awesome. >> Yeah. And I have another analogy where uh uh I think the model refreshes is just going to keep coming. And so right now what we're uh hoping that everybody gets out of is analogous to like learning how to drive a car. So cars will always refresh, but we can't wait forever because that's that's a constant stream. If you learn how to drive early, you can basically anticipate what's going to be different with every single drop of the model like in in in in that in that connection. So that's that's uh that's where we're coming from and uh the one retake is going to help sort of like bridge the two um so that you don't have to do kind of like the grunt work of figuring out oh what what exactly is different if if there is a model drop in between.
44:08 >> Yeah I think there's a question about how many skills and agents will be part of the boot camp that is not part of the free repo yet. So we are changing even what is part of the current repo like there are skills and agents that are part of the current repo that we are changing them every time we try to see there it could be improved like I'm sure you would all uh do it too right if you start running the repo we could always improve on what we had so there it's going to be improvements of what already shared and also we have a bunch of things related to Google docs Google um and visualization related agents and skills uh that we adding Uh Sean um do you want to uh add anything to that? And it's not just going to be about the new agents and skills that we have in the boot camp that we'll share with you. It's also majorly about how do you do that yourself because this is not uh I would say something that you can't learn to do them yourself. Maybe once you learn it to do it yourself, you're going to come up with even more wonderful things that you could share with the world yourself.
45:12 So it is also a lot about how to do this in a way work with cloud code in a way that's uh where you don't probably uh use as many tokens but um and you know we basically talk through all of those details with you in the boot camp. >> Yeah. I think like just to like make it more concrete like we're not selling a product like I don't know I have this philosophy where it's like products don't matter anymore because everyone's going to be able to build it like it's not this year it's next year like um so like we're not trying to sell product here like there there's definitely a bunch of extra stuff in our like repo we'll be showing them and we have we've put around together a lot more stuff on like the kind of analytics engineering stuff we'll be talking about Um, but like Shraia said, it's more actually about you learning how to build this specific to your use case. Like we said earlier, not trying to build the things that the frontier models are going to solve later on, but how do you apply this in your day-to-day job, connect it to your data, build out the things that you're you care about specific to your job to like automate your work much faster so you earn more time to do more important things. That's kind of like what the boot camp's more about.
46:30 Build how to build Agentic Systems. Not necessarily like here's a product we're giving you, you get access. You can you can have the product, it's free. Like I'll probably put a V3 of the product up in a couple weeks that's going to have like way more stuff than like a V4 thing later on. Like that's that's free for everyone. This is more about like how do you build a Gentic Systems >> so that you could build a V5 guys. Like nothing stopping you from building a V5 yourself. Yeah. Awesome.
46:58 >> There's a question around are there pros and cons or heristics for deciding whether to use API accounts versus pro accounts etc. >> Pro use uh all right individually like use pro account. Um the API accounts can cost you way more money. So I do like the I use it pretty aggressively. I have like the $200 a month one. I did the math on trying to do like switch over to API and I'd be spending like five grand or something. So like that's the if you're just building it yourself and you're not building a product for someone else to use, there's not a benefit to going the API route. And if you hit your Max on the on the Max account, you can just make another pro account and log out and log back into that one. So that's my tip there costwise.
47:56 >> Awesome. AJ uh mentioned that he's looking forward uh to the boot camp to take practical steps. Yeah, looking forward to teach you A and a bunch of uh people that are signing up. Um yeah, it's pretty exciting that we get to share all of this with you all. >> Um I know I feel like Anna had another question up here that she's pinged. How might we instruct Claude to save the session output to an MD file? Prompts versus agents versus skill.
48:26 >> That's a good one. >> Uh do you want to go for it, Sean? Yeah, I think um so in terms of saving the session output um yeah, I mean I usually try and work that into my workflow as much as possible like within uh an agent or a skill. Like you could just prompt it obviously at the end too. But if it's something I want to do, I know I'll want every time, then I will literally ask you that at the end, like, how do I get you to do this every time at the end of your workflow? And then it exports the output for me. I also like the uh something else I do is I like to have it journal what it's doing. So even like this isn't the output like but like what it's reasoning through and what it's thinking. I actually have it stop at certain milestones and write like issues log or a journal so that if like this gets interrupted I can go back and say like hey what were we working on or what did we work on you know last month even because that's not going to be in its memory anymore. um I want to like go back into that workflow and you can you can resume your cloud sessions through their interface too. But uh I find this is nice because I can then be in a context of of a new problem and then refer back to the context of a old problem I was solving a while ago rather than resetting all the way back to that context which is a lot of weird mumbo jumbo I just said but maybe you get the drift.
50:03 >> Yeah. One thing to uh what Tron mentioned is what I generally try to look through a lot if I need do I need a tool for this workflow or is it uh something that I can get away with how Claude is already good at right there's so many things that Claude's so good at especially if you look at other models like if you use sonnet versus opus there's a huge difference that sonnet probably would need more handholding but opus doesn't it's already good at it maybe some like some clear prompt would help it get there. Um but there are definitely some workflows you see that it definitely needs more handholding and only for those workflows I go and create skills and if I need this auto like you know done it uh fully uh repeatable I'd create agents and have it like you know do it uh in a fully automatic way but yeah um that's what I try to do in my workflows with cloud code >> journal mechanic So Claude creates and updates daily, weekly EMD files and stores them to your um I actually have I have basically uh Greg so the journal mechanics I have like at certain milestones and my work like if it's basically I'm go having to go through the workflow or if I'm building out the system more uh whenever it gets to a point where it's going to commit uh I have it also like go and write to it's literally like a it's like a YAML file in my repo. It's like journal YAML and it like kicks off a skill to like go write a journal entry of like everything we just did and then that way like later on it can clear context. You could definitely like uh store that elsewhere. um because you might not necessarily want to like I have it like in git ignore. So I'm not going to like share with everyone else. But um something we've been doing for storing context that we do want to share like that is like putting it into notion like a private notion page and I can share it with my colleagues but not everyone. Uh Google Drive could work too. Yeah. Yeah, I don't I just don't do GitHub because I don't know if I'm if I'm pasting something in there that's like stakeholder XYZ, here's their Slack message and I want you to like iterate on on what their ask is, I don't really want like that up in GitHub somewhere, but I do want it stored locally. So later on I can be like, hey, think about like what the, you know, SVP of product or something wants and like does this align with with it? If that makes sense.
52:43 I wish I could take credit for the journal things of Jay, but actually one of the one of our uh actually most junior data scientists on our team thought of that one during a hack week and I was like, "Oh, stealing that." That's like the best thing about like when everyone's like working on it together. Like if you guys take the repo that we're working on, you're just going to like think of stuff that we didn't think of and make it way better than we ever could. So that's like the good thing about like doing this yourself cuz all that learning gets shared.
53:13 >> Absolutely. I think that's what we're trying to build with our Slack community too. Anything that you find uh interesting workflow we have few people definitely share in the Slack around hey this is what working is better uh this is what working is good. So we'd love for you all to come join and talk about uh what's working for you guys and we could you know learn and share from each other specifically when things are going this fast. Um yeah so just wanted to like you know highlight that again.
53:45 Awesome. Okay so we are very close to the end of the session. Uh I would say uh please check out join the Slack. Please check out uh we'll pro we'll have one more lightning lesson probably before we start the boot camp. It's going to be about how do you design analysis with cloud code. Uh Sean uh or Sean's going to do that or maybe one of us uh will come back to you guys and share uh what we learned from cloud code. Everything that we are doing uh as part of this lightning lessons and as part of our regular research, we'll keep sharing and adding that to our boot camp related uh like you know skills and agents that we share with you as part of the boot camp. So yeah, look forward to see you all in the Slack and also in the future ch future lightning lessons.
54:32 Thank you so much. >> Thanks everyone. Appreciate the time and the good questions. Bye.
Summary
- Effective presentations should clearly communicate findings, stakes, evidence, and asks.
- Audience awareness is crucial; presentations should be tailored to the specific needs and interests of the audience.
- A checklist for presentations includes ensuring clarity in titles, concise messaging, and actionable recommendations.
- The session introduces tools like the "presentation doctor" to critique and improve slide decks.
- Emphasis is placed on reducing clutter in presentations, focusing on key insights rather than overwhelming details.
- The importance of a structured narrative in presentations is highlighted, following a four-beat framework: situation, finding, implication, and ask.
- Participants are encouraged to join a Slack community for ongoing support and learning.
- A boot camp is offered to teach participants how to build their own systems and improve their data storytelling skills using cloud code.