ਤੁਸੀਂ ਇੱਕ ਚੰਗੀ ਉਤਪਾਦ ਲੋੜ ਦਸਤਾਵੇਜ (PRD) ਕਿਵੇਂ ਲਿਖਦੇ ਹੋ?

Question

Accepted Answer

ਇੱਕ **ਉਤਪਾਦ ਲੋੜ ਦਸਤਾਵੇਜ (PRD)** ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਸੀਂ *ਕੀ* ਬਣਾ ਰਹੇ ਹੋ, *ਕਿਉਂ*, ਅਤੇ *ਤੁਸੀਂ ਕਿਵੇਂ ਜਾਣੋਗੇ ਕਿ ਇਹ ਕੰਮ ਆਇਆ* — ਤਾਂ ਕਿ ਇੰਜੀਨੀਅਰਿੰਗ ਅਤੇ ਡਿਜ਼ਾਇਨ ਟੀਮ ਬਿਨਾਂ ਲਗਾਤਾਰ ਸਪਸ਼ਟਤਾ ਦੇ ਸਹੀ ਚੀਜ਼ ਬਣਾ ਸਕਣ। ਇੱਕ ਚੰਗੀ PRD ਇੱਕ ਸੋਚ ਦਾ ਸਾਧਨ ਅਤੇ ਸੰਰੇਖਣ ਕਲਾਕਾਰੀ ਹੈ, ਨਾ ਕਿ ਬਿਊਰੋਕ੍ਰੇਟਿਕ ਕਾਗਜ਼ ਪੱਤਰ।

## ਇੱਕ ਮਜ਼ਬੂਤ PRD ਰੂਪਰੇਖਾ

```text
1. PROBLEM / CONTEXT → what problem, for whom, why now
2. GOALS & SUCCESS METRICS → what outcome, how measured
3. NON-GOALS → what this explicitly does NOT cover
4. USER STORIES / REQUIREMENTS → what it must do
5. UX → flows, wireframes, key states
6. EDGE CASES → errors, empty states, limits
7. DEPENDENCIES & RISKS → what could block or break this
8. OPEN QUESTIONS → known unknowns to resolve
```

## ਕਿਉਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ **ਸਮੱਸਿਆ ਅਤੇ ਟੀਚੇ** ਹੈ। ਜੇ ਟੀਮ ਸਮਝ ਲੈਂਦੀ ਹੈ ਕਿ *ਕਿਉਂ* ਅਤੇ *ਸਫਲਤਾ ਕਿਹੋ ਜਿਹੀ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ*, ਤਾਂ ਅਕਸਰ ਉਹ ਉਸ ਤੋਂ ਬਿਹਤਰ ਹੱਲ ਲੱਭ ਲਿਆ ਕਰਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਦੱਸਿਆ ਸੀ। ਇੱਕ PRD ਜੋ ਸਿਰਫ ਫੀਚਰ ਸਪੇਸੀਫਿਕੇਸ਼ਨ ਹੈ, ਇਸ ਨੂੰ ਖੁੰਝ ਜਾਂਦੀ ਹੈ।

## ਗੈਰ-ਟੀਚਿਆਂ ਨੂੰ ਘੱਟ ਮੁੱਲ ਨਹੀਂ ਦਿਤਾ ਜਾਂਦਾ

ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਕਹਿਣਾ ਕਿ ਕੀ ਸੀਮਾ ਤੋਂ ਬਾਹਰ ਹੈ, ਸੀਮਾ ਦੀ ਕ੍ਰੀਪ ਨੂੰ ਰੋਕਦਾ ਹੈ ਅਤੇ "ਜਦੋਂ ਅਸੀਂ ਇਸ ਨੂੰ ਕਰ ਰਹੇ ਹੋਵੀਏ..." ਦਾ ਜਾਲ। ਇਹ ਲੋੜ ਹੀ ਜਿੰਨਾ ਮੁੱਲਵਾਨ ਹੈ।

## ਆਮ ਰੁਕਾਵਟਾਂ

```text
✗ Over-specifying the HOW → boxes in engineering's better ideas
✗ No success metric → you can't tell if it worked
✗ Writing it alone → involve eng/design early to catch issues
✗ Treating it as fixed → a PRD is a living doc
```

## ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਜ਼ਿਆਦਾਤਰ ਮੁੜ ਕੰਮ ਗਲਤ ਸੰਰੇਖਣ ਤੋਂ ਆਉਂਦਾ ਹੈ: ਟੀਮ ਨੇ ਜੋ ਪੁੱਛਿਆ ਗਿਆ ਸੀ ਉਹ ਬਣਾਇਆ, ਨਾ ਕਿ ਜੋ ਲੋੜ ਸੀ।

ਇੱਕ ਸਪਸ਼ਟ PRD ਉਹ ਖਾਲੀ ਜਗ੍ਹਾਵਾਂ *ਕੋਡ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ* ਉਜਾਗਰ ਕਰਦੀ ਹੈ।

ਇਹ *ਤੁਹਾਨੂੰ* ਸਮੱਸਿਆ ਦੇ ਮਾਧਿਅਮ ਤੋਂ ਸੋਚਣ ਲਈ ਵੀ ਮਜ਼ਬੂਰ ਕਰਦੀ ਹੈ।

ਜੇ ਤੁਸੀਂ ਟੀਚੇ ਅਤੇ ਸਫਲਤਾ ਮਾਪਦੰਡ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਨਹੀਂ ਲਿਖ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਸਮੱਸਿਆ ਨੂੰ ਬਣਾਉਣ ਲਈ ਱ੁਫਾ ਸਮਝ ਨਹੀਂ ਲਿਆ।