Product Management Process

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

See the Product & Engineering handbook on sharing progress for weekly, monthly, and quarterly steps needed for tracking progress on OKRs and the roadmap.

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

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.

Collaboration

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 & Marketing

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 DRIProduct Management is DRI
Customer-first with orientation towards marketCustomer-first with orientation towards product and engineering
Providing important market context to the roadmapDefining the roadmap
Receives new product info and product updates from product management teamsDelivers new product info and product updates to product marketing team
Responsible for aligning product packaging and messaging with market demandsResponsible for aligning product requirements with market demands
Defines key value props and messaging of new and updated products to sales, marketing, and support teamsDelivers technical aspects of new and updated products to product marketing team
Closest allies are product management, marketing, and salesClosest allies are the development team, customer support, customer engineering, and product marketing

Shared areas of ownership where both teams contribute are:

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

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