ਡਿਸਕਵਰੀ ਕਾਲ ਤੋਂ ਬਿਲਡ-ਰੇਡੀ ਪ੍ਰੌਂਪਟ ਜੋ ਟੀਮਾਂ ਵਰਤ ਸਕਣ

ਡਿਸਕਵਰੀ ਕਾਲਾਂ ਅਕਸਰ ਹਥੌੜੀ-ਹਾਂ ਵਾਂਗ ਹਥਿਆਰ ਨਹੀਂ ਬਣਦੀਆਂ

ਅਕਸਰ ਟੁੱਟਣਾ ਮੀਟਿੰਗ ਦੌਰਾਨ ਨਹੀਂ, ਮੀਟਿੰਗ ਦੇ ਬਾਅਦ ਹੁੰਦਾ ਹੈ। ਹਰ ਕੋਈ ਡਿਸਕਵਰੀ ਕਾਲ ਤੋਂ ਬਾਅਦ ਇਕ ਰੂਪ ਵਿੱਚ ਸਹਿਮਤ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ, ਪਰ ਨੋਟਸ ਬਹੁਤ ਪਤਲੇ ਹੁੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਬਣਾਉਣਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ। ਟੀਮਾਂ ਕੰਮਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖ ਦਿੰਦੀਆਂ ਹਨ: "needs approvals," "admin view," ਜਾਂ "customer portal" ਅਤੇ ਸੋਚਦੀਆਂ ਹਨ ਕਿ ਇਹ ਕਾਫ਼ੀ ਹੈ — ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਕਾਫ਼ੀ ਨਹੀਂ ਹੁੰਦਾ।

ਸੱਚਾਈ ਵਿੱਚ ਜੋ ਗੁੰਮ ਹੋ ਜਾਂਦਾ ਹੈ ਉਹ ਕਾਰੋਬਾਰ ਦੀ ਰੋਜ਼ਮਰਰਾ ਹਕੀਕਤ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਕਾਲ ਫੀਚਰਾਂ ਦਾ ਜਿਕਰ ਕਰ ਸਕਦੀ ਹੈ ਪਰ ਇਹ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਕੰਮ ਕੌਣ ਕਰਦਾ ਹੈ, ਕਿਹੜੀ ਕ੍ਰਮਬੱਧਤਾ ਨਾਲ ਕੰਮ ਹੋ ਰਿਹਾ ਹੈ, ਕਿਹੜੇ ਨਿਯਮ ਟੁੱਟਣ ਯੋਗ ਨਹੀਂ ਹਨ, ਜਾਂ ਇੱਕ ਆਮ ਹਫਤੇ ਵਿੱਚ ਕਾਮਯਾਬੀ ਕੀ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਇਹ ਸੰਦਰਭ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਪਹਿਲੀ ਵਰਜਨ ਅੰਦਾਜ਼ਿਆਂ ਤੇ ਬਣਦੀ ਹੈ।

ਉਹ ਅੰਦਾਜੇ ਦਰਮਿਆਨੇ ਪਹਿਲੇ ਵਰਜਨ ਕੋਲ-ਕਮਜ਼ੋਰ ਬਣਾਉਂਦੇ ਹਨ। ਸਕ੍ਰੀਨ ਸੁੰਦਰ ਲੱਗ ਸਕਦੀ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਗਲਤ ਸਮੱਸਿਆ ਹੱਲ ਕਰ ਰਹੀ ਹੋ ਸਕਦੀ ਹੈ। "Users submit requests" ਸਹੀ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਉਪਭੋਗਤਾ ਗਾਹਕ ਹੈ, ਫੀਲ্ড ਵਰਕਰ ਹੈ ਜਾਂ ਮੈਨੇਜਰ, ਜਾਂ ਸਬਮਿਟ ਕਰਨ ਦੇ ਬਾਅਦ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇਸ ਲਈ ਇੱਕ ਚੰਗਾ ਪ੍ਰੌਂਪਟ ਸਿਰਫ ਇੱਕ ਫੀਚਰ-ਲਿਸਟ ਨਹੀਂ, ਬਲਕਿ ਕਾਰੋਬਾਰੀ ਸੰਦਰਭ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਮਜ਼ਬੂਤ ਹੈਂਡਆਫ਼ ਇੰਝ ਲੱਗਦਾ ਹੈ: "Field staff ਮੋਬਾਈਲ ਤੋਂ service requests ਭੇਜਦੇ ਹਨ, supervisors ਉਹਨਾਂ ਨੂੰ ਇੱਕੋ ਹੀ ਦਿਨ ਰਿਵਿਊ ਕਰਦੇ ਹਨ, urgent jobs ਨਾਰਮਲ ਕਤਾਰ ਨੂੰ ਛੱਡ ਦੇਂਦੇ ਹਨ, ਅਤੇ ਹਰ ਤਬਦੀਲੀ ਨੂੰ ਲੌਗ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ." ਇਹ ਬਿਲਡਰ ਨੂੰ ਅਸਲੀ ਚੀਜ਼ ਦੇਂਦਾ ਹੈ।

ਇਹ ਹੋਰ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਟੀਮ ਪ੍ਰੌਂਪਟ ਤੋਂ ਕੰਮ ਕਰ ਰਹੀ ਉਤਪਾਦ ਤੱਕ ਤੇਜ਼ੀ ਨਾਲ ਪਹੁੰਚ ਸਕਦੀ ਹੈ। Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਨਾਲ ਗਤੀ ਇੱਕ ਵਾਸਤਵਿਕ ਫ਼ਾਇਦਾ ਹੈ, ਪਰ ਸਿਰਫ਼ ਉਸ ਵੈਕਤੀਕਤਾ 'ਤੇ ਜਦੋਂ ਪ੍ਰੌਂਪਟ ਵਿੱਚ ਕਾਰੋਬਾਰੀ ਲੋਜਿਕ ਵੀ ਹੋਵੇ।

ਮਕਸਦ ਸਧਾਰਨ ਹੈ। ਕਾਲ ਤੋਂ ਬਾਅਦ ਕਿਸੇ ਇਕ ਵਿਅਕਤੀ ਨੂੰ ਪ੍ਰੌਂਪਟ ਪੜ੍ਹ ਕੇ ਤੁਰੰਤ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਉਸਨੂੰ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ ਦਾ ਕੋਡ ਖੋਲ੍ਹਣਾ ਜਾਂ ਘੁੰਮ-ਫਿਰ ਕੇ ਘੁੰਮਨਾ ਨਹੀਂ ਪੈਣਾ ਚਾਹੀਦਾ।

ਅਦਾਕਾਰਾਂ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਅਸਲ ਕੰਮ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

ਚੰਗੀ ਹੈਂਡਆਫ਼ ਲੋਕਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਫੀਚਰਾਂ ਨਾਲ ਨਹੀਂ। ਜੇ ਇਹ ਕਦਮ ਛੱਡ ਦਿਓ ਤਾਂ ਪਹਿਲਾ ਬਿਲਡ ਅਕਸਰ ਬਿਨਾਂ ਸਪਸ਼ਟ ਮਾਲਕ ਦੇ ਸਕ੍ਰੀਨਾਂ ਦਾ ਢੇਰ ਬਣ ਜਾਂਦਾ ਹੈ। ਡਿਸਕਵਰੀ ਨੋਟਸ ਨੂੰ ਵਰਤੋਯੋਗ ਬਣਾਉਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਇਹ ਪੁੱਛਣਾ ਹੈ: ਇਹ ਉਤਪਾਦ ਕੌਣ ਖੋਲ੍ਹੇਗਾ, ਅਤੇ ਉਹ ਕੀ حاصل ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ?

ਹਰ ਕਿਸਮ ਦੇ ਉਪਭੋਗਤਾ ਦਾ ਨਾਮ ਲਵੋ, ਭਾਵੇਂ ਗਰੁੱਪ ਸਪਸ਼ਟ ਲੱਗਣ। ਇੱਕ founder, sales rep, manager, finance lead, ਅਤੇ support agent ਸਭ ਇੱਕੋ ਸਿਸਟਮ ਨੂੰ ਵੱਖ-ਵੱਖ ਕਾਰਨਾਂ ਲਈ ਵਰਤ ਸਕਦੇ ਹਨ। ਜਦੋਂ ਇਹ ਭੂਮਿਕਾਵਾਂ ਮਿਲਾ ਦਿੱਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਪ੍ਰੌਂਪਟ ਅਸਪಷ್ಟ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਪਹਿਲੀ ਵਰਜਨ ਸਭ ਨੂੰ ਇਕਠ्ठਾ ਸੇਵਾ ਦੇਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ।

ਹਰ ਅਦਾਕਾਰ ਨੂੰ ਅਸਲੀ ਕੰਮ ਨਾਲ ਜੋੜੇ ਰੱਖੋ। ਇੱਕ sales rep ਸਾਇਦ deal stages ਅੱਪਡੇਟ ਕਰੇ, call notes ਲੌਗ ਕਰੇ, ਅਤੇ next actions ਚੈੱਕ ਕਰੇ। ਇੱਕ manager pipeline ਨੰਬਰਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰ ਸਕਦਾ ਹੈ, discounts ਮਨਜ਼ੂਰ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਹਫ਼ਤਾਵਾਰ ਰਿਪੋਰਟ ਐਕਸਪੋਰਟ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਫਰਕ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਹਰ ਵਿਅਕਤੀ ਨੂੰ ਪਹਿਲਾਂ ਕੀ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਉਹ ਕੀ ਬਦਲ ਸਕਦੇ ਹਨ।

ਇੱਕ ਸਧਾਰਨ ਵੰਡ ਮਦਦ ਕਰਦੀ ਹੈ:

• Daily users ਉਹੀ ਮੁੱਖ ਕਾਰਵਾਈਆਂ ਦੁਹਰਾਉਂਦੇ ਹਨ।
• Managers ਸਮੀਖਿਆ, ਮਨਜ਼ੂਰੀ, ਅਤੇ ਸਹੀ ਕਰਦੇ ਹਨ।
• Admins ਸੈਟਿੰਗਜ਼, permissions, ਅਤੇ ਸਿਸਟਮ ਨਿਯਮ ਸੰਭਾਲਦੇ ਹਨ।
• View-only users ਸਥਿਤੀ ਚੈੱਕ ਕਰਦੇ ਹਨ ਬਿਨਾਂ ਸੰਪਾਦਨ ਦੇ।
• Finance ਜਾਂ operations ਵਰਤੋਂਕਾਰ ਅਕਸਰ ਐਕਸਪੋਰਟ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਦੀ ਲੋੜ ਰੱਖਦੇ ਹਨ।

ਇਹ ਇੱਕ ਆਮ ਗਲਤੀ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ: ਹਰ ਉਪਭੋਗਤਾ ਨੂੰ admin ਵਾਂਗ ਬਣਾਉਣਾ। ਜ਼ਿਆਦਾਤਰ ਲੋਕਾਂ ਨੂੰ ਪੂਰਾ ਕੰਟਰੋਲ ਨਹੀਂ ਚਾਹੀਦਾ; ਉਹਨਾਂ ਨੂੰ ਆਪਣੇ ਆਮ ਕੰਮ ਤੱਕ ਸਭ ਤੋਂ ਛੋਟੀ ਰਾਹ ਚਾਹੀਦੀ ਹੈ।

ਇਹ ਵਿਵਰਣ ਪਹਿਲੇ ਪ੍ਰੌਂਪਟ ਦੀ ਗੁਣਵੱਤਾ ਬਦਲ ਦਿੰਦਾ ਹੈ। "Build a CRM" ਅਸਪਸ਼ਟ ਹੈ। "Sales reps leads ਅੱਪਡੇਟ ਕਰਦੇ ਹਨ, managers quote changes ਮਨਜ਼ੂਰ ਕਰਦੇ ਹਨ, support account history ਦੇਖ ਸਕਦਾ ਹੈ, ਅਤੇ finance closed deals export ਕਰਦਾ ਹੈ" ਉਤਪਾਦ ਨੂੰ ਅਸਲੀ ਸ਼ਕਲ ਦਿੰਦਾ ਹੈ।

ਗੱਲਬਾਤ ਨੂੰ ਸਪਸ਼ਟ ਕੰਮਾਂ ਵਿੱਚ ਬਦਲੋ

ਇੱਕ ਵਰਤੀਯੋਗ ਪ੍ਰੌਂਪਟ ਕੰਮਾਂ ਨੂੰ ਐਕਸ਼ਨਾਂ ਵਿੱਚ ਵੰਡਦੀ ਹੈ ਜੋ ਲੋਕ ਵਾਸਤਵ ਵਿੱਚ ਕਰਦੇ ਹਨ। ਇਹ ਉਹ ਨਿਯਮ ਹੈ ਜਿੱਥੇ ਡਿਸਕਵਰੀ ਨੋਟਸ ਬਿਲਡ ਕਰਨ ਯੋਗ ਬਣ ਜਾਂਦੇ ਹਨ।

ਜੇ ਕੋਈ ਕਹੇ "We need a better way to manage orders," ਤਾਂ ਪੁੱਛਦੇ ਰਹੋ ਜਦ ਤੱਕ ਕਦਮ ਸਪਸ਼ਟ ਨਾ ਹੋ ਜਾਣ। "Manage orders" ਇੱਕ ਟਾਸਕ ਨਹੀਂ ਹੈ। "Create an order, review payment status, approve shipment, and send a confirmation" ਇੱਕ ਟਾਸਕ-ਲਾਇਨ ਹੈ।

ਛੋਟੀ ਕਾਰਵਾਈਆਂ ਵਾਲੇ ਸ਼ਬਦ ਨੋਟਸ ਨੂੰ ਸਾਫ਼ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ:

• Create
• Review
• Approve
• Send
• Update

ਇਹ ਕਿਰਿਆ-ਸ਼ਬਦ ਉਸਤੋਂ ਵਰਤੋ ਕਿ ਵਿਆਪਕ ਬਿਆਨਾਂ ਨੂੰ ਟਾਸਕ ਲਾਈਨਾਂ ਵਿੱਚ ਲਿਖ ਸਕੋ। ਇੱਕ ਕਲੀਨਿਕ ਮਾਲਕ ਕਹਿ ਸਕਦਾ ਹੈ, "I want staff to handle bookings faster." ਇਕ ਬਿਲਡ-ਰੇਡੀ ਵਰਜਨ ਹੋਵੇਗਾ: "Receptionist creates an appointment, reviews doctor availability, confirms the slot, and sends a reminder to the patient."

ਹਰ ਟਾਸਕ ਨੂੰ ਇੱਕ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਦੀ ਸਥਿਤੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਹ ਕਿਹੜੀ ਚੀਜ਼ ਟਰਿਗਰ ਕਰਦੀ ਹੈ? ਅਗਲਾ ਕਦਮ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ? ਜੇ ਇੱਕ manager refund ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹ ਕੀ ਮੌਜੂਦ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਮਨਜ਼ੂਰੀ ਤੋਂ ਬਾਅਦ ਕੀ ਬਦਲਦਾ ਹੈ? ਇਹਨੀਆਂ ਛੋਟੀ-ਛੋਟੀ ਜ਼ਰੂਰੀਆਂ ਚੀਜ਼ਾਂ ਸਕ੍ਰੀਨਾਂ, ਬਟਨਾਂ, ਸਥਿਤੀ ਲੇਬਲਾਂ, ਅਤੇ ਨੋਟੀਫਿਕੇਸ਼ਨਾਂ ਨੂੰ ਰੂਪ ਦਿੰਦੇ ਹਨ।

ਇੱਕ ਸਧਾਰਨ ਚੇਨ ਵਰਕਦੀ ਹੈ: trigger, action, result. ਉਦਾਹਰਨ ਲਈ: "When a new lead comes in, the sales rep reviews the details, updates the priority, and sends a first reply." ਇਹ ਪਹਿਲੇ ਬਿਲਡ ਵਿੱਚ ਬਦਲਣਾ ਬਹੁਤ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।

ਇਹ ਵੀ ਮਦਦ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਟਾਸਕ ਦਿਨ ਇੱਕ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਜੇ ਤਿੰਨ ਕਾਰਵਾਈਆਂ ਹਰ ਰੋਜ਼ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਦੋ ਮਹੀਨੇ 'ਚ ਇਕ ਵਾਰੀ, ਤਦ ਪਹਿਲਾਂ ਦੈਨਿਕ ਵਾਲੀਆਂ ਬਣਾਉ। ਇਸ ਨਾਲ ਪਹਿਲਾ ਰਿਲੀਜ਼ ਫੋਕਸਡ ਅਤੇ ਉਪਯੋਗੀ ਰਹਿੰਦਾ ਹੈ।

ਅਣਛੁਏ ਨਿਯਮਾਂ ਨੂੰ ਪਹਿਲਾਂ ਕੈਪਚਰ ਕਰੋ

ਇੱਕ ਚੰਗਾ ਪ੍ਰੌਂਪਟ ਸਿਰਫ ਫੀਚਰਾਂ ਦੀ ਸੂਚੀ ਨਹੀਂ; ਇਸ ਵਿੱਚ ਉਹ ਸੀਮਾਵਾਂ ਵੀ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਜਿਸ ਵਿੱਚ ਟੀਮ ਕੰਮ ਕਰੇਗੀ। ਜੇ ਇਹ ਸੀਮਾਵਾਂ ਕਾਲ ਦੌਰਾਨ ਢਿੱਲੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ, ਤਾਂ ਪਹਿਲਾ ਵਰਜ਼ਨ ਬਾਹਰੀ ਤੌਰ 'ਤੇ ਠੀਕ ਲੱਗ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਅਮਲ ਵਿੱਚ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ।

ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ। ਜੇ ਟੀਮ ਪਹਿਲਾਂ ਹੀ technical ਜਾਂ legal ਸ਼ਬਦਾਵਲੀ ਨੂੰ ਸਮਝਦੀ ਹੈ ਤਾਂ ਛੱਡੋ, ਪਰ ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਸਪਸ਼ਟ ਬੋਲੀ ਵਰਤੋ। "role-based approval matrix" ਦੀ ਥਾਂ ਕਹੋ: "sales reps discount draft ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਸਿਰਫ managers ਹੀ ਉਹਨੂੰ ਮਨਜ਼ੂਰ ਕਰ ਸਕਦੇ ਹਨ."

ਕੁਝ ਸੀਮਾਵਾਂ ਪੂਰੇ ਬਿਲਡ ਨੂੰ ਰੂਪ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਜਲਦੀ ਕੈਪਚਰ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੁੰਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਪ੍ਰਾਈਵੇਸੀ ਨਿਯਮ, ਡੇਟਾ ਦਾ ਰਿਹਾਇਸ਼ੀ ਸਥਾਨ, ਅਤੇ ਉਦਯੋਗ ਖਾਸ ਜ਼ਰੂਰਤਾਂ ਸ਼ਾਮਲ ਹਨ। ਜੇ ਗਾਹਕ ਡੇਟਾ ਇੱਕ ਖ਼ਾਸ ਦੇਸ਼ ਜਾਂ ਖੇਤਰ ਵਿੱਚ ਹੀ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਸਪਸ਼ਟ ਲਿਖੋ।

ਇਹ ਵੀ ਲਿਖੋ ਕਿ ਕੀ ਬਦਲਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ। ਕਈ ਟੀਮਾਂ ਨਵੀਂ ਐਪ ਚਾਹੁੰਦੀਆਂ ਹਨ ਪਰ ਕੁਝ ਮੌਜੂਦਾ ਟੂਲ ਜਾਂ ਮੈਨੂਅਲ ਕਦਮ ਜਾਰੀ ਰਹਿੰਦੇ ਹਨ। ਫਾਇਨੈਂਸ ਨੂੰ ਵੀ ਇੱਕੋ ਹੀ accounting ਸਿਸਟਮ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਸਪੋਰਟ ਨੂੰ ਹੁਣਲੇ help desk ਵਿੱਚ tickets ਰਹਿਣੇ ਲਾਜ਼ਮੀ ਹੋ ਸਕਦੇ ਹਨ। ਇਹ ਸੀਮਾਵਾਂ ਨਵੇਂ ਫੀਚਰਾਂ ਜਿੱਤਰੇ ਮਹੱਤਵਪੂਰਨ ਹਨ।

ਇੱਕ ਛੋਟੀ ਸੈਕਸ਼ਨ ਰੱਖੋ ਪ੍ਰਭਾਵੀ practical constraints ਲਈ, ਜਿਵੇਂ:

• fixed launch date
• budget cap ਜਾਂ spending range
• team size ਅਤੇ ਉਪਲਬਧ reviewers
• ਉਹ ਟੂਲ ਜੋ workflow ਵਿੱਚ ਰਹਿਣੇ ਲਾਜ਼ਮੀ ਹਨ
• ਕਾਨੂੰਨੀ, ਪ੍ਰਾਈਵੇਸੀ, ਜਾਂ ਸਥਾਨਕ ਜ਼ਰੂਰਤਾਂ

ਇਹ ਵੇਰਵੇ ਪਹਿਲੇ ਬਿਲਡ ਨੂੰ ਗਲਤ ਅਨੁਮਾਨ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ ਅਤੇ ਨਿਰਮਾਤਾ ਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ trade-offs ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।

ਉਦਾਹਰਣਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰੌਂਪਟ ਨੂੰ ठोस ਬਣਾਓ

ਉਦਾਹਰਣ vague ਨੋਟਸ ਨੂੰ ਕਿਸੇ ਐਸੀ ਚੀਜ਼ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ ਜੋ ਟੀਮ ਅਸਲ ਵਿੱਚ ਬਣਾ ਸਕੇ। "manage orders" ਜਾਂ "review leads" ਵਰਗੇ ਬਿਆਨ ਅਸਲ ਇਨਪੁਟ, ਉਮੀਦਗਾਰ ਆਉਟਪੁੱਟ ਜਾਂ ਗੁਣਵੱਤਾ ਮਿਆਰ ਨਹੀਂ ਦਿਖਾਉਂਦੇ।

ਇੱਕ ਆਮ ਉਦਾਹਰਣ ਲਓ ਜੋ ਹਾਲੀਆ ਕੰਮ ਤੋਂ ਹੈ। ਅਸਲ ਵਿੱਚ ਆਮ ਹੋਈ ਇੱਕ ਵੀ ਕੇਸ ਲਓ, ਅਜਿਹਾ ਹੋਰ ਨਹੀਂ। ਜੇ ਟੀਮ ਕਹਿੰਦੀ ਹੈ ਕਿ ਉਹਨਾਂ ਨੂੰ leads qualify ਕਰਨ ਲਈ ਐਪ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਉਨ੍ਹਾਂ ਤੋਂ ਇਕ ਸੱਚਾ lead record ਦਿਖਾਉਣ ਨੂੰ ਕਿਹਾ ਜਾਏ: ਕੀ التفاصيل ਆਈਆਂ, ਅਤੇ ਰਿਵਿਊ ਤੋਂ ਬਾਅਦ ਆਉਟਪੁੱਟ ਕਿਹੜਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇੱਕ ਉਪਯੋਗੀ ਉਦਾਹਰਣ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਚਾਰ ਚੀਜ਼ਾਂ ਸ਼ਾਮਲ ਕਰਦੀ ਹੈ:

• sample input
• ਉਹ ਕੰਮ ਜਾਂ ਫੈਸਲਾ ਜੋ ਐਪ ਕਰੇਗਾ
• ਉਮੀਦਗਾਰ output
• ਕੀ ਚੀਜ਼ ਇਸ output ਨੂੰ ਕਾਬਿਲ-ਏ-ਕਾਬੂ ਮੰਨਿਆ ਜਾਣਾ ਚਾਹੀਦੀ ਹੈ

ਫਿਰ ਇੱਕ ਗੰਦੇ ਕੇਸ ਲਈ ਪੁੱਛੋ ਜੋ ਅਕਸਰ ਹੁੰਦਾ ਹੈ। ਇੱਥੇ ਛੁਪੇ ਨਿਯਮ ਨਿਕਲਕੇ ਆਉਂਦੇ ਹਨ। ਸ਼ਾਇਦ ਫਾਰਮ ਵਿੱਚ ਫੋਨ ਨੰਬਰ ਗੁੰਮ ਹੋਵੇ, ਜਾਂ ਇੱਕੋ ਗਾਹਕ ਦੋ ਵਾਰੀ ਹੋਵੇ, ਜਾਂ ਬੇਰੁਖ ਹੋਈ ਰਿਕਵੇਸਟ ਹੋਵੇ। ਜੇ ਤੁਸੀਂ ਇਹ ਹੁਣ ਹੀ ਕੈਪਚਰ ਕਰ ਲੈਂਦੇ ਹੋ ਤਾਂ ਪਹਿਲਾ ਪ੍ਰੌਂਪਟ ਕਹਿ ਸਕਦਾ ਹੈ ਕਿ ਐਪ ਇਸਨੂੰ ਫਲੈਗ ਕਰੇ, ਛੱਡ ਦੇਵੇ, ਜਾਂ ਹੋਰ ਜਾਣਕਾਰੀ ਮੰਗੇ।

ਗੁਣਵੱਤਾ ਬਾਰੇ ਸਪਸ਼ਟ ਹੋਵੋ। "It should work" ਲਾਭਕਾਰੀ ਟੀਚਾ ਨਹੀਂ ਹੈ। "It should group duplicates, keep the newest contact details, and mark low-confidence matches for review" ਇੱਕ ਐਸੀ ਚੀਜ਼ ਹੈ ਜਿਸ 'ਤੇ ਨਿਰਮਾਤਾ ਕਾਰਵਾਈ ਕਰ ਸਕਦਾ ਹੈ।

ਅਮਲੀ ਤੌਰ 'ਤੇ, ਇੱਕ ਸਾਫ਼ ਅਤੇ ਇੱਕ ਗੰਦਾ ਕੇਸ ਆਮ ਤੌਰ 'ਤੇ ਲੰਬੇ ਅਧਿਐਨ ਦੀ ਬਜਾਏ ਦੋ ਚਿਪਕੀਆਂ ਉਦਾਹਰਣਾਂ ਨਾਲ ਜ਼ਿਆਦਾ ਮਦਦਗਾਰ ਹੁੰਦੀਆਂ ਹਨ।

ਪਹਿਲੇ ਬਿਲਡ ਨੂੰ ਬਚਾਉਣ ਲਈ ਨਾ-ਉਦੇਸ਼ (non-goals) ਨਿਰਧਾਰਿਤ ਕਰੋ

ਇੱਕ ਮਜ਼ਬੂਤ ਪਹਿਲਾ ਪ੍ਰੌਂਪਟ ਸਪਸ਼ਟ ਸੀਮਾਵਾਂ ਦੀ ਲੋੜ ਰੱਖਦਾ ਹੈ। ਬਿਨਾਂ ਉਹਨਾਂ ਦੇ, ਵਰਜ਼ਨ ਇੱਕ ਵਾਧੂ ਵਿਚਾਰਾਂ ਨਾਲ ਭਰ ਜਾਂਦਾ ਹੈ ਅਤੇ ਨਤੀਜਾ ਫੈਲਾ, ਹੌਲੀ, ਜਾਂ ਬਿਨਾਂ ਧਿਆਨ ਦਾ ਹੋ ਸਕਦਾ ਹੈ।

ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਉਤਪਾਦ ਹੁਣ ਤੱਕ ਕੀ ਨਹੀਂ ਕਰੇਗਾ। ਇਹ ਮੁੱਖ workflow ਦੀ ਸੁਰੱਖਿਆ ਕਰਦਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਅਜ਼ਮਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ।

ਨਾਈਸ-ਟੂ-ਹੈਵ ਵਿਸ਼ੇ ਆਮ ਤੌਰ 'ਤੇ ਆਸਾਨੀ ਨਾਲ ਪਛਾਣੇ ਜਾਂਦੇ ਹਨ। ਇਹ ਲਾਭਕਾਰੀ ਲੱਗਦੇ ਹਨ ਪਰ ਉਤਪਾਦ ਕੰਮ ਕਰਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੁੰਦੇ। ਇੱਕ custom dashboard, advanced roles, ਡੀਪ ਰਿਪੋਰਟਿੰਗ, ਜਾਂ ਸੋਨੇ-ਚੰਦੀ ਵਾਲੀਆਂ ਨੋਟੀਫਿਕੇਸ਼ਨ ਬਾਦ ਵਿੱਚ ਆ ਸਕਦੀਆਂ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਵਰਜ਼ਨ 1 ਦੇ ਮੁੱਖ ਫਲੋ ਨਾਲ ਮੁਕਾਬਲਾ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।

ਕੁਝ ਸਵਾਲ ਮਦਦਗਾਰ ਹਨ:

• ਪਹਿਲੇ 1-2 ਹਫ਼ਤੇ ਲਈ ਉਪਭੋਗਤਾ ਕਿਸ ਚੀਜ਼ ਦੇ ਬਿਨਾਂ ਜੀ ਸਕਦੇ ਹਨ?
• ਕੀ ਟੀਮ ਸ਼ੁਰੂ ਵਿੱਚ ਹੱਥੋਂ-ਹੱਥ ਕੰਮ ਸੰਭਾਲ ਸਕਦੀ ਹੈ?
• ਕੀ ਕੋਈ ਚੀਜ਼ ਲਾਭਦਾਇਕ ਲੱਗਦੀ ਹੈ ਪਰ ਮੁੱਖ ਨਤੀਜੇ ਨਾਲ ਜੁੜੀ ਨਹੀਂ?
• ਕਿਹੜੀਆਂ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਮੁੱਖ ਫਲੋ ਸਥਿਰ ਹੋਣ ਤੱਕ ਰੁਕ ਸਕਦੀਆਂ ਹਨ?

ਮੈਨੂਅਲ ਕੰਮ ਅਕਸਰ ਸਹੀ ਅਸਥਾਈ ਚੋਣ ਹੁੰਦਾ ਹੈ। ਜੇ leads ਦੀ ਦਿਨ ਵਿਚ ਇਕ ਵਾਰੀ ਹੱਥੋਂ-ਹੱਥ ਸਮੀਖਿਆ ਹੋ ਸਕਦੀ ਹੈ ਤਾਂ ਤੁਹਾਨੂੰ ਦਰੁਸਤ ਆਟੋ-ਰਾਉਟਿੰਗ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋ ਸਕਦੀ। ਜੇ invoices ਇੱਕਸਥਿਤ ਤਰੀਕੇ ਨਾਲ ਐਕਸਪੋਰਟ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ ਤਾਂ ਪੂਰੀ ਬਿਲਿੰਗ ਆਟੋਮੇਸ਼ਨ ਬਾਅਦ ਵਿੱਚ ਆ ਸਕਦੀ ਹੈ। ਇਹ ਨਾਕਾਮੀ ਨਹੀਂ; ਇਹ ਫੋਕਸ ਹੈ।

ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਬਾਰੇ ਵੀ ਇਹੀ ਗੱਲ ਲਾਗੂ ਹੁੰਦੀ ਹੈ। ਬਹੁਤ ਤੀਆਂ ਟੀਮਾਂ ਤੁਰੰਤ payment tools, email platforms, calendar sync, ਅਤੇ CRM connections ਦੀ ਮੰਗ ਕਰਦੀਆਂ ਹਨ। ਜੇ ਪਹਿਲਾ ਬਿਲਡ ਇੱਕ workflow ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਹੈ ਤਾਂ ਨੋਟ ਕਰੋ ਕਿ ਕਿਹੜੇ ਸਿਸਟਮ ਵਰਜ਼ਨ 1 ਦੇ ਬਾਹਰ ਰਹਿਣਗੇ।

ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਅੰਦਰੂਨੀ CRM ਸੰਪਰਕ ਕੈਪਚਰ, ਸਥਿਤੀ ਅੱਪਡੇਟ, ਅਤੇ ਇੱਕ ਬੁਨਿਆਦੀ ਟਾਸਕ ਲਿਸਟ ਨਾਲ ਸ਼ੁਰੂ ਹੋ ਸਕਦਾ ਹੈ। Non-goals ਵਿੱਚ multi-team permissions, advanced analytics, mobile push alerts, ਅਤੇ ਬਾਹਰੀ ਟੂਲਾਂ ਨਾਲ live sync ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ।

"Version one ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ" ਅਕਸਰ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ। ਸਪਸ਼ਟ ਸੀਮਾਵਾਂ ਪਹਿਲੇ ਬਿਲਡ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਭੇਜਣਯੋਗ ਅਤੇ ਟੈਸਟ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ।

ਇੱਕ ਸਧਾਰਨ ਕਦਮ-ਬਦ-ਕਦਮ ਪ੍ਰੌਂਪਟ ਟੈਮਪਲੇਟ

ਇੱਕ ਵਰਤੀਯੋਗ ਪ੍ਰੌਂਪਟ ਛੋਟੇ ਬ੍ਰੀਫ਼ ਵਾਂਗ ਪੜ੍ਹਨਾ ਚਾਹੀਦਾ ਹੈ, ਨਾਂ ਕਿ ਨੋਟਸ ਦਾ ਢੇਰ। ਹਰ ਵਾਰੀ ਇੱਕੋ ਢਾਂਚਾ ਵਰਤਣ ਨਾਲ ਹੈਂਡਆਫ਼ ਬਹੁਤ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।

1. ਇੱਕ ਇੱਕ-ਲਾਈਨ ਉਤਪਾਦ ਸਰਾਂਸ਼ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਕਿਹੜਾ ਉਤਪਾਦ ਹੈ, ਇਹ ਕਿਸ ਲਈ ਹੈ, ਅਤੇ ਮੁੱਖ ਨਤੀਜਾ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
2. ਅਦਾਕਾਰਾਂ ਦਾ ਨਾਮ ਲਵੋ। ਉਹਨਾਂ ਨੂੰ ਲਿਸਟ ਕਰੋ ਜੋ ਇਸਨੂੰ ਵਰਤਣਗੇ।
3. ਮੁੱਖ ਕਾਰਜਾਂ ਵਰਣਨ ਕਰੋ। ਵਰਜ਼ਨ 1 ਵਿੱਚ ਸਭ ਤੋਂ ਜ਼ਰੂਰੀ ਕਾਰਵਾਈਆਂ 'ਤੇ ਧਿਆਨ ਦਿਓ।
4. ਸੀਮਾਵਾਂ ਅਤੇ ਉਦਾਹਰਣ ਜੋੜੋ। ਨਿਯਮ, ਸੀਮਾਵਾਂ, ਡੇਟਾ ਦੀ ਲੋੜ, ਅਤੇ ਇੱਕ ਜਾਂ ਦੋ ਅਸਲ ਕੇਸ ਦਿਓ।
5. ਸਫ਼ਲਤਾ ਮਾਪਦੰਡ ਨਾਲ ਖਤਮ ਕਰੋ। ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਪਹਿਲਾ ਵਰਜ਼ਨ ਕਿੰਨੇ ਚੰਗੇ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਇਹ ਉਪਯੋਗੀ ਹੋਵੇ।

ਸਧਾਰਨ ਅਤੇ ਸਪਸ਼ਟ ਬੋਲੀਆਂ ਵਰਤੋ। "manage projects better" ਨਾ ਲਿਖੋ ਜੇ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਮਤਲਬ ਹੈ "team leads can create a project, assign tasks, and mark work complete."

ਸਧਾਰਨ ਵਾਕ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੇ ਹਨ। ਉਦਾਹਰਨ: "Build a small CRM for a sales team. Actors: sales reps and a manager. Tasks: add leads, update deal stage, and view follow-ups. Constraints: mobile-friendly, simple dashboard, CSV export. Example: a rep should log a call in under 30 seconds. Success: the team can track active deals without using spreadsheets."

ਇਹ ਨਿਰਮਾਤਾ ਨੂੰ ਪਹਿਲੀ ਸ਼ੁਰੂਆਤ ਦੇਣ ਲਈ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ ਬਿਨਾਂ ਪੂਰੇ ਉਤਪਾਦ ਨੂੰ ਵੇਰਵਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੇ।

ਉਦਾਹਰਣ: ਇਕ ਕਾਲ ਨੂੰ ਇੱਕ ਵਰਤਣਯੋਗ ਪ੍ਰੌਂਪਟ ਵਿੱਚ ਬਦਲਣਾ

ਕਲਪਨਾ ਕਰੋ ਇੱਕ ਛੋਟੀ ਸੇਵਾ ਕਾਰੋਬਾਰ ਵਰਗਾ ਇੱਕ ਲੋਕਲ cleaning ਕੰਪਨੀ। ਕਾਲ 'ਤੇ ਮਾਲਕ ਕਹਿੰਦਾ ਹੈ, "Customers need to book online, pay easily, and my staff need a simple way to manage appointments." ਇਹ ਮਦਦਗਾਰ ਹੈ, ਪਰ ਪਹਿਲੇ ਬਿਲਡ ਲਈ ਇਹ ਫਿਰ ਵੀ ਬਹੁਤ ਢਿੱਲਾ ਹੈ।

ਇੱਕ ਬਿਲਡ-ਰੇਡੀ ਵਰਜਨ ਉਸ ਗੱਲਬਾਤ ਨੂੰ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਬਦਲ ਦਿੰਦਾ ਹੈ ਜੋ ਤੁਰੰਤ ਵਰਤੀ ਜਾ ਸਕੇ:

Build a mobile-friendly booking app for a small cleaning service.

Actors:
- Customer: browse services, choose a time, pay, and get a confirmation.
- Staff: view bookings, block unavailable times, and manage refunds.

Rules and constraints:
- Bookings are available only during business hours: Monday to Friday, 9am to 5pm.
- Same-day bookings close at 2pm.
- Refunds are allowed only if the customer cancels at least 24 hours before the appointment.
- The main use case is mobile, so booking and payment screens must be simple on a phone.

Version 1 should include:
- service list with prices
- available time slots
- online payment at checkout
- booking confirmation for customers
- a basic staff view for upcoming jobs

Version 1 should not include:
- loyalty rewards
- advanced reporting
- multi-location support
- live chat

ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਅਦਾਕਾਰਾਂ ਨੂੰ ਸਪਸ਼ਟ ਧਰਤੀ 'ਤੇ ਨਾਂ ਦਿੰਦਾ ਹੈ ਅਤੇ ਢਿੱਲੀਆਂ ਮੰਗਾਂ ਨੂੰ ਅਸਲ ਕੰਮਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਸੀਮਾਵਾਂ ਵੀ ਬਰਾਬਰ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਸੀਮਿਤ ਘੰਟੇ ਸਿਸਟਮ ਨੂੰ ਅਸੰਭਵ ਟਾਈਮ ਸਲਾਟ ਦਿਖਾਉਣ ਤੋਂ ਰੋਕਦੇ ਹਨ। ਰਿਫੰਡ ਨਿਯਮ ਭਵਿਖ ਵਿੱਚ ਗਲਤਫਹਮੀ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ। ਮੋਬਾਈਲ ਪ੍ਰਯੋਗ ਵਰਤੋਂ ਤੋਂ ਸ਼ੁਰੂ ਤੋਂ ਹੀ layout ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।

ਨਾਨ-ਗੋਲਸ (non-goals) ਬਿਲਡ ਨੂੰ ਬਚਾਉਂਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਦੇ ਬਿਨਾਂ, ਇੱਕ ਸਧਾਰਨ ਬੁਕਿੰਗ ਐਪ ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਵੱਡੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਬਦਲ ਸਕਦੀ ਹੈ।

ਆਮ ਗਲਤੀਆਂ ਜੋ ਪਹਿਲੀ ਵਰਜ਼ਨ ਨੂੰ ਕਮਜ਼ੋਰ ਬਣਾਉਂਦੀਆਂ ਹਨ

ਇੱਕ ਕਮਜ਼ੋਰ ਪਹਿਲਾ ਵਰਜ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਲਈ ਫੇਲ ਹੁੰਦਾ ਹੈ ਕਿ ਪ੍ਰੌਂਪਟ ਬਹੁਤ ਧੁੰਦਲਾ ਹੁੰਦਾ ਹੈ, ਨ ਕਿ ਕਿਉਂਕਿ ਟੀਮ ਉਸਨੂੰ ਤਿਆਰ ਨਹੀਂ ਕਰ ਸਕਦੀ।

ਇੱਕ ਆਮ ਗਲਤੀ ਫੀਚਰ-ਆਈਡੀਅਜ਼ ਨੂੰ ਕਾਰੋਬਾਰੀ ਨਿਯਮਾਂ ਨਾਲ ਮਿਲਾ ਦੇਣਾ ਹੈ। ਇੱਕ founder ਕਹਿ ਸਕਦਾ ਹੈ, "We need a dashboard, filters, and alerts," ਪਰ ਅਸਲ ਨਿਯਮ ਹੋ ਸਕਦਾ ਹੈ: "Only managers can approve refunds above a set amount." ਜੇ ਉਹ ਨਿਯਮ ਇੱਕ wish list ਦੇ ਵਿੱਚ ਛੁਪ ਜਾਂਦਾ ਹੈ ਤਾਂ ਪਹਿਲਾ ਬਿਲਡ polished ਦਿੱਸ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ।

ਦੂਜਾ ਸਮੱਸਿਆ founder ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ ਹੀ ਲਿਖਣਾ ਹੈ। founders ਅਕਸਰ ਉਹ ਦਿਖਾਉਂਦੇ ਹਨ ਜੋ ਉਹ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹਨ, ਨਾ ਕਿ ਹਰ ਉਪਭੋਗਤਾ ਨੂੰ ਕੀ ਕਰਨਾ ਪੈਣਾ। sales rep, operations manager, ਅਤੇ support agent ਇਕੋ ਐਪ ਨੂੰ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਵਰਤ ਸਕਦੇ ਹਨ। ਜੇ ਪ੍ਰੌਂਪਟ ਸਿਰਫ਼ leadership ਦੇ ਹਿਤਾਂ ਨੂੰ ਦਰਸਾਂਦਾ ਹੈ ਤਾਂ ਰੋਜ਼ਾਨਾ ਕੰਮ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

ਸਭ ਤੋਂ ਆਮ ਗਲਤੀਆਂ ਹਨ:

• ਵਿਚਾਰਾਂ, ਨਿਯਮਾਂ ਅਤੇ ਅਨੁਮਾਨਾਂ ਨੂੰ ਇਕੋ ਸਮਾਨ ਮੰਨਣਾ
• ਐਪ ਨੂੰ ਇੱਕ ਵਿਅਕਤੀ ਲਈ ਵਰਣਨ ਕਰਨਾ ਬਜਾਏ ਸਾਰੇ ਮੁੱਖ ਉਪਭੋਗਤਿਆਂ ਲਈ
• edge cases ਜਿਵੇਂ partial payments, late approvals, ਜਾਂ duplicate records ਨੂੰ ਛੱਡ ਦੇਣਾ
• approval ਕਦਮ ਨੂੰ ਧੁੰਦਲਾ ਛੱਡਣਾ, ਬਿਨਾਂ ਟ੍ਰਿਗਰ, ਮਾਲਕ, ਜਾਂ ਡੈਡਲਾਈਨ ਦੇ
• ਪੂਰੇ ਰੋਡਮੇਪ ਨੂੰ ਵਰਜ਼ਨ 1 ਵਿੱਚ ਫਿੱਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ

"order approval" ਲਓ। ਇਹ ਸੁਣਨ ਵਿੱਚ ਸਪਸ਼ਟ ਲੱਗਦਾ ਹੈ, ਪਰ ਨਹੀਂ। ਕੌਣ ਉਸਨੂੰ ਮਨਜ਼ੂਰ ਕਰੇਗਾ? ਜੇ approver ਗੈਰਹਾਜ਼ਰ ਹੋਵੇ ਤਾਂ ਕੀ ਹੋਵੇਗਾ? ਕੀ ਹਰ order ਦੀ ਮਨਜ਼ੂਰੀ ਲੋੜੀਂਦੀ ਹੈ ਜਾਂ ਸਿਰਫ਼ thresholds ਤੋਂ ਉੱਪਰ ਵਾਲੀਆਂ ਲਈ? ਇਹ ਵੇਰਵੇ ਬਿਲਡ ਨੂੰ ਬਦਲਦੇ ਹਨ।

ਜਦੋਂ ਟੀਮਾਂ ਤੇਜ਼ ਐਪ-ਬਿਲਡਿੰਗ ਟੂਲ ਵਰਤਦੀਆਂ ਹਨ ਤਾਂ ਇਹ ਖਾਮੀਆਂ ਜਲਦੀ ਸਾਹਮਣੇ ਆ ਜਾਂਦੀਆਂ ਹਨ। ਇੱਕ ਵਧੀਆ ਪ੍ਰੌਂਪਟ ਤੁਹਾਨੂੰ ਇੱਕ ਪਹਿਲੀ ਵਰਜ਼ਨ ਦਿੰਦਾ ਹੈ ਜਿਸ ਦੀ ਲੋਕ ਅਸਲ ਵਿੱਚ ਟੈਸਟ ਕਰ ਸਕਣ, ਨਾ ਕਿ ਸਿਰਫ਼ ਪ੍ਰਤਿਕਿਰਿਆ ਦੇ ਸਕਣ।

ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਤੁਰੰਤ ਚੈੱਕਲਿਸਟ

ਪ੍ਰੌਂਪਟ-builder ਨੂੰ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟੀ-ਜਿਹੀ ਸਮੀਖਿਆ ਕਰੋ। ਇਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਢੀਲੇ ਨੋਟਸ ਸਪਸ਼ਟ ਨਿਰਦੇਸ਼ ਬਣ ਜਾਂਦੇ ਹਨ।

ਪਹਿਲਾਂ ਕੀ ਪੁਸ਼ਟ ਕਰੋ

• Actors ਆਸਾਨੀ ਨਾਲ ਨਾਂ ਦਿੱਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਤੁਸੀਂ ਹਰ ਉਪਭੋਗਤਾ ਕਿਸਮ ਦੇ ਨਾਮ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਲਿਸਟ ਕਰ ਸਕਦੇ ਹੋ।
• ਹਰ actor ਦੇ ਅਸਲੀ ਕਾਰਜ ਹਨ। ਹਰ actor ਕੋਲ 2-5 ਸਪਸ਼ਟ ਐਕਸ਼ਨ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
• Limits ਲਿਖੇ ਗਏ ਹਨ। ਅਜਿਹੇ ਨਿਯਮ ਸ਼ਾਮਲ ਕਰੋ ਜਿਵੇਂ approval steps, privacy needs, mobile ਵਰਤੋਂ, ਜਾਂ ਲਾਜ਼ਮੀ ਟੂਲ।
• Examples ਇਸਨੂੰ ठੋਸ ਬਣਾਉਂਦੇ ਹਨ। ਇੱਕ ਸਧਾਰਨ ਕੇਸ ਅਤੇ ਇੱਕ edge case ਜੋੜੋ।
• Non-goals ਦਿੱਖ ਰਹੇ ਹਨ। ਵਰਜ਼ਨ 1 ਵਿੱਚ ਕੀ ਨਹੀਂ ਸ਼ਾਮਲ, ਇਹ ਸਪਸ਼ਟ ਕਰੋ।

ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਣ ਫਰਕ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ। "Staff creates bookings" ਪਤਲਾ ਹੈ। ਇੱਕ ਮਜ਼ਬੂਤ ਪ੍ਰੌਂਪਟ ਕਹੇਗਾ ਕਿ staff create, edit, ਅਤੇ cancel bookings ਕਰ ਸਕਦੇ ਹਨ, managers exceptions approve ਕਰ ਸਕਦੇ ਹਨ, double-booking block ਹੋਵੇ, ਅਤੇ version 1 invoicing ਸ਼ਾਮਲ ਨਹੀਂ ਕੀਤਾ ਗਿਆ।

ਜੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਟੁੱਟ ਰਹੇ ਹਨ ਤਾਂ ਰੁਕੋ ਅਤੇ ਠੀਕ ਕਰੋ। ਇੱਕ ਛੋਟੀ, ਪੂਰੀ ਪ੍ਰੌਂਪਟ ਲੰਮੀ ਪਰ ਖਾਮੀਆਂ ਵਾਲੀ ਪ੍ਰੌਂਪਟ ਨਾਲੋਂ ਬਿਹਤਰ ਹੁੰਦੀ ਹੈ।

ਪਹਿਲੇ ਬਿਲਡ ਲਈ ਸੁਧਾਰਣ ਵਾਲੇ ਅਗਲੇ ਕਦਮ

ਕਾਲ ਖਤਮ ਹੋਣ ਤੋਂ ਬਾਅਦ ਨੋਟਸ ਨੂੰ chat, docs ਅਤੇ ਯਾਦ ਵਿੱਚ ਨਾ ਛੱਡੋ। ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝਾ ਬਿਲਡ ਬ੍ਰੀਫ਼ ਵਿੱਚ ਬਦਲੋ ਜੋ ਕੋਈ ਵੀ ਕੁਝ ਮਿੰਟ ਵਿੱਚ ਪੜ੍ਹ ਸਕੇ। ਉਹ ਬ੍ਰੀਫ਼ ਉਪਭੋਗਤਿਆਂ, ਮੁੱਖ ਕਾਰਜਾਂ, ਨਿਯਮਾਂ, ਉਦਾਹਰਣਾਂ ਅਤੇ non-goals ਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਕੈਪਚਰ ਕਰੇ।

ਫਿਰ ਵਰਜ਼ਨ 1 ਦੇ ਸਕੋਪ 'ਤੇ ਸਾਈਨ-ਆਫ਼ ਲਵੋ। ਪੂਰੇ ਉਤਪਾਦ ਦੀ ਮਨਜ਼ੂਰੀ ਨਹੀਂ — ਸਿਰਫ਼ ਇਹ ਕਿ ਵਰਜ਼ਨ 1 ਕੀ ਕਰੇਗਾ ਅਤੇ ਕੀ ਨਹੀਂ। ਇਹ ਛੋਟਾ ਕਦਮ ਉਸ ਆਮ ਸਮੱਸਿਆ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ਇੱਕ ਵਿਅਕਤੀ ਨੂੰ ਡੈਮੋ ਦੀ ਉਮੀਦ ਹੋਵੇ ਅਤੇ ਦੂਜਾ ਵਿਅਕਤੀ ਟੋਟੇ-ਟੂਟੇ ਲੰਮੀ ਚੀਜ਼ ਦੀ ਉਮੀਦ ਕਰੇ।

ਇੱਕ ਚੰਗਾ ਪਹਿਲਾ-ਵਰਜ਼ਨ ਸਕੋਪ ਚਾਰ ਗੱਲਾਂ ਦਾ ਉੱਤਰ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ:

• ਇਹ ਅਜੇ ਲਈ ਕਿਸ ਲਈ ਹੈ?
• ਉਹ 3-5 ਕਾਰਵਾਈਆਂ ਕੀ ਹਨ ਜੋ ਪਹਿਲਾਂ ਕੰਮ ਕਰਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ?
• ਕਿਹੜੀਆਂ ਸੀਮਾਵਾਂ ਟੁੱਟਣ ਯੋਗ ਨਹੀਂ ਹਨ?
• ਇਸ ਰਾਊਂਡ ਲਈ ਖਾਸ ਤੌਰ 'ਤੇ ਕੀ ਬਾਹਰ ਹੈ?

ਕਿਸੇ ਵੀ ਜਨਰੇਟਿੰਗ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਪਲੈਨਿੰਗ ਪਾਸ ਕਰੋ। ਰੌਅ ਨੋਟਸ ਨੂੰ ਇਕ ਵਰਤੋਂਯੋਗ ਬਿਲਡ ਪ੍ਰੌਂਪਟ ਵਿੱਚ ਬਦਲੋ, ਗੁੰਝਲਦਾਰ ਚੀਜ਼ਾਂ ਲਈ ਜਾਂਚ ਕਰੋ, ਅਤੇ "simple," "fast," ਜਾਂ "user-friendly" ਵਰਗੇ ਢਿੱਲੇ ਸ਼ਬਦ ਹਟਾਓ। ਇਹ ਸ਼ਬਦ ਲਾਭਕਾਰੀ ਲੱਗਦੇ ਹਨ ਪਰ ਅਕਸਰ ਨਿਰਮਾਤਾ ਨੂੰ ਨਹੀਂ ਦੱਸਦੇ ਕਿ ਕੀ ਬਣਾਉਣਾ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, "make client onboarding easy" ਦੀ ਥਾਂ ਲਿਖੋ: "A new client can submit their business name, contact details, project type, and budget in one form, then receive a confirmation screen."

ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਯੋਜਨਾ ਬਣਾਉਣ ਦਾ ਕਦਮ planning mode ਨਾਲ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਫਿੱਟ ਹੁੰਦਾ ਹੈ। ਇਹ ਟੀਮਾਂ ਨੂੰ ਜਨਰੇਸ਼ਨ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਐਪ ਨੂੰ ਸ਼ੇਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਅਤੇ snapshots ਨਾਲ ਪ੍ਰੌਂਪਟ ਬਦਲਾਅ ਦੀਆਂ ਕਿਸਮਤਾਂ ਬਿਨਾਂ ਮੌਜੂਦਾ ਵਰਜ਼ਨ ਖੋਣ ਦੇ ਟੈਸਟ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ।

ਮਕਸਦ ਦਿਨ 1 'ਤੇ ਪਰਫੈਕਟ ਪ੍ਰੌਂਪਟ ਨਹੀਂ ਹੈ। ਮਕਸਦ ਇੱਕ ਸਾਂਝਾ, ਮਨਜ਼ੂਰ ਕੀਤਾ ਪ੍ਰੌਂਪਟ ਹੈ ਜੋ ਪਹਿਲੇ ਬਿਲਡ ਨੂੰ ਸਹੀ ਦਿਸਾ ਦਿੰਦਾ ਹੈ। ਜਦੋਂ ਬ੍ਰੀਫ਼ ਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਪਹਿਲੀ ਵਰਜ਼ਨ ਦੀ ਸਮੀਖਿਆ ਆਸਾਨ ਹੁੰਦੀ ਹੈ, ਸੁਧਾਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਅਸਲ ਕਾਰੋਬਾਰੀ ਜ਼ਰੂਰਤ ਤੋਂ ਗੁੰਮ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਕਾਫ਼ੀ ਘੱਟ ਹੋ ਜਾਂਦੀ ਹੈ।