What shipping products teaches you
Five practical observations about dates, first versions, measurement, release size and memory, written as field notes rather than rules.
Product Desk · Product & design
In this story (5 sections)
General edition. , or use the switcher above.
Shipping is where opinions meet users. These notes collect five habits that tend to survive that meeting.
They are editorial field notes, not a methodology, and they reflect common practice rather than any single team’s record.
The short version
- When a date is fixed, cut scope before quality; rank features by what you’d be embarrassed to launch without.
- Treat v1 as a question asked in public, and make it informative.
- Decide how you’ll know it worked before you build it, and record only what you need to answer that.
- Release small, and write down why you decided what you decided.
A date is a constraint, not a quality level
When a date is fixed, something has to give. The least harmful thing to give is scope. Teams that cut quality to hit a date pay for it in the same release or the next; teams that cut scope usually find the smaller product was the one users needed first.
The practical move is to rank features by what you would be embarrassed to launch without, and to agree that ranking before the pressure arrives.
The first version teaches you the problem, not the solution
A first release is a question asked in public. What people ignore, misuse or ask for next is information you couldn’t get from the specification. It follows that v1 should be designed to be informative, with clear ways to see what happened, rather than merely complete.
“Ship the question, not just the answer.”
Instrument the question before the feature
Before writing the feature, write the sentence that will tell you whether it worked: “If this works, more people will finish X.” Then make sure you can count the people who finish X. Teams often discover after launch that the one number they need was never recorded.
Instrumentation isn’t surveillance. It is the minimum you need to answer your own question, and collecting less is usually better for the people using the product.
Small releases make bugs attributable
When a release contains one change, a regression has one suspect. When it contains forty, the investigation becomes archaeology. Frequent small releases cost more ceremony per release and far less per defect.
Write down what you decided, and why
Six months later nobody remembers why the button is where it is. A short decision note (the options considered, the reason for the choice, what would change your mind) is the cheapest institutional memory a team can buy.
- One paragraph is enough.
- Link it from the code or ticket.
- Date it. Decisions age.
Key takeaways
- 01Agree the “embarrassed to launch without” list before the deadline pressure arrives.
- 02Write the success sentence first, then instrument it.
- 03Keep a one-paragraph decision note for every consequential choice.
Your perspective
A better read starts with knowing what matters to you.
Three quick questions. A publication that adapts to your perspective.
Keep reading
All stories →What does it really take to bring AI into production?
Make four decisions about a hypothetical AI project (scope, data, oversight, rollout) and see what you’d be trading away. A simulation, clearly labelled.
What happens before a good product decision
Framing, evidence, options, trade-offs and a pre-mortem: the unglamorous work that makes a product decision look obvious afterwards. Illustrated with a clearly hypothetical team.
Why promising AI pilots never become real products
A pilot proves something is possible. A product has to keep working. The gap between the two is predictable, and it can be closed before the money is spent.