Innovator

When everyone who showed up in the first weeks was treated as one group, there was no way to read what their arrival meant. Three hundred signups in week one, forty of them back every day filing bug reports — teams read that as the market wanting the product. Nothing had ever attracted anyone before, so that reading felt reasonable.

The meetings kept ending the same way. One post in a developer community brought a rush of signups, the team planned hires and added servers the next week, and two months later daily signups were down to two or three. Nothing had gone wrong, the number had simply stopped, and there was nowhere to look for a cause. Nobody could see that those first three hundred people and the people who were supposed to come after them were moving for entirely different reasons.

Innovator is the name given to those first three hundred. It marks the front slot in a split that cuts a market into five groups by when they accept something new. Once the group had a name, the numbers could be read apart: a rush at the front of the line and a market moving are two different events, and the first one guarantees nothing about the second.

This group responds to newness itself rather than to any benefit the product delivers. They arrive almost regardless of how finished it is, and when the novelty runs out there is nothing left holding them.

Four things keep their numbers from being misread.

1. They are roughly 2 to 3 percent of a market. The share is small enough that collecting all of them still doesn't add up to a business.
2. They have almost nothing at stake. They don't move real work onto the product — it goes in a personal account or a side project. Nothing breaks for them when the product breaks, and watching it break is part of the appeal.
3. What they return is whether the thing functions. Environments where installation fails, buttons that behave differently from the docs, errors that only appear in one browser. If this group leaves without saying anything, the product doesn't even switch on yet.
4. They rarely pay. What they want is the experience of handling something new, not a solved problem, so paid conversion moves almost independently of how many of them there are.

The gap is obvious in numbers. If 250 of 300 signups come from this group, conversion stalls somewhere between zero and two. If the same 300 people arrived with their own work riding on it, conversion runs ten times higher. Both months show 300 signups.

The word earns its keep in two places: reading early numbers, and picking who gets into a trial.

First invitations to a closed beta usually go to this group. An invite-only trial needs people who will stay after seeing a broken screen, and this group tolerates the breakage in exchange for getting to report it fast. A minimum viable product (MVP), built to test a single assumption and nothing more, gets its first run here too.

In metrics reviews the term shows up as a defense. Two months after launch with zero paid conversions, a product looks dead — but if everyone who came in belongs to this group, that zero hasn't judged anything yet. It works in the other direction as well. If signups keep growing and keep coming only from this group, that isn't good news; it means the product hasn't reached past them.

In roadmap discussions the term adjusts how much a request weighs. This group is loud and specific, which makes their suggestions tempting to build straight through. What they ask for is usually finer-grained settings and more keyboard shortcuts. The early majority waiting behind them wants the opposite — few choices and defaults that are already correct. Word of mouth travels well in this group for the same reason, and it stops at the edge of it: the fun of telling people about something new doesn't carry into the next group.

"Most of this week's signups are innovators. It's too early to judge on conversion."

Look at who came in and that zero isn't a verdict yet.

"That came from an innovator, so I left it off the roadmap for now."

The request was heard, but it points away from what the next group wants.

"We have enough innovators. Time to go find people who will pay."

There's nothing left to learn from this group, so move the target.

At Pagedeck, the month the automatic document cleanup feature went into trial, this word came up in meeting after meeting. Ravi posted in a developer community and pulled 400 signups in two days, and Theo used their error reports to fix twelve browser-specific problems. That part went to plan.

The next review was where it got interesting. Grace saw the 400 and wanted to hire sales first. Mia pulled up the composition of those signups: three of them had asked about a paid plan. This group tells you the product switches on, not that anyone will pay for it — that was the sentence that settled it, and hiring moved out a quarter. The following month's goal changed from signup count to the number of teams that said they would put real work on it.

The most common mistake is reading a rush of this group as proof the product succeeded. It's the first time anyone has shown up, the reaction is enthusiastic, and both of those make the reading feel earned. But they came because the product was unfamiliar, not because it solved anything. Treat that as a market signal, hire against it, scale servers against it, and two months later the signups flatten while the costs don't.

The second mistake is assuming that building what this group asks for brings the next group along. The requests are specific and technically sound, which makes them easy to write straight into a backlog. The trouble is that this group wants more surfaces to adjust and the next group wants nothing to adjust. Follow those requests for six months and you arrive in front of the early majority with three times the settings screen, where the product gets cut from consideration for being complicated.