The MVP is a question, not a product

An MVP is not the first version of a product. It is the most expensive question you can ask reality, cut until software can answer it. If you cannot name that question in one sentence, you do not have an MVP. You have a backlog wearing a launch date.

What question does an MVP answer?

Jargon treats the MVP as an object. A version. A set of screens. A “minimum” defined by whatever fits the sprint.

That reverses the order. Code is the last step. Clarity is the first. Most failed products were built correctly — for the wrong problem.

An MVP answers one question. Not three. Not “and also”. If launch has to prove the engine, the directory, the payment gateway, the native app and the analytics dashboard, you are not asking anything. You are building the product you imagined, with less CSS.

The question has to be expensive. Expensive means: if the answer is no, you change the product or you stop. If the answer cannot be no, it is not a question. It is a justification.

It also has to be observable. “Will people love it?” is not observable. “Will an independent professional in Chile publish a site and a calendar in five minutes and stop using WhatsApp as the agenda?” is. Someone does it, or they do not.

Scope is born from that question, not the other way around. You cut until it is obvious what is in and what is out. What stays out is not debt. It is a decision.

That cut is the work I call product engineering: name the problem, engineer the system that holds it, put it in someone’s hands. It is not a deck. It is not a prototype that dies in a folder.

What question was each product answering at launch?

I shipped three products in 2026. Each one had a question. None of them was “a platform”.

Agendamelo

Agendamelo was not asking whether Chile needs a booking SaaS. Software does not answer that. An opinion does.

The question was narrower: will an independent professional leave WhatsApp as the calendar if the public site exists after name, services and hours, and the client books without anyone replying?

WhatsApp is a transport, not a public object. There are no published hours. There are no prices a crawler can read. There is no URL a client can forward without screenshotting a chat.

If that is the question, five-minute onboarding is not copy. It is the experiment. Gallery, reviews, team and FAQs can wait. Commission per booking does not enter: the client books online and pays at the venue. The platform charges for the software, not for the trade.

Recurring sessions do enter on day one. They look like “another feature”. They are not. The product already promises weekly treatments. If the engine cannot model a series, the question is only half-asked. Reducing is not deleting everything. It is deleting what does not answer, and keeping what does.

The directory of 19 trades across 69 communes — about 1,400 URLs — was not the question of the first Ship. It was a consequence of having public tenants. The object exists first. Then it becomes findable.

PGAS

PGAS was not asking whether SEO still works. It was asking whether a visibility service can be bought as a catalog.

People ask ChatGPT, read Perplexity, and stop inside AI Overviews. The agency offer did not move: keywords, a monthly PDF, price behind “request a quote”. Liquid scope. A method that lives in a meeting. The agency site does not demonstrate the pages it claims it can build.

That is a product failure, not a copy failure. Liquid scope cannot carry a public number. A method that only exists on a call cannot be versioned.

The question at launch: will someone buy a first cut of SEO, AEO and GEO if the price, the 48-hour window and the deliverable are public — with no sales call?

That is why Diagnóstico Express exists at $79,000 CLP, in 48 hours, with a PDF, a 30-minute call, and the top five opportunities. It is not a coupon. It is the question made into a SKU.

I did not want another agency. I wanted a service with a catalog, a pipeline I can run, and a site that demonstrates that pipeline. The VERA method lives on the product. This domain says who built it.

WspWrapped

WspWrapped was not asking whether AI can understand your chats. It was asking something more uncomfortable.

Every chat hides questions memory cannot answer: who writes more, who starts, who replies at 3am, who goes silent, who deletes. The data is inside the export. The file is unreadable as a conversation metric.

The question at launch: if I never store a message, will people still upload a .txt or a .zip, get 30+ metrics, and walk away with a card for Stories?

Privacy is not a policy. It is the data model. The parser runs in memory. Only aggregates persist. If the question includes “and also a model reads the chat”, you no longer have that architecture. You have a different product: an archive of other people’s conversations.

Usage is episodic. One chat, once, to post a story. A subscription fights that shape. Credits do not: one credit, one full report. Three credits for $2.99. Ten for $4.99. They never expire. A free tier with basic metrics.

The 9:16 card also enters on day one. Without a frame that can be posted, the report dies in a screenshot folder. That is not growth. It is the question: does the result leave the screen?

How does “reduce until it becomes obvious” change scope?

Reducing is not cutting features at random. It is separating symptom, request, constraint, assumption and noise until the problem remains.

Agendamelo’s symptom was “I answer WhatsApp all day”. The request was “a booking app”. The constraint was perceived five minutes, Chilean pesos, and the commune as the geographic unit. The assumption was that a professional would publish if starting was cheap. The noise was a payment gateway, a native app, a marketplace, a commission.

When you cut until it becomes obvious, scope stops being a list. It becomes a minimum schema. Name, services with prices, weekly hours. With those three, the public render already has an H1, a price list and a calendar. If any is missing, the page does not publish. Everything else is additive.

On PGAS, reducing froze deliverables. Fifteen on-page URLs. Four pieces of content a month. A diagnostic in 48 hours. A public price is a promise. You cannot publish one if scope is renegotiated on every call. Custom work sits at the foot of the catalog as the exception, not the default.

On WspWrapped, the obvious thing was the file the user already owns. Not “add AI to chats”. Export, drop the file, see numbers, share a card. If the report cannot leave the dashboard as a frame, the product does not finish.

Reducing also changes the stack. PGAS has no CMS and no database behind the site: the catalog fits in the repo. WspWrapped has no messages table. Agendamelo does have Postgres tenancy, because the question requires isolated agendas. Tools follow the question. Not the other way around.

The minimum left behind does not look small. It looks inevitable. If you still have to explain why each piece exists, you have not reduced enough.

What did I decide not to build?

Deciding what not to build is half the work. The other half is being able to say why. On all three products, the most visible “no” protects the question.

Agendamelo takes no commission per booking. A commission would have forced a payment gateway and a remote deposit. The product would have answered “how do I get paid?” instead of “does the client book alone?”. Book online, pay at the venue. The subscription charges for the software. The venue charges for the trade. Commission: 0%.

It also does not sell domains on day one, and it does not automate WhatsApp. The slug is the site. Email carries reliability; WhatsApp is sent from the panel, one click.

PGAS does not hide price behind “request a quote”. The H1 on /precios names SEO, AEO and GEO in Chilean pesos. Monthly plans do not ask for a lock-in. Custom work is overflow. If the default is a quote, nobody can buy without a meeting. The catalog question never gets answered.

There is also no CMS on that site, and no SEO blog on this domain. pgas.online talks about the method. jorgeco.tech talks about who built it.

WspWrapped is not a subscription. A Friday-night curiosity product trains people to cancel, not to analyze. Credits that never expire lower regret. The trade-off is no monthly revenue smoothness. I accepted that.

I also do not store message text. If I persist the chat, I become a store of intimate data. A product I refuse to operate. If I invent a new metric next month, the user re-uploads the file. That is cheaper than a message lake. Whatever the landing calls “AI” has to run on those numbers, not on the transcript. Sending the chat to a model voids the privacy question.

Each “no” protects a question. An MVP that says yes to everything is not asking. It is postponing the cut.

How does Think / Build / Ship turn the MVP into a loop?

Think / Build / Ship is not a three-column slogan. It is the order in which a question becomes a system and the system becomes a question again. Think names the problem and decides what not to build. Build engineers the system. Ship puts it in someone’s hands, learns, and returns to Think. It is not translated. It is the method.

The MVP is not the end of Ship. It is the first step of the loop. Reality’s answer feeds the next Think.

Agendamelo shows it. The 7-day trial with no card answers “does anyone publish?”. After that comes Perfil Gratis: the URL stays; the booking engine turns off. Indexing a tenant that can no longer take a booking is a decision that only appears once the first Ship hits reality. The reason to pay is booking, not the existence of the site. That was not in the first cut. It came out of the loop.

PGAS shows it another way. The diagnostic is credited in full if you hire implementation within 30 days. That lowers the cost of entering without diluting the SKU. Mention tracking in models is still, in part, a manual loop. The method says so. I did not sell a dashboard that does not exist. That debt is the next Think.

WspWrapped shows it in the parse. A line that works in English on Android is a different line on iPhone, in Spanish, with a Unicode mark before the bracket. The fix for a bad parse is a better parse, not a model. Each format that survives is a Ship that feeds the next cut.

Without the loop, the MVP becomes version 1.0 forever. With the loop, the minimum stops being an object. It becomes a question again: more expensive, narrower, more honest.

That is what I sell when someone arrives with a brief and a date. Not a specialist per layer. The whole path. The same path the three products walked, and the one I describe under product engineering.

How I apply this

1. 01/
   I name the question in one sentence. If it does not fit, it is not a question. I keep cutting until a stranger can repeat it.
2. 02/
   I write down what would count as a no. If the no does not exist, I am justifying a backlog. The expensive question is the one you can lose.
3. 03/
   I list what I will not build, with the why. Commission, subscription, hidden quote: each no protects the question. Without a why, the no does not survive the first meeting.
4. 04/
   I drop the publish threshold to the minimum schema. Additive waits. The experiment does not. Name, services and hours publish Agendamelo. A 48-hour SKU publishes PGAS. An export and a report publish WspWrapped.
5. 05/
   I pick the charge that does not fight the use. Software subscription, not commission. Credits, not a monthly plan. A public catalog, not a mandatory call. Price is part of the design.
6. 06/
   I put it on a URL. I watch what people do. The next Think starts there, not from the original deck. If reality cannot answer, I have not shipped. I have shipped a prototype with a domain.

The same path fits a consumer product, a multi-tenant SaaS, and a service packaged as a catalog. The category changes. The cut does not.

The MVP is a question, not a product. The product is what you build in order to ask it. If the answer arrives, you cut again. If the answer is no, you stop. Everything else is backlog.