How to create your first digital product
Scope, build, test, and package a first digital product that a real person can use without your help.
Define a task you can prove the file completes
For a first product, choose a small outcome with a clear pass or fail. Here is a complete example: a shared-expense spreadsheet that tells two housemates who owes whom after each person pays different bills.
The scope is two people and configurable expense splits. Bank connections, receipt scanning, and multi-currency conversion are outside this first version. That boundary keeps the product testable.
Build the inputs and the result first
Use columns for description, amount, who paid, and Alex’s percentage share. Sam’s share is the remainder. Calculate each person’s total paid and total allocated share.
Label the cells the user may change. Apply validation to payer names and percentage shares, and protect formula cells where the chosen software supports it. Put the settlement result in one visible place so the customer does not need to interpret several totals.
Test with numbers whose answers you already know
| Test input | Correct settlement | Failure it can reveal |
|---|---|---|
| Alex pays $60; equal split | Sam owes Alex $30 | Basic allocation error |
| Alex pays $60; Alex’s share is 70% | Sam owes Alex $18 | Unequal split error |
| Alex pays $60; Sam pays $20; both equal split | Sam owes Alex $20 | Payment and share totals mixed up |
| Add a blank row | Settlement is unchanged | Empty values breaking formulas |
| All entered amounts are zero | Nobody owes anything | False debt or divide-by-zero behaviour |
Reject negative expense amounts in this version rather than silently treating them as refunds. Test what happens if a user pastes data into a field with validation. A dropdown alone does not prove that invalid input cannot reach the calculation.
Test the exact file you will deliver
Give a clean copy to someone and ask them to enter two expenses and identify the settlement. Do not explain the screen first. If they edit a total instead of an input, change the labels or protection; adding a longer manual may not fix the interface.
Open the file in every application you claim to support. Do not advertise broad compatibility from a test in only your own software. Check the delivered copy again after removing sample data.
Package only what makes the task work
Include the clean spreadsheet, a short instruction sheet explaining the inputs and settlement sign, and a separate worked example. Give the file a version label. Keep your test table with the master and rerun it after formula changes.
The product is ready when a new user can reach the correct settlement without your help and all specified tests pass.
Design the workbook so the user cannot mistake the result for an input
Put instructions next to the editable cells. Use a consistent fill for inputs, a different treatment for calculated outputs, and a short key explaining the difference. Colour alone is insufficient: label the input area and result in words.
In the expense example, make the payer field a choice between the two configured names. Keep Alex’s percentage as an explicit input and derive Sam’s percentage. Asking the user to enter both shares creates another error: they could add to something other than 100%.
The result should name the payer and recipient, not just display a positive or negative number. “Sam owes Alex $20” is easier to use than “Net: 20,” especially for someone who has not read the instructions.
Define what happens to invalid input
A robust first version needs a response for inputs it does not support. Decide whether blank means unused, required, or unknown. A blank payer with a non-zero amount is incomplete data; silently assigning it to someone produces a convincing but incorrect answer.
| Input condition | Response to define |
|---|---|
| Amount entered with no payer | Flag the row and exclude it from a final settlement until corrected. |
| Alex’s share exceeds 100% | Show an invalid-share message. |
| A negative amount | Reject it in this version; refunds are outside the defined scope. |
| Text pasted into the amount column | Flag it rather than treating it as a valid expense. |
| No expenses entered | Display a zero settlement with a clear empty-state message. |
Describe these rules in your own implementation and test them. Validation, protection, and error messages are separate mechanisms. Protection may prevent editing a formula; it does not establish that the remaining inputs are meaningful.
Build a short test protocol for another person
Give a tester a clean copy and this task: “Alex paid $60 for groceries; Sam paid $20 for a shared bill. Split both equally and tell me who pays whom.” Watch where they click and how they interpret the result.
Next, ask them to change one expense to an unequal split and then delete a row. These actions test the normal workflow, an alternative rule, and a correction. Do not coach them through the interface unless you are recording the point where assistance became necessary.
Write down the error, its cause, and the revision. “User confused” is too broad. “User edited the total because the input area was not labelled” tells you what to change. Rerun the task after the revision.
Check compatibility in the delivered version
Choose which spreadsheet applications the product supports. If you export from one application to another, test formulas, dropdowns, number formats, protection, and instructions in the exported file. A spreadsheet can open successfully while some behaviour changes.
Confirm currency display and decimal handling. A cell displaying two decimal places can still contain more precision, so define where rounding occurs. Reconcile the two net positions after your rounding rule; they should balance under the model.
Test a fresh download or delivery copy, not only the master in your own account. Shared permissions, local links, or hidden sample data can make those versions behave differently.
Make the handover small but complete
Package three clearly named components: the clean workbook, a one-page start guide, and the worked example. Tell the buyer which file to open first, where to enter data, how to read the result, and which uses the workbook does not support.
Keep a version number and a simple change log. After a formula change, rerun the full test set instead of checking only the case you just fixed. A correction can accidentally break a different split or empty-state rule.
Do not add bank importing or refunds until the core settlement works reliably. Extra features widen the test surface and the instructions. A first product earns trust by completing its stated task accurately.
