Alchemy PRD

PRD for GPT-powered Alchemy Build Feature

PRD: GPT-Powered Tools for Alchemy Build

Project Data

Explore

PRD: GPT-Powered Tools for Alchemy Build

Alchemy Interview Project

Linda

Project:

Private embeds

⁠

EDIT INFO

⁠

TL;DR: GPT-Powered Tools for Alchemy Build

Status:

@In progress

⁠

Shipping: 6/4/2023

⁠

Problem Alignment

The Problem

Describe the problem (or opportunity) you’re trying to solve. Why is it important to our users and our business? What insights are you operating on? And if relevant, what problems are you not intending to solve?

One of the greatest challenges for developers is debugging code. Even minor errors can take hours to find, especially in complex codebases, which often results in reduced productivity. Based on user feedback and industry research, the need for a more efficient debugging tool is apparent, and Alchemy Build is uniquely positioned to address this gap. By providing a GPT-powered code debugging feature, we can significantly decrease the time developers spend on debugging and increase their overall productivity, leading to enhanced user satisfaction and, consequently, increased adoption and retention rates.

High-level Approach

Describe briefly the approach you’re taking to solve this problem. This should be enough for the reader to imagine possible solution directions and get a very rough sense of the scope of this project. (e.g., if “The Problem” was engagement in the design process from non-designers, “The Approach” might be a feed which surfaces work that's relevant to them.)

Our approach leverages the advanced natural language processing capabilities of GPT-4, which can parse and understand code just as well as it can comprehend human languages. The feature will inspect the code, identify potential errors, and suggest fixes to the user, reducing debugging time. It will be able to handle various programming languages and will be designed to integrate seamlessly into the existing Alchemy Build workflow.

Goals & Success

What does success look like? What metrics are you intending to move? Explain why these metrics are important if not obvious.

Success for this feature includes a reduction in the average debugging time per user, increased user productivity, and a rise in user satisfaction levels. Key metrics include user engagement with the debugging feature, time saved per debugging session, and overall user activity on Alchemy Build. These metrics are important because they directly indicate the efficiency and effectiveness of the feature and its impact on our users' work.

⁠

Solution Alignment

Key Features

Give an overview of what we’re building. Provide an organized list of features, with priorities if relevant. Discuss what you’re not building (or saving for a future release) if relevant.

Code Inspection: The feature will scan through the user’s code to identify potential errors or bugs.

Error Highlighting: Potential errors or bugs will be clearly highlighted in the user’s code.

Suggested Fixes: The feature will provide users with suggested fixes for identified errors or bugs.

Multi-language Support: The feature will support debugging in multiple programming languages.

Integration with Alchemy Build Workflow: The feature will be seamlessly integrated into the current Alchemy Build workflow.

Key Flows

Show some mocks/embeds of the experience. Link to any other documentation as necessary. In general, it’s helpful to organize these around certain user journeys / use cases. Show enough of a clickthrough where people can walk away with a reasonable understanding of how the product works.

Embed example:

⁠

⭐️ Now you can embed private Figma files, too!

Open Issues & Key Decisions

Keep track of open issues / key decisions here. Sometimes, certain decisions are made that might feel controversial; document these here so people know that the discussions have happened and there’s strong awareness of the tradeoffs.

⁠

Launch Readiness

Key Milestones

Identify any relevant milestones (e.g., a Dogfood or Beta milestone) that people should know about. Make sure to show when you’re expecting to publicly launch, too.

Date

Milestone

Audience

Description

Mon, May 4

Dogfood 🐶

Internal employees only

Testing internally

Mon, May 11

Beta 👥

Early cohort of 100 customers

Getting user feedback

Tue, May 19

Launch! 🚀

Gradual ramp over the day to 100% of all users

It's the big day!

There are no rows in this table

⁠

Launch Checklist

Make sure you answer all of the questions below and involve necessary stakeholders.

Area

Question

Answer

Instructions if "Yes” (or unsure)

Support

Will new learning material be needed (or updates to existing documentation)? Help Center articles? Images/GIFs? YouTube videos? Plugin documentation?

Yes

Talk to the Product Education team.

Will this feature require new support processes, like saved replies, new tags to track feature changes, or training the support team on new products/changes?

Talk to the Support team.

Growth & Data

Have you implemented sufficient tracking in order to measure success, risks and impact on user behavior for the new feature?

Involve your data counterpart to make sure feature is well instrumented.

Could this impact Growth numbers? (E.g., impact to NUX, UI changes to CTAs.)

Let the Growth team know. Consider running this as an A/B if you haven’t already.

Are we turning this feature on for everyone immediately (versus a gradual rollout)

Defend in this section why you’re opting for an instant ramp to 100%.

Marketing

Are we running a Beta for this?

Talk to the PMM team.

Do we need an onboarding experience?

Talk to the PMM team.

Enterprise

Will this be available only in certain tiers (Pro or Org)?

Make sure the Enterprise team is in the loop and have good reasoning for your packaging decisions. In addition, if this is to be included in sales enablement material, talk to your PMM.

Is this a new action that should be included in the Activity Logs?

Talk to the Enterprise team.

Platform

Are you introducing new functionality that we’d want to add to our Web or Plugin APIs?

The general expectation is that the feature team builds these capabilities into these APIs. Talk to the Platform team if you have questions.

Could this break any existing integrations (e.g., with Zeplin, JIRA)?

Talk to the Platform team.

Will this introduce new work on mobile or mobile web?

Talk to the Prototyping team.

Security & Privacy

Are you introducing new data models, or exposing new API end points? Or are you changing anything to do with Authentication, Sign in, or Sign up? Is data flowing to a new vendor or outside of Figma prod ?

Talk with the Security team.

Are we collecting any data that we did not already, or are we using any data in a manner that we did not already use it in?

Talk with the Legal team.

⁠