Product Principles are the fundamental values that we use to validate every action, decision, or move the product team makes.
They complement our Product Vision (where we want to go), Product Strategy (what we’ll do) and our KPIs (have we been successful) by outlining how we’ll get there.
We believe that Sourcegraph will be a long-term enduring business to achieve our goal of making it so everyone can code. To support this, we should not build any feature that encourages short-term usage but may have a detrimental impact on our reputation or perception with our users. These include features considered dark or anti-patterns (e.g. default opt-ins, misleading UX) as well as intrusive or disruptive user notifications (e.g. hard to dismiss banners, context-unaware pop-ups etc.).
We believe that our growth will be driven by solving developer’s painpoints and making them more productive. We don’t need to rely on any cheap tricks or “hacks” to drive our business.
Each project, no matter how long-running, needs to plan to ship something in each release. The “something” depends on the project. We strongly prefer for it to be a minimal viable feature that is enabled by default. The next best thing is to ship something that is feature-flagged off by default. When possible, larger features should be merged mid-cycle to solicit feedback from the team and customers before the release is cut. The reason for this is to avoid going for too long without customer feedback (from users trying it) or even technical/product feedback (from performing the diligent work of polishing it to be ready to release). Lacking these critical checks means we will end up building something that doesn’t solve people’s problems or that is over-built.
When we have relaxed this in the past, the results have been bad and the overwhelming feedback from retrospectives has been to release regularly.