As a founder, I get the smallest product in front of users and let usage and payment settle what comes next
I have founded products and hired a team of engineers to grow one, and running them meant decisions engineering does not answer: who the product answers to, the smallest version people can try, whether they use it and pay for it, and what a no should trigger.
Founding meant settling who a product answers to, and who builds it, before what it does
A self-funded product of mine answered to the publishers who ran it on their sites and to its own running costs, because no investor stood behind it. An unfunded network I founded answered to the volunteers who contributed to it and to the outside auditors who checked its security. On another product I hired a team of engineers and support staff to grow it past a one-person build, and set the engineering standards, documentation and processes they worked to. Who is responsible to whom sets who may change the scope and who signs off before real money moves, so it is settled first.
How a product earns its next stage
- Name who it answers toWho is responsible to whom, before the scope
- Build the smallest pilotOnly what the first question needs
- Put it in front of usersAs soon as it can be used
- Are people using it?No: pivot and go again
- Can it make money?No: pivot and go again
- Grow, pivot or sunsetGrow on two yeses; sunset when pivots keep returning the same no
The first version only has to show whether people use it, and then whether they will pay for it
The pilot is the smallest thing people can use, put in front of them as soon as it works, with one question at a time. Are people using it, yes or no. Then, can it make money, yes or no. When a better-known rival took off in one market, I already had the core technology, so I competed on a lower fee rather than on raw efficiency, and opened the product to site owners as a new kind of customer. The marketing claims only what the product has shown: copy is checked against a list of confirmed facts and the release evidence, with no invented customers, waitlists or deadlines. Where real money moves, the stages shrink further: the first run is done by hand, under a spending limit a person sets.
A no sends the product back to pivot, and the same no after repeated pivots means it is sunset
A no is a reason to change direction, not to add features. Most of one product's traffic came from phones, which became the premise of the next product I founded; when the community that idea depended on would not adopt it, I built it on its own rather than keep pressing. Speed comes from cutting each version to what its question needs: when users reported that one product felt slow, the fix was a targeted pass, and larger rewrites with no measurement behind them were turned down. When pivot after pivot returns the same no to the same question, the product is sunset, as a decision made and stated, rather than left to fade.
You get a pilot in front of users soon, with its yes-or-no questions written down before it ships
The expensive mistake for a founder is building past a question the product has not answered yet. I help you name who the product answers to, cut the first version to what its first question needs, and write down what a no will trigger before anyone sees it.
The work starts with a workflow review. My software factory does the volume and I review it, with no constant meetings to take you away from the company. Bring the product you are deciding about to the workflow review.