Estimation & Ordering
Estimation as decomposition, uncertainty communicated instead of hidden, the riskiest unknown first, and what to build first.
"This will take two weeks" is a feeling about a list you have not written. Break the store into product model, cart, checkout, payment, testing and deployment, estimate each with a range, and the number becomes something you can defend — and revise.
A range you know and a point you say is a lie by rounding. Estimates should carry their uncertainty — what is known, what is assumed, what has not been discovered yet — in a form the listener can plan with, without false precision and without hiding behind "it depends".
When everything is easy except one thing, the one thing decides the project. Prototype the payment integration before polishing product cards — not because payment is most valuable, but because it is the piece whose answer could change everything else.
Dependency, risk, user value and learning value — four questions asked of each piece, and the first vertical slice falls out. One possible sequence for the store, and the other sequences that are also right, and when.