# Three ways to start: an idea, a skill, a problem you have lived Founders begin from an idea, a skill or a problem they have lived. This article sets the three starting points side by side and names what each skips. Canonical URL: https://worldenterprise.org/insights/three-ways-to-start-an-idea-a-skill-a-lived-problem/ Last updated: 2026-10-10 Publisher: World Enterprise, run by World Enterprise Group Incorporated Almost every company has a different first day. One founder wakes up with a product idea they cannot shake. Another has fifteen years of skill in a trade and a suspicion that software could do part of it. A third spent a year annoyed by the same broken process at work and finally decided to fix it. These are three different starting points, and they leave three different things unchecked. None of them is a better way to begin, and none of them guarantees a company. This article describes each one, says what it gives you, and names the question it tends to skip. It does not rank them, because the right place to start is the one you are standing on. ## Starting point one: an idea An idea starts with a solution. You can see the product, perhaps down to its screens, before you have talked to anyone who would use it. **What it gives you.** Energy and a concrete thing to test. A clear picture is useful when you need to explain what you are building to a designer, an engineer or a first customer. Ideas also tend to be specific, which makes them easier to discuss than a vague ambition to "do something in health." **What it leaves unchecked.** Whether anyone has the problem the idea solves, how often, and what they do about it today. When the product comes first, the problem is often assumed. The idea and the evidence arrive in the wrong order, and every later conversation tends to be a search for agreement rather than a search for facts. **A fair first check.** Write the idea as a problem statement without naming the product. If the sentence still makes sense, you have something to test. If it only makes sense with the product in it, the idea may be a feature looking for a problem. The article on [whether an idea is a business or a feature](https://worldenterprise.org/insights/is-your-saas-idea-a-business-or-a-feature/) works through that distinction. ## Starting point two: a skill A skill starts with a capability. You know how to build, design, sell, analyze or operate something, and you are looking for the place where that capability is worth the most. **What it gives you.** Speed on the part you know. A founder who writes software can ship a first version without hiring. A founder with years in a regulated trade can read the rules the way an outsider cannot. Skill also gives you credibility in a narrow area, which helps when you speak to the first people you would like as customers. **What it leaves unchecked.** Demand. A capability is not a customer. It is common to build something well, because building is the part you are good at, and to discover afterwards that nobody was waiting for it. The skill also colors what you see: a person who builds software sees software-shaped problems, and may miss that the real fix is a process change, a hire or a different tool. **A fair first check.** Name three people, not companies, who currently pay money or lose hours because of the problem you think your skill can solve. If you cannot name them, the skill is real and the market is still unknown. The [customer interview guide](https://worldenterprise.org/library/customer-interview-guide/) is a structure for the first conversations. ## Starting point three: a problem you have lived A lived problem starts with an experience. You were the person for whom the process was broken, the tool was missing or the information was impossible to find. **What it gives you.** Detail. You know the context, the vocabulary and the workarounds. You also know what a bad day looks like, which is often the most useful thing to know when you design a product. People in a similar position tend to recognize someone who has been where they are. **What it leaves unchecked.** How representative you are. One person's problem may be shared by thousands of people or by almost nobody. Your workaround may be unusual, and the thing that bothers you most may not be what others would pay to remove. There is also a quieter risk: when the problem is personal, it can be uncomfortable to hear that others experience it differently. **A fair first check.** Interview people who are not your friends and who did not hear your account first. Ask them to describe the last time the problem happened, without telling them what you think the answer is. ## The three side by side | | Idea | Skill | Lived problem | |---|---|---|---| | Starts with | A solution you can picture | A capability you hold | An experience you had | | Usually strong on | A concrete thing to test | Building or delivering | Context and detail | | Often unchecked | Whether the problem exists | Whether anyone wants the output | Whether others share the problem | | Typical blind spot | Looking for agreement | Seeing only skill-shaped problems | Treating your case as typical | | First evidence to collect | Who has the problem, and what they do now | Who pays or loses time today | How others describe the same event | The table is a map of tendencies, not a verdict. Plenty of founders combine two of them: a skilled engineer who also lived the problem has a different set of strengths and a different set of gaps. ## What the three have in common Whatever the starting point, the work that follows is the same kind of work: find out what the problem is, for whom, and whether it is worth solving, before you commit to building. The public-sector design guidance published as the GOV.UK Service Manual puts the habit plainly. Before building a service, it says, you need to understand the problem that needs to be solved. It also says that your discovery is finished when you have decided whether to move on, and that it is not a failure to stop at the end of discovery if the research shows that is the right call. That last point matters for founders, who tend to treat stopping as defeat. A cheap decision not to build is a result. The U.S. Small Business Administration, in its guidance on market research, describes the purpose in a sentence: market research helps you find customers for your business. It also says that competitive analysis helps you make your business unique. These are modest claims. They are useful because they are modest: the first job is finding customers, not producing a forecast. A working order that suits all three starting points: 1. **Write the problem down in one page.** The [one-page problem brief template](https://worldenterprise.org/library/one-page-problem-brief/) is built for this. Say who has the problem, what it costs them, and what they do now. 2. **Find the people.** Name the first ten people you could ask, and how you would reach each of them. 3. **Ask about the past, not the future.** Questions about what someone did last month are more reliable than questions about what they would do if you built something. 4. **Decide what would change your mind.** Write down, before the conversations, what you would need to hear to stop. 5. **Then choose how to build.** The [validate the problem playbook](https://worldenterprise.org/playbooks/validate-the-problem/) covers this stage in more detail. ## Questions to ask yourself about your own starting point - If I removed the product from my description, would the problem still stand? - Who, other than me, has told me in their own words that this costs them something? - What would I do differently if I found out that I was an unusual case? - Which of the three starting points am I closest to, and which gap does it leave? - What am I giving up to find out, in time and money, and how long can I afford to look? ## What this article cannot tell you It cannot tell you which starting point suits you, whether your idea, skill or experience points to a real market, or how long finding out will take. The two sources cited are a public-sector design manual and a national small business agency; neither studies software startups specifically, and both are written for their own audiences, one for teams building government services and one for small businesses in the United States. The article makes no claim about how often any of the three starting points leads to a company, because none of the cited sources measures that. Other starting points exist, including joining a company, buying one or building around a customer, and the other articles on this desk cover some of them. Your own circumstances, including money, time, family, location and the rules that apply to you, change the picture in ways a general article cannot see. ## Sources - How the discovery phase works. GOV.UK Service Manual, Government Digital Service. - Market research and competitive analysis. U.S. Small Business Administration.