Let’s start from a baseline: if you’re here reading this piece, it’s because you think it’s possible to learn product design in 7 days, or, at best, you think the title is a provocation and the design community would be happy to call me out for it. Both scenarios are bad for different reasons, but I think it’s more interesting to explore why the first one is unrealistic.
A sea of opportunities
At this moment in time, when technically everything seems possible, when the gap between a business’s ambition and the delivery of its product keeps shrinking, believing that you can have something up and running in a couple of days to answer the market doesn’t sound so crazy. But I think it’s worth distinguishing between two things: are you looking to learn product design in a week, or to pick up a batch of terms and concepts that let you tell an LLM, brimming with confidence and drive: BUILD ME A PRODUCT, MAKE NO MISTAKES, with some linguistic flourishes thrown in to dress up the order? Once you make that distinction, the first is impossible, and the second isn’t enough.
The problem is that, if technically everything is possible, the one thing the tool won’t give you is a reason to say no, whether for business-model reasons or because of how its use was conceived. And designing is, before anything else, saying no. Des Traynor wrote as much more than a decade ago, back when agents doing knowledge work were far from our everyday reality. Today we could count it among the fundamentals of design.
So, then, what?
Limits. Give me limits. Look for limits. A product isn’t what it can do (infinite): it’s what it decided not to do (solid). What sets it apart from a demo isn’t the number of features but the number of things given up, and each of those trade-offs has a reason that lives outside of the code and outside of Figma, whether because of financial struggling, or, in some cases, intuition and hypotheses built on experience.
What’s curious, what we can see after years now of interacting with LLMs, is that the reasons don’t come from the model. The model says yes to everything, and an unlimited yes produces an average; something that works more or less the same for everyone, because it wasn’t built for anyone in particular. But in practice, the limits, the edges, come from who’s going to use this thing, at what time of day, with how much patience, what they’ve already tried and given up on, what they won’t tolerate even once. None of that is in the prompt. It’s in the people.
And here’s something you actually can do in 7 days. Not learn to design, but draw boundaries before you start building: what context this happens in, who’s involved, what solution hypothesis you have, what outcome you’re going to measure it against. Four lines. That’s not design yet. It’s what makes design possible afterward, instead of a menu of pretty options from which you’ll pick one without knowing why. Or worse, because it was the criteria your everyday agentic battle-buddy handed you on the screen, and you only accepted it out of weariness, out of fatigue, or—worse still—out of blind trust.
And why is that?
Behind the idea that it’s possible to put together a product in just one week lies a belief older than LLMs, one that accompanies every disruptive technological leap humanity makes: that the tool decides the outcome. That using the device correctly is enough to get you to the result. It’s a comfortable idea, and the temptation is understandable: it takes off your plate the most annoying part of the job, the encounter with other people’s opinions, experiences, and problems.
But a product doesn’t come out of the tool. It comes out of the meeting point between a need and someone willing to listen to it. The tool shows up later, over time, after iterations, after decisions (and maybe mistakes). First the need, second the listening, third the prototype.
And I have bad news for you if you were counting on turning a million-dollar business around in a week: the only one of those three steps that (thanks to this wonderful technology) can be compressed into a week today is the third. The other two have no shortcut, because there’s something hard to accept sometimes: they don’t depend on you. They depend on other people, and other people have their own timelines, their own contradictions, their own budgets, and their own ways of not telling you what they need until they’ve seen you use what you built with a lot of tokens, sweat, and tears.
Plant your flag against technological determinism, raise the voice of users. Welcome the frustrations, the search for people to talk to, and the long-term building.
By Tomás Milgrón