Project Management
This section of the wiki provides an overview of our end-to-end project management lifecycle, from customer feedback all the way to shipping features!
There are several distinct stages of the entire process.
Feedback from customers comes in continuously from multiple sources. We have meetings with customers, we receive emails from customers, customers post on GitHub or StackOverflow, etc...
We aggregate all of this feedback into productboard. Our productboard is a private tool not open to the public (since meeting notes and feedback from customers may have private data). We link this feedback up to requests within productboard so that we can always view how many requests a feature has.
While the feedback stage happens continuously (including during the planning stage), planning and shipping happens in more of a waterfall sequence.
| PM or dev | Tool used | Task |
|---|---|---|
| PM |  |
💡 Decide which requests should be in the upcoming release. Through various criteria, like number of customer requests, priorities from customers, rough guestimates of the work involved, and more, the PMs decide which features should tentatively be part of the next release. |
| PM | |
📩 Push the requests to GitHub. Using the GitHub integration of productboard, PMs push the list of requests to GitHub, which creates issues for each request. |
| PM/dev |  |
💍 Start writing proposals for the requests. Either the PMs or devs can start writing proposals for the requests in GitHub. The proposal is meant to be a high level description of how we think we'll solve the problem. It's not a full spec just yet, but it should paint a broad picture. |
| PM | |
👌 Pre-review proposals with customers. Reach back out to the customers that asked for the features and validate that our proposal meets their needs. |
| PM/dev | |
👓 Review finished proposals. Once a proposal is finished, it's ready to review. The reviewing team will include PM and dev and any key stakeholders in the feature. The review is meant to cover the feature at a high level, deciding whether this is indeed the right direction to continue. |
| Dev | |
📝 Start writing dev spec. The dev can now start writing a dev spec for the feature. The dev spec should be authored in the specs folder, combined with the PM schema spec. |
| PM/dev | |
✍ Start writing PM spec. The PM (or dev) can also simultaneously start writing the PM schema spec, which should be authored in the specs folder. |
| Dev | |
⌚ Provide estimates. The dev should be able to provide estimates for how long the feature will take. |
| PM | |
🔄 Revise the list of features. With the new information about estimates and growing clarity of dev capacity, we might cut or re-prioritize some features. |
| PM/dev | |
👀 Review final PM/dev specs. After the specs have been completed, they must be reviewed with a team consisting of PM, dev, and key stakeholders. |
| Dev | |
💻 Code the feature! |
| Dev/PM | |
🚀 Release the release |
| PM | |
😍 Notify customers. Tell the customers that asked for these features that they shipped! |
Using the GitHub integration of productboard, PMs push the request to GitHub, which creates an issue for the request.
Either the PMs or devs can start writing proposals for the requests in GitHub. The proposal is meant to be a high level description of how we think we'll solve the problem. It's not a full spec just yet, but it should paint a broad picture. Edit the issue, replace it with the proposal template, and fill out the template.
Once a proposal is finished, it's ready to review. The reviewing team will include PM and dev and any key stakeholders in the feature. The review is meant to cover the feature at a high level, deciding whether this is indeed the right direction to continue. Maybe we should add on to an existing control rather than creating a new one? Maybe we need a new property for a use case? The rough schema is relevant here, but not expected to be final.
The PM (or dev) starts writing the schema spec, contained in the specs folder.
The properties table in these specs is auto-generated from the schema, so the first step is updating the schema.
In schemas\src, add your new properties/elements to the schema
If you followed the setup instructions, simply save the file and the spec will be updated! Add any necessary rendering details to the spec.
Submit a pull request for your updated spec/schema. The proposed schema in the proposal becomes outdated and should be replaced with a link to the PR.
Once approved, we tag the PR as approved. We do NOT merge to master until the feature has been implemented on all platforms.
Devs start coding the feature. They open the issue, which has a link to the open schema PR, which shows them exactly the additions and what properties to add!
Inevitably, we decide to rename some of the properties. We open a new PR, review/approve it, and leave the PR open while all platforms implement the changes, then merge the PR. Platforms that already implemented it should reference what commit of the PR they implemented from, so that they can easily see the diff of the new changes and know what they need to update.
Once all platforms have implemented the feature, we merge the schema PR into master.