The job of the product team is to provide clarity:
- Clarity about what we’re building
- Clarity about who we’re building it for
- Clarity about why we’re building it
- Clarity about who the company is and how it expresses itself
- Do fewer things but do them better
- Multi-quarter outlook
- Continuous improvement
- Developer-centered design
- Painkillers > Vitamins
Instead of trying to “peanut butter” the product team across all of the products, doing all of them badly, we’re going to focus on the highest priority items and do those well. If other projects suffer due to lack of Product team involvement, that will be a good signal to hire.
We’re going to pick the best direction we can based on the information we have and then adjust (not u-turn) along the way. With a solid product strategy in place, even a lightning strike like ChatGPT turns us towards the fun but doesn’t upset the apple cart.
That’s not to say that we’re always going to be right. As we have new data, we’ll need to adjust our strategy. When we do so, we’ll do it with the least amount of disruption to our teams and to our customers as possible.
In the old days of Microsoft, it was well known that the v3 of any of their products was the first good one. v1 was half of the original scope, v2 was the other half and v3 was the first version that actually took customer feedback into account, whether it was from metrics, surveys, bug reports, feature requests, sales, face-to-face meetings, A/B tests and data analyses, etc.
If we never get to the version that takes feedback into account, then we never get to the good stuff! Our job is to put our best ideas into our products and then use customer feedback to make them better over time.
If you prefer, Scott Guthrie, a Microsoft VP well known for his shotgun product demos, used to say that his job was to “eliminate the red,” which was his way of saying first, understand the pain customers are having and work to remove it, making way for the next set of pain points and so on.
The overall goal of our products is to empower developers and enhance their productivity. To achieve this goal, we collaborate closely with our developer teammates during all stages of the design process and we continuously gather feedback from both internal and external developers as we test the results of our efforts.
As an example, the following is a set of Cody scenarios that are like vitamins in that you know they’re good for you, so you take them when it’s convenient:
- Increase code coverage
- Suggest merge conflict resolutions
- Chatting with Confluence, your wiki, your docs
- Asking for commentary on your metrics dashboard
- Monitor your logs for potential problems
Vitamins are not as powerful a motivator as painkillers, which are problems that must be solved:
- Suggest a fix for a critical bug
- Speed up the implementation for a critical feature
- Find software license violations
- Patch a security vulnerability
- Find the crash reported in your logs
- Explain a large, undocumented code base
We should focus on pain killers over vitamins to provide maximum values to our customers.
The product team is led by Chris Sells, our Head of Product (and temporary PM VS Code) and consits of several teams focused on crafting amazing tools for developers:
- Kevin Chen - Product Led Growth
- Ryan Phillips - Cody Strat, Sourcegraph Platform and Code Search
- Taylor Sperry - Cody Clients
The design team’s missions are to ensure the software we ship is powerful, usable, accessible and delightful, to be the voice of the developer, and to create a differentiated, inspired and trustworthy brand.
Learn more about the design team and their process in the design team section of the handbook.
- Ryan Phillips - TPM Manager
- Kalan Chan
- John Wesonga
Product will achieve clarity by understanding the goals of the business and by listening to our customers. It will drive clarity by producing a number of outputs. While this isn’t a complete list of things you’ll see come out of the product team, you can count on us for at least the following:
- Product Requirements Documents (PRDs)
- Product designs
- Brand designs
- User research (both evaluative and generative)
- User feedback via metrics and surveys
- Schedules, task lists, etc.
The product managers (PMs) are trained to listen to our customers and turn what they hear into proposed requirements at a scope that’s appropriate for driving the creation, shipment and maintenance of our products over time. Those requirements will be communicated via a Product Requirements Document (PRD).
A PRD will contain details about our goals for a specific product or feature, the target customers, the supported user scenarios and features, along with priorities, metrics for success and a schedule laid out in a set of launch milestones. This will form the product plan for a specific product as well as be a parent document to provide references to additional resources, like eng designs and/or RFCs, product design artifacts, detailed schedules and task lists, etc.
PRDs will be reviewed by interested stakeholds and driven by the PM associated with that work, but the PRD’s approval will come from the EPD of the related product team, i.e. the Engineering, PM and Design leads for that team.
PRDs help us to drive towards our company’s product goals as set up in the Product Strategy document (pending), which will also be drafted by the product team and updated as appropriate based on employee feedback and new data.
The PRDs will also be used to lay out a high-level multi-quarter roadmap (pending).
Product design and user research will produce artifacts as required to satisfy the needs of the product development process. This may include user personas, user journey maps, wireframes, prototypes, mockups, user flows, storyboards, high fidelity designs and other documents that help improve communication around intended product features.
Brand design will produce design artifacts to meet the needs of marketing, internal comms, people ops, and sales. These artifacts might include, brand and logo development, web design, slide decks, ads, print ads, swag, trade show booths and other collateral and assets. These assets will convey the company’s value, mission, and personality across all touch points. They will elevate Sourcegraph in the eyes of the viewer and contribute to a memorable brand experience for every viewer.
Technical Program Managers (TPMs) manage schedules, assignments, and processes to ensure that customers receive new features seamlessly. Serving as partners to the feature teams, TPMs clearly outline and document the dependent elements of cross-functional projects. They act as the heartbeat of an organization, guaranteeing that every participant in a cross-functional project meets their deadlines and maintains high standards of quality.
To ensure that product and engineering work well together, we’ve gathered some principles and pointers together in this non-exhaustive but hopefully illustrative section.
Each product team has its own EPD triad (Engineering, Product and Design) to lead the product over time, ensuring that both departments are in sync. That team will be used in conjunction with the eng management structure to handle various common scenarios:
- Bring the work to the EM Sync Meeting
- Should we do that work? No? Bail.
- Find the team that should own that work
- Can it fit into the work for that Q?
- Yes: do it!
- No: What do we cut?
- Q: Should we do that work? No? Bail.
- Q: Does it fit into the work for that Q?
- Yes: do it!
- Q: What should I cut?
- “Let me take that to my manager and get back to you.”
Often we’ll be driving towards scenarios that cross multiple engineering teams. To ensure the success of that work, we’ll adopt the following broad processes:
- Product defines cross-team scenarios and features in their PRDs
- TPMs track dependencies between teams
More engineering team specific details here.
As per the product-focused planning process, product teams propose work based on each Q’s goals.
Rule #1: Make no promises about the dates of future functionality. Work with product and marketing on how best to message the vision of the future via the sales process and public communication.
Rule #2: Practice this phrase: “Thank you for your feedback.” Don’t use harsh or dismissive language with our customers, potential customers or random people in the street when you’re representing Sourcegraph.
Rule #3: Don’t mention our competitors by name publicly; we don’t want to give them the airtime.
Rule #4: Use kindness and respect when discussing competitors with our sales customers. Dissing our competitors doesn’t make them look bad, it makes us look bad. Instead, encourage our customers to publicly share stories of how they think about us relative to our competitors. Their stories are 10x more powerful than ours.
Rule #6: Not every customer is a good fit for everything we’re doing. There’s no reason to let a customer know about any feature, program, opportunity unless it’s something we can offer them. If they know and don’t get to participate, that just leads to hurt feelings.