PRD process

The TPM team use PRD as a tool to set direction and to identify requirements. We have an introduction deck about this that can be found here. On a high level we see PRD as lightweight process and a way for us to streamline our work and to better be able to articulate the things we intend working with. This will allow us to separate high level milestone work from implementation details.

Workflow

This is the workflow that we propose. The one marked with bold face font is the one responsible for the sub-task in question.

  • Idea with a product flavor comes to our attention [ANYONE]

  • Create a draft PRD based on the Confluence PRD template. [TPM]

  • Invite to the first review meeting [TPM, QA, Architects (TL?), BD and PM]

    • Review the objective.

    • Review the background.

    • Review existing user stories

      • Remove, add and modify

      • Identify and create requirements

  • Split up requirements as necessary and create Jira tickets for the planned tasks [PM, TL]

  • Make milestone roadmap [TPM]

  • Make engineering roadmap [PM]

  • Implementation [TL, Engineers, others]

FAQ

  1. Q: Should everything we do in Linaro use the PRD Process?
    A: No, it should be used when it’s product related or whenever we believe it brings value to us.

  2. Q: No one has informed me of this, how can I get more information?
    A: Reach out to <tpm@linaro.org> and we’ll give a walk-through.

  3. Q: Who is responsible for the PRD documents?
    A: The TPM team is the owner and responsible that it gets the attention needed. The TPM team will invite people from other teams to review, contribute and give feedback.

  4. Q: Is it a document created once and then closed when everything has been completed?
    A: No, it’s meant to be a living document that is continuously updated (relates to “3”).

  5. Q: The way we approach PRD seems to be a bit different to how other companies do PRD work?
    A: Correct, Linaro is different to many other companies. We’re often bound to commitments by our members, hence we’ll have to tweak the PRD process to fit our needs.

  6. Q: Who can read the PRDs?
    A: Right now, they’re only accessible to Linaro employees, i.e., not accessible to members, assignees etc. Perhaps this will change in the future.

  7. Q: I have an idea and I want to try use the PRD process for it, what should I do?
    A: Reach out to <tpm@linaro.org> and we will guide you.

  8. Q: What is the cadence for PRD reviews?
    A: Ad-hoc as needed.

  9. Q: Can we re-use a requirement number in a PRD if the previous idea was dropped?
    A: No, if an item is dropped, do a strike-through or something similar. We want to be able to refer to ideas that we’ve dropped. Also it’s likely that we reference PRD requirements elsewhere and we don’t want to end with references pointing to something totally different.

  10. Q: Can I get a high level milestone roadmap?
    A: Yes, intention is to have them in the PRD document. If not found there, reach out to <tpm@linaro.org> and will address it.

  11. Q: Can I get an engineering roadmap? I.e., a higher granularity of milestones?
    A: Yes, talk to the PM person in the PRD.

  12. Q: I can see PRDs on the TPM page that I cannot access, why?
    A: Probably because they’re in draft and before not shared with all employees or it’s something that contains confidential information and cannot be shared widely. It could of course simply also be that the PRD owner forgot to change the permission. Email <tpm@linaro.org> and we’ll guide you.