Problems worth solving. Deciding what to build before you build it.

Warm-up: what do you already believe?

Before we start, take three short questions. They are not a test of knowledge. They surface the beliefs you bring with you, so you notice when the guide disagrees with them. Answer honestly, then read the explanation even if you got it right.

How to study this guide

1. Pick one product to carry through. Your current product, or one you want to build. Every exercise applies to it. If you have nothing yet, use a product you use every day and imagine you are its sole maker.
2. Read a Part, then do its exercises before moving on. The Parts build on each other: you cannot map assumptions you have not found, or position a product whose job you do not know.
3. Keep one document, your "problem file". Every exercise adds a section: problem statement, job stories, interview notes, insights, assumption map, positioning, principles, shaped pitch, onboarding plan. By the end it is the strategy for your product, written in your own words.
4. Come back to the recap quizzes after a few days. Each Part ends with one. Retrieval after a gap is what moves ideas into long-term memory.

Most failed products are well-made answers to questions nobody was asking. Start from a struggle you can observe, state it precisely, and stay attached to the struggle rather than to your first idea for fixing it.

Builders think in solutions. It is the fun part, and it is what our hands know how to do. An idea arrives as a picture of a screen: "an app where you can save highlights and review them like flashcards." The picture is so vivid that it feels like evidence. It is not. It is a guess about what someone else needs, dressed in the details of how you would build it.

The trouble is cost. For a solo creator, the scarcest resource is not money, it is months. If you build first and learn second, every wrong guess costs you a whole build cycle: three, six, twelve months. If you learn first, a wrong guess costs you a conversation or an afternoon of reading reviews. That ratio, hours versus months, is the entire argument for this guide.

What a problem is (and what it is not)

A problem is a struggle a specific person has in a specific situation, visible in what they do today. It is not the absence of your solution. "There is no good app for reviewing Kindle highlights" is a statement about the market. "I re-read books and realize I highlighted the same passage twice and forgot both times" is a struggle. The first invites you to build. The second invites you to understand.

The most reliable sign of a real problem is a workaround. When people care enough about something, they already do something about it, badly. They email files to themselves. They keep a spreadsheet next to the app. They screenshot a page to remember it. They pay a virtual assistant. They copy text into Notes and never find it again. A workaround proves three things at once: the struggle exists, it hurts enough to act on, and the person has already budgeted time or money for it. Your product only has to be better than the workaround, and you can watch the workaround directly.

When you find no workaround, be suspicious. Either the problem is rare, or mild, or people have accepted it as part of life. All three make for slow, uphill products.

Five tests of a problem worth your months

You rarely get five strong signals. Two or three strong and none weak is a good start. The last test matters more for solo creators than for companies: you will spend years with this problem, often alone, and caring about it is what keeps you going through the quiet months after launch.

Writing a problem statement

A problem statement is one or two sentences that make the struggle specific enough to test. A useful template:

Each slot forces a decision you would otherwise avoid. "Who" forces a narrow group. "Progress" forces you to say what they are trying to achieve, not what feature they lack. "Situation" pins down when it happens, which is where design gets concrete. "Cause" is your current hypothesis, written down so it can be wrong. "Workaround" and "cost" are the evidence that it matters.

Fall in love with the problem

Uri Levine, co-founder of Waze, titled his 2023 book Fall in Love with the Problem, Not the Solution. The advice sounds soft. It is actually a hard rule about where your loyalty sits. If you love your solution, every piece of disconfirming evidence feels like an attack, and you will explain it away. If you love the problem, disconfirming evidence about your solution is good news: it brings you closer to whatever does solve the problem.

You can tell which one you love by how you describe your product. Solution-lovers describe features ("it has spaced repetition, tags, and an AI summary"). Problem-lovers describe a person and a moment ("you finish a book on Sunday, and on Monday you can't remember the three ideas that mattered"). Practise the second. It is also, not by accident, much better marketing (see Identity & Launch).

The five whys, used carefully

The five whys comes from the Toyota Production System, where Taiichi Ohno taught engineers to ask "why?" repeatedly at a broken machine until they reached a root cause rather than a symptom. In product work it helps you dig beneath the first problem you see, which is usually a symptom.

Two cautions. First, each "why" should be answered with evidence (something you observed, measured or were shown), not with a plausible story. Chains of plausible stories drift into fiction fast. Second, do not ask a person "why?" five times in an interview. Asked directly, people invent tidy reasons for messy behavior; psychologists call it confabulation (see The Human Mind). Ask what happened, what they did next, and what that was like. You do the "why" afterwards, in your notes.

The problem framing canvas

When a problem feels fuzzy, lay it out on one page. The canvas below is a compact version of the frames used in design-thinking workshops, trimmed for one person. Fill each box in a sentence or two. Blank boxes tell you what to research next.

The canvas, filled for one example. Box 2 is the centre of gravity (highlighted). Box 5 separates what you saw from what you guessed; every guess is a research task. Box 7 is as important as box 2: a problem without edges grows until it is unsolvable.

In the wild

• DropboxDrew Houston, 2007
  Houston has often told how he started it after forgetting his USB drive before a bus trip, so his files were out of reach for hours. The problem (my files are stuck on one device) existed long before the product, and the workaround (USB sticks, emailing files to yourself) was everywhere. A common, frequent struggle with a visible, clumsy workaround is the best possible starting point.
• Basecamp37signals, 2004
  Built as an internal tool to run 37signals' own client projects, where email threads were losing decisions and files. Only later sold to others. Living the problem gives you the "yours" test for free, and a daily stream of evidence.
• SlackTiny Speck, 2013
  Grew out of the chat tool a small team built for itself while making an online game that did not succeed. The problem (scattered team communication) outlived the original product. Sometimes the problem you solve for yourself along the way is the real one. Keep your eyes on your own workarounds.
• Waze2008
  Levine describes the starting point as a daily struggle, sitting in traffic, rather than a mapping technology. The crowd-sourced solution came from that framing. The problem framing ("avoid traffic jams") left room for a better solution than the obvious one ("better maps").

People do not buy products; they "hire" them to make progress in a particular situation. Understand the job and the forces around switching, and you know who you really compete with and what your product must do first.

Jobs to be Done (JTBD) is a lens, not a process. It asks one question: what progress is this person trying to make, in this circumstance, when they reach for a product? The answer is the "job". The product is something they hire to do the job, and fire when something better comes along. The vocabulary sounds odd at first, but it does useful work: it moves your attention from the customer's demographics (age, job title, country) to their situation, which is what actually predicts behavior.

The milkshake story

Clayton Christensen, the Harvard professor best known for The Innovator's Dilemma, told this story many times, and it appears in his 2016 book Competing Against Luck. A fast-food chain wanted to sell more milkshakes. It surveyed customers about the ideal shake (thicker, sweeter, cheaper?) and made changes. Sales did not move. Christensen's team, which included Bob Moesta, instead watched who bought milkshakes and when. A surprising share were bought early in the morning, by people alone, who left with them in the car.

When the researchers asked those morning buyers what they were trying to do, the answer was not "enjoy dessert". It was something like: I have a long, boring drive to work, I need something to do with my spare hand, and I need to not be hungry by mid-morning. Against that job, the milkshake competed not with other milkshakes but with bananas (gone in a few minutes), bagels (dry, need two hands), doughnuts (crumbs, sugar crash) and nothing at all. A thick shake that lasts the whole drive through a thin straw is, for that job, the best hire on the menu.

The lesson for software is direct. Your reading app does not compete only with other reading apps. It competes with whatever people hire today for the same job: a stack of paper, a browser tab left open for weeks, a podcast on the commute, a "read later" folder nobody opens, or the decision to simply not read. Reed Hastings of Netflix made the same point when he said, in 2017, that Netflix's biggest competitor was sleep. The job (unwind in the evening) has many candidates, and most of them are not products.

Three layers of every job

Christensen described jobs as having functional, emotional and social dimensions. All three shape design.

Small, calm products often win on the emotional layer while matching others on the functional one. iA Writer's focus mode does not add capability. It removes distraction, which serves the emotional job ("help me feel I can write") better than any feature list could.

The forces of progress

Bob Moesta, who worked with Christensen on the milkshake research, built a practical method around one moment: the switch, when someone stops using one way of doing the job and starts using another. With Chris Spiek he described four forces acting on that moment. Two pull a person toward change, and two hold them back.

Push

The struggle with the current situation that makes someone open to change. Without a push, people do not look. Your marketing should name it.

Pull

The attraction of a better life with the new solution. Not the feature list: the picture of the progress.

Anxiety

Fear about the new thing. Will it work for me? Will I lose my data? Is it worth the money? Will I look foolish learning it?

Habit

The comfort of the known. The old tool is "good enough", its costs are familiar, and switching takes effort.

This model explains things that feature thinking cannot. Why do people who love your demo never sign up? Anxiety and habit outweigh the pull. Why do people sign up and then drift back to the spreadsheet? The habit force kept acting after the switch. The fixes are design work: import from the old tool (habit), a visible export and an honest price (anxiety), a first session that delivers a small win (pull made real). Each force maps to a part of your product.

Switch interviews

Moesta's method for finding the forces is the switch interview: talk to people who recently switched to (or away from) a way of doing the job, and reconstruct the story of that switch like a documentary. You are not asking what they want. You are asking what happened. He describes the switch as a timeline:

Good switch questions are concrete and set in the past: "When did you first think the old way wasn't working? Where were you? What did you try first? What did you almost buy instead? What nearly stopped you? What happened the first day you used it?" Chapter 5 turns these into an interview script.

In the wild

• Things 3Cultured Code, 2017
  The job is less "store tasks" than "feel in control of my day without a system to maintain". The Today and This Evening split, and the calm visual design, serve the emotional layer as much as the functional one. Two apps with the same features can be hired for different jobs. Design for the job you want to win.
• NetflixReed Hastings, 2017
  Hastings' remark that Netflix competes with sleep reframed competition around the job of unwinding at night rather than around other streaming services. Your real competitor is often a habit or a different use of the same time.
• Readwise2017
  Grew by importing highlights from where people already read (Kindle and other apps) and resurfacing them, rather than asking readers to move their reading into a new tool. Working alongside the old way lowers the habit force instead of fighting it.

Write what you build as job stories, "When [situation], I want to [motivation], so I can [outcome]", because the situation is where design decisions come from. Use personas sparingly, and only ones grounded in real people.

Once you know the job, you need a unit of work small enough to design and build. Agile teams use the user story: "As a [role], I want [goal], so that [benefit]." The format came out of early Extreme Programming practice around 2001 and spread through Scrum. It is useful for planning, but it puts a role at the front, and the role often carries no information. "As a user, I want to export my notes" tells you nothing about when, why, or under what pressure.

The job story was introduced at Intercom around 2013 and popularized by Alan Klement. It replaces the role with the situation:

The change looks small. It is not. Situation carries the information a designer needs: the person's state of mind, their device, their time pressure, what they just did and what they will do next. "When I'm in a meeting and someone asks what we decided last week" produces a very different design (fast search, one hand, no setup) from "When I'm planning the quarter on Sunday evening" (overview, drag and drop, time to think).

What makes a job story good

1. The situation is a moment, not an identity. "When I'm a student" is an identity. "When I'm cramming the night before an exam" is a moment. Moments have triggers you can design for (a notification, a shortcut, a widget).
2. The motivation is progress, not a UI element. "I want to tap a button to export" has already designed the answer. "I want to get my notes into my essay" leaves you free.
3. The outcome is something that changes for the person. "So I can be more productive" is filler. "So I can submit by midnight" or "so I don't look unprepared in front of my manager" is real.
4. It is falsifiable. You could watch a user and see whether the situation occurs and whether your product delivered the outcome.
5. It is small enough to ship. A job story that covers your whole product is a job, not a story. Split it until each one is a single moment.

Personas, proto-personas and jobs: when each helps

Alan Cooper introduced personas to software in The Inmates Are Running the Asylum (1999): a specific, named, archetypal user, built from research, so a team would design for someone in particular rather than an elastic "user" who stretches to justify any feature. Used that way, personas work. Used badly, they become marketing posters: a stock photo, an age, a favorite coffee and a list of hobbies, none of which predicts what the person will do in your product.

Jeff Gothelf's proto-persona (from Lean UX, 2013) is a lighter version: a quick sketch of who you think the user is, written explicitly as assumptions, to be corrected by research. For a solo creator, that honesty is the main value.

In the wild

• Intercom2013 onward
  Intercom's product team wrote publicly about replacing personas and role-led user stories with job stories, and later published a book on how they use JTBD. The format spread because it is cheap and changes the conversation from "who" to "when".
• DraftsAgile Tortoise, 2012
  The app opens to a blank text field, ready to type, and decides where the text goes afterwards. That design follows from a situation ("when an idea arrives and I might lose it in seconds") rather than from a role. A precise moment produces a precise, opinionated design.
• Apple Watch timers and Siri shortcuts2015 onward
  Features designed around hands-busy moments (cooking, driving, exercising) look nothing like their phone equivalents. Situation, not person, decided the interface.

People will lie to you about your idea, kindly and without meaning to. Ask about their life, about specific things they did in the past, and listen far more than you talk. Then look for commitment, not compliments.

Rob Fitzpatrick's short book The Mom Test (2013) is named after a thought experiment. If you ask your mother whether your business idea is good, she will say yes, because she loves you. The answer is useless. But if you ask her how she uses her phone, what she did last time she wanted to share photos, and what she spent on it, she cannot mislead you even if she wants to. The question, not the person, decides whether the answer is trustworthy.

The three rules

1. Talk about their life instead of your idea. The moment you describe your idea, the conversation becomes about being polite to you. Keep your idea out of it for as long as possible, ideally the whole conversation.
2. Ask about specifics in the past instead of generics or opinions about the future. "Would you…?", "Do you ever…?" and "How much would you pay…?" invite hopeful fiction. "When was the last time…? What happened? What did you do then?" invites memory.
3. Talk less and listen more. If you are talking, you are not learning. Silence after an answer often produces the most useful sentence of the interview.

Three kinds of bad data

Fitzpatrick names three things that feel like learning but are not. Compliments ("that sounds great") tell you about the person's manners. Fluff comes in three forms: generic claims ("I always…", "I usually…"), future promises ("I would…", "I will…"), and hypotheticals ("I might, if…"). Ideas (feature requests) are interesting, but they are the person's solution; your job is to find the problem that produced them. When you hear any of the three, you do not argue. You redirect: "When did that last happen? Can you walk me through it?"

Bad questions, rewritten

Commitment and advancement

A good conversation ends with a clear next step that costs the other person something. Fitzpatrick lists three currencies: time (a follow-up session, trying an early version, introducing you to others), reputation (recommending you to their boss or community), and money (a pre-order, a deposit, a paid pilot). If a meeting ends with "keep me posted" and no commitment, treat it as a polite no, however warm it felt.

For a solo creator selling to individuals, the cheapest commitments are a sign-up with an email for a test version, a 20-minute screen-share to try a prototype, or a pre-order at a launch price. Count commitments, not compliments.

In the wild

• SuperhumanRahul Vohra, 2017–2018
  Vohra has written about onboarding early users one-to-one and measuring how disappointed they would be without the product, rather than asking whether they liked it. Even "liking" questions can be made honest by asking about loss rather than gain, and by pairing them with behavior.
• The pre-order pagea common indie pattern
  Many indie apps open a paid pre-order or "founding member" price before launch. Whatever the page looks like, the number of people who actually pay is a stronger signal than any survey. Money is the highest rung on the evidence ladder, and it is available to solo creators.

Five to eight good conversations with people who have the problem will teach you more than any survey. Recruit them from where they already gather, follow a loose script built around one real story, and synthesize by clustering observations, not opinions.

Interviews scare many builders: talking to strangers, asking for their time, not knowing what to say. The fear is mostly about recruiting and about silence. Both get easy with a little structure. The rest of this chapter is that structure, sized for one person doing it in the gaps of a build.

How many people?

For a narrow group with a shared problem, patterns start repeating quickly. A well-known study by Greg Guest and colleagues (2006) found that most themes in a set of interviews with a fairly similar group appeared within the first twelve, and the basic elements within the first six. That fits practitioners' experience: after five to eight interviews in one segment, you stop being surprised. Stop when you can predict what the next person will say. If you serve two different groups, you need five to eight in each.

Teresa Torres argues for a different rhythm once you have a product: rather than a big research project, talk to at least one customer every week, forever. For a solo creator that habit is more valuable than any one study. Do a burst of six to eight before you commit to a direction, then keep a weekly conversation going.

Recruiting without a budget

People with a problem gather to complain about it. Go there. Subreddits, Discord and Slack communities, forums, Facebook groups, LinkedIn groups, Telegram channels, Hacker News threads, comments under YouTube tutorials, your own newsletter and waitlist, and the support inbox of your existing product. Read first, for a week, so you know the language. Then post or message honestly:

Always ask at the end: "Who else should I talk to?" One good interview often brings two more. And offer something in return when you can: a summary of findings, early access, a small gift card. Thank-yous matter; you may want to talk to these people again.

A 30-minute script

Taking notes you can use

Record (with permission) and transcribe automatically, but also take light notes live. Write three kinds of thing, marked differently: verbatim quotes in quotation marks, observed behaviors (what they did or showed you), and your interpretations, clearly flagged, such as with "[me]". Keeping your interpretations separate is the single most useful note-taking habit. When you synthesize, you want to be able to tell what they said from what you thought.

Within an hour of the call, write a one-page summary while memory is fresh: who, their story in five lines, the forces, the best three quotes, surprises. Steve Portigal's advice in Interviewing Users is to treat this debrief as part of the interview, not as homework.

Synthesis by affinity mapping

After five to eight interviews you have hundreds of notes. Affinity mapping turns them into patterns. The method is old and simple: write each observation on its own note (a sticky, or a card in a digital whiteboard), one idea per note, with the interviewee's initial. Then cluster bottom-up: put notes that feel related near each other, without deciding categories in advance. Only when clusters form do you name them, as a sentence in the user's voice. Finally count: how many different people appear in each cluster?

In the wild

• Continuous discoveryTeresa Torres, 2021
  Torres recommends automating recruiting (for example, an in-product prompt inviting users to talk) so that a weekly interview happens without effort. Make the habit cheap enough that it survives busy weeks.
• Indie Hackers and Redditongoing
  Many indie founders describe finding their first interviewees by answering questions in niche communities for weeks before asking anything. Earn the right to ask by being useful first.

What people say they do and what they actually do are different, and the gap is where the best design opportunities hide. Watch people do the job in their own setting, and when you can't watch, have them report small moments as they happen.

Interviews capture what people can recall and put into words. A lot of what matters is below that line: the habits they no longer notice, the sticky note on the monitor, the three apps they switch between, the moment they sigh. Liz Sanders, a pioneer of participatory design, described levels of knowledge reached by different methods: what people say (interviews), what they do (observation), and what they make (creative exercises that surface feelings and dreams). The deeper you go, the less people can tell you directly.

Contextual inquiry, done alone

Hugh Beyer and Karen Holtzblatt described contextual inquiry in Contextual Design (1998). The core idea is the master and apprentice relationship: you sit with someone while they do real work, in their real setting, and learn it the way an apprentice would, by watching and asking about what you see as it happens. The person is the expert. You are there to learn the craft of their job, not to test your product.

You do not need to travel. A screen-share call where someone does their actual work (not a demonstration of it) gets you most of the value. Ask them to do the real thing they would have done today anyway: process this week's reading notes, plan tomorrow, write the report. Then mostly watch. Interrupt only to ask about what just happened: "You paused there. What were you looking for?" "Why did you copy that into the other window?"

What to watch for

• Workarounds
  Spreadsheets next to apps, notes to self, screenshots, emailing files to themselves, printed pages. Each one is a job your product could do. The most valuable thing you will see.
• Switching
  Every move between apps or windows, especially copy and paste. It marks a seam where the job crosses tools. Seams are where integration and import features earn their keep.
• Hesitation
  Pauses, hovering, scrolling back, re-reading labels, sighs, muttering. They mark confusion or anxiety. Ask "what were you thinking just then?" right after.
• Language
  The words people use for things. If they call it "my pile" and your app calls it "Inbox", note it. Their words make better labels (see Words).
• Environment
  Device, posture, noise, interruptions, time of day, lighting. A phone used on a train with one hand is a different design problem from a desktop at night. The situation clause of your job stories, seen live.

Diary studies, lite

Some jobs happen rarely or unpredictably: an idea arrives at 11 pm, a reading session on Sunday, a deadline once a month. You cannot watch those. A diary study asks a few people to record each instance briefly, as it happens, for a week or two. Formal diary studies use special tools. You can run a perfectly good one with a messaging app.

Keep it light: three to five people, five to ten days, a one-line daily prompt at a fixed time, and a request to send a screenshot or photo whenever the moment you care about happens. Thank people generously; this asks more of them than an interview. In the debrief, go through their entries together and ask about the ones that surprised you.

In the wild

• Intuit "Follow Me Home"from the 1980s
  Intuit, the maker of Quicken, became known for watching customers set up and use its software in their own homes and offices. Watching people's real setting has been the classic edge of software makers who cared about ordinary users.
• Screen-share researchany product, today
  Video calls made "follow me home" free and global. Watching someone's actual desktop for 20 minutes reveals their tool stack and workarounds. Remote observation is the solo creator's contextual inquiry.

Thousands of people have already written about the problem you care about, in reviews and forums. Mine that first. Use surveys to measure things you already understand, analytics to see what people do in your product, and your own use as a starting point, never as proof.

Not all research needs another person on a call. Some of the richest evidence is already published, for free, by people who care enough to complain in public. And once you have a product, it produces evidence every day. Each of these sources has a characteristic blind spot. Knowing the blind spots matters more than knowing the methods.

Mining reviews and forums

App Store and Play Store reviews, Reddit threads, product forums, comparison sites, YouTube comments under tutorials and "I switched from X to Y" blog posts are free interview transcripts. They are biased toward strong feelings, but they are written by people with real experience, in their own words, about real moments.

Start with competitors' reviews. Read the one- to three-star reviews. Five-star reviews say "love it". One-star reviews are often about bugs or billing. The middle, especially three stars, is where people describe what they hoped for and what got in the way: the exact gap your product could fill.

Use a simple spreadsheet so this becomes data rather than a vague impression:

After 50 to 100 rows, sort by theme and count. You will have a ranked list of struggles, in customers' own words, ready to use in interviews (as topics to probe) and in your marketing (as language that resonates).

Surveys, done right

Surveys are the most misused research tool, because they look scientific and are easy to send. Erika Hall's warning in Just Enough Research is worth taking to heart: a survey is easy to create and easy to get wrong, and wrong data in a tidy chart is more dangerous than no data. A survey can tell you how many people do something you already understand. It cannot tell you what to build, and it cannot discover problems you have not imagined, because you wrote all the options.

1. Run interviews first. Use surveys only to measure the size of patterns you found qualitatively.
2. Ask about behavior, not opinion. "In the last month, how many books did you finish?" beats "How much do you love reading?"
3. One idea per question. "How fast and reliable is sync?" is two questions.
4. Neutral wording, balanced options. Include "none", "other" and "I don't know".
5. Keep it under five minutes. Every extra question lowers completion and quality.
6. End with one open question. "Anything else about how you [do the job]?" Often the most useful answers.

One survey question is worth knowing by name. Sean Ellis, who coined the phrase "growth hacking", proposed asking existing users: "How would you feel if you could no longer use this product?" with the options "Very disappointed", "Somewhat disappointed" and "Not disappointed". His benchmark: if around 40% or more say "very disappointed", you likely have product/market fit for that group. Rahul Vohra described in 2018 how Superhuman used this question to segment users and decide what to build. It works because it asks about loss of something real, not about a hypothetical gain.

Analytics as research

Once people use your product, behavior data shows what they do, at scale, without asking. It cannot tell you why. Use analytics to find where to look, then interviews and observation to learn why. A few events answer most questions a solo product has:

• Activation: what share of new sign-ups reach the first moment of value (chapter 16)?
• Funnels: where do people drop out of a key flow?
• Retention: of people who started in a given week, how many are still active after 1, 4 and 12 weeks (chapter 17)?
• Feature use: what share of active users touch each feature? (Often eye-opening: many features are used by a small minority.)

Collect less than you think. A dozen well-named events beat hundreds of auto-captured clicks you will never analyze. Choose privacy-respecting tools, tell users what you collect, and never record content they write. Calm products earn trust by being restrained (see Honest & Calm).

Dogfooding and its bias

"Eating your own dog food", using your own product for real work, was popularized at Microsoft in the late 1980s. For solo creators it is natural and powerful: you feel every rough edge, daily, for free. Many of the best indie apps started as their maker's own tool. But your own use has strong biases you must correct for.

Correct for it in three ways. Regularly do a "fresh start": new account, empty data, on a device you don't usually use, timing yourself to first value. Watch someone else's first session at least once a month. And distrust features you want that nobody else has asked for; label them "for me" and keep them small, or behind a setting.

In the wild

• Superhuman2018
  Vohra's essay on the product/market fit engine described surveying users with the Sean Ellis question, then focusing on the "somewhat disappointed" users who shared the main benefit with the fans. A single, well-chosen question, combined with segmentation, can guide a roadmap.
• Basecamp, Things, Bear and other maker-used toolsvarious
  Products built and used daily by their makers tend to have unusually good everyday polish. Dogfooding sharpens the daily loop. Pair it with fresh-start runs so first-run doesn't rot.

An observation is what you saw; an insight is why it happens and what it means for design. Organize insights as opportunities under one clear outcome, and compare several solutions for each before you pick one.

After a week of research, most people write a list of findings like "users find setup confusing" or "4 of 6 use Notion". These are observations. They are necessary and they are not enough, because they do not tell you what to do. An insight adds two things: an explanation of the behavior and an implication for design. Insights are where your judgment enters, so they are also where you can be wrong, which is why you keep them tied to evidence.

How might we…

A useful bridge from insight to ideas is the "How might we…?" question, a phrasing that came out of Procter & Gamble in the 1970s and was spread by IDEO. Turn each insight into one: "How might we bring highlights into the place where people write?" The phrasing is deliberate. "How" assumes it can be done, "might" allows ideas that may not work, and "we" invites collaboration (with yourself, on a solo project). Good HMWs are neither too broad ("How might we help people learn?") nor already a solution ("How might we build a Notion plugin?").

The opportunity solution tree

Teresa Torres, in Continuous Discovery Habits (2021), offers a simple visual that keeps discovery honest: the opportunity solution tree. At the top is one desired outcome, a measurable change in user behavior that your product can drive. Below it are opportunities: customer needs, pain points and desires found in research (phrased from the customer's side, not as features). Below each opportunity are several solutions. Below each solution are the assumption tests that would tell you if it works.

Three details make the tree work. The outcome must be something your product can move and you can measure, phrased as user behavior ("more readers revisit a highlight within a week"), not as business results ("increase revenue"), which are lagging and hard to connect to any one decision. Opportunities are phrased from the customer's perspective, ideally in their words; if an opportunity names a feature, it's a solution in disguise. And you work on one target opportunity at a time, chosen by comparing opportunities against each other (how many people have it, how painful it is, how well it fits your strengths), not by scoring each in isolation.

In the wild

• Product teams using OSTs2020s
  Torres' tree is widely used by product teams as a living map that is updated weekly from interviews, rather than a one-off workshop artifact. The value is in keeping it current; a stale tree is just a pretty diagram.
• Readwise's resurfacing2017 onward
  The product's core feature is not storage but resurfacing a few highlights at a time, through a daily review. That follows from an insight that people don't lack a place to keep highlights; they lack a reason to see them again. The insight's "because" decided the product, not the observation that people highlight.

Every product idea rests on a stack of beliefs. List them, sort them by how much they matter and how much evidence you have, and test the important, unproven ones first, with the cheapest test that could change your mind.

When you pick a solution, you are betting that several things are true at once: people want it, they can use it, you can build it, and it can sustain you. Usually most of those beliefs are fine. One or two are shaky, and if they turn out false the whole thing fails. Assumption mapping is a way of finding those one or two before you've spent months building on top of them.

Kinds of assumption

A long-standing frame from IDEO's design thinking groups risks into three: desirability (do people want it?), feasibility (can we build it?) and viability (can it sustain the business?). Marty Cagan, in Inspired, splits product risk into four: value, usability, feasibility and business viability. Teresa Torres adds ethical assumptions (could this harm anyone?). For a solo creator, a practical list is:

The map

David J. Bland, in Testing Business Ideas (2019, with Alexander Osterwalder), popularized a simple 2×2: one axis is importance (if this is wrong, does the idea fail?), the other is evidence (how much have you actually seen?). The quadrant that matters most is important and unproven. That is where you test first.

Choosing the cheapest test that could change your mind

For each "test first" assumption, design a test: what you'll do, what you'll measure, and what result would make you change course. Write the threshold before you run it, so you can't move the goalposts afterwards. Then pick the cheapest test that could produce that result.

In the wild

• Dropbox demo video2007–2008
  Before the product was broadly available, Drew Houston posted a short screencast showing how it would work, aimed at a technical audience. The beta waiting list grew dramatically overnight, by his own account. The riskiest belief was desirability, not feasibility. A video tested it in days.
• Zappos1999
  Founder Nick Swinmurn tested whether people would buy shoes online by photographing shoes in local stores and buying them at full price when someone ordered. A concierge test answered the viability-of-demand question before any warehouse existed.
• Buffer2010
  Joel Gascoigne put up a landing page describing the product, then a pricing page, before building it, and talked to people who signed up. A two-page fake door tested both desirability and willingness to pay.

Positioning is the context you set so the right people instantly understand why your product matters to them. Define it from the alternatives people use today, what only you do, and who cares most about that, and make the group small enough that you can be the obvious choice for it.

April Dunford, in Obviously Awesome (2019), defines positioning as how a product is the best in the world at delivering some value that a well-defined set of customers cares a lot about. The key word is context. People understand a new product by comparing it to something they know. If you don't choose that comparison, they will, and they often choose badly: your calm reading app gets judged as "a worse Kindle" when it was meant to be "a better notebook for what you read".

The components, in order

Dunford breaks positioning into five components (plus optional relevant trends) and insists on an order, because each depends on the one before:

Two points from Dunford are especially useful for solo creators. First, competitive alternatives are what customers would really do without you, which is often a spreadsheet, a generic tool, an assistant, or nothing (chapter 2's job thinking, again). Second, best-fit customers are not "who could use this". They are the subset who care a lot about your specific value, and who will buy quickly, stay, and tell others. Start there, even if the group feels too small.

Why narrow wins for one person

A narrow niche also makes design easier. Every decision gets a clear test ("does this help readers who write?"), the right defaults become obvious, and you can use the vocabulary of that group. It feels risky to exclude people. In practice, a focused product attracts people from neighboring groups who like its clarity, while an unfocused one attracts nobody in particular.

The "only" statement

Marty Neumeier, in Zag (2006), proposed a blunt test of differentiation: complete the sentence "Our product is the only [category] that [what makes it different]." If you can't finish it without lying, or without "best" and "easiest", you're not differentiated yet. He extends it with who, where, why and when; a compact version for a solo product:

Value proposition, briefly

Alexander Osterwalder's Value Proposition Canvas (2014) is a related tool: on one side, the customer's jobs, pains and gains; on the other, your product's pain relievers and gain creators. It is useful as a check that every feature maps to a real pain or gain. For one person, positioning already does most of this work, so treat the canvas as optional. The headline of your landing page and the name of your category are where positioning becomes visible; designing those lives in Identity & Launch.

In the wild

• Superhuman2017 onward
  Positioned on speed for people who live in email, at a premium price, rather than as "a better Gmail" for everyone. A narrow, demanding group and one unique attribute (speed) made the category obvious.
• iA WriterInformation Architects, 2010
  Entered a market full of word processors by positioning around focus and simplicity for writers, with deliberately few options. Choosing the frame (a writing tool, not a word processor) made the missing features a strength.
• Linear2019 onward
  Positioned as fast, opinionated issue tracking for software teams, implicitly against heavily configurable enterprise trackers. The competitive alternative (a slow, flexible tool people resent) defined the unique attributes: speed and opinions.
• HEY37signals, 2020
  Launched as email with a different philosophy (screening first-time senders, no tracking pixels) rather than as one more mail client. Positioning around a stance attracts the people who share it and repels the rest.

Write a few product principles that settle real trade-offs, and a list of anti-goals that names what you will never become. Aim the whole product at the user's growth in their own craft, not at their attention to your app.

Principles that do work

Most "principles" pages are useless because they state things nobody would argue with: "simple", "delightful", "user-first". A useful principle helps you choose between two good options. The test: would a reasonable product choose the opposite? "Fast over flexible" passes, because many good products choose flexibility. "Easy to use" fails, because no one chooses "hard to use".

The Agile Manifesto (2001) used a form worth borrowing: "X over Y", where both X and Y are good, and you're declaring which wins when they collide. It forces you to name the cost of your choice.

Principles you can see in calm products

Some companies publish principles; for others you can infer them from consistent decisions. The table below is a reading of observable product behavior, not quotations of official documents. Practise this inference; it's a good way to learn taste.

Anti-goals

An anti-goal is something you could do, that might even help in the short term, and that you have decided never to do. It protects your product from slow drift. For a calm product, anti-goals are often the most important part of strategy, because the pressures (growth, engagement, feature requests) all push in one direction.

Saying no

Steve Jobs made the point at Apple's developer conference in 1997, roughly: focus is not saying yes to the thing you're focusing on, it's saying no to the hundred other good ideas. Jason Fried and David Heinemeier Hansson's Getting Real (2006) gave it as a default: start with no; make every feature fight to get in. Des Traynor of Intercom wrote about why product strategy means saying no: each yes adds cost forever, and it adds up quietly (chapter 15 shows how). Derek Sivers' rule, "if it's not a hell yeah, it's a no", is a decent heuristic for a solo creator's roadmap.

Saying no to users kindly is a skill. Thank them, restate the underlying problem, explain your reason in terms of your principles, and, where possible, point to a way to get the job done (an export, an integration, another tool). People respect a clear, principled no far more than a vague "it's on our roadmap".

Make users awesome

Kathy Sierra's Badass: Making Users Awesome (2015) reframes the purpose of a product. People don't want to be good at your tool; they want to be good at what the tool lets them do. Nobody wants to be an expert in a camera's menus. They want to take great photos. Her argument is that sustainable success comes from users getting better at the thing they care about, and talking about that, rather than from users liking your product.

This changes what you measure and what you build. Instead of "how much do they use the app?", ask "are they getting better at the thing they came for?" A writing app asks whether people are writing more and better; a reading app, whether people remember and use what they read. It also changes your marketing: show what users can do, not what the app has.

In the wild

• Basecamp / 37signals2000s onward
  Known for publicly declining whole categories of features and writing about why, in Getting Real, Rework and on their blog. Stating principles in public makes them easier to keep.
• Duolingo vs calm learning appscontrast
  Duolingo deliberately uses streaks and reminders to build habit, and it works for its goals. Calmer learning tools choose the opposite. "Streaks over calm" and "calm over streaks" are both legitimate principles. Pick one on purpose.

A minimum viable product is not a broken first slice of your big vision. It's the smallest complete thing that solves the core job for someone, well enough that they'd be sad to lose it. Each version should be usable on its own.

Eric Ries popularized the term "minimum viable product" in The Lean Startup (2011) as the version that lets you learn the most with the least effort. In practice the phrase got bent into an excuse: ship something half-built, buggy and ugly, and call it an MVP. Users don't experience your roadmap. They experience the thing in front of them, and a half-built thing teaches you only that people don't like half-built things.

Henrik Kniberg drew the clearest picture of the difference in his 2016 essay "Making sense of MVP". If the customer needs to get from A to B, don't build a car one part at a time (a wheel, then a chassis, then a body), because nothing is usable until the end. Build a skateboard, then a scooter, a bicycle, a motorcycle, and a car. Each one gets the person from A to B. Each one teaches you something, and you might discover they'd be happy with the bicycle.

What makes something "viable"

Kniberg suggested replacing "MVP" with clearer terms: earliest testable (the skateboard: does anyone use it?), earliest usable (the bicycle: people choose to use it), and earliest lovable (the motorcycle: people love it and tell friends). The phrase "minimum lovable product" is used in the same spirit: the smallest thing that people don't just tolerate but are glad to have.

For software, "complete and small" means one job, end to end, with quality. A highlights app's skateboard might be: paste in your Kindle clippings file, see every highlight from one book on a clean page, search them, copy one with its citation. No accounts, no sync, no tags, no AI. But the parts that exist are fast, readable and reliable. That's a real product for a real moment. It's also something one person can ship in two weeks.

In the wild

• Instagram2010
  Its founders had first built Burbn, a check-in app with many features, then cut it down to photos, filters, likes and comments for the iPhone. The lovable product was a small, complete part of the larger one.
• Twitter, Basecamp, many indie appsvarious
  Early versions did one thing, with obvious gaps (no search, no threads, no integrations), and the core loop was usable from day one. People forgive missing features. They don't forgive a broken core.

Instead of estimating how long a feature will take, decide how much time it's worth, your appetite, and shape a solution that fits. Fix the time, vary the scope, and remove the rabbit holes before you start building.

Ryan Singer's Shape Up (2019) describes how Basecamp built products. It was written for small teams, but its central moves suit a solo creator even better. The most important is a reversal. Usual practice: design a feature, then estimate it, then watch the estimate double. Shape Up: decide first how much time the problem is worth, then design something that fits in that time.

Appetite

Shape Up uses two sizes. A small batch is a week or two. A big batch is a full cycle of six weeks. Basecamp worked in six-week cycles followed by a two-week cool-down for fixes and exploration. You don't have to copy the numbers, but having a small menu of sizes helps enormously. "Is this a two-week problem or a six-week problem?" is a question about value, and you can answer it from your positioning and research.

Singer also describes a circuit breaker: if a project isn't done by the end of its cycle, it does not automatically get more time. You stop, and decide whether to reshape it and bet again. For a solo creator this rule is gold. It is the cure for the eight-month feature.

Shaping: rough, solved, bounded

Before building, you shape the work: you work out the solution at the right level of detail. Singer says shaped work is rough (not a polished mockup, so there's room to design while building), solved (the main elements and how they connect are worked out) and bounded (it's clear what's out). Two sketching techniques help you stay at that level.

Breadboarding borrows from electronics: a breadboard has the components wired together with no case. In UI terms, you write places (screens, dialogs, menus), the affordances in each (buttons, fields, things the user can act on), and connection lines showing how affordances take you between places. No layout, no visuals. It's the flow, as words.

Fat marker sketches are for when the idea is visual. You sketch with a pen so thick (Singer suggests imagining a broad marker) that you can't add detail. It forces you to stay at the level of "there's a list here, a big field there" rather than choosing fonts.

Rabbit holes and no-gos

A rabbit hole is a part of the work that could swallow unbounded time: a tricky edge case, an unknown technical question, a design decision with many options. Shaping means finding these before you start and patching them: decide the edge case now ("long quotes are truncated at 400 characters with a 'more' link"), spike the technical unknown for half a day, or cut the part. No-gos are things you explicitly exclude from this project ("no tag filtering", "no Windows"), so you don't slide into them mid-build.

Singer's pitch bundles all of this into a short document with five parts: problem, appetite, solution (breadboards and fat marker sketches), rabbit holes, no-gos. For a solo creator, writing a one-page pitch for yourself before each cycle is the single most effective planning habit I know.

In the wild

• Basecamp and HEY37signals
  Built in six-week cycles with shaped pitches, as described in Shape Up, which is free to read online. The method came from shipping real products with very small teams.
• Indie makers adopting Shape Up2020s
  Many solo developers describe using appetite and pitches for themselves, often with shorter cycles (two to four weeks). The numbers flex; fixed time and variable scope is the part that matters.

Prioritization frameworks are tools for comparing options and exposing assumptions, not machines that output the right answer. Learn the four classics, use them as sanity checks, and for a solo product decide mostly with appetite plus conviction grounded in your research and principles.

There will always be more good ideas than time. Frameworks promise to turn the choice into arithmetic. They're useful, in a limited way: they make you state your assumptions (how many people? how much impact? how sure are you?), which is valuable. But with one person, small numbers and fast-changing evidence, the scores are mostly your guesses multiplied together. Know the tools, and know what they can't do.

1 · Impact versus effort

2 · RICE

RICE was developed at Intercom and described by Sean McBride on the company's blog. Each idea gets four numbers: Reach (how many people it affects in a period), Impact (on a fixed scale: 3 massive, 2 high, 1 medium, 0.5 low, 0.25 minimal), Confidence (100% high, 80% medium, 50% low) and Effort (person-weeks or person-months). The score is Reach × Impact × Confidence ÷ Effort. Its best feature is the C: it explicitly punishes ideas you're excited about but have little evidence for.

3 · The Kano model

Noriaki Kano, a professor at Tokyo University of Science, published the model in 1984. It sorts features by how satisfaction responds to them. Its great insight is that features are not all of one kind: some only prevent anger, some scale satisfaction linearly, and some delight precisely because nobody expected them.

For a calm, small product, Kano suggests a strategy: get the must-bes rock solid (data safety, speed, reliability), compete on one performance dimension your best-fit customers care about, and spend a little of every cycle on a delighter. And remember the arrow: delighters decay into must-bes. Dark mode was once a delight; now its absence draws complaints.

4 · MoSCoW

MoSCoW was created by Dai Clegg at Oracle in the 1990s and adopted in the DSDM agile method. Every item in a release is a Must have, Should have, Could have, or Won't have (this time). It's a fine way to cut scope within a fixed appetite: the Musts must fit comfortably, the Shoulds are planned, the Coulds are the first to go. Its weakness is inflation: under pressure, everything becomes a Must. A good rule is that Musts should take no more than about 60% of the appetite.

Why appetite plus conviction

Frameworks were built for teams: many stakeholders, many ideas, a need to make decisions defensible. You have none of that. Your constraint is energy and attention. For you, the next thing to build should be the one you have evidence for (research), that fits your strategy (positioning, principles), that you have the appetite for (time it's worth), and that you have conviction about (you believe in it enough to finish it well). Conviction isn't a whim. It's what's left when your research, strategy and taste agree. Use a framework when you're stuck between two options, or when you suspect you're fooling yourself.

In the wild

• IntercomRICE
  Published RICE as a way for its product teams to compare ideas consistently, with the confidence factor to counter enthusiasm for pet projects. The framework's purpose was discipline in a growing team, not precision.
• Dark mode across iOS and macOS2018–2019
  Once Apple added system-wide dark mode, apps without it quickly drew complaints. Kano's decay in action: yesterday's delighter is today's must-be.

Building a feature is the cheapest part of owning it. Every feature adds maintenance, support, testing, interface space and interactions with every other feature, forever. Value saturates while complexity compounds, so the best products stop early.

Features are visible and costs are not. When you add a feature, you see a new capability. You don't see the next five years of bug reports, edge cases, documentation, onboarding paragraphs, settings, migrations, OS updates, and the small extra weight every user feels when they look at a slightly busier screen. As a solo creator, all of that lands on you.

Why complexity compounds

The visible cost of features grows linearly: ten features, ten things to build. The hidden cost grows faster, because features interact. With n features there are n(n−1)/2 possible pairs that might affect each other: does search include archived items? Does export include tags? Does sync handle the new field? Ten features have 45 pairs; twenty have 190. Settings are worse: every independent on/off setting doubles the number of possible configurations, so ten toggles create 1,024 combinations you could, in principle, need to test.

Less, but better

Dieter Rams' motto "Weniger, aber besser" (less, but better) is usually read as an aesthetic. It's also an economic argument for solo creators: fewer features means more time per feature, which means each one can be fast, reliable and well designed. The products you admire for calm (Things, iA Writer, Reeder, Kindle) are not missing features by accident. Their makers decided again and again not to add.

When you do add, prefer features that remove work or deepen the core job over features that broaden the product. And practise removing: look at your usage data once a quarter for features used by very few people. If a feature serves no best-fit customer and costs upkeep, removing it, with notice and an export path, is a legitimate design decision.

In the wild

• Google Reader to Reeder2013 onward
  After Google Reader shut down, calm RSS readers such as Reeder competed by doing less: excellent reading, a few well-chosen sync options, not every feature a power user might ask for. In a crowded category, restraint is a position.
• Basecamp 32015
  37signals has spoken about rebuilding Basecamp rather than piling more onto older versions, keeping old versions running for existing customers. Sometimes the way to cut accumulated complexity is a deliberate fresh start, with care for those who depend on the old one.
• Big-platform settingscontrast
  Large operating systems and office suites accumulate settings screens few people fully understand. Even with huge teams, every toggle multiplies complexity. With one person, it multiplies faster than you can test.

New users decide in minutes whether your product is worth learning. Get them to a real, personal result as fast as possible, teach in context rather than in tours, use empty states and sample data as onboarding, and ask for commitment (sign-up, payment, permissions) only after they've seen value.

Remember the suck zone from chapter 11. Every new user starts out not knowing your product and not yet trusting it. Their patience is short and their alternatives are a tap away. Onboarding isn't a tutorial; it's the shortest path from "what is this?" to "oh, this is useful to me". Samuel Hulick, whose UserOnboard teardowns made the topic popular, frames it as helping people become successful at what they came to do, not teaching them your interface.

Three terms worth separating

Time-to-value

How long from first open until the person gets something they care about. Measure it in seconds and minutes, by watching real first sessions.

Aha moment

The moment a person feels the value: "oh, it found that quote instantly." It's subjective, so you find it in research.

Activation

A measurable event that marks a new user as having got the value, chosen because it predicts they'll come back: "imported a book and copied a quote in the first session". It's how you count aha moments at scale.

Well-known examples of activation metrics are widely cited from larger companies: Facebook's early growth team focused on users connecting with a handful of friends quickly, and Slack's leaders have said that teams which had exchanged around 2,000 messages were far more likely to keep using it. The specifics don't transfer. The method does: find the early action that best predicts retention, and redesign the first session to get people there.

Empty states are onboarding

The first screen most products show a new user is empty: no notes, no tasks, no highlights. An empty screen teaches nothing and invites the question "now what?" There are three kinds of empty state, and each needs design: first use (nothing yet), user-cleared (they finished everything, which deserves a calm "all done") and no results (a search or filter returned nothing, so help them recover). The first-use empty state is the most important screen in your onboarding, because every user sees it.

A good first-use empty state does three things: says what will appear here, offers the one action that fills it, and, where possible, shows a preview of what it looks like full. Sample data is often the strongest version: the product shows itself working, with realistic content the user can explore, edit and delete.

Progressive onboarding beats tours

The product tour, a sequence of tooltips or carousel screens explaining the interface before use, is the most common onboarding pattern and one of the least effective. People skip them, and those who don't skip forget, because they're learning answers to questions they haven't asked yet. You know why from The Human Mind: working memory is small and learning sticks when it's tied to a goal.

Progressive onboarding teaches at the moment of need: a hint next to the search field the first time the list gets long, a one-line tip after the first copy ("Tip: ⌥Space opens search from any app"), a gentle prompt to import once they've played with samples. Each piece of teaching is small, contextual and dismissible, and it appears because the user did something, not because a timer fired.

Sign-up friction

Every field, verification step and permission prompt before value costs you people. Practical rules: let people try before an account when you can (local-first apps make this easy); ask only for what you need now (email, maybe; name, birthday, company, rarely); prefer passwordless sign-in links or platform sign-in; explain every permission at the moment it's needed, in plain words, rather than asking for all of them at launch. Duolingo is a well-known example: you can start a lesson before creating a profile, and the sign-up arrives after you've learned something.

In the wild

• Things 3Cultured Code
  On first launch it includes a short built-in project whose to-dos teach the app by being done: you learn to complete, schedule and move items by acting on the tutorial itself. The onboarding is made of the product's own content, so learning and using are the same act.
• Duolingo2010s onward
  Lets you choose a language and start a lesson before creating a profile, then asks you to save your progress. Gradual engagement: commitment is requested once there's something to keep.
• Notion2018 onward
  Offers templates and pre-filled starter pages, so a blank workspace is never the first experience. For flexible tools, sample structures teach what's possible far better than a list of block types.
• Superhuman2017 onward
  Famously onboarded new users through a one-to-one session with a person for a long period of its early growth. At small scale, personal onboarding is both the best experience and the best research. Solo creators can do this for their first users.

The shape of your retention curve, not its starting point, tells you whether you've solved a real problem: a curve that flattens means a group has made your product a habit. Your pricing model then decides where commitment sits in the journey, and that changes what your onboarding and interface must do.

Reading a retention curve

Take everyone who started using your product in the same week (a cohort). For each following week, plot the share still active. Every product's curve drops at first: curious people leave. What matters is what happens next. If the curve keeps falling toward zero, you have a leaky bucket: no amount of marketing will build a lasting user base. If it flattens, some group has found lasting value, and your job is to understand who they are and find more of them.

The Sean Ellis question from chapter 7 is a useful companion to the curve: ask the people on the flat part how they'd feel without the product, and what they use it for. Their answers tell you your real best-fit customer and your real job, which are often slightly different from what you planned.

Your pricing model is a design decision

How you charge decides where in the journey people commit, and what your product must prove before that point. It's not just a business choice to make at launch; it changes onboarding, interface and even which features make sense. (Designing the pricing page itself is covered in Identity & Launch.)

Some guidance for choosing. Subscriptions fit products with ongoing costs (sync, servers, AI) or ongoing value (content, continuous updates); one-time purchases fit tools that do a stable job well and run locally. Freemium works when the free tier has real value and the paid line is easy to explain (more storage, sync, team use), and it fails when the free tier is a demo in disguise. Trials suit products whose value appears within days. Patrick McKenzie (patio11), who wrote widely about pricing software as an indie developer, made a long-running case that small software makers tend to charge too little; low prices attract price-sensitive customers and leave you no margin for the time support and quality require.

In the wild

• Ulysses2017
  Moved from paid-upfront apps to a subscription, explaining the change publicly and offering existing customers a discount. The move drew criticism at first. Pricing changes are design changes: communicate them like a feature, with reasons, and take care of existing users.
• Obsidian2020 onward
  The core app is free for personal use, storing plain Markdown files locally; money comes from optional services (Sync, Publish) and voluntary licenses. Charging for an ongoing service (sync) rather than for the core tool aligns price with cost and builds trust.
• Things 32017
  Sold as a one-time purchase per platform, with years of free updates. For a stable, local tool, a one-time price is a clear, calm promise.

After launch, the best research arrives on its own: support emails, feature requests, reviews, cancellations. Collect it in one place, translate requests into problems, count people rather than votes, and close the loop with a changelog that tells people what changed and why.

Launch is not the end of research; it's when research becomes cheap. Real users, with real stakes, tell you what's wrong every day. The danger flips: before launch you had too little evidence; after launch you can drown in it, and the loudest voices will try to steer. A light, regular feedback loop keeps the signal and filters the noise.

Collect in one place

Feedback arrives scattered: email, app store reviews, social replies, community posts, in-app messages, cancellation reasons. Put it all into one simple list (a spreadsheet, a database, a notes folder), with the date, the person, their exact words, and a link back. Make in-app feedback effortless and include context automatically (app version, device, the screen they were on) so you don't have to ask. And reply to everyone personally if you can; for a solo creator, that personal reply is one of your biggest advantages over large companies.

Listen to problems, not solutions

Users are experts on their problems and amateurs at designing your product. A feature request is a solution someone designed for a problem you haven't seen yet. Your job is to find the problem: "What were you trying to do when you wished for this?" Often the problem behind three different requests is the same, and the best solution is none of the three.

Count people per problem, not votes per feature

Public voting boards are popular and tempting. They have two problems: they count solutions rather than problems, and they reward people who campaign rather than your best-fit customers. If you use one, treat votes as a pointer for where to ask questions, not as a ranking. In your own log, tag each piece of feedback with the opportunity behind it (from your opportunity solution tree) and whether the person is a best-fit customer. A problem raised by eight best-fit customers outranks a feature requested by forty passers-by.

Close the loop: the changelog

A changelog is the public record of what you've changed. For a solo product it does three jobs: it tells users the product is alive and cared for; it closes the loop for people who asked (reply to each with a link); and it disciplines you, because writing "why this matters" forces you to know. Linear's frequent, well-designed changelog and the detailed release notes of apps like Things show how a changelog can become part of a product's character.

In the wild

• Linear2019 onward
  Publishes a regular, carefully designed changelog that explains new features with visuals and context. A changelog can be a product surface in its own right, and part of the brand.
• Indie apps' personal repliesa common pattern
  Many solo developers answer every support email themselves, and users frequently mention this in reviews. Personal care is a competitive advantage large companies can't copy.
• Cancellation surveyscommon SaaS practice
  A single optional question when someone cancels ("What made you decide to stop?") gives a steady stream of switch-away stories. Churn is a switch interview you didn't have to schedule. Keep it one question and never block the cancel.

Wrap-up

You started with a picture of a screen. You end with a problem file: a framed problem, jobs and job stories, interview notes and an affinity map, insights and an opportunity tree, an assumption map with a test result, positioning, principles and anti-goals, a shaped pitch, a first-session storyboard and a feedback loop. That file is your product strategy, and it fits on a few pages. Keep it alive; reread it before each cycle.

Practice assignment for the next two weeks

1. Days 1–2. Fill the problem framing canvas (Ex 1.1) and rewrite your backlog as job stories (Ex 3.1).
2. Days 2–3. Rewrite your question list (Ex 4.1), post recruiting messages, and build a 50-row review sheet (Ex 7.1).
3. Days 4–8. Run five interviews, turning one or two into observations (Ex 5.1, 6.1). Debrief within an hour each time.
4. Day 9. Affinity map, three insights, opportunity solution tree (Ex 8.1).
5. Day 10. Assumption map and one one-day test, such as a pre-order page (Ex 9.1).
6. Day 11. Positioning, "only" statement, principles and anti-goals (Ex 10.1, 11.1).
7. Day 12. Skateboard row and a one-page pitch for your next cycle (Ex 12.1, 13.1).
8. Day 13. Fresh-start run, first-five-minutes storyboard, activation event (Ex 16.1).
9. Day 14. Set up the feedback log and the weekly calendar block (Ex 18.1). Reread the whole problem file and write one paragraph: what changed in what you plan to build?

Reading list

• The Mom Test
  Rob Fitzpatrick, 2013 · the shortest, most practical book on customer conversations. Read it before your first interview.
• Competing Against Luck
  Clayton Christensen, Taddy Hall, Karen Dillon, David Duncan, 2016 · the Jobs to be Done theory, including the milkshake story.
• Demand-Side Sales 101
  Bob Moesta with Greg Engle, 2020 · forces of progress and switch interviews from the person who ran them.
• When Coffee and Kale Compete
  Alan Klement, 2016 · JTBD and job stories, free to read online.
• Continuous Discovery Habits
  Teresa Torres, 2021 · opportunity solution trees, weekly interviewing and assumption testing as a habit.
• Just Enough Research
  Erika Hall, 2013 (2nd ed. 2019) · research for people without a research budget, with a sharp chapter on surveys.
• Interviewing Users
  Steve Portigal, 2013 (2nd ed. 2023) · the craft of listening, follow-ups and debriefs.
• Testing Business Ideas
  David J. Bland and Alexander Osterwalder, 2019 · assumption mapping and a library of cheap tests.
• Obviously Awesome
  April Dunford, 2019 · positioning, step by step, with the components in order.
• Shape Up
  Ryan Singer, 2019 · appetite, breadboards, fat marker sketches, rabbit holes. Free online.
• "Making sense of MVP"
  Henrik Kniberg, 2016 · the skateboard-to-car essay. Ten minutes.
• Badass: Making Users Awesome
  Kathy Sierra, 2015 · design for the user's growth, not the product's applause.
• Getting Real
  37signals, 2006 · short essays on saying no, building less and shipping. Free online.
• Fall in Love with the Problem, Not the Solution
  Uri Levine, 2023 · the founder's case for problem-first thinking.

Next: Structure & Interaction turns your job stories into flows, screens and states. When you're ready to test what you build, see Testing & Iteration.