Product Management

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.

Product process

Keeping strategy up to date

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:

OKR and roadmap tracking

We have a high-level OKR and roadmap tracker (internal only) in GitHub. Each week you should work with your team to update your status and plans. After updating, you should ensure it is reflected in the manually created slide decks which rely on this information:

Weekly (by Friday ):

  • The OKR slide deck which contains an easy to read version of the information in the tracker. This document contains only OKRs at the product/engineering level, not individual org OKRs, and is updated by Product Directors (based on the updates provided by product teams).

Monthly:

  • The PMM roadmap deck (internal only) deck which contains upcoming and recently launched important customer-facing features from the OKR and roadmap tracker. In the future we may transition updating this to PMM, but for now its important product managers are involved in ensuring it is up to date and correct.
  • The Key accounts deck (internal only) contains status information on key accounts. Christina and Kylie own making this update for the product team.

Per-team strategy pages

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.

Product data

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.

Glossary

  • 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.

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.

Communications

Feature roll-outs

Communications around feature roll-out are especially important, and are documented onthe rollout process page.

Talking to customers and stakeholders

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.

Talking about customers publicly

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.

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.

Tools/Templates

References