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.

Other teams at your company hear you say “sure, that’s on the roadmap” (probably in an effort to get out of committing to something), but really they get used to all of their requests defaulting to “yes, but later”. This gets translated in their minds to “I expect a yes every time”, which is also bad.

Have conviction about the direction your product is going, and the next couple problems you want to solve for your users. Thinking more about those problems than features you want to ship keeps you much more flexible than those one-off requests you promised three quarters ago. It’s better for you users and your sanity.