The Product team strives to make the following true:
- The team is working on the most important things (listed in the project roadmap) to execute on our strategy that is moving us forward on our vision.
- Each teammate has the customer and product context needed (about customer problems, likely future priorities, possible solutions, etc.) to perform their work effectively.
- The product vision and roadmap are communicated well to teammates and everyone outside Sourcegraph.
See job descriptions and responsibilities of roles on the Product team:
- The Sourcegraph workflow describes how our product fits into the developer workflow.
- Product metrics dashboard
- Planning - how we do planning and the artifacts we use to plan.
- Delivery plans - how validate the things we build solve user problems.
- Tracking issues - how we keep track of planned and on-going work.
- Prioritizing - how we prioritize work, and how to get things prioritized.
- Tracking user feedback - sources of feedback and how we keep track of that feedback.
Release early, release often
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 customers 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.