• 👋 Hi, I’m Josh Burgess
• ⚙️ I’m interested in building experiences!
• 🌱 I’m always learning new tech, but some of my favorites are Flutter, React, all things Golang, AWS, Argo, and of course Kubernetes.
• 🖥️ Find me helping with CNCF Projects, especially Argo and OpenFeature!
• 📫 You can reach me at [email protected]
• Click to see my Site

According and inspired by PostHog

Good product engineers:

• Ship quickly so they have a fast feedback loop
• Understand the company strategy, and prioritize based on this and what they believe users want
• Can easily propose ideas for what to build
• Make sure the things they've built are being used
• Follow up after they've built something to improve it if needed
• Are good at descoping things and getting products or features into people's hands quickly
• Have users that they're friendly with
• Manage to build things without lots of internal meetings
• Dive deep when they need to, because shipping D might also require solving A, B, and C

Bad product engineers

• Consider research something that takes two weeks rather than two hours
• Can't explain our company strategy
• Can't explain who their product is built for
• Don't know their product's competitors
• Only work on things they've been told to work on
• Don't know the names of any of their users
• Never challenge why they're being told to work on something
• Don't talk to users about what they're going to build, or what they've built
• Don't track if the things they've built are being used
• Spend 6 months on a huge feature before a user can try it
• Never remove features or complexity, often by shipping features that aren't used and leaving them
• Focus on internal alignment over company strategy and what users need
• Wait for someone else to fix an adjacent problem

So, when you ship something:

• Consider what you are trying to learn (if anything, importantly – many things are so obvious like fixing a well-defined bug, you aren't trying to learn anything) product-wise.
• Descope it as much as possible to reduce the cost you incur upfront of building it.
• Judge for yourself if and how to limit brand damage (your options are one or more things like - internal use first, a feature flag rollout, messaging a couple of friendly users, not marketing it or limiting the marketing, or shooting for Minimum Lovable Product instead of Minimum Viable Product).
• Follow up... figure out if / why it is or is not being used and iterate. If you've shipped early, it'll be crappy so will need more work as you figure out what users want.