A paid feature request deserves evidence before it earns the roadmap. The real decision is whether the customer has exposed a stronger market or offered enough money to turn your product into their private tool.
In 2012, Stewart Butterfield faced a more severe version of that choice. His company, Tiny Speck, had built Glitch, an online game. The game was closing, but the communication system the team had built for itself was still useful. Keeping that internal tool meant accepting that the company they intended to build was over.
When the side product becomes the main product
Butterfield had already lived through one unexpected product shift. Years earlier, a feature from another game project became Flickr. With Glitch, the pattern returned under worse conditions: the original product had launched, attracted players and still failed to become a viable business.
Tiny Speck shut Glitch down in December 2012. The team then developed its internal communication tool into Slack. Wired documented the shift in its 2014 profile of Butterfield, including the uncomfortable period between closing the game and proving that the new product had a market.
That story has a clean ending because we know Slack succeeded. The decision did not arrive with that certainty. Tiny Speck had to stop treating its internal tool as supporting software and ask whether it deserved the company’s remaining attention.
A founder reading a first paid feature request faces the same shape of decision at a smaller scale. The customer is offering evidence, money and distraction in one email. Each part needs to be judged separately.
Separate payment from market evidence
A request becomes dangerous when the price answers every question.
Suppose a SaaS founder in Accra has spent six months building an AI workflow for small logistics teams. On Tuesday, a company in Berlin offers to pay for custom approval rules, an audit export and access controls. The contract could cover several months of engineering.
The money matters. Limited runway makes it impossible to pretend otherwise. But payment from one buyer proves that one buyer will pay. It does not show that the requested feature belongs in the product, that similar customers need it or that the team can support it without delaying the original roadmap.
I would write down three different propositions before answering:
- This contract extends our runway.
- This request reveals demand from a repeatable customer segment.
- Building it moves the product toward a company we want to operate.
Those statements can have different answers. A founder can accept the contract because survival comes first while admitting that the work provides little reusable product evidence. That honesty changes how the feature gets designed, priced and contained.
The reverse also happens. A small request may expose a problem several customers already share. The payment might be modest, but the product signal is strong. The missing page an AI demo avoided can reveal more about demand than the polished feature everyone expected to sell.
Decide how much of the company the customer is buying
The useful question is not simply, “Should we build this?” It is, “What else becomes harder if we build this?”
A feature consumes more than its first development cycle. It creates support questions, permissions, edge cases, documentation and expectations about what comes next. A custom approval flow may lead to reporting requirements. The export may need fields designed around one customer’s process. Access controls can change the assumptions beneath the rest of the product.
Before saying yes, I would mark the request against four boundaries:
- Can another customer use the same capability without custom work?
- Can we remove the customer-specific language and still describe a clear product benefit?
- Can we maintain it after the contract ends?
- Which committed roadmap item moves if this enters the next release?
The fourth answer matters most. Teams often approve a paid request without naming the displaced work. The roadmap then appears to contain both paths, while the engineer quietly decides which one receives attention.
That is how a company changes direction without making a direction change.
Put the split into writing before Tuesday ends
Tiny Speck eventually made the split explicit. Glitch closed. Slack became the product. Butterfield’s team could then test one proposition instead of funding a game while informally maintaining a second company inside it.
Most founders do not need such a final break after one request. They do need a written decision that prevents temporary revenue from becoming an accidental strategy.
Record the customer, the amount at stake, the reusable problem, the customer-specific work and the roadmap item that will move. Then choose one of three labels: product feature, paid custom work or market test. Each label creates a different obligation.
A product feature must serve a defined segment. Paid custom work needs a price that covers delivery and maintenance. A market test needs a stopping point and a question it will answer.
Send the reply only after the request has one label. If the team cannot agree on the label, the roadmap has already split. The next meeting should decide which company receives the next release.
Comments
No comments yet.