Disclosure: This article was generated with AI and reviewed against the source transcript.
A founder writes “simpler than the market leader” at the top of a product brief. Underneath, the feature list starts growing. By the end of the page, the supposedly simpler alternative requires most of the incumbent’s functionality before anyone can try it.
The brief needs a more precise question: which customer, doing which job, would prefer the proposed alternative enough to change an existing habit?
In a Starter Story interview, Charlie Clark describes building a link-in-bio product after working with artists and noticing how they presented themselves online. He recounts making pages for early users, collecting feedback, and developing the business over several years. The interview reports revenue figures; this article does not independently verify those figures or treat them as a forecast.
The useful product lesson is narrower: a crowded category still permits a specific investigation into an underserved preference.
Describe the moment of dissatisfaction
Consider a hypothetical portfolio tool for freelance illustrators. “A better website builder” gives the founder too much room to interpret every request as a missing feature.
A more useful starting observation would be that an illustrator has a finished project ready to share but struggles to present several images and a commission contact option in one coherent mobile page. The founder should establish that this situation occurs through actual conversations and observation.
The customer’s current method belongs in the record. They might already use a general website builder, an image gallery, or a document link. Each alternative has advantages the new product would need to respect.
Write the switching reason as a proposed improvement in that moment. Keep it provisional until a customer uses the product and explains what changed. Enthusiasm about a concept is different evidence from choosing it during real work.
Help someone complete the job
Clark’s account includes preparing pages for people early in the product’s development. That is interesting because an actual page exposes decisions that a feature conversation can leave abstract.
In the illustrator example, the founder could work with an invited participant to prepare one project page using material the participant is authorized to share. The purpose would be to observe the work: choosing images, arranging them, checking the mobile layout, and deciding where inquiries should go.
Record where the participant needs assistance. Also record what the founder supplied manually. If the founder selects the strongest images, writes the description, and repairs the layout, the trial has tested a substantial service alongside the software.
That is still useful evidence. It becomes misleading only when the manual contribution disappears from the account of what the product accomplished.
Turn repeated friction into a bounded requirement
A request for more customization can hide several different needs. One participant might want a recognizable visual style; another might need to group commissioned work separately from personal projects.
Ask for the concrete task behind the request. Then decide whether it belongs inside the product’s chosen job. A requirement might be that a participant can arrange a small project gallery and find the inquiry link in a mobile preview without the founder’s assistance.
This is an illustrative acceptance condition, not a measured result. It is useful because someone can inspect whether the proposed improvement exists.
Keep a separate list of adjacent requests. Declining to build one immediately should preserve the observation that produced it. Otherwise, the team will repeatedly reopen the same discussion without remembering the original context.
Recheck the reason after the first use
The first completed page answers only part of the switching question. Return to see whether the participant shares it, edits it later, and continues to use it when another project is ready.
Those observations may reveal that the attractive first result depended on the founder’s help, or that the customer valued a different part of the workflow. Either finding should change the next product decision.
The interview’s business trajectory belongs to one founder’s account, with circumstances that do not transfer automatically. What can transfer is the discipline of making the proposed advantage visible in a real task.
Before adding another feature, finish the sentence in the brief: this customer would switch when this recurring job becomes easier in this specific way. Then identify the observation that could prove the sentence wrong.