# Second-career founders: turning domain knowledge into a SaaS idea Years in an industry give you a problem others cannot see. How to separate what you know from what you assume, and turn it into a testable SaaS idea. Canonical URL: https://worldenterprise.org/insights/second-career-founders-turning-domain-knowledge-into-a-saas-idea/ Last updated: 2026-10-10 Publisher: World Enterprise, run by World Enterprise Group Incorporated *This article is general information, not legal or financial advice. It was written on October 10, 2026. What you may reuse from a previous employer is a question for your own counsel.* If you have spent many years in an industry, you know things that outsiders do not: where the work is slow, which forms get re-keyed by hand, which report nobody trusts and which workaround everyone has quietly agreed to. That knowledge is the reason many second-career founders start a software company, and it is a real advantage. It is also a trap, because knowing a domain well can feel like knowing the answer. This article is about the step between "I know this industry" and "I have a SaaS idea worth testing." It sets out how to treat your knowledge as a source of questions, how to check it against people who are not you, and how to shape what you found into something small enough to try. The [dream desk](https://worldenterprise.org/insights/topic/dream/) covers the steps that come after, and its articles are linked where they apply. ## What your experience gives you, and what it does not Experience gives you three things that are hard to buy. You can recognize a problem when you see it, because you have lived it. You know the vocabulary, so you will not waste a customer's time on basics. And you probably know people who still work in the field, which shortens the path to your first conversations. Experience does not give you three other things. It does not tell you whether your problem is shared, because you saw it from one employer, one role and one period. It does not tell you whether anyone will pay to fix it, because you were paid to live with it. And it does not tell you what has changed since you left. The GOV.UK Service Manual, which sets out how UK public services are built, has a sentence that applies to every domain expert: "Treat any opinions or suggestions that do not come from users as assumptions that have to be proven by doing research." Your own history in the field counts as an opinion until current users confirm it. ## Step 1: Write down what you know, in three columns Before talking to anyone, take an hour and list everything you believe about the problem. Put each item in one of three columns: - **Saw it myself.** Things you observed directly, with a date and a place. "At my last employer, the month-end reconciliation took two analysts several days" (an invented example). - **Heard it from others.** Things colleagues or customers told you. Note who. - **Believe it.** Conclusions you drew. "Every firm of that size has the same problem." The third column is the one to test first. The first two give you people to call, and the first tells you what to ask them about. Nothing here needs to be impressive. The purpose is to make the boundary between knowledge and assumption visible. ## Step 2: Turn your solution into a problem Domain experts often arrive with a solution already in mind, because they have been wishing for it for years. The discovery guidance in the service manual deals with the same situation, where a team is handed a ready-made answer. It says that before you start research, "you’ll need to interrogate that solution and reframe it as a problem to be solved", and adds: "Break down assumptions and ask lots of questions." The page gives an example. A team is told to build an interactive map showing where its contact centers are. The page reframes it as a question: how can the team make it easier for people to find their nearest contact center if they need a face-to-face appointment? The map is one possible answer, and there may be others. Try the same move on your idea. Write the solution you have in mind ("a dashboard that shows X") and then write the problem it assumes ("people who need to know X cannot find out until it is too late"). The second sentence is the one you test with customers. The [problem brief template](https://worldenterprise.org/library/one-page-problem-brief/) gives you a place to put it, and the article on [writing the problem brief before the code](https://worldenterprise.org/insights/write-the-problem-brief-before-the-code/) explains why. The same page also suggests quantifying the value of solving the problem. During discovery, it says, "that means understanding how much the problem is currently costing." You are better placed than most to estimate that. Treat your estimate as a guess to check, and let a customer correct it. ## Step 3: Find out who else has the problem The service manual lists what to find out in the early phase: "who your likely users are and what they’re trying to do", how they currently do it, and "the problems or frustrations they experience." Each of those can be answered by a conversation with someone in the field. Two points from the same guidance matter for a second-career founder. First, the guidance says you must understand the needs of "all kinds of users", not just typical ones, and the needs of the people who provide a service or support its users. In many industries the person who feels the pain is not the person who buys the software, and your own old role may be one of the two. Second, it recommends talking to people who work with users, such as caseworkers and agents, as well as the users themselves. A former colleague who now runs the process you used to work in is exactly that. The [customer discovery interviews](https://worldenterprise.org/insights/customer-discovery-interviews-without-false-positives/) article describes how to run these conversations so that people tell you what they do, not what they think you want to hear. When you interview people you know, take extra care. Friendly sources tend to be polite. ## Step 4: Combine existing sources with direct research The U.S. Small Business Administration describes two routes for market research. In its words, "You can do market research using existing sources, or you can do the research yourself and go direct to consumers." Existing sources "can save you a lot of time and energy, but the information might not be as specific to your audience as you’d like." Direct research "can give you a nuanced understanding of your specific target audience", though it "can be time consuming and expensive." For a domain expert, the sensible split is this. Use existing sources, such as industry reports and public data, to check the general claims in your third column, like how many firms there are and what they use today. Use direct conversations to answer the specific ones, like what the problem costs and who decides. The SBA page also lists questions to answer, among them "Is there a desire for your product or service?" and "What do potential customers pay for these alternatives?" The second question matters because every problem you know well already has a current solution, even if it is a spreadsheet and a person. The [bottom-up market sizing](https://worldenterprise.org/insights/bottom-up-market-sizing-for-a-first-saas/) article shows how to turn those answers into a size estimate that you can defend. Once you have those numbers, [is your SaaS idea a business or a feature](https://worldenterprise.org/insights/is-your-saas-idea-a-business-or-a-feature/) sets out the checks to run on them. ## Step 5: Choose a narrow first customer Domain knowledge tempts you to build for the whole industry. Choose one role at one kind of company, one that you know well, and write one sentence describing the person and the job they are trying to do. If you cannot name someone, you do not yet have a first customer. Name the person you would call tomorrow. Along the way, note what you may not use. If your idea draws on a former employer's systems, data or methods, or on a contract you signed, stop and ask counsel what you may reuse before you build. A separate article in this desk covers intellectual property and employment agreements for people who start a company while employed. Neither it nor anything here substitutes for that conversation. ## A first test, before any code You now have a short list: your claims by column, a reframed problem and a named first customer. A good first test is five conversations with people in that role, using the questions from your list, and a note of what each one does today. The [validate the problem playbook](https://worldenterprise.org/playbooks/validate-the-problem/) puts those steps in order. If the conversations confirm the problem, you have earned the right to sketch a solution, and if they do not, you have saved yourself months. > **Experience is a long-horizon asset** > > Census Bureau research on founders, summarized in the encore founders article, finds that prior work in the same industry goes with higher rates of strong growth outcomes. That is an association and not a promise, but it supports starting from what you already know. A second-career founder often has the advantage of knowing a field well enough to see what is missing. The [encore founders article](https://worldenterprise.org/insights/encore-founders-starting-a-company-after-fifty/) collects the public research on age, industry experience and prior business ownership, and the [founder age study](https://worldenterprise.org/insights/founder-age-and-growth-what-the-census-study-of-2-7-million-founders-found/) describes its limits. Founders who want company on the way can look at independent [programs and communities](https://worldenterprise.org/insights/choosing-a-startup-program-that-fits-a-decision-guide/) and at the public counseling network in the [SBA resource partners](https://worldenterprise.org/insights/using-sba-resource-partners-sbdc-score-wbc-and-vboc/) article. Join them. WE works alongside, for the long run. Domain knowledge from research work can also qualify for federal research awards; the [SBIR and STTR guide](https://worldenterprise.org/sbir-sttr/) explains the phases and how to prepare. The [ecosystem directory](https://worldenterprise.org/ecosystem/) lists independent incubators, university programs and SBA resource partners that help second-career founders test an idea, and the [who starts data page](https://worldenterprise.org/data/who-starts/) shows how many new entrepreneurs start later in life. ## What this article cannot tell you This article rests on two pages of UK public-service guidance and one page from the U.S. Small Business Administration, plus reasoning. It does not measure whether second-career founders succeed more or less often than others. The service manual was written for government teams, so its examples are borrowed as method. The article does not tell you whether your industry is a good one for software, how large the market is, whether you should leave your job, or what you may reuse from past work. Those depend on your facts and, for the last, on advice from counsel. Check each source's current text before relying on a quotation. ## Sources - How the discovery phase works. GOV.UK Service Manual, Government Digital Service. - Learning about users and their needs. GOV.UK Service Manual, Government Digital Service. - Market research and competitive analysis. U.S. Small Business Administration.