Product Form Factor

Back when software shipped on discs, nobody needed this term. A product was one program you installed on a PC, and there was no second shape it could take. "Our product" meant the same object to everyone in the room, so there was nothing to name.

Once software moved onto the internet and smartphones followed, one set of features started splitting across several shells. A single capability — editing a document with other people — now existed as a screen you open in a browser, an app you install on a phone, and a channel another company's system calls. From that point on, "what should we build" and "what should we put it in" became two different questions.

Without that distinction, meetings go in circles. Theo says "that doesn't work in the app," Mia hears it as "that feature is hard," and the requirement gets trimmed for no reason. What Theo meant wasn't the feature at all — it was a constraint of the shell. An app installed on a phone has to pass app store review every time it changes, so one urgent fix takes three days. The same fix on a browser screen is live in thirty minutes. The two numbers describe the same one-line change; what differs is the shell it has to travel through to reach anyone. With no name for that gap, the same conversation restarts from zero every time.

Choosing a form factor is heavy because the choice reaches past the product itself. The shell decides the path users arrive through, the cycle on which fixes go out, the cut somebody else takes from each payment, and which specialty you have to hire for. Changing shells after building has started costs nothing like changing a feature. That's why this branch sits on the structural side of product work rather than beside this quarter's feature list: it isn't a decision about what to build next, it's a decision about the frame the product stands on.

Eight terms sit under this one, and they form a single branch: the form itself. What separates them is where the user meets the product. The first four have a screen a person looks at, the next two run without a screen inside somebody else's software, and the last two put other people's products or other people's transactions on top of themselves.

1. Web app — open a URL in a browser and you're using it. No installation means a single link can bring someone in, and pushing new code means every user is on the new version that moment. Those two properties are why work tools cluster here. The weaknesses are that it stops when the connection does, and that it's awkward on a phone screen.
2. Mobile app — installed on a phone. It can use what's attached to the device, like the camera, location, and push notifications, and the icon left on the home screen makes reopening far more likely. In exchange it lives by app store rules: every version goes through review, the store takes a share of payments made inside it, and users who put off updates keep running a build from six months ago.
3. Desktop app — installed on a computer. It gets the full power of the machine and can work directly with files on disk, which is why heavy work like video editing and writing code still lives here. The cost is the heaviest of the four: build and ship separately for each operating system.
4. Browser extension — a program that attaches to the browser and runs on top of other people's websites. What makes it unusual is that it enters a screen the user is already working in, typically as one button parked next to another company's interface. The barrier to entry is low, but the browser vendor can change its rules and break the whole thing overnight.
5. API product — called by other programs, with no screen of its own. There's a channel that returns a result when a request arrives, and what the user actually looks at is somebody else's interface displaying that result. Because the customer is a developer, it sells differently: documentation quality matters more than advertising, and once it's wired into someone's code it rarely gets removed. The flip side is that one outage spreads to every service stacked on top of it.
6. Software development kit (SDK) — a bundle of developer tools meant to be embedded inside someone else's product. Think of payments, maps, or error collection packaged so a team can attach them in a few lines instead of building them. Where an API is a channel called from outside, this ships and runs inside the other app. So even after you release a new version, the old one keeps running until each customer wires the update in.
7. Platform — a base product other services run on top of. It opens slots where outside teams can attach their own capability, and the product gets more valuable as the number of attached things grows. The goal of this form is the moment outsiders add capability faster than the company can build it. The catch is that other people's code runs on your product, so review and permission management come with it, and slots nobody fills leave you with maintenance costs and nothing else.
8. Marketplace — connects a selling side to a buying side and takes a fee on the transaction. What separates it decisively from the other seven is that gathering one side alone does nothing. No sellers means no buyers show up; no buyers means the sellers leave. That's why the early phase usually means subsidizing one side to fill it, whether that's waiving fees for the first sellers or filling the supply side by hand until buyers find enough there to come back.

Picking one of the eight is much rarer than running several at once. The same product lives in a browser, lives on a phone, and keeps a channel open for other companies to call. What actually has to be decided is the order: what goes out first, what follows, and whether the later one can be maintained at the same standard as the first. Each additional form multiplies the places to fix, the places to test, and the places an outage can start. A team of five developers running a web app and a mobile app together usually ends up with one of them untouched for two months. Shipping the same feature into two shells costs more than double, not double, because on top of building it twice you pay for keeping both behaviors aligned and for finding the mismatch when they drift.

What goes first isn't a matter of taste — it's set by where users do the work. Writing documents and working with tables happens at a desk, so the browser leads. Checking and replying while moving around puts the phone in front. If the user is another system rather than a person, no screen is needed at all. When the call is genuinely unclear, counting where current users connect from settles it faster than arguing. If nine of every ten sessions arrive from a desktop browser and the team still decides to build the phone app first, that decision followed what somebody wanted to build rather than where the users are.

It helps to keep this branch separate from two neighbors. Software as a service (SaaS) names a way of selling and delivering — no installation, a subscription fee — and business type splits selling to individuals from selling to companies. All three name the same product from different angles, so they stack rather than compete. "A web app sold to companies on a subscription" contains all three at once: the first word is the form factor, the last three are the delivery and pricing model, and the middle names who the buyer is. Mixing them up usually surfaces as an argument where two people defend positions that were never in conflict.

"Let's ship this on web first and add the app next quarter."

Matching both shells at once would delay the release, so go out through the one that updates fastest.

"If we move this to the app, review means an urgent fix can't go out same day."

The objection is about the delivery path, not the difficulty of the feature.

"The customer says they don't need a screen, they just want the data."

A request to open a channel other systems can call instead of an interface for people.

Pagedeck started as a document tool you open in a browser. For the first two years there was exactly one form factor, which is why something fixed in the morning could ship by lunch. As enterprise customers grew, two requests arrived at once. Sofia brought back a request to at least review and approve documents while away from a desk, and Theo got a request to generate documents automatically from a customer's internal HR system.

Mia refused to treat those as the same request. The first needed a shell installed on a phone but only needed two capabilities, reading and approving. The second needed no screen at all, but leaned entirely on reliability and documentation. The decision was to open the second one first. Two developers could open the channel in six weeks, while the app would take four months with the same people and then require maintenance every month after that. The rule Grace stated in the meeting was one line: a decision to add a form factor gets judged on whether it can be maintained for the next three years, not on what it costs to build.

The most common belief is that more form factors are better. Having a web app and a phone app and a desktop app makes the product look substantial, which is a natural enough thought. But one form factor behaves less like a one-time build cost and more like a monthly fixed cost. Every new feature gets built once per shell, tested once per shell, and checked once per shell when something breaks. A team running three of them spends close to three times as long shipping the same thing, and that multiplier applies to the small work too, not only the features worth announcing. Left alone, the shell with the fewest users gets neglected first, and the people on that shell experience it as the product being broken and leave. Adding a form factor is closer to taking on another product than to adding another feature.

Calling your own product a platform is the other frequent slip. It sounds larger and it fits neatly into an investor conversation, so the word is tempting. But what defines this form is not size — it's whether outsiders build on top of it. A product with an enormous feature list, all of it built internally, is a product with many features; the name only holds when work attached by outside developers is actually running. Blurring that costs real time. Claiming the name early pushes the actual work — opening the slots, writing the documentation, defining review rules — to the back of the queue, and the companies that were ready to build on you go somewhere else in the meantime.