Code Intelligence Platform cross-product owner

Hierarchy of terms

To set up for success in 2023, we need all these steps. But we are not going to try to do any of them at the same time – they need to be sequential.

We will start with ensuring our vision is defined.

Then we will create our strategy.

Finally, we’ll move to specific goals and problems to solve on the roadmap.

Good strategy

We’ve arrived at a good strategy when we have something that is:

1. Focused
   1. Easy to communicate to teammates and to customers
   2. Not trying to be all things to all people, but makes concentrated deep bets
      1. There should be very clear answers to “things we are not going to do”, at the level of detail where we can keep a running list as necessary
   3. Contains only the critical path: if we could still achieve our vision without succeeding at [X], [X] is not part of our strategy
2. Actionable
   1. Teams understand the shared vision and their role in delivering on it, and are all positioned to succeed
   2. We can answer to key prioritization and strategic questions based on our strategy
3. Problem-oriented
   1. It’s clear how we solve the problems preventing our vision from becoming reality
   2. It’s clear how problems are related or dependent
4. Insight-driven
   1. Supported by user research
   2. Supported by data
   3. Solving the right problems
5. Cohesive
   1. The pillars of our strategy relate – we’re not trying to achieve two or three unrelated strategies at once

Good goals

We’ve arrived at good goals when we have goals that are:

1. Iterative
   1. They’re fast to measure and re-measure
   2. The faster/shorter timelines we can set on goals the sooner we know if we’re not on track
2. Specific
   1. Scoped to only the goals/problems needed to achieve our strategy
3. Actionable
   1. We can solve the Drive our strategy
4. Focused on outcomes (not outputs)
   1. Example: As we move to MAU pricing, it’s likely we have MAU metrics as a key KPI in many goals

Good roadmap

We’ve arrived at a good roadmap when it:

1. Is validated to very likely achieve our goals
   1. (We validate our roadmap during this planning period)
2. Matches our timeline
   1. Meaning: a 9-month series of sequential problems (and features, for the nearer-in-time months we’ll build immediately starting Jan 1; it will get fuzzier the further out in time you go)
3. Maps to owners, drivers, and teammates
4. Is publicly shareable with customers (and anyone)
   1. As a result, this means we must also focus on quality, confidence, and storytelling

Product’s role

As we plan this project, there are a few product-related risks to avoid:

• Failure to communicate and collaborate; becoming silos. We have a complex product, and any “platform” vision will involve all of our efforts. We need to ensure we’re not pursuing contradictory goals, features, or visions.
• Failure to operate “at the same level.” We will confuse ourselves if one person is focusing on features/roadmap while another focuses on strategy. We need to maintain a consistent level of fidelity across our efforts and advance to each level (roughly) together.
• Failure to decide, or getting stuck in analysis paralysis. Having deliberate planning time can lead folks to slow decisions and always want to validate “more” before pursuing a path. We can avoid this by keeping ourselves honest (when we’re at enough information to decide), sharing in validation efforts (to get to that level of information faster), and acknowledging that it’s better to make a decision and invalidate it or iterate rather than make no decision at all. We thus want to set specific timelines for each stage of this process.

At a high level, the product team will be involved in some of these ways specifically:

• Owning the timelines and outputs of each stage. The product team owns ensuring we keep to our plan at each stage, whether those outputs are explorations, syntheses, or specific plans (for many of the early stages when we’re all together, this will be Joel Kwartler. As we start to do more independent work to synthesize together each week, every PM will own that.)
• Ensuring we prioritize the most impactful directions. As we discover multiple paths for research and exploration, the product managers will prioritize which we focus on (with design’s input, but product teammates are the deciders), based on inputs like:
  • The use case / job to be done (Desirability).
  • The technical tradeoffs (Feasibility).
  • The alignment to our strategy, business, and overall product (Viability).
  • Product teammates may not own each of those inputs, but they are responsible for collecting them to the fidelity necessary for a decision.

Design’s role:

As we plan this project, there are a few design-related risks to avoid:

• Difficulty planning design resources when problems are unknown. The actual problems to be solved are as of yet unknown. We need to do the research, synthesis, and strategy to define what those problems are, and from there, we will be able to go do actual design exploration, testing, and validation.
• Difficulty validating design directions with a high level of confidence. The nature of Sourcegraph and the problems it solves for users—today and in the future—means many design directions cannot be validated with interactive Figma prototypes alone, but rather need to be prototyped in code (e.g. entirely new whole-product changes like the search home page (vs individual product pages).
• Simultaneously avoiding big-design-up-front and feature silos. There are likely two “tracks” of design:
  • A higher-level track where we rethink the foundation of information architecture, structure, and interaction models to evolve from code search towards code intelligence
  • A product-feature track where teams evolve existing product feature areas to solve newly-identified problems while also integrating with the outcomes of the higher-level track.
  • The higher-level track represents significant design risk (is a dependency for a lot of other design work; reflects a conceptual pivot in a product that customers already pay for in its current form), while product-feature tracks represent less risk, but still a lot of complexity in avoiding feature silos.

At a high level, the design team will be involved in some of these ways:

• Ensuring we use research and validation best practices. The design team and design partners will guide our research methods and synthesis, not just as direct contributors but as advisors to the processes each team pursues.
• Owning design problem definition, exploration, and validation. As we identify problems and opportunities, design will be responsible for making sure that these problems and opportunities are clearly defined and actionable, will drive design exploration, and will plan and lead validation efforts. As we’ll be operating with limited engineering resources, many design directions we take into validation will need to rely on design resources to define and create prototypes.
• Managing expectations and outcomes. At the 3 month mark, we won’t necessarily be executing on high-quality, production-ready design outcomes; instead, we will likely be continuing to prototype and validate, in code, together with engineering. Design will ensure we don’t move our designs too far ahead of engineering so that work is wasted or must be redone.

Engineering’s role

As we plan this project, there are a few engineering-related risks to avoid:

• Failure to involve engineering perspectives end to end. The code intelligence platform effort is a fundamentally cross-disciplinary effort that relies on product, design, and engineering contributions throughout. The overall discovery and delivery phases help us to think about the activities that take place and which domains will be contributing the most—but don’t imply any limitation to specific domain involvement.
• Failure to consider technical feasibility, viability, and problems. This effort represents significant technical risk and validation. We cannot conduct research or define our strategy and problems/goals with only product and design perspectives.

At a high level, key engineers will be involved in some of these ways:

• Providing input on feasibility, complexity and team impact of the directions proposed by product and design.
• Building prototypes for validation, as applicable.