Shipping Philosophy

Use the absolute lowest number of steps, stages, artifacts, stakeholders, and approvals you can get away with. Never add process or guardrails to fix a problem that you wouldn’t have if you’d hired better.

How you work is at least as important as what you build, because the former directly shapes the latter. Use excellent tools you find inspiring. Use Retina displays so you can actually tell if something is aligned. Pay for the extra NewRelic seats so PMs can read logs too. And just say no to Microsoft slop.

If you can’t easily get code to prod in minutes - not hours, days or weeks - after its tests are green, fix that first.

Then (and only then) can you embrace an effective product loop: ship something small, track its impact directly from the database, and repeat until you’ve delivered something that makes a difference.

You have no idea what your market, competitors, growth, adoption, or team will look like in a couple years. Why pretend?

Keeping a long roadmap (or backlog) just sets bad expectations. Your users hear about something you’re planning for the future, want it, and immediately feel like it’s late. You made them unhappy with your current product for no reason.

Internal teams like support and sales get used to hearing “it’s on the roadmap” as the go-to product response, used in order to avoid a short-term commitment. That builds the expectation that the response to every suggestion is “yes”. It should obviously not be.

Have conviction about the direction your product is going, and the next couple problems you want to solve for your users. That’s enough!