FieldworkExplore Fieldwork ↗
Chapter I

Find a problem worth your time.

The beginning is usually quiet: a recurring frustration, an awkward workaround, or something you wish existed. Before you make a plan for the whole company, find one problem you can understand deeply.

Original pixel illustration for the start chapter
How to start · The Fieldwork guide

Choose a problem you understand

Start close to your own experience. Look for a task that people repeat, avoid, or solve with a messy combination of tools. Write down who experiences it, when it happens, and what they do today.

Listen to real stories

Talk to five people who experience the problem. Ask about the last time it happened. What did they try? Where did they lose time? What did it cost them? Let their account lead the conversation.

Choose a narrow first audience

A small, specific group is easier to understand than everyone who might eventually use your product. Choose people with similar needs and a clear way to reach them. You can broaden later, once you know what works.

Write the first promise

Put your idea in one sentence: who it is for, what it helps them do, and why that matters. The sentence is a working hypothesis. Keep revising it as you learn.

End of chapter INext: How to build ↗
Chapter II

Make the smallest useful thing.

A first version is a question someone can use. It does not have to answer every future need. It does need to carry one person from a real starting point to a useful result.

Original pixel illustration for the build chapter
How to build · The Fieldwork guide

Describe one complete journey

Write the input, the steps, and the result before choosing features. Include what someone sees when there is no data, when something takes time, and when a step fails. Those states are part of the product.

Build a version you can finish

Choose familiar tools and a narrow scope. Prefer a complete, modest flow to several impressive fragments. Keep sample data visibly separate from real data, and make every primary action do something honest.

Watch someone use it

Give a person a goal without explaining every control. Watch where they pause, what they expect, and whether the result makes sense. A successful build command is useful evidence, but it does not show that the experience works.

Release a small, recoverable version

Check the deployed result, including reloads, links, narrow screens, and the main failure state. Keep a known working version and a clear way to undo the release. Then ask the next user to try the same journey.

End of chapter IINext: How to grow ↗
Chapter III

Find the people who need it.

Growth begins with understanding where your audience already looks for help. Be useful in those places, tell a concrete story, and learn from what people actually do.

Original pixel illustration for the grow chapter
How to grow · The Fieldwork guide

Tell one specific story

Show a person, a problem, and a better outcome. Use a real example when you have permission; otherwise label an illustration clearly. Let the product demonstrate the value instead of relying on broad claims.

Choose one channel to learn

Start where your first audience already spends time: a relevant community, a newsletter, a search query, or a direct introduction. Choose one channel and one audience long enough to learn something meaningful.

Make the first message useful

Explain why the message is relevant to this person. Keep the request small and specific. Ask for a conversation or offer something useful rather than assuming they are ready to buy. Review every message before sending.

Measure interest honestly

Track what happened with a denominator and a timeframe. Five replies from twenty relevant introductions means something different from five replies from thousands. Record the learning, including results that did not support the idea.

End of chapter IIINext: How to scale ↗
Chapter IV

Make good work repeatable.

Scale the parts that already help people. A little structure can protect quality, keep context available, and give a growing team room to make good decisions.

Original pixel illustration for the scale chapter
How to scale · The Fieldwork guide

Write down the recurring work

Describe the input, the steps, the owner, and what a good result looks like. Include the exceptions and the point where someone should ask for help. A useful process makes judgment easier instead of removing it.

Keep consequential decisions visible

Identify the actions that need a person to review them: public communication, spending, access changes, or irreversible updates. Make the pending decision and its consequences clear before the action happens.

Choose metrics that reflect value

Measure whether customers reach the outcome they came for and whether they return. Use a small number of measures with clear definitions. A rising activity count can be distracting if the underlying experience is getting worse.

Find the next real constraint

Look for the step that most often slows down a useful result. Improve that step before adding another tool or process. Sometimes the best next move is to remove a handoff, simplify a decision, or stop work that no longer helps.

End of chapter IVBack to the beginning ↗
Explore the resource library ↗