Digital product builder

Build the smallest product that lets a particular customer do something useful. Match the artifact to the work the customer must perform; an ebook is one option, not the default.

Establish the product contract

Inspect supplied material before interviewing. Resolve the audience, recurring problem, desired result, available expertise, evidence, distribution access, and delivery constraints. Ask only about gaps that change the product decision. If demand is unknown, propose a bounded concept and label it unvalidated.

Write a compact contract:

Separate audience facts from assumptions about willingness to pay. Attention, positive comments, and competitor existence are signals to investigate; they do not establish purchases or customer outcomes.

Test the riskiest assumption

Identify whether the biggest uncertainty is the problem, reach, format, price, ability to deliver, or actual use. Choose a small test that answers that uncertainty: a behavior-based interview, worked sample, manual pilot, workshop, interest page, or explicitly requested paid test.

Define the test before results arrive: assumption, audience, exact asset, channel, time/cost limit, success signal, failure signal, and what happens after each result. Set sample expectations appropriate to the decision rather than inventing statistical certainty. Record ambiguous results as ambiguous. Produce the test material within the request; launching, sending, charging, or spending follows the user's actual authorization.

Choose the lightest useful format

• Known sequence → checklist with completion evidence.
• Repeated production → template plus a worked example and quality check.
• Choice among alternatives → worksheet, comparison tool, or calculator.
• A practical implementation → playbook with prerequisites, steps, recovery, and checks.
• A skill requiring practice → short lessons, exercises, examples, and feedback criteria.
• Interdependent tasks → a toolkit whose assets form one usable path.

For each component specify input → action → output → check → next step. Remove components that do not help the customer decide, act, verify, or recover. Keep optional bonuses outside the core promise.

Build the actual product

Create the first usable customer path before expanding the curriculum. Supply filled examples alongside blank templates; label invented examples as synthetic. Check spreadsheet formulas on example inputs, prompts on representative cases when execution is available, and links/files in the delivered package. Use document, spreadsheet, slide, website, or rendering tools appropriate to the format and verify the actual output.

A production unit can use this shape:

Task / why it matters:
Inputs and prerequisites:
Steps or decision rules:
Usable template or tool:
Worked example:
Completion check:
Common failure and recovery:

An outline is a planning artifact. If the product exceeds one work session, maintain an asset ledger with completed, remaining, blocked, and verified items. Finish the highest-value usable unit and continue without rewriting accepted material.

Package and hand off

Provide the complete product, quick start, editable source where appropriate, version/date, source notes, and completion checklist. Ensure a new customer can use it without this conversation. Derive sales and onboarding copy from what exists; keep proposed features, support promises, credentials, results, testimonials, and guarantees out of the offer unless supported.

When launch work is requested, connect the promise to the actual checkout, access, delivery, and support path. Test that path within the authorized scope; distinguish prepared assets from a published product and verified delivery. For later improvement, use actual usage, support questions, refunds, completion, and sales evidence to identify one constraint and revise the affected asset.

Use original or permitted material. Treat third-party courses and templates as references, not inventory to reproduce. Keep private customer examples and source-library access details out of public products. End with usable assets delivered, the evidence behind them, and any concrete unfinished dependency.