This page contains information that is relevant for how to do well at your job as a product manager. For information that is relevant to the whole company, including all product managers, check the index at the product home page.
- Planning process - how we do planning and the artifacts we use to plan.
- Pricing - how we decide what tier a feature goes in/how much an add-on feature costs.
- 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 & stakeholder feedback - sources of feedback and how we keep track of that feedback.
- Responding to user feedback - how we respond to user feedback for the feedback channels the product team owns.
- Feature rollout - how we test, rollout and launch new features.
- Learning - how we learn from what we shipped.
- Feature deprecation - how we deprecate features when necessary.
Sourcegraph has a top-level strategy page that describes at a high level where our product is headed and why. Everyone contributes to this page, and it’s important to be familiar with its contents. In addition to this shared content, each team has a set of non-overlapping sources of truth that they should review and update regularly:
See the Product & Engineering handbook on sharing progress for weekly, monthly, and quarterly steps needed for tracking progress on OKRs and the roadmap.
We also use per-team strategy pages as a narrative framework for prioritization, to document trade-offs between goals, and to communicate strategy outwardly. Because this is a longer outlook, they tend to not change much each month but should be reviewed. Be sure to @ mention your engineering, design, product marketing, and any other important partners for feedback in your monthly update PR.
Engineering should feel empowered to bring up that they feel strongly about in conversations with product. We want to push decisions down to people closest to those problems. It is product’s responsibility to help give insight into customer pains and feedback, strategic priorities, and to ensure consistency across the product.
We ask that teams leverage the Strategy page template when creating and updating content.
The last thing teams should review and update monthly are the product data files, in particular the features.yml in case the feature has reached a new maturity, delivered new code host compatibility, or otherwise updated any information displayed on the automatically generated product team and feature reference pages.
Part of the product data is a (internal-only) list of what’s supported, which contains extended product information for our Sales and Support teams. This should also be manually reviewed and updated as feature capabilities evolve.
- Product priorities: An ordered list of problem statements or outcomes that product has evidence is important
- Roadmap: The tasks and timeline for when each will be worked on
- Backlog: The ordered list of items to be tackled after items on the roadmap are complete
- Department: A top-level organizational unit of people, such as Sales, Product or Marketing.
- Org: A mid-level organizational unit of people, such as Code Graph, Enablement, or Cloud. Note that an org does not necessarily represent a coherent product area that exists in the product, it’s an internal team.
- Team: A well-defined product team that works to deliver features for one or more product areas.
- Product Area: A loosely defined collection of features or capabilities that may be worked on by one or more teams.
- Developer onboarding: Referring to the use case of “developer onboarding and velocity,” where a new developer joining a company is able to quickly understand and become productive in their new company’s codebase.
- (Early Access / Beta) enrollment: Referring to the process of enabling early or beta access for customers or prospects so they can begin using a product feature.
- First experience: Referring to the user journey of a new user of Sourcegraph in and around the product.
Launch tier levels (L1, L2, and L3) are also an important term to be aware of, and the definitions as well as process/source of truth are documented on the marketing launch page.
Product Management collaborates with a lot of different groups. Beyond our shared work as a team value, there are some teams where collaboration is especially important and where roles and responsibilities can be unclear. To help clarify this, we have documented high level practices around how we work together.
Product Management and Marketing must work closely together to successfully create and launch products. Because of this, it’s important to be clear on what the shared and unique responsibilities are within the working relationship.
|Product Marketing is DRI||Product Management is DRI|
|Customer-first with orientation towards market||Customer-first with orientation towards product and engineering|
|Providing important market context to the roadmap||Defining the roadmap|
|Receives new product info and product updates from product management teams||Delivers new product info and product updates to product marketing team|
|Responsible for aligning product packaging and messaging with market demands||Responsible for aligning product requirements with market demands|
|Defines key value props and messaging of new and updated products to sales, marketing, and support teams||Delivers technical aspects of new and updated products to product marketing team|
|Closest allies are product management, marketing, and sales||Closest allies are the development team, customer support, customer engineering, and product marketing|
Shared areas of ownership where both teams contribute are:
- Pricing and tiering/packaging
- Market research, including personas, ideal customer profiles, etc.
- Competitive positioning and analysis
- Go to market planning
- Customer communications
Since we have the same goal of launching products that drive adoption and revenue, we don’t experience a lot of conflict over the shared ownership. When we do, though, we use the clean escalation process to get to the best decision.
Communications around feature roll-out are especially important, and are documented onthe rollout process page.
In general, product team members are empowered to communicate directly with customers and stakeholders. Sometimes it can be helpful to have someone review your communication before sending it, especially if it is going to a wide or unfamiliar audience. If you want, the Marketing and PR teams are available to help any time: simply ask in #marketing and someone will be happy to review your communication.
There are just a few places where a review is required; these should include your product director and someone from the marketing team:
- Release posts/blog posts (review process already includes this, so nothing special to be done here)
- Social media using the official accounts, including YouTube
- Public presentations/events/speaking engagements
- about.sourcegraph.com site updates
- Updates on pricing/packaging changes
- Updates on feature deprecation
- Speaking to press
Unless the change is extremely wide in impact (a large about site update, a major press outlet, or a major pricing change), you do not need to continue blocking on marketing or product director review after 3 full business days have passed from the review request.
When talking about customers publicly, we can use the process for linking to customer or prospect names in public places to do this in an anonymous (to non-Sourcegraph users) way that still links everything together for us.
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.