The challenge, though, is that this is the natural way to build most products, especially especially if you're coming from a larger company without resource scarcity. And if you're 100%, correct about what you need to build, if you're, you know, if your initial shot is exactly right, then this is actually probably the fastest strategy. But the problem, especially with a startup is twofold. One is you don't have infinite resources. And two, you probably aren't 100% correct about exactly what you have to build. So what is your optimal strategy? I think it's twofold. First, you need an explicit consistent tempo for the company, a cadence where you're going to come up for error, evaluate what you've built, and course correct. Second, you need to design an explicit feedback loop at every single stage. It's not enough to just have internal milestones where you're track whether you're 50% done with some feature, you need to build things in such a way that you can actually show them to customers, show those features to customers and get real feedback. This isn't new, per se. And you'll hear people talk about this in various firms. The entire idea, I think of consistent sprints in software development is sort of a manifestation of this. Or, you know, Reed Hoffman, I think famously had some advice around, you should be embarrassed about the first thing you ship. All of this is rooted in the same idea. And it all gets at the same thing, which is you need tempo. And you need feedback, not just at the software engineering level, but at the whole company level. Now, this is this sounds great in theory, but how do you actually do this in practice? I think a few tips. First, you'll sometimes hear investors talk about wedges. The idea is you want to find some small acute pain for a customer, build a simple, great solution for that pain and then expand from there. That's a great strategy, you should do that. Find the narrowest point deist wedge you can use to get started. Second, explicitly break bigger problems into smaller ones. And for each smaller problem, designed a feedback loop. Ideally, you can ship interim work to customers after every single stage and get their feedback. Even if it's a little bit awkward, like you want to the feedback loop will not come naturally you have to design it, you have to be explicit about it. If you can't do that, you can't ship the interim product to customers for some reason, at the very least, show it to them and get their feedback. be explicit and be greedy at every single step along the way about getting feedback. Now, that sounds great, but sometimes you realize you're in a hole. And this happens all the time. It happens with companies I work with all the time, you build a bunch of stuff, you refactor it something big. And suddenly you realize you've been out of market for six months, and it's gonna take another three to four months to finish it all off and sort of get it back into the hands of customers. This is a super tough spot. Because of the sunk cost fallacy. You're six months in, you see the end, you see light at the end of the tunnel, and nine times out of 10, you'd rather plow ahead, then reset. But it's also super dangerous, because you have no idea if that big rewrite is going to work. And this year, the deeper you dig, just the harder you make your problem. And so I think when you realize you're in this world, pause and try to figure out how to get back on a regular cadence, even if you're six months in pause and figure out okay, how can I ship something to customers this month or in the next few weeks. So I can validate that six months of work and sort of get back on the feedback cycle get back on the the cadence of feedback. Building in a corner without any feedback for nine months, I have found to be highly anti correlated with success. So what are some best practices here on the on the enterprise side, this is a little bit easier. You cast a net for a few development partners, folks who can work with you to deploy the product early and give you a steady stream of free, steady stream of feedback. They're often free or pay you nearly nothing. But trade is really that they're going to take alphabets and give you feedback instead of paying. The how dissatisfied would you be if this thing went away tests from superhuman, I think, is one really good metric for measuring if you're heading in the right direction here. One example of this is a company called Viva, which is a $50 billion company in the life sciences space. They initially develop their product in very, very close collaboration with just a single customer Pfizer.