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

Product data

Teams should review and update the product data files monthly, 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

There is also a company-wide glossary of terms we use, the below are specific to the product team.

  • 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 enrollment: Referring to the process of enabling early access for customers or prospects so they can begin using an Experimental or Beta feature.
  • New user 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.

Use case sponsorship

Our use cases help us align our platform, products, features, and roadmap to the most important value drivers for our customers. The use cases are problems that our customers encounter that our product helps solve, and in Product and Engineering we’re building for these scenarios, demonstrating a clear progression of solving our customers’ (and potential customers’) pain points over time. When we talk about what’s coming next on the roadmap, we think about how we’re enhancing the product to better solve these use cases. They provide general alignment and focus that the team is constantly thinking about, across the organization and within our product teams and features. When we package together Sourcegraph’s products like search, code insights, code intelligence, batch changes, notebooks - we’re able to create a cohesive and compelling narrative and solution in a particular use case for the end-user.

To support the ongoing maintenance and improvement of each use case, each can have a designated product, design, and engineering sponsor. That group is responsible for:

  • Working just like a team-based design/product/engineering triad, but with a focus on a specific use case
  • Being a point of contact for people with product, design, and/or engineering ideas/questions about the use case
  • Facilitating flow of ideas to owning teams backlogs as necessary
  • Including designers and researchers as needed to make sure that the features for use cases have a coherent flow and user experience, and that the voice of the customer is properly included.
  • Maintaining the use case strategy pages, including ensuring they are ready for planning. This can include talking to customers, internal teams, stakeholders or other kinds of research. This does NOT include maintaining a use case backlog, but just making sure ideas, trends, and important product/design/engineering concepts associated with the use case are documented on (or linked to from) the strategy page and captured in an actionable format (i.e., RFC, PD).

The assigned sponsors for each use case are listed on the individual use case pages.

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.

Apart from the guidance for specific groups we collaborate with below, we also have a general principle within Product & Engineering of welcoming contributions.

Executive decisions

There are some classes of questions that occasionally require an executive level in order to proceed, usually because they are part of a high level strategic decision or because they require making tradeoffs between different organizations or departments within the company. Some examples of these in the past which have gotten stuck are:

  • Pricing strategy
  • Upgrade strategy
  • Competitive strategy
  • Prioritization across org/department boundaries
  • Decisions when values conflict

The procedure is for the team who needs clarity around any of these kinds of items to write a proposal with how they would like to proceed, which can be added to the executive decision log.

It’s important to keep in mind that, when multiple parties are disagreeing on the path forward, it’s important to lean in with empathy (escalate cleanly) and ensure everyone understands each others views. You won’t always come to an agreement because of different priorities/contexts, but you should always be able to come to a mutual understanding of the trade-offs that you can present together for a decision.

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 on the 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