Find Your Missing Piece

“I'm creative” is a description. “I can turn messy product information into a clear one-page buying guide” is an ability. “I'm organized” becomes useful when you can explain what you organize, for whom and what changes afterward.

Go back through Lesson 01. For each promising item, write an action: explain, repair, design, compare, build, teach, plan or simplify. Then name something you have actually done. Paid work counts. So do volunteer projects, personal projects and helping someone solve a real problem.

You don't need a polished portfolio yet. You do need an honest distinction between something you've delivered, something you're practicing and something you only want to learn.

Industry context helps you spot details an outsider misses. Lived experience helps you understand friction. Technical or creative skills help you make something useful. Relationships can help you reach people for a conversation—not guarantee that they'll buy.

Look for two or three ingredients that strengthen each other. A former receptionist who builds simple websites may understand the questions customers ask before booking. A parent who manages complicated schedules may be good at designing practical planning tools.

Access is not ownership. A former employer's customer list, confidential documents and paid work are not yours to reuse. Your advantage is what you've learned, not material you don't have permission to use.

1. Name the skill you can use now.
2. Name the context you understand.
3. Identify the person you can realistically learn from.
4. Write the smallest useful result you could deliver.

A beginner can offer a narrow, low-risk result they can competently deliver. They should not sell expertise they don't have. If your idea depends on learning six new skills before you can help anyone, shrink the first version.

Write down the skill gap, how you will practice it and what evidence would show you're ready. Some work needs qualifications, insurance or professional oversight. Health, legal and financial advice are not shortcuts into a business because you've had a personal experience.

This person hasn't proved a business exists. They have identified a credible starting point: helping small appointment-based teams reduce avoidable confusion.

The next question is whether those teams have a problem important enough to solve—not whether scheduling templates are trending.

“Small businesses need help” is too broad to build around. “Solo cleaners lose time rewriting estimates after every enquiry” gives you a person, a moment and a task to investigate.

Start with people whose work or life you understand. Describe the situation where the problem happens. What are they trying to do? What gets in the way? What happens if they leave it alone?

Consequences can include wasted time, unnecessary spending, mistakes, uncertainty or a frustrating experience. Describe those consequences without exaggerating them. An inconvenience can be real without being worth paying to remove.

“Would you buy my app?” invites politeness and guesses. Ask what happened the last time they faced the problem. Let them describe their process before you introduce a solution.

Talk to three people who fit the situation. You are collecting clues, not claiming that three conversations validate a market. Ask permission to take notes and keep identifying information out of your exercise answers.

1. Tell me about the last time this happened.
2. What did you do to solve it?
3. How often does it happen, and what does it cost you?
4. What have you already tried or paid for?
5. What is still difficult about your current approach?

Repeated workarounds, spending on alternatives, an urgent deadline and a person actively searching for help are useful signals. “That sounds cool” is not purchase evidence.

Find out who experiences the problem and who decides to spend money. An employee may hate a process while the owner controls the budget. A good idea can stall if you never understand that difference.

Write what you've observed separately from what you believe. If you haven't spoken to anyone yet, call it a hypothesis and schedule the conversations. Don't manufacture quotes, numbers or demand with AI.

A meal planner is one possible response. A shopping service, workshop or simpler checklist might fit better. We don't know yet.

If people already have an easy solution and don't care about changing it, that matters. Let what you learn change the idea.

A service solves a problem through work you do for a client. It can be a quick route to direct feedback, but delivery uses your time. Define scope, revisions, capacity and what is not included.

A digital product packages something people can use themselves: a template, guide or tool. It still needs a clear use case, quality checks, a way to reach buyers and support. Downloadable does not mean automatically sellable.

Teaching helps someone learn a skill or process. You need relevant competence, a useful learning sequence and honest boundaries. A course is not the default just because you know something. Start with a small lesson or workshop if that is enough.

Software can automate a recurring task, but introduces usability, maintenance, privacy and support responsibilities. Test the workflow manually or with a simple prototype before committing to a large build.

Physical products involve production, stock, shipping and returns. A membership adds an ongoing delivery promise. Content-led businesses depend on audience access and monetization. None of these are passive by definition.

How many hours can you consistently give this? What money can you afford to risk? Do you want client conversations, solo making, teaching or technical maintenance? What can you deliver without a long chain of new skills?

A model can be attractive and still be a poor fit right now. If you have five hours a week, a daily-content membership may be an obligation you can't sustain. If the problem needs personal judgement, a generic template may not be enough.

Consider the cost to deliver, not only the possible sale price. Include tools, materials, fees, support and your time. We will develop pricing in Phase 01; right now we are testing feasibility, not forecasting income.

A manual pilot can reveal what customers need before you automate it. A single fixed-scope service can teach you more than a website listing fifteen offers. One useful resource can test a use case before you create a library.

Pick one primary model for the first experiment. You can change it after learning. Write a delivery promise you could actually keep and a boundary that prevents the pilot from turning into unpaid unlimited work.

1. Match the model to the customer's task.
2. Check that you can deliver the first version.
3. Set a time and spending limit.
4. Name the simplest pilot and its boundaries.

Someone who understands cleaning jobs and spreadsheets could start with the manual service. Someone with no relevant knowledge should first learn the process, not promise accurate estimates.

The first choice doesn't close every future door. It makes the next experiment manageable.

Compare three ways the person currently handles the task. Include a paid offer, a free tool or manual workaround, and the option of leaving the problem unsolved where relevant.

For each, record who it's for, the task it helps with, the delivery format, the stated price and what is included. Use public information, note the date and don't treat a temporary price as permanent.

Read specific reviews and questions for recurring friction: setup is confusing, the instructions assume experience, the product is too complex, support is slow. A single complaint is a clue to investigate, not a market gap you have proved.

A fact might be that a public product page lists a template at a particular price. An interpretation might be that it is aimed at beginners. An unanswered question might be whether buyers can use it without help.

Record the source beside the observation. A review is one person's account; a vendor's promise is their claim. Neither gives you private revenue, conversion or retention numbers.

Time-box the desk research to 30–45 minutes, then identify a question to ask a real person. Research should lead to a decision or a conversation, not a permanent browser-tab collection.

Do not copy names, sales copy, layouts, artwork, lessons, proprietary templates or confidential processes. Buying a resource does not automatically give you resale or reuse rights. Check licences and permissions.

You can notice that people need clearer onboarding. Your response should come from your understanding of those people, your delivery model and your own work—not a lightly rewritten version of someone else's product.

AI can help organize notes or suggest questions. It cannot turn guesses into verified demand or authorize copying. Check sources yourself, avoid uploading personal or confidential information and never generate fake customer quotes.

You are not copying the planner or promising that one complaint represents everybody. You are using an observation to design a better question.

If conversations show setup isn't a meaningful problem, drop that assumption. That is useful research, even when it changes your plan.

Shortlist no more than three ideas. For each, ask: can I competently help? Does a specific person experience the problem? Can I reach them? Does the delivery fit my constraints? Can I test the riskiest assumption with a small amount of work?

Mark each answer as supported, partly supported or unknown, and add the evidence. A score without reasons is just a preference dressed up as a spreadsheet. No scoring system can prove demand.

Choose the idea with the clearest responsible next experiment. If all three rely on unknown demand, your first experiment may be conversations rather than building. Put the other ideas aside for now; you aren't deleting your future options.

1. Choose one person and one problem.
2. Name the ability and delivery model you will use.
3. Identify the assumption most likely to break the idea.
4. Design the smallest test that could change your mind.

Your map names your useful skills, the primary income path, the person and problem, a working Missing Piece statement, a proof project and a 7-day sprint. It is a decision document, not a sales promise.

Write: “I help [specific person] solve [specific problem] by [concrete approach].” If you haven't tested it, say so. Avoid words such as guaranteed, effortless or profitable when you have no evidence behind them.

Use the earlier exercises to draft your map. Keep existing saved map answers if they are still right. Revise only what your learning has changed. An honest unknown belongs in the map too.

If the uncertainty is whether people care, a polished logo won't answer it. If the uncertainty is whether someone can use your resource, let them try a small version. If the uncertainty is whether they'll pay, compliments aren't enough; a later clearly scoped paid pilot can provide stronger evidence.

Before testing, write what you will observe and what would make you continue, change or pause. Three target users completing a task without help can test usability. It does not prove a market. Separate feedback, usage and actual purchase behaviour.

Keep scope and risk small. Get permission, explain that the project is a test and protect participant information. Don't sell something you can't deliver. Phase 01 will help you turn a promising direction into a clearer offer.

Day 1: review your map and name the riskiest assumption. Day 2: contact appropriate people and arrange conversations. Day 3: ask about recent experiences and refine the problem.

Day 4: make the smallest useful proof project—or continue research if you haven't established a real use case. Day 5: let suitable people try it with permission. Day 6: record what they did, where they struggled and what they said. Day 7: decide whether to continue, narrow, change the model or pause.

Adapt the schedule to availability. No replies in seven days are not proof that nobody wants the idea. They may mean your access or outreach needs work. Record what happened instead of forcing a success story.

A useful first version and positive feedback would still not prove willingness to pay. That would need a separate offer test.

The map makes the next step concrete while leaving room for the evidence to disagree with you.