Defining The Requirements

You can find the full system design doc here - Feel free to use it as a template for when you're designing systems at your job!

The concrete details are covered in the doc linked above, so this summary will focus on the "meta" context behind this part and additional commentary:

• It's very important for engineers to clearly understand the requirements of the product as they need to build them.
  • A common failure mode is that the proposed requirements aren't technically feasible. It's important for engineers to call this out as early as possible, which is why it's a valuable exercise for them to really lay out in the requirements in their system design doc and overall process.
  • Very senior product managers may give broad strokes in terms of what the product should do. Another reason why this exercise helps engineers is that it's actually up to them to convert the high-level points from their PM into very concrete features and requirements.
• "Jobs to be done" is a mental framework championed by Kevin Systrom, the co-founder and initial CEO of Instagram. The idea is that every product is "employed" by users to do a certain "job" in their life. This is a very important thing to understand about a product and clarifying this serves as an intermediary step towards creating concrete requirements.
• Something that's missing from this document are designs - This is because Taro has no dedicated design support at this stage. At a more mature company (which you almost certainly work at as the viewer), you would have designs at this stage in the document (it can be its own section). For front-end products, you need to put pixels on screen at the end of the day, so it's crucial for engineers to have designs to really understand the requirements and provide concrete feedback.