PMing with o1 pro, v0, and DeepSeek-R1

Product management is usually fast. The reason I came up with 40x, we have 2 hours today. And so what is 2 times 40? 80. In about 2 hours, we should do about 2 weeks of product management. Every company has a different definition of product management. Let's ask Claude, because Claude is faster. I think of PMing as the else of the product team. There's designers, engineers, and then everybody else. PMs are just everybody else, which is why it is hard to categorize like exactly what a PM does. But generally a PM decides what to build. Their primary output is the spec. It's like the list of things that make up a product feature getting shipped. And the cool thing, the reason I think it's so 40 times faster is that typically you would have a PM that comes up with a spec. The spec might look like this. It's mostly text in Slack or in Notion or in Linear. Engineer or in Google Docs and it just has some text of what the feature is and then it has some other stuff like what the sub-features, like what it actually is going to take to build, and then you pass that off to a designer, the designer actually then turns it into pixels and then that designer may pass it off to an engineer, that engineer, like front-end engineer, may build it and then there's really the majority of the time that 2 weeks that it may take to design and build a feature. Time is spent in the translation between different parts of the org. And I find that if you're able to do all of it by yourself, that is what creates this 40x speed increase, that you're able to go from writing text to designing stuff and then going into code. And if I can just open FigJam, does Figma not own figjam.com? They do not. Let's see if I can spin up what I think of PM, let's say in Slack. Then you have, you know, design Figma, and then you have, let's say, code in Cursor. But really where it lives, right? This sort of situation, the design goes back, you end up with this back and forth. And if you took all these things and you moved them together, the PM, designer, and coder are much closer together. All of a sudden this line gets really short. The product feature itself is better. The exciting thing is you get to try out more stuff and iterate. You have that time. So you can spend that time getting better and better. And by the time you end up in that same 2-week period, you end up shipping something that's really awesome. So yeah, pretty exciting. Before I get started, some questions have popped up. Someone asked, is design how the product should work or aesthetics? I don't differentiate. People say there's like an X. I think they're the same, really. They're same thing basically. Like I only hire designers who do UI/UX. I think in the real world you would never think about separating those things, right? An elevator is not designed by a designer and then built by an engineer. It's a thing built together. The materials matter. Software you can cheat because there are no materials. You're not constrained by material science. I personally don't think I'm very good at UI. My strength is more at testing this nonsense. A lot gets lost in this transfer, right? One of the things I love— so to start with something I love about O1 is it tests your ability to communicate Often in a product org, the PM has some idea. The idea is, yeah, the idea is, let's say PM has idea, right? The idea is this, right? And then the engineer, the designer comes up with, and when they read this, right, what do they like? There's a lot of compression happening, especially for the CFO company. You're busy with other stuff. What I find helpful, let's use Claude for now, cause it's faster. I do this all the time, which is I put this spec in and I say, this is a product spec. You're a designer. Flashes this out into a more specific PRD is some people like to use. I had to actually look up what a PRD is. It's a product requirements document, all the requirements for building something. Then the designer will say, okay, Sahil wants me to design a payout data API. This is their chain of thought. They're like, okay, target users. I need to target different kinds of users. There's gonna need to be an authentication section. Okay, Gumroad API. Does Gumroad already have an API? Okay, this is what that page looks like. It has an authentication section, different methods. This should be more of a header. Design systems are overused and end up with bad design. So it's useful for me because I can disagree with this. I can say, actually, no, that's not what I meant. I can go back into this often, like going back to this Figma thing. I really spend time going back and forth. Oops, I did not mean— for example, I should probably link this. It's probably helpful, right? Add new API methods. That's useful for the designer to know. Then I'll just start again and say, okay, I'll just keep iterating on this. By the time I send this document to a designer, you may end up with a much, much healthier specification. And then all of that back and forth you save because you're presenting something higher quality, the functional kind of requirements. Pretty simple, right? Not a crazy feature request. Expose an API that allows people to access payout data. So Gumroad, if you don't know, helps people sell stuff on the internet. You make a bunch of money and wanna see your analytics, you can do that. You can select all time, and it's really slow because my Gumroad account is really old. So let's do this year, or last year actually, probably a little bit more data. And then you can download, you can go into your sales, download the information, etc. People want to do— we want to add these API methods, especially engineers and developers. This is the format we use at Gumroad: what and why. Why is to make sure that If someone is going to give me feedback on something, they know why I'm trying to do the thing I'm trying to do so they can align on that because sometimes there's a lot of miscommunication on, oh, Sahil wants to do that because of this. No, actually, no, that's not why. So we always have this format, what and why. Useful for high-volume creators that want to have to do actual accounting. Currently, this is kind of pretty key. Currently, the only way to access payout data outside of the report we send is to export a CSV for each payout period. So yeah, so let's scope this out and let's try O1 and see how I would use O1 to do this. And it's going to take some time, so we can take questions. Oh, this is not using R1. When it has web search too, that's pretty cool. We can pull in that URL, all the information from that URL. I find this very useful. To get into the head of the person you're asking to do some work. I can't even think this fast. Can anyone think this fast? First, I'll check the results. It's cool. This gives you a hint of the work you make other people do is, right? If you're already done so much of the context switching yourself, you don't realize how much work is involved. Basically does some random stuff too, but pretty good. Add the following endpoints to this. Require new scopes. Interesting. New scope. You may want to say no new scope or new scope, right? You clarify the scope of what you're trying to build. Webhooks extend the sample response. That's nice. Think about how much better this is than the other response. Great. Success. Oh yeah, I noticed PRDs do this often. Success metrics. I don't really care about those personally. Cool. Let's read this. Let's see my own thing. API. Where's my API? Why do we need a new scope? View sales is probably good enough. No new scope, in my opinion. Nice. Payout data is different than sales data, but effectively the payouts are the sales. Less complexity, less work. Big fan of less work. Okay, cool. And now there's 3 API endpoints that it thinks we should make. Why is that? Another example would be products. Products has an ID of a single product and many products, and delete and put and some other things. The reason we're building this feature is so that high-volume creator— it's actual accounting. So presumably, I don't think you need any of this, right? Just a single new API method and it's going to be this one. The only way to access this data is to export a CSV for each payout period. So a simple approach would be to return the aggregate payout data equivalent to the CSV for each period in the date range. Right. So I'm just saying turn this into a more fleshed out PRD. I'll just say scope for a product designer to design in Figma for Gumroad. Deepseek already knows what Gumroad is. We're basically done with most of the PME type stuff. Pretty much ready. Typing all this would take me several hours. API spec. Let's see if there's anything I should list to hit here specifically. I will add the search and say mirror the new API method to follow the statement forms nicely. For developer experience, when you're talking to AI, just be clear why you're saying certain things. If it makes changes, we can start designing the feature. Okay, so you see how it does that v2. So all of these are scoped under v2. So technically this would be v2 parameters. Oh, now it has a nice table. It's confusing because it doesn't I don't know, this always gets me. Like, does it include this date or not? Presumably it should include the date. That would make more sense. So I would say include the date when doing the filter, not exclusive. I also find this pro tip of adding et cetera helpful. Also do the same thing with humans. Nice, cool, great. Stat— I guess this could be true that you could end up with different statuses. Sure, we'll keep that. And then page keys. Do we have a page key here? See products, no pages. Don't need this. Just get rid of the page key. Maybe we wanna mention that no pagination support. Keep it super simple. Nice. I do want to add this status. That's like a good win. How do I insert row? Just string. I'm lazy and stupid. Let's get this to be the hard Gumroad is like a 15-year-old product, so it is quite a complicated product in my opinion. I think it's the job, like a user doesn't need to understand your entire product in order to use it. You only need to pick the thing that's closest to the new thing that you're building. You don't have to do everything. Description, valid values. Oh, see, this changed. Oh yeah, see, it moved. Let's just make this nicer for myself. Also, I found this great quote by David Lynch about writing. Maybe pull it up for me. What's the quote by David Lynch about writing things? And this is a very boring product, but we'll do a more fun front end one. Oh, now the other thing we should include is a response structure. Matches the state display pattern from product objects. Let's just confirm. I still need these two things, so I'm going to copy this. Go back to my Deepseek and say, give me more of this new API endpoint. Load it in this. I don't need search. And then we'll start using v0 to design and build this. I'm just gonna go find the quote because it's bugging me. But it's not the final thing. It's to remind you of the idea, which could be much more full than what the words actually are saying. For instance, the script has no sound, just ideas. So I think it's useful, this bit, basically write down the ideas in such a way that when you read it again, the idea comes back in full. I think a lot of people don't like to scope. They don't like to plan, and they think it's about helping other people that are not as good at them as them at certain things. But, but it's really about helping yourself so your idea is not lost in translation to the future you. All your good ideas stick around. Awesome. I think this does all the things I wanted. I will delete this one, which was subpar. Slack still needs to work on this, but we're trying to use it and put it in here. It's still a bit janky. I should have— I guess there's like a copy button that maybe would be better. Cool. So you have the example response, you have the curl example. Pretty good, right? I think this is what a designer would need to build a thing. We can take this spec and go to v0 and design it out. To see how good of a job it does. Something like this, I could almost one-shot as a designer. Open that page in Cursor and say, add this new payout endpoint. Do people wanna see that or are people bored with how awesome Cursor is? I'll show it because v0 is slow, so there's something to do while v0 is doing its thing. Here's the file that generates all of the API methods. It's overly complex. We should just move it all into the page. Now that we've got rid of localization, AI can translate on the client side. I just highlighted the entire page. Maybe I should use an agent feature of Cursor. Go to Composer. I'm in this page and basically say, I'll update a new API method. Cool. All right. I would just paste this in, keep the Y in, and do it. Make sure agent is selected. And it'll do its thing on the side. I'm just increasing the font size for the 720p resolution. You can see what v0 is thinking. Too slow. Don't know why it froze. Let's try again. You know what I can say? Design an API methods page. Maybe you can do a better one and it'll inspire me. Just to recap, I don't really use Figma anymore, to be honest. I design now in v0 and then I go straight to Cursor. All right, not bad, but we have much more information. Let's see if I can get it to do more formatting like this top part. I'm just gonna take a screenshot of use this content. Cursor will do the hard work. Boom. There you go. Pretty good, right? So yeah, that's basically what Cursor does. I didn't have to think about code. I could just tell the Composer agent what to do and it did the thing. Created a new section for it called payouts. This is just the front end, right? As a PM, I would commit this. So I would say, what is it called? It's like payout data API. I could actually use Devin to do this too. I don't even need to open up Cursor, but while I'm at my laptop, I'm just gonna say new payout data API method. Oh no, I pushed this, but that's fine. That's an extra file I created for something else. And now the engineer, the backend engineer has an example exactly of what needs to be done. I'll replace the designer in this situation. I've done the design part and maybe we can do the backend engineering part. Go back to the scope. Go to agent. I will use the hub. Let's see. Do I need to provide any context? I haven't worked on API in so long, so I have no idea where this would be. Let's see what it does. And while it's doing that, I can add this section. So yeah, that's an example of PMing and designing. And in this case, the design system is already well established, so there's not really any new design that needs to happen. We'll pick something harder and more creative next. All right, some questions. How did you arrive at the what and why in the first place? Basically, we just email our customers and say, what do you want us to build? And then they tell us. Then we try to think about what is going to lead to the most earnings for creators. Effectively just doing the basic math, like number of creators times average GMV per creator. Then what you also want to figure out how much time each thing is going to take. 5 hours, 50 hours, 100 hours. And then you just do ROI. What's the highest ROI thing you could be doing? And honestly, nowadays you could probably just take the whole thing that, that these creators give you. Oh, oh, one pro can help with a lot of this stuff. Like, our creators want all of these things. Tell me what I should build first to make them more money. Add this specific payout method. What's your approach to make sure you're leveraging the knowledge of your expert team members? Since it's more specific, it seems to take away some agency from the people who do the work. I'd like to believe I'm just saving them time and energy. Energy so they can focus on other things that are more creative and interesting. Designers can spend more time on the design, the engineers can spend more time making the API fast, etc. And it's just like a V1, right? Like they can always toss it aside. I think more is more. I try to provide it and say, look, I spent— it didn't take me that long. I was already in the context. It was like 10 minutes. Generally people appreciate it. Oh, people are asking why I don't use Bolt.new. Yeah, I don't know. No, no good reason for not using Bolt.new. I guess Bolt.new comes with a backend. This is just me doing frontend engineering, so it feels like overkill. I'm not trying to like ship a product. I'm just using it internally. So yeah, I find, but I've heard good things about Bolt.new. Their UI is really, UX is pretty good. Do I use Jira or Linear to do product planning? We used to use Notion, but right now we use Slack canvases. Honestly, the best tool for product planning is an office. 'Cause I feel like most of these tools exist because people aren't in the same location. Just talk it out. Google Docs is still number one. All right, there you go. Cool. Pretty good. Let's compare this to what Cursor did. Cursor. Retrieve payout data for the authenticated user available with the view sales scope. Oh, it updated it. It changed 7 files. Including this, this might be a good change I've made. It's just the description now. Yes, I always review code. Someone asked, I normally review it in GitHub. I review it by like testing the feature, right? Like I would actually see it in the browser. I don't have it running right now, but I would normally look at it in the browser and then I'd have noticed it was doing something weird. But yeah, I think it's important to review the code. Pretty cool. Retrieve all payouts with optional date range and status filters. And then you get the parameters layout comes from get payouts, etc. So let's see what it did. Review changes. Sure. But created a new controller for payouts. Seems reasonable. Created a new route. Seems very reasonable. Wrote specs. Seems pretty reasonable. Created the API documentation. Sounds good. Create a new commit. Why did it not say the route change here? And then I would review it in up before. Obviously I'm not gonna merge it. The tests have to pass and all that stuff, but let's open it up in GitHub to show you guys. I would look at this after tests pass. I would merge it normally. I would personally hand it off to, I'd be like, hey Connor, please review and merge. I don't know that how much time that would've taken. I'm not saying it's perfect, but there's probably, if there's anything wrong, it's probably within 5 lines of code. It's probably really close. My seems reasonable. This is a massive code base. I didn't give it any context. It got rid of the gap and it constant again. And shipped a new API method for the Gumroad API. So boom, did all of this. And I don't know, I should have probably approximated how long it would have taken, but to actually ship all of this, what did, uh, I think Deepseek said 7 to 10 days. If you have a PM, a designer, and an engineer, it's going to take all this time. And basically we're done. 30, 40 minutes. So I don't know how fast, what was my thing here? 40 times faster. So what is 40 times? How long does it take us? 30? Yeah, I would say it would've taken at least a week to ship to production. Maybe 3 days. Let's say 3 days. It took us 40 minutes. How many minutes are in 3 days? That's 3 times 24. Actually, you're not really working all of these days. Let's say 8 hours a day. 36. How close was I? 36 times faster. And what did I say? Not bad. Pretty good. Towards the numbers a little more and I'll get there. That was not even a high intensity idea. More questions. Do we still have designers at Gumroad or one person who does? Yes, we do. We do have designers at Gumroad, though they do all code as well. We don't have designers who just push pixels around, to be honest. So it's not really like a high demand to ask designers to know how to code a little bit. Do you think it's worth the time to provide a lot of context to the LLM? Generally, no. The smarter the LLMs get, the less you need to provide. They're smarter than most humans, right? By default, it's going to be pretty good. If you just say, design me an onboarding form, you don't have to say information architecture, all the stuff you learn in school, pretty font, nice padding. It's just gonna do it by default. Part of the shocking thing about deep learning is that it is good. It actually produces like a good, it's, it learns, it gets smarter. Smarter as you give it more data and you let it reevaluate its weights. I think the issue with dictation is it's not the writing that's hard, it's the editing. Editing text is still text. Being able to select, edit, and lead a copy paste. I would never send this as a voice memo. I need all this formatting. But yeah, in theory you could like, you could type like this. I could have said really fast if I were competing with myself, design me an onboard reporting, like I'm already behind, but that's not the bottleneck generally. Add some nice animations. Think about how long this would've taken a human to do. It's not hard, it's just so time consuming. If it messes up by rewriting parts of your app that it shouldn't, do you reenter the prompt with more instructions or manually make the edits? Normally, you ever see a Dave Portnoy eat pizza? One bite, everybody knows the rules, right? Same thing for AI. One shot, everyone knows the rules. The goal is to do it in one shot and doesn't do it in one shot, then I'll just do the rest myself. That builds my skill of being able to get better and better at using AI to one-shot it. Because think about that 40 minutes. Imagine I had a really good prompt. It could have taken 5 minutes, right? Would've been faster. Mark says, are you able to, oh, let's see if it did add some animations. Okay, sure. It's random, but it did the pick your favorite design agency and it'll do do it. So design it like a Facebook designer, design it like Apple, design it like Android. There's a lot in few words. Jean-Paul says, with 40x increases in PM velocity, why are there so few businesses built this way? Is it just too soon or not enough people believe you can just do stuff? Why no single person, $50 million, $1 billion? That's a big difference. Why are there no one-person billion-dollar companies or whatever? There are, truthfully, there's a gazillion of them. Like Google is worth $2 trillion, so that's 2,000 billion-dollar companies within Google. Many are run by a single person within empires. Why are there so few businesses built this way? I think most people don't want to be so solo. Like, people like collaborating. Oh, see, this is what Pentagram would've done. Pretty cool. So remove animations and redesign like Facebook. Or stripe with big blue glossy buttons, something like that. See what it does. So yeah, I think most people just don't want to, and to be honest, it's not the bottleneck, like shipping a bunch of, like shipping that feature is not gonna generate more revenue right away. And yeah, I think it's a combination of personal desires and it doesn't really move the needle directly. I saw a tweet from Tyler Tringas. He tweeted a while back. Next week, launching a competitor to a widely used product that's outrageously overpriced for being so simple. Jan 18, and a few little bits later, he shipped this product. It's called DocFizz. It's a DocSend competitor. It's a lot cheaper. But how many people have switched from DocSend to DocFizz? It's impressive to ship something like this quickly, but the bottleneck is is in marketing and sales. People like to make fun of DocuSign and having, what are all these 8,000 employees doing? I can tell you what they're doing. They're doing sales. They're an $18 billion company off a very simple product. And my guess is if you look at their Q, what is it, 10-Q? If you actually look at what they spend money on, see if I can find it. I forget exactly where they list this. Not here. I don't know why their 10-Q is not at 10. See here for 2024. Wow, they have so many documents. Oh, here it is. TechQ. See their financial statements. So you can see here their research and development is $151 million for just these— for one quarter. Crazy, right? And they spent $300 million on sales and marketing. So that's like where most of the budget goes, right? So sales and marketing is really the bottleneck. It's like the outreach. It's actually convincing people. To use your software. Google, for example, Google is pretty massive. My guess is they're probably even more extreme on this, right? Like Google, how many people sell Google Ads and AdWords and YouTube ads and all that stuff? And how many people actually work on google.com search? That's probably, the ratio is probably pretty extreme because what drives revenue is, well, I think that's just mostly supply demand, not really the value. Sales is really valuable, but there's a lot of people who want to do sales and the value they create is much higher than the salaries they get, which is why Google's worth a lot of money. And then what's your take on the fact that taste and craft will be the differentiator? Hamza says. I think that's cope, honestly. I think there is no, there will be no differentiator, right? There's none. You, there's nothing that you, that AI will not be able to do that you can do. That's the exciting thing is that there's no, there's nothing left. It'll be better than you at every single thing. Taste is nothing. Really, to be honest. Like, taste is just trying out a lot of things and taking a lot of notes on what is good and what resonates and getting market feedback and doing a lot of research and reading and going to museums and listening to music and traveling and getting a lot of insights. Just going, like, scrolling Pinterest.com, right? This is taste. It's just scrolling Pinterest and, like, trying things out and figuring out why things resonate with people. But nothing that I add can't do better than you, faster than you, cheaper than you. I actually never asked this, so let's see what it comes up with. I didn't even say what to do, so let's see what it does. Let's ask about, let's ask this question. But yeah, I think taste is total cope. Like, I don't, I don't, anyone, anytime you use, someone uses this word, I'm like, why would you use this word? It's not a very tasteful thing, right? Taste means coming up with something different, I think. Taste and craft, or, and I, there's so few people, like Kanye West, I think has taste. Taste. Like, like there's some people who are truly have different ideas. They generally look weird. They generally say things that people don't hear often, but most people are not tastemakers in any real way. We set the rules, right? Lions are stronger than us. We still rule the world. So I'm not too worried, but, but I think, yeah, differentiator-wise, I think taste and craft will not. And by the way, like it doesn't matter. Look at DocuSign. Look at your iPhone versus any other phone. There's not that much differentiation at this point. It's really the best book I've ever read about this. The thing that really does matter, what is differentiation-wise, is economics. So the thing I always go back to is, is how do you win? And he's probably not a— he's probably an AGI kind of skeptic because he doesn't believe that scarcity will ever be resolved. Economics, it's pretty simple, which is basically the cheapest good wins. Like, why does DeepSeq win right now? Is because it's the cheapest, right? If it were more expensive, then no one would care. So the differentiator has always been who can produce the good for the cheapest price. The reason people who code and design and PM all in one win is not because they're better or they produce better products. It's because they can ship the product for the cheapest price because they need less people to do it. So DocuSign wins. You might say, oh, what about this? That honestly, DocuSign probably has way more features than DocuSign. Offers, right? There actually is a lot that DocSend actually provides that only once you start building it and trying to compete would you realize how much they've built. It's like a 10-year-old business, right? There's, it's like Gumroad. People compete with Gumroad all the time. There's a lot of features that Gumroad offers. It's gonna take you a long time to, to build. Okay. What does Owen Pro think though? Oh, disagrees. Okay, great. Only 'cause everyone else does. I think what matters is being able to produce the same good for the cheapest price. But why is Nvidia winning? It's because they can produce GPUs for the cheapest price. Why is Apple winning? It's because they can produce phones for the cheapest price. If you disagree, come try competing with them. Can you produce an iPhone for cheaper? I can't. Economies of scale are very real. How expensive is google.com to use? How expensive is facebook.com to use? How expensive is ChatGPT-4o to use. All right, anyway, Mark says, on the subject of Cursor, have you seen any noticeable difference between paid and open source alternatives? Continue.dev. This is a good example of I underspecified, right? Like probably, probably even just the single letter probably leads to a lot of this stuff. You could say, how could you improve this to ship 99% of the value? With a lot less code complexity. Maybe let's see if it gets this one right. This is some reasoning. It has to actually think. Yeah. Anyway. Oh, see, this is Facebook. This is how Facebook would've designed it. Pretty good. I'd sign up for this service. It doesn't really matter. Pretty good. Jordan says, I think larger companies don't realize or are not capable of operating the way Sahil is. I appreciate that. I think it's just tough. It's tough to make hard decisions. Even as someone who runs a business as a dictatorship, I have a hard time making hard decisions. It's not fun. It triggers your fight or flight response. Yeah, I think especially as you have more orgs, bigger orgs, more people in the loop that have to participate in making every single decision, it's very hard to get alignment on making a decision. And yeah, that's why I like being small. It's not about saving money or it's mostly about moving faster and shipping cooler stuff. I just wanna ship the best possible stuff. What was the book? Basic Economics was the book. Someone says, how will sales be impacted? Will there be cut? I honestly think sales will grow. I don't think there'll be any cuts in sales. I could be wrong, but yeah, I don't know. I think there'll be tons of cuts in engineering. I think there'll be a lot of cuts in design eventually once Figma gets around to stuff. I think sales and marketing will be untouched. I think customer support is mostly a function of sales really. You don't need it. But it helps with sales, so I think it goes under that, in my opinion. Like very small product. No one should, in my, I don't know, I have a strong view on this, but I don't think anyone, like I personally don't believe in the PM role. Like I never have, never hired anyone who does that. We have product leads now that we have 5 projects, but we generally pick engineers to run them or designers, people who are, I just think it's just like typing text is not like a real job. Like you have to do something a little bit more. Beyond that. Think about how much time it took me to— it's not that much. You have to make a lot more decisions. In my opinion, these are not very many, just 5 to 10 decisions. This is maybe 5 to like 30 to 100 decisions, and then the engineer has to make 30 to 100 decisions. So I just think the ratio has never made, made sense to me, but that may be just because I am a PM and I, so I just don't do it. I just don't hire them because I just do it all myself and AI allows me to scale so much that I've never needed another PM. I think it depends on where you work. What should current PMs do to stay relevant? Learn to code, learn to design, do what's fun, learn to paint. I don't know, do stuff. Learn as much as possible. You're competing with other things that learn a lot. So let's do another one, which may be more designy, which is the social proof widget. So for Gumroad, we're gonna add a social proof widget, which I like. How do I download download this thing though. Let's see it. So one of our designers did this, Jack. Oh no, Deepseek, why you? Yeah, Gumroad, if you're familiar with Gumroad, these product pages, let's see an example of one. You know, it looks like this. You can buy it. It has ratings, blah, blah, blah. And we want to increase conversions. That's a big part of Gumroad's jam is trying to help creators make more money. So One idea we had, this came from creators, is a sort of social proof widget, right? So these things that pop up in the corner. And so let's PM design and build this. So just to have some happy accidents, and let's just say build a social proof widget. When browsing a Gumroad product page, in order to increase conversion versions. Sure, not bad. Gumroad. And then I can put this part here, probably. It's always about making creators more money. Okay, so this did a basic social proof, but it, for example, toast is browsing a Gumroad product page. So let's try again. Okay, while it's doing that, I can also do some other stuff. I'll say build a Gumroad product page so we have something good test with. Which one of these should we focus on? Pick one to MVP and provide a very simple scope for a design to build. See what it does over there. Then I'm also going to take this and which one do I like? I'm just going to pick one. Probably purchase activity seems like the most reasonable one. So let's just do These are not bad, right? Pretty good. Oh, there's an error. Failed runtime error. Alright, 38 seconds. Wow, really trivial thing to build. Oh, why not with limited stock? What? I think that's wrong. I think purchase activity would be better. I guess I didn't say, I just randomly said which one. I didn't say, you know, what the why is. If I said in order to increase conversions, maybe it would've done a better job. Alright, This is useless. I like this though. This is pretty good. Like pretty good Gumroad product page, I think. So let me add this, see what it does. And then the last thing I will do is I will take, take this and I will be there. Okay, so let's make it more Gumroad-y. I feel like Gumroad is a bit different. If you go to Bet Small Bets, page. Gumroad has a bit more of a brand, so let's design this one more black. Neo— neo-brutalist would be the word. Yeah, this is pretty good. I actually like this more than what we designed. I like how it has a purchase now button in there so you can just click it to purchase it. Oh no, it went away. Oh, this is nice too, black. But honestly, I think it's gonna be hard to beat that simple one that just Gotta— I like some of these things show up or just within toast like that. Put these as examples. Small bites. All these. If a purchase. This one too. Oh, that's cool. Answering some more questions. What do you see the benefit of being a sole designer or engineer being? The reason I think the design engineer sort of role is not really a thing is because the AI has made the bar for becoming multi-hyphenatic so low that you would you just will identify strongly as one or the other. If you think about architecture or designing a building, like, the people who get to decide these roles are schools, right? Like, at the end of the day, it's like genre fiction. Like, you write a book, you're not thinking about, oh, this is this kind of book. You're just writing a book. But they have to put it on a shelf, they have to put it in a catalog, they have to put it— submit it for awards. So that's where the genre comes comes from. It's actually awards. You can't have best documentary without labeling what a documentary is. Otherwise, who cares? You're just an MP4, right? But basically, if you think about any field as a square— I don't know how to make this a square. There you go. This is like an industry, right? Like, you can say this is like software. Generally, you have a narrow, shallow horizontal, which may be design, and then you have deep, deep thing, right? So if you want to build something, you generally have designers. You expand them, can design anything, right? Like designers can design it. It's not, oh, I didn't go to school for designing mobile apps. I'm screwed. No designer learns these general principles on design. The engineers generally have, can build anything, something all the way through, right? They have a deep sort of foundational knowledge. And so that's how I think about any industry. It's like this. And so you're gonna go to school and the school's gonna tell you, okay, I know you want to go into software, but are you more interested in being, talking to users and being more horizontal and designer? Designers and engineers because that's just like the way the industry has been built up. Just like you have soldiers and cavalry and scouts, it doesn't like, like that what they actually do is very soft and fuzzy. Generally you go to school for something and until you go to school for something in the middle, like a new word, right? It's not gonna be amalgamation of two things in my opinion. So yeah, I think it's mostly just you want to be really good. And what I tend to find is a lot of design engineers are just not good at it. They're like me, not that good at anything. And in that case, they should be founders. Like, they should be PMs. PMs are design engineers basically, right? Like, PMs are the glue in a team of people that you're trying to ship this, but you have 3 columns. Then the PM kind of glues everything together. The PM organization, right, is basically the glue. So yeah, if you're a design engineer, you're really just a PM that knows how to code and design more than anything. That's how I think about myself anyway. Someone says, why would anyone buy DocuSign? I don't know. You gotta ask someone who buys DocuSign. I'm not a customer of DocuSign, but I think the sales make it easy for you to make the decision. People are lazy. They don't want to do research. Time is the ultimate scarcity, right? So that's fine. So anyway, this also turned out to be a lot simpler than I was expecting, but I like this thing. So yeah, I don't even know if I need to do that much more. I guess I could, but let's scope it out then. Maybe I'll take a screenshot and like I can put it in. So things like this, I would put it in for the engineer so they know what I'm referring to. Where is my— I feel like I had an O1 Pro going, but maybe I didn't. I like this too. It's not bad. Pretty simple feature, to be honest. Let's get O1 Pro to turn this into a slightly more fleshed out scope. All right. Any other questions? We're basically done. Done. Designing process, pretty simple. Anything anyone else wanted to learn specifically about how we do stuff? This is it, there's no magic. I do write, use Cursor to write tests. Yes. Actually the first iteration of Shortish, which I built, was a test writing tool, but we actually changed it now, so that is just a test framework. Makes it really easy to write tests, because when you build a feature and want to test it, We try to make it really easy for people to write tests. Simple. How easy it is to write a test? Test the API endpoint, expect the response. We have lots of examples you can check out. If you're Google, perform a Google search for shortest test framework. Test Google's advanced search features. You can test all of the— cool. They can be really simple, like just single English sentence. You can add some variables, watch a YouTube video, search for cute puppies, play the first video. So yeah, I want to make it as easy as possible to write tests because I think tests are really important, especially as AI writes more and more code faster and faster. If you go back now and relaunch Govern with AI tools, I don't know, how do I answer this question? If I went back, there would be no AI tools yet. What? I'd build something completely different if I had AI tools. I guess like a robot toy company, Door, who knows? But you don't have to look at going back. I'm now, I'm here now and I have access to AI tools, right? So just look at what I'm up to these days and you'll probably get a good sense of what I would've been up to those days too. I'm not that different. How, Seth, what do you do if it's something more architecture-based? As in schema or coming up with a schema or whatever? I guess I would just do it from scratch. No real AI involved there. But often what I'll do is I'll go and I'll open up the schema.rb file and I'll paste it in and be like, I am building a new feature. This is my existing schema. Like, how would you architect the new feature in our database? When a visitor loads the product page, we'll call an API to retrieve how many sales occurred in the last 24 hours. If there's at least one sale, buy now button that triggers the Gumroad checkout flow. Oh, this still should fade in. Yeah, that feels reasonable to me. I'll note that maybe we want to use Clickhouse. Actually, no, it's not worth it. Pretty simple win. This style is a bit ugly, so maybe I'll spend 3-0 making it a bit prettier. Make it Gumroad-themed. Neo-brutalist. No rounded corners. 1px black border. Ability to close. Show for, say, 10 seconds, then fade. See what it does. I've used Operator a bit, but not too much. Not nothing really to do with PM though. Probably for stuff research. Oh, that's cool. It's cool that it knows what government looks like so much. Take a screenshot of this too. This is a good example of I think it's worth maybe having a designer spend more time visually making it look interesting. Let's see what it does. I do not use AI for code review. Yeah, I think JavaScript, React's next. It's fine. Just building stuff in v0 is a really good start in my opinion. Every PM should be spending most of their time, I think, prototyping stuff. Ideally they were in Figma before doing prototypes. Now they can be in v0 or Voltnew or whatnot because people have mentioned it. Let's put this in here. I don't know what it's gonna do, but people seem to like it. Oh, cool, lots of different purchase. Yeah, it looks pretty good. Oh yeah, I wanted to do a purchase button. So a more complex thing is just a bunch of simple things put together. So this is the exact same process I would use to build anything in software, at least any, any web app is— think about the most complicated web app that exists, not that much more complicated than— like, a piece of it is not that much more complicated than Gumroad, or like, what is the most complicated web app out there? Figma? Maybe. Do you think O1 Pro as it at the moment would be able to review designs and find US issues and flaws? Yeah, definitely. That's often I use it for that. I'll give you an example. That's like a— I think I'm falling sick. No, not good. Okay, that's getting better. I would say put the X in the top right. Maybe try like horizontally center the title. And just now, and don't make the button full but match the text. But yeah, so for example, let's say I took a screenshot of this and I said, one pro, I'll just say it. This is a very simple— if you want to improve as a designer or as an engineer, definitely use AI to improve your thinking, just like I did. I feel as a PM could do the exact same thing. I think the best marketers are product people. Like, they built really good products. Deepseek is the best right now. Oh, I like that. The padding on the top is a bit too big. Padding on the top is too much. Bottom is too little. Make the whole toast way more rounded. Not bad. Yeah, it's pretty good. Comes up, comes down. How would it look on the page itself? Can you imagine it? Go up there. All right, let's ship it. And the original just to compare it with this. Looks like this now. Oh no, where'd it go? Does this thing— yeah, it works pretty well. Oh yeah, the other thing I can do is I can always share the link to save the design— the engineer some time implementing it, or the designer if they want to iterate. Now they have the v0 link. All right, what did it say? Ambiguous context. Okay, ignore that. Okay, okay, let's see. I'll use this iteration This is O1 Pro feedback. Put it in here and see what it is. And then we'll be done. Oh, I like this. It's basically the same design just with some new copy, but. Alright, catch you guys later.