Ideation Stage

For a long time the only word for the beginning of a company was "early." The trouble is that one word covered two different situations. In one, a team has built something and is trying to fit it to a market. In the other, nobody has decided what to build. The work in those two situations is close to opposite, and sharing a name kept conversations sliding past each other.

The mismatch usually shows up like this. An investor asks what stage the company is at and the founder says early. The investor pictures something already built and asks about user numbers, and when the founder explains they're still choosing a problem, both sides realize the last ten minutes were spent on different companies.

Inside the team the cost was higher. A stretch of work with no name is easy to skip. Building is visible and checking is not, so a team with an engineer in it starts drawing screens in week one. Six months later a product exists that nobody uses, and the belated conversation with prospective customers turns up the reason: nobody had that problem badly enough to act on it.

Naming the ideation stage gives that stretch a place to sit. Not shipping anything stops reading as slowness and starts reading as the definition of where the company is — and in exchange, the stage comes with homework of its own and a condition for leaving it.

There is no product and there are no customers, and the team runs from one person to about five. Often the company isn't even incorporated yet. What assets exist are documents and conversation notes rather than code.

The work here is checking rather than making. The central activity is the customer interview, a direct conversation with a candidate customer about how they handle the work today. Twenty conversations is a common target, though what gets asked matters more than how many. "Would you use something like this?" is a question almost everyone says yes to, so it separates nothing. "How do you do it now?" and "what did that cost you last month?" separate people.

What comes out of those conversations collects into a problem statement — one paragraph pinning down whose problem is being solved and what that problem is. Everything built later branches off that paragraph.

Some building does happen. It's just building to ask with, not building to sell. A few screens go up as a prototype to watch people react to, or the team delivers the service by hand with no automation behind it to see whether anyone wants the result.

The money is usually a founder's savings or a first pre-seed check. The amounts are small, so the runway — how many months of cash the current burn leaves — is short too. Past about six months in this stage, time tends to run out before money does.

You move on once someone who would pay actually exists and you can name who that is in one sentence. That single line breaks into four checks.

1. The problem is already costing money. Someone has been assigned to it, another tool is being paid for, or a few hours a week are going into it. If seventeen of twenty companies call the problem annoying while spending neither money nor headcount on it, it isn't yet a problem anyone buys a solution for.
2. You can point at the buyer. "Any team that collaborates" is not an answer. "The operations lead at a software company between 30 and 200 employees" is narrow enough to go meet.
3. The problem statement is written as one paragraph and the team repeats the same one. If two founders describe it separately and two different problems come out, the choosing isn't finished.
4. The first scope is narrow. What goes into the minimum viable product (MVP) — the smallest build that can test the hypothesis — has to be decided before the next stage's work can start.

When the checks don't clear, there are two routes: keep the problem and go looking for a different buyer, or change the problem itself, which is a pivot. Either route runs on the interview record, so a team that took sloppy notes ends up choosing its new direction on instinct too.

"We're still in the ideation stage, so engineering hires moved to next quarter."

Nothing is decided yet, so adding people who build comes later.

"Eight months in the ideation stage usually means the problem needs another look."

A long search is normally a signal about the problem, not about effort.

"That was settled back in the ideation stage."

There's already evidence behind it, so it isn't open for another round of debate.

Before Pagedeck was Pagedeck, Grace and Theo spent four months here. Their first candidate was a tool that cleaned up meeting notes automatically. They talked to fourteen companies, and while everyone agreed meeting notes were tedious, not one had assigned a person or a budget to the problem.

Something else kept coming up in the same interviews. Documents were scattered across teams, and nobody could find what had been decided the previous year. Six of the fourteen were running an internal wiki because of it, with someone maintaining it. That problem was already drawing money. Grace rewrote the problem statement around it and narrowed the first build to a single document type.

The name invites people to read this as the stage for generating ideas. Since "ideation" is in the label, it looks like the place to spread candidates wide. The actual work runs the other direction: it narrows. A team starts with five candidates, interviews its way through them, discards four, and keeps one. Stack up candidates without discarding any and the team stays busy for eight months and still can't name one customer to go see.

The other common reading is that nothing may be built here at all. Turning "check first" into "write no code" shuts down the conversation you're trying to have. A feature described out loud and the same feature shown as three screens get answers of very different sharpness. What gets built in this stage is an instrument for asking better questions, which is why it's made fast and with the expectation of throwing it away.