Build in public with a question worth answering

Recognize the problem?

Useful work. An unclear message.

A stream of commits or optimistic announcements gives people little to respond to. The useful thread is the question you are exploring, the evidence that changed your thinking and the next thing someone can help you understand. Your public story can continue even when a release slips or you choose a smaller scope.

What you will make

Prepare one evidence-backed update, a relevant feedback request and a follow-up record with an owner and review date. You can use the worksheet in any document. Publishing is optional; a useful decision may be to keep the note private or wait for a better example.

What you need

One project, the people you want to reach and the specific task or problem they recognize.
A permitted note, release, screenshot, test or firsthand observation, with its date and original source.
A realistic review budget and clear boundaries for public, private and permission-dependent material.

Step 01

Give the update one useful job

Choose whether this moment should explain a change, ask about a real difficulty, invite a test or report back on an earlier question. Name the relevant reader. A potential user, a fellow builder and a future collaborator may need different explanations. Keep one main invitation so the response will be useful.

Trailnote wants to learn whether a traveler can explain why an item appears in a packing checklist. The next update invites that task, rather than asking everyone whether they like the idea.

Step 02

Keep the evidence and the limitation together

Record what changed and what establishes it. Separate a visible behavior, a proposed explanation and an unknown outcome. A screenshot may establish what the interface shows; it does not establish that people understand it. Preserve the earlier source when the project changes so your next update can explain the difference.

In the fictional example, one reader can find a suggested item but cannot explain its reason. That supports a retest of the explanation; it does not show how all travelers will behave.

Step 03

Choose what is permitted to leave the workspace

Check the exact passage, image or clip you intend to use and its allowed destinations. Keep customer identities, private replies and unrelated context out of the draft. Use sample material when permission is unclear. A public lesson can explain your decision without reproducing the underlying private conversation.

Step 04

Write the change, its meaning and the next question

Give a new reader enough context, show the useful detail, explain why you chose it and retain the limitation. The project voice describes the current behavior; a personal voice can own a changed assumption. Ask about a specific experience or an available task, rather than collecting general praise.

“The sample checklist now explains the reason beside each item. Try one item in the example: is the reason sufficient to decide whether you would pack it?”

Step 05

Adapt to the destinations you already use

Choose the format that lets each audience understand the same evidence: a short update, an annotated image, a demonstration clip or a longer note. Keep destination preferences in your normal settings. Review the time this requires; skip an optional variant if it adds no useful perspective. A weekly review is a working habit, not a requirement to post weekly.

Step 06

Record the response and close the loop

Keep the relevant observation separate from your interpretation. Decide what it changes: the product, the explanation, the next test or nothing yet. Give the next action an owner and review date. At that review, record what actually happened, including no response. When sharing the next update, connect it to the question you opened.

Fictional worked example

The facts stay. The perspective changes.

The starting material

Fictional continuation of Trailnote after the Common Ground hackathon: a sample trip becomes a packing checklist. One fictional reader found the suggested rain jacket but could not explain its inclusion. The team added a reason beside the item and chose to retest it. No real traveler records, live forecast or measured improvement are involved.

The company or project voice

The personal perspective

Make it your own

Evidence → question → response → decision

Copy this into the tool you already use. Fill in what you know and leave unknowns visible.

Project and current status:
Reader and useful job for this update:
Earlier question or promise:

What changed:
Source, date and exact supporting detail:
What this establishes:
What remains unknown:
What stays private / permitted destinations:

Public update: [context → change → reason → limitation]
One specific question or task:
Where the reader can try it, and access checked on:
Owner, reviewer and time available:
Decision: share / revise / hold / keep private

Observed response and date:
Interpretation, separate from the response:
Next action and owner:
Review date:
What actually happened at that review:

Stay faithful to the work

The boundaries to keep.

Common Ground, Trailnote and the observations in this worked example are fictional. They are not customer evidence.
Public reactions, completed tests, product decisions and commercial results are different observations. Silence or missing analytics stays unknown.
This is a manual method you can use today. The public demonstration does not connect accounts, listen to conversations or publish automatically.
The references support the feedback practices; this worksheet and its suggested workflow are Tellshift editorial choices, not a validated growth formula.

Turn progress into a better conversation.

Choose one real question, inspect a work signal, edit a useful update and turn the response into a next decision.

No sign-in required. Progress stays in this browser; nothing is submitted or published. The guided workspace currently uses English. You can prepare content in English or French.

Try the builder journey Build in public