A two-week product discovery and build log template

A short build log can help a founder keep a product experiment focused. It should show what was decided, what was tested, and what remains unknown. It should not turn a calendar into a promise of paying customers.

This revised article provides an illustrative two-week planning window. It is not a verified account of a historical launch. The earlier first-customer narrative has been removed because the supporting evidence was not established. The original URL and publication date are retained.

Before the window begins

Choose one user and one task. Confirm that the people needed for feedback are available and that you have permission to use the required data. If the task involves sensitive information, payments, or complex permissions, the necessary review may extend beyond this example window.

Write the experiment's question. An illustrative question is whether a program administrator can invite a member and help them find the first required activity without explaining each screen.

First working week: test the journey

Begin with a sketch or prototype that lets you inspect the complete path. Record where a person gets stuck and which assumptions the feedback challenges. Avoid using a polished prototype as evidence that the underlying system is ready.

When implementation is appropriate, build the smallest path that supports the experiment. Include error states relevant to that path. An invitation flow needs an answer for an expired invitation, not only a successful one.

Keep a daily record:

• The decision made and why.
• The evidence inspected.
• The uncertainty still open.
• The next action.
• Features deliberately deferred.

Second working week: examine the limits

Try the difficult cases and review the operating responsibilities. Check permissions, missing information, interrupted actions, and the route to support. A test with one cooperative user will not reveal all of these.

Write down what is ready for further evaluation and what is not ready for production. If the result fails the agreed criteria, use the log to explain the next change or the reason to stop.

Separate product evidence from commercial evidence

A completed task demonstrates something about usability or functionality. A booking click demonstrates interest in a next step. Neither is revenue. Record actual purchases and customer outcomes only when they occur and can be substantiated.

The Valori case study is separately labeled founder-built product work. This template does not borrow its history or results.

For a broader scope, use the custom application guide. Application Development is estimated after discovery; this example window does not establish a delivery commitment or a package price.