Skip to content

Solo Founder Product Engineering Handbook / Chapter 6

Where Solo Founder Ideas Come From

Learn to notice product ideas in observable pain, repeated work, workarounds, and reachable customer moments before inventing features.

Ideas Begin as Evidence

Technical founders often begin too late. They write down “AI for accountants,” “workflow automation for clinics,” “marketplace for local services,” or “better CRM for agencies.” The words sound like ideas because they suggest software. They hide nearly everything a founder needs to know: the person, the painful moment, the current workaround, the consequence, the path to a buyer, and the first test.

A useful idea begins earlier and looks less impressive:

Every Friday, an account manager at a five-person recruiting agency spends two hours chasing candidate statuses, turning rough recruiter notes into client-safe language, and assembling an update from a shared spreadsheet and old email threads.

That sentence is not a product. It is more useful than a product name because somebody could go and check it. There is a role, a cadence, a workflow, a workaround, and a visible cost. There are also important blanks: whether this happens at other agencies, whether owners care enough to change it, and whether the work can be improved without creating a bespoke writing service.

The solo founder’s advantage is proximity. One person can notice a narrow moment, speak to the people inside it, serve it manually, and build only after the pattern survives contact with reality. The corresponding danger is expensive imagination. A founder can turn one annoyance into months of architecture before learning whether anyone else has the problem.

Idea generation is the practice of noticing before naming.

An idea inventory diagram shows a founder collecting pain from personal pain, workflow friction, manual work, spreadsheets, email queues, community complaints, and platform change, then checking customer, pain, workaround, frequency, reach, and first test before building.
Useful ideas become visible when the founder records pain sources and checks whether each one names a customer, workaround, frequency, reach path, and first test.

Follow the Work

The best places to look have one quality in common: people are already doing something. They are moving data, chasing approvals, reconciling records, producing reports, cleaning up exceptions, paying an expert, or recovering after the same failure. Behavior leaves tracks.

Personal pain can provide unusually fine detail. You know the awkward step, the misleading field, the Sunday-night task that should have ended on Friday. That access is valuable, but your annoyance is a sample of one. Look for other people doing the same work, with consequences that give them a reason to change.

Handoffs are especially revealing. A sales team waits for legal; a clinic waits for forms; a bookkeeper waits for receipts; a contractor waits for site photos. The delay matters, but so do the reminders, ambiguous ownership, rework, and exceptions around it. Follow who chases, who decides, and who absorbs the cost. A repeated manual process becomes interesting when its inputs and outcome are similar enough to learn from. One act of copying is an errand. Copying, checking, formatting, routing, and reconciling the same kind of information every week may contain a product.

The current tools often disclose the shape of the work. A spreadsheet may contain its first data model: columns show what a team tracks, hidden tabs show what it fears, and comments show where coordination breaks. Long email threads and repeated “any update?” messages reveal missing state. Slack, WhatsApp, and Discord channels become improvised queues, knowledge bases, and approval logs. None of these artifacts proves demand. They show where to ask better questions.

Services and professional niches expose another layer. Recruiters, accountants, brokers, consultants, auditors, agencies, and implementation partners already know which judgments repeat, which exceptions consume senior attention, and which outcomes customers will pay to obtain. Compliance paperwork can be tedious and expensive while also carrying trust, privacy, and legal boundaries that make casual automation irresponsible. An underserved niche is attractive only if the founder can understand and safely serve the work, not merely because the existing software is old.

Internal tools and APIs hide product opportunities in different ways. A dashboard rebuilt inside many companies may point to a shared workflow. An API repeatedly glued into business processes may be less valuable than the permissions, monitoring, import path, exception handling, and opinionated sequence around it. An agency’s repeated delivery process may become software, but first the founder has to separate reusable work from expertise that clients are actually buying.

Communities are useful when complaints point back to behavior. Ten people mocking a clumsy tool may be entertainment; several people exchanging templates, paying assistants, or repeating the same workaround are doing something worth observing. New AI capabilities, platform changes, pricing shifts, integration removals, and regulatory changes can create urgent work, but the change itself is not the market. The opportunity appears only when a reachable group must alter its behavior and a founder can help without taking on obligations they cannot carry.

The source is never the proof. It is the place to observe.

Write the Pain Before the Product

Suppose the recruiting-agency observation first arrived as this note:

AI for recruiting agencies.

It supplies a technology and a market, but no moment to investigate. Rewriting it as the Friday update reveals what is known and what is merely inferred. The account manager appears to own the labor. Recruiters supply uneven inputs. An agency owner may care because a late or careless update weakens client trust. The spreadsheet and email threads are the current alternative. Friday provides a trigger and a cadence.

Even this stronger note must not borrow certainty from its detail. Perhaps the account manager enjoys the editorial judgment. Perhaps the agency’s clients barely read the update. Perhaps the delay comes from recruiters withholding weak news rather than from missing software. A good pain note makes these uncertainties inspectable; it does not settle them.

Keep an idea inventory as a notebook of such observations. For each entry, capture the person, recurring moment, trigger, current workaround, consequence, and frequency. Add where you could reach people close to the work, the smallest honest test you can imagine, and the likely trust, support, sales, and exception burden on the founder. Fill only what you know. A blank is a research task, not an invitation to invent.

The inventory should look unfinished. Record the phrases people use, but do not collect private customer data merely to make an entry feel substantial. Merge notes when the same behavior appears in several places. Cross an idea out when the consequence disappears, the buyer cannot be reached, or the first useful outcome requires an operating burden you do not want. An idea graveyard contains product fantasies waiting for their turn. An inventory preserves evidence and the decisions it caused.

Do not score the entries yet. Numbers create false comparability when one note comes from work you know intimately and another comes from a complaint you saw online. The next chapters will filter ideas. This chapter’s discipline is observational honesty.

Stay with the Friday Update

The broad label invites a recruiting operations suite: applicant-tracking integrations, a client portal, permissions, automated summaries, recruiter nudges, analytics, and benchmarks. Any of those features might eventually belong. None has been earned by the observation.

Stay with the smallest consequential moment. Account managers want a client-safe update on Friday. Recruiters are busy sourcing, screening, and calling candidates, so their notes arrive late or rough. The account manager closes the gap with reminders and rewriting. The agency owner cares only if this work affects time, consistency, or client confidence enough to deserve action.

The founder can learn before integrating anything. Ask two agency owners to reconstruct last Friday: which roles needed updates, who chased whom, what sources were consulted, which sentences required judgment, and what the client did next. With permission and appropriately anonymized inputs, manually prepare one digest. Then watch the corrections. Corrections reveal whether the hard part is missing state, coordination, factual accuracy, tone, or client-specific judgment.

Offer to do it again. Repetition raises the quality of the evidence. If nobody wants a second digest, the first may have been courtesy. If the owner uses it but every client requires a different narrative and every fact needs an expert to interpret it, the founder may have found a service rather than a product. If several small retained-search agencies use similar inputs, make similar corrections, and value the same outcome, a bounded workflow begins to appear.

Measure founder labor while it still teaches. Time spent chasing inputs, resolving ambiguities, protecting sensitive information, and rewriting prose is part of the candidate product. Code does not remove that burden merely by hiding it behind a screen.

This is where the five product risks leave the previous chapter’s map and enter ordinary work. The manual digest probes value, usability, feasibility, viability, and sustainability at once, but it does not prove all five. It reveals which question deserves the next test.

Let the Test Discover the Product Shape

The same pain could lead to several products. The first useful intervention might be a clearer update template, a managed weekly service, a narrow status-collection workflow, a writing assistant with an approval step, or an integration into the agency’s existing system. Starting with a product category makes one of those shapes feel inevitable before the founder understands the work.

Restraint is not timidity. A manual test puts the founder close to the buyer, the workflow, the quality bar, and the operating load. It can also kill the idea cheaply. Agencies may already have acceptable templates. The problem may be real but too infrequent. Clients may not value the update. A different format for every client may turn each new account into more custom labor. Each answer prevents software from making a weak idea harder to abandon.

The trend trap works in the opposite direction. It begins with AI, a marketplace, mobile, blockchain, or a new platform capability, then searches for pain to justify the mechanism. The artifact trap mistakes a spreadsheet or internal tool for demand. The personal-pain trap assumes the founder represents a market. The reach trap discovers serious work inside an organization the founder cannot enter. All four substitute a suggestive sign for observed customer behavior.

An Idea Can Earn Discovery

An idea is ready for active discovery when you can name a specific customer and a recurring painful moment; describe the current workaround and its visible consequence; and explain where the first serious conversations will come from. You should also be able to imagine a test that creates or measures value without building the full product, while admitting the founder burden it may create.

Some blanks can remain. They should be answerable through conversation, artifact review, or a manual service.

  • Proceed when the note is concrete enough to investigate and the missing evidence is reachable.
  • Narrow when the pain is real but the customer group, workflow, or first value moment is too broad.
  • Pause when you cannot get close to the people, artifacts, or behavior behind the claim.
  • Kill when the entry is still a trend, product category, personal preference, or technology demonstration searching for a customer.

Spend a week collecting pain notes. Look at work you have done, communities you know, services you have bought, tools you use, and processes you have watched. Write twenty recurring moments, leaving every unsupported field blank. Choose the five with the clearest behavior and, for each, name a reachable person and a first test that does not require the product you currently imagine.

The result is not a list of validated businesses. It is a set of observations strong enough to face the next question: whether you are the right founder to pursue them.