We will go over how to specify the context for this system design series.
Core points from the video:
- Weak organizations will have product and engineering be incredibly siloed. It is far more effective when product managers and engineers work very closely together. Meta in particular has seen a lot of success by having this harmonious culture.
- This means that software engineers should also understand why they are building something and not purely be responsible for implementation.
- Software engineers should have an opinion on the product and work with their PMs to optimize vision and direction.
- A master spec should also have the context behind the "why" of a product and not only contain technical details.
- The product details will often live in a separate document called a PRD (Product Requirements Document). In this scenario, you should link it in your technical spec and maybe have a paragraph summary of its contents as well.
- Capture any existing context that will affect how you build your system. This will often means that there's components that are already around in your company's ecosystem that you need to build on top of - This scenario is extremely common when building projects in Big Tech.
- Attach visual aides if you can (images, videos, gifs): It makes it far easier for project stakeholders to grok the information.
- Context behind Taro playlists:
- One of the most requested feature within Taro
- Think of it as being similar to YouTube playlists
- We have already shipped a read-only version of playlists
Click here for Part 3, "Defining The Requirements".
For the full system design doc, you can get it by becoming a Taro Premium member.