Code Intelligence Platform strategy planning process and timeline
Important tactical note: further specifics for each stage will be added on a rolling basis.
🔄 Kick off by aligning on the “why” | Sep 14 – Sep 30 (2 weeks including Cancun)
Actions
- Cancun workshop (detailed process doc)
- Group async workshop
- Initial understanding of “what is a code intelligence platform.”
- Identify some of the knowledge gaps.
- Synthesis of Cancun workshop into excitement areas and research directions
Roles
- Design: All designers involved together with their product partner, to maximize domain knowledge in this research and synthesis.
- Product: all PMs involved directly in this together with a single shared set of outputs
- Engineering: Key engineers involved with their product partners or with the overall group
Exit with
Initial agreement on a primary definition of “code intelligence platform,” possible competing interpretations worth filtering research against, and specific things we will need to learn more about, as well as a framework for the research in the next step.
Identify and explore specific knowledge gaps | Oct 3 – Oct 14 (2 weeks)
Actions
- Research planning
- Identify further knowledge gaps and specific research questions via asking “what evidence do we have that this is true” of each of our assumptions
- Share a framework for research so that each team isn’t coming up with this from scratch
- Conduct research in domain areas
- Existing market research
- Ad-hoc research
- Positioning
- Reviewing existing resources (e.g. prospect use cases) from the lens of “code intelligence platform” rather than “code search.”
- User archetypes and role from lens of “code intelligence platform” rather than “code search”
Roles
- Design: All designers involved in research together with their product and engineering partners or with the overall group.
- Product: PMs will focus on individual slices of the research we decide, as a team, it’s valuable to do (in order to parallelize this and move faster as a united team).
- Engineering: Key engineers involved in research with their product partners or with the overall group.
Exit with
Research findings and insights from a variety of perspectives that prove or disprove our assumptions on what a code intelligence platform must do to be valuable 10+ times a day for the average developer.
Synthesize platform-focused learning and define “code intelligence platform” | Oct 14 – Oct 21st (1 week)
Actions
- Group workshop (async or sync)
- Synthesize findings together
- We all prepare async synthesis of our research, do 1 round of async feedback, 1 round of sync feedback, and continue async from there.
- This is 1 week because the timeline is entirely controlled by us (limited external dependencies) so we can cover this in 1 week
Roles
- Design: All designers involved in synthesis and definition.
- Product: All PMs involved
- Engineering: Key engineers involved in synthesis and definition.
Exit with
Specific high-level opportunities and insights, specific customer-facing value areas that a code intelligence platform provides – the definition of the “code intelligence platform”.
Align on “code intelligence platform” strategy | Oct 24 - Nov 4 (2 weeks)
Actions
- Strategy workshop (some high level background):
- “What are the steps we need to take to go from our existing product to this vision?”
- (can be multiple paths)
- Here’s where we are, here are our challenges/why we are taking actions, here is what we are doing about it
- How can we achieve each step? What are the risks to each step (or set of paths)?
- Which path do we think is most likely to succeed based on our research so far?
- “What are the steps we need to take to go from our existing product to this vision?”
- Strategy doc
- Define strategy together that meets our definition of “what makes a good strategy.”
- Specific individuals assigned to make final decisions as needed based on input.
Roles
- Design: All designers involved in aligning on the strategy.
- Product: Every PM is an input provider here. If there are any important points where we cannot align as a team/have a distinct split, Joel Kwartler will facilitate Quinn Slack as a decider.
- Engineering: Key engineers involved in aligning on the strategy.
Exit with
A Sourcegraph-wide product strategy to realize the vision. Teams have a shared strategy with ownership / non-overlapping goal areas that realize the Sourcegraph-wide strategy.
Identify goals and problems that need to be solved and in what order of dependency | Nov 7 – Nov 18 (2 weeks)
Actions
- Generative ideation / validation
- What is the full list of viable, feasible, desirable things we can pursue?
- TBD
- Generative technical validation
- What can we do that we couldn’t do a year ago technically, that’s worth exploring in concert with product ideas? (examples that come to mind: SCIP, SSBC / executors, Compute, etc)
- TBD
- Async artifact as outcome
- Define goals together that meet our definition of “what makes a good goal.”
- Identify known problems and subproblems under each goal. Design challenge statements may be an effective format for these to make them actionable.
- Potential Product Advisory Board session.
Roles
- Design: All designers involved in identifying and ordering goals to define the overall roadmap. These goals may be tied to specific feature teams or identified as higher-level.
- Product: All PMs will help map dependencies, and surface any holistic goals that need to be solved by a shared effort.
- Engineering: Key engineer involved in identifying and ordering goals to define the overall roadmap of goals and problems , with a particular focus on known technical problems or known knowns.
Exit with
Collected set of opportunities and unsolved problems that match strategy, and necessary strategy updates. Shared overall roadmap and specific team roadmaps that are specific to the problems to solve in the near term (and less specific in the later term). Also now have a rough product roadmap deck that sales can use.
Begin design exploration, testing, and iteration | Nov 21 - Dec 16 (4 weeks)
Actions
- Kick off two tracks of design efforts (higher-level, foundational and product-feature level).
- Each effort needs its own discovery / delivery process including problem definition, design exploration, technical exploration, prototyping, testing, and iteration.
- Demo tests / strategy tests on first calls.
- Start setting up research calls for mid-Oct and beyond.
Roles
- Design:
- Higher-level track: A small group of ~2-3 designers will focus on the problems in this track. The team will work with transparency and collaboration with the full design and product team and engineering partners should be involved.
- Feature-level track: Existing product feature teams identify specific problems their team is best positioned to solve, and those team’s designers will focus on those problems together with their product and engineering triads.
- Product:
- Higher-level track: A few PMs will work with designers on any higher-level work (e.g., information architecture, interaction model, systems).
- Feature-level track: All PMs working on specific aspects of our strategy.
- Engineering:
- Higher-level track: Specified engineering partners to be directly involved in this to contribute with an engineering perspective and to help in building and validating prototypes.
- Feature-level track: Existing product feature teams to identify specific individuals to contribute with an engineering perspective.
Exit with
No clear “exit,” but rather transition into overall delivery phase by continuing to carry out the iterative design/delivery process. Goals for the strategy and roadmap.