Let’s get into the live demos. I wanted to use a product we all know - the Lime scooter app. In Tel Aviv, Lime requires parking in very specific areas, but your phone doesn’t always have GPS. So they created this cool feature where you scan your surroundings, and based on the scan, it can figure out where you are. Sometimes it completes the scan and says “You can’t park here” - this matters because Lime needs good relationships with municipalities, but they also need to balance that with people being able to park their scooters. For this demo, I’ll use ChatGPT. I think the goal, both in our day-to-day and when we build products, is to use the smallest, slightest, cheapest model that will get a really good job done. First, I just tell it what’s going to happen. This is not a fancy prompt - I didn’t spend hours iterating or engineering this. I just told it what we’re going to do and asked if it understood. Then I started dictating context: “We are a scooter company where people can rent scooters as part of a shared economy model. We operate in cities that sometimes don’t have a GPS signal. It’s really important that participants parking their scooters can park them in designated places agreed upon with the municipality. But on the other hand, almost in all situations can park the scooter and unload it so they’re not stuck with a scooter and don’t want to come back and use our service anymore.” I continued: “Recently GPS hasn’t been available for various reasons. When people can’t park their scooters, it’s really time consuming for our support team. It creates a lot of tickets in a short amount of time that are very urgent. The solution involves a lot of billing and it’s really complicated and overwhelms the support queue.” I could talk about user research, data we know, design principles - basically talk like I’m talking to a team and building up context. I added: “It’s really important that anything we build is super simple for most people to figure out. No matter what we do, it’s really easy to reach support. Even if our best solutions don’t work, there’s always a way out to talk to a human.” I gave it a lot of context. It’s still inferring and saying things I didn’t say out loud, but it’s inferring pretty smart things because of the amount of context it has. I can take this, paste it into Notion or whatever, and continue to edit it. It’s really leaning on that context and biasing towards it, with a lot less hallucination or things I need to really watch out for or edit. ➡️ Skip the prompt engineering. Dictate massive context about your product problem like you’re talking to your team. Simple instructions plus rich context beats fancy prompting every time. All right, that was an easy one. Let’s go on and try user stories. Again, 4.0 is perfectly fine for this. I’m gonna start a brand new thread and use my team lead’s preferred template - nothing sacred about it, he just really likes it. Before getting started writing the user stories, I’ll share more strategic context on what we’re doing and why. I’m actually going to go back and take the same context I just gave for the PRD - I could even take the objective from there. Now I’ll dictate the first user story: “When a user who has an active ride wants to park, has stopped the vehicle, opened the app, and hit the button for parking, it first checks if GPS is available, and if so, parks and verifies the location using GPS as normal. If GPS is not available, then it will inform the user that GPS is not available and that we will try another method to verify their location. Before starting to activate the camera, it will ask the user to confirm that they’re ready.” I’m not going over a lot of edge cases here. I’m not totally describing every detail. I’m not feeding it a design even though we saw the video prototype. If it doesn’t do a great job, we can go back, hit the edit button, and just add more context until it does a great job. From here I could do another story and keep going: “In the next story, when the user confirms that they’re ready to verify their parking using their camera, open the camera, show the view…” and so on. The cool thing about this is you save the thread. You do all your user stories in one thread. It starts to get really smart and build on the other ones. What’s really interesting is that saved thread becomes valuable weeks later. Let’s say we’re deep in development and realize we forgot something major or need to add something. You just open this thread and keep talking: “In this user story, blah blah blah.” It’ll spit out the Jira format and you just paste it in. ➡️ Build user stories in a single thread that accumulates context. When requirements change weeks later, just reopen the thread and continue the conversation - the AI remembers all the context and constraints.