06 ਦਸੰ 2025·8 ਮਿੰਟ
ਤਕਨੀਕੀ ਫਾਊਂਡਰ: ਕੋਡ ਤੋਂ ਬਿਹਤਰ ਫੈਸਲਿਆਂ ਵੱਲ ਕਿਵੇਂ ਬਦਲਣਾ
ਤਕਨੀਕੀ ਫਾਊਂਡਰਾਂ ਕਿਵੇਂ ਕੋਡ ਲਿਖਣ ਤੋਂ ਹਟ ਕੇ ਬਿਹਤਰ ਫੈਸਲੇ ਲੈਂਦੇ ਹਨ: ਬੇਟਸ ਦੀ ਤਰਜੀਹ, ਪ੍ਰੋਡਕਟ ਸੌਝ ਬਣਾਉਣਾ, ਅਤੇ ਟੀਮਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਜਿਵੇਂ ਕੰਪਨੀ ਵਧਦੀ ਹੈ।
ਤਕਨੀਕੀ ਫਾਊਂਡਰਾਂ ਕਿਵੇਂ ਕੋਡ ਲਿਖਣ ਤੋਂ ਹਟ ਕੇ ਬਿਹਤਰ ਫੈਸਲੇ ਲੈਂਦੇ ਹਨ: ਬੇਟਸ ਦੀ ਤਰਜੀਹ, ਪ੍ਰੋਡਕਟ ਸੌਝ ਬਣਾਉਣਾ, ਅਤੇ ਟੀਮਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਜਿਵੇਂ ਕੰਪਨੀ ਵਧਦੀ ਹੈ।
ਸ਼ੁਰੂਆਤੀ ਦੌਰ ਵਿੱਚ, ਤਕਨੀਕੀ ਫਾਊਂਡਰ ਦਾ ਕੰਮ ਅਕਸਰ ਲਗਦਾ ਹੈ: “ਸਭ ਕੁਝ ਬਣਾਓ.” ਤੁਸੀਂ ਜ਼ਿਆਦਾਤਰ ਕੋਡ ਲਿਖਦੇ ਹੋ, ਮਿੰਟਾਂ ਵਿੱਚ ਫਿਕਸ ਸ਼ਿਪ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਫੈਸਲੇ ਐਡੀਟਰ ਖੋਲ੍ਹਕੇ ਲਏ ਜਾਂਦੇ ਹਨ। ਇਹ ਦੌਰ ਅਸਲੀ ਅਤੇ ਕੀਮਤੀ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਤੇਜ਼ੀ ਅਤੇ ਤਕਨੀਕੀ ਸਹਿਮਤੀ ਪੋਲਿਸ਼ ਤੋਂ ਅਹੰਕਾਰਾਂ ਮੁਕਤ ਹੁੰਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਬਣਾ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸਿੱਖ ਸਕਦੇ ਹੋ।
ਪਰ ਜਦੋਂ ਕੰਪਨੀ ਕੰਮ ਕਰਨ ਲੱਗਦੀ ਹੈ (ਵੱਧੀ ਹੋਈ ਯੂਜ਼ਰ ਬੇਸ, ਰੈVenue, ਉਮੀਦਾਂ), ਕੰਮ ਖਾਮੋਸ਼ੀ ਨਾਲ ਬਦਲ ਜਾਂਦਾ ਹੈ—ਭਾਵੇਂ ਤੁਹਾਡਾ ਟਾਈਟਲ ਨਾ ਬਦਲੇ। ਹੁਣ ਤੁਸੀਂ "ਕੀ ਅਸੀਂ ਇਹ ਬਣਾ ਸਕਦੇ ਹਾਂ?" ਦੀ ਥਾਂ "ਕੀ ਅਸੀਂ ਇਹ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਸ ਲਈ ਅਸੀਂ ਕਿੰਨੀ ਤੋਂ ਕੱਢ ਰਹੇ ਹਾਂ?" ਦੇ ਲਈ ਅਪਟੀਮਾਈਜ਼ ਕਰ ਰਹੇ ਹੋ। ਕੰਮ ਘੱਟ ਹੋ ਕੇ ਫੀਚਰ ਬਣਾਉਣ ਤੱਕ ਨਹੀਂ ਰਹਿੰਦਾ—ਇਹ ਸਿਸਟਮ ਨੂੰ ਸੰਵਾਰਨ (ਪ੍ਰੋਡਕਟ, ਟੀਮ, ਪ੍ਰਕਿਰਿਆ) ਬਾਰੇ ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ ਕਿ ਸਹੀ ਫੀਚਰ ਬਣਨ।
ਬਿਲਡ ਫੇਜ਼ ਵਿੱਚ ਤਰੱਕੀ ਆਮ ਤੌਰ 'ਤੇ ਲੀਨੀਅਰ ਹੁੰਦੀ ਹੈ: ਜ਼ਿਆਦਾ ਘੰਟੇ ਕੋਡ ਕਰਨ ਨਾਲ ਅਕਸਰ ਜ਼ਿਆਦਾ ਉਤਪਾਦ ਸ਼ਿਪ ਹੁੰਦਾ ਹੈ। ਸੰਚਾਰ ਹਲਕਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਫੈਸਲੇ ਵਾਪਸ ਯੋਗ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਸਰਫੇਸ ਏਰੀਆ ਛੋਟੀ ਹੁੰਦੀ ਹੈ।
ਸਕੇਲਿੰਗ ਫੇਜ਼ ਵਿੱਚ ਤਰੱਕੀ ਗੈਰ-ਲੀਨੀਅਰ ਹੋ ਜਾਂਦੀ ਹੈ। ਹਰ ਨਵਾਂ ਫੀਚਰ ਮੌਜੂਦਾ ਗਾਹਕਾਂ, ਸਪੋਰਟ ਲੋਡ, ਸੇਲਜ਼ ਵਾਅਦਿਆਂ, ਇੰਫ੍ਰਾ ਸੀਮਾਵਾਂ ਅਤੇ ਹੋਰ ਇੰਜੀਨੀਅਰਾਂ ਦੇ ਕੰਮ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਦਾ ਹੈ। "ਸਿਰਫ਼ ਸ਼ਿਪ ਕਰੋ" ਛੁਪੇ ਖਰਚੇ ਬਣਾਉਂਦਾ ਹੈ: ਹੋਰ ਬੱਗ, ਢਿੱਲਾ onboarding, ਮੁਸ਼ਕਲ ਡਿਪਲੌਏਮੈਂਟ ਅਤੇ ਇਕ ਬੈਕਲੌਗ ਜੋ ਉਸ ਦੀ ਅਦਾਇਗੀ ਦੀ ਸਮਰੱਥਾ ਤੋਂ ਤੇਜ਼ ਵਧਦਾ ਹੈ।
ਤੁਹਾਡੀ ਲੀਵਰੇਜ ਬਦਲਦੀ ਹੈ। ਸਭ ਤੋਂ ਵੱਧ ਪ੍ਰਭਾਵ ਵਾਲੀ ਗੱਲ ਅਕਸਰ "ਅਗਲਾ ਮੋਡੀਊਲ ਲਿਖਣਾ" ਨਹੀਂ ਰਹਿੰਦੀ। ਇਹ ਇਹ ਫੈਸਲਾ ਕਰਨਾ ਹੁੰਦਾ ਹੈ ਕਿ ਟੀਮ ਨੂੰ ਅਗਲੇ ਕਦਮ ਕੀ ਬਣਾਉਣੇ ਚਾਹੀਦੇ ਨੇ, ਮਿਆਰ ਕਿੱਥੇ ਗੈਰ-ਨਿਗੋਸ਼ੀਏਬਲ ਹਨ ਅਤੇ ਕਿੱਥੇ ਤੇਜ਼ੀ ਠੀਕ ਹੈ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਉਹ ਹੋਰ ਲੋਕ ਬਿਨਾਂ ਲਗਾਤਾਰ ਸਹੀ ਕਰਨ ਦੇ ਨਿਭਾ ਸਕਣ।
ਇਸਦਾ ਅਰਥ ਹੈ ਕਿ ਤੁਸੀਂ ਅਧੂਰੇ ਡੇਟਾ ਨਾਲ ਵੱਧ ਫੈਸਲੇ ਲੈਣੇ ਪੈਣਗੇ। ਹਰ ਵਿਕਲਪ ਦੀ ਪੂਰੀ ਖੋਜ ਕਰਨ ਦਾ ਸਮਾਂ ਨਹੀਂ ਹੋਵੇਗਾ। ਯਕੀਨ ਦੀ ਉਡੀਕ ਆਪਣੇ ਆਪ ਇਕ ਫੈਸਲਾ ਬਣ ਸਕਦੀ ਹੈ—ਅਤੇ ਅਕਸਰ ਗਲਤ।
ਜਿਵੇਂ ਤੁਸੀਂ ਸਕੇਲ ਕਰੋਗੇ, "ਜ਼ਿਆਦਾ ਕੋਡ" ਦੀ ਜਗ੍ਹਾ ਤਿੰਨ ਹੁਨਰ ਮੁੱਖ ਸਾਧਨ ਬਣ ਜਾਂਦੇ ਹਨ:
ਜਿਵੇਂ ਇਹ ਹੁਨਰ ਮਜ਼ਬੂਤ ਹੁੰਦੇ ਹਨ, ਤੁਹਾਡਾ ਨਤੀਜਾ ਕੋਡ ਦੀ ਲਾਈਨਾਂ ਤੋਂ ਬਦਲ ਕੇ ਵਧੀਆ ਫੈਸਲਿਆਂ ਵੱਲ ਹੋ ਜਾਂਦਾ ਹੈ—ਓਹ ਫੈਸਲੇ ਜੋ ਪੂਰੀ ਕੰਪਨੀ 'ਤੇ ਸੰਯੁਕਤ ਪ੍ਰਭਾਵ ਪਾਂਦੇ ਹਨ।
ਸ਼ੁਰੂ ਵਿੱਚ, ਇੱਕ ਤਕਨੀਕੀ ਫਾਊਂਡਰ ਦਾ ਫਾਇਦਾ ਸਾਫ ਹੋਂਦਾ ਹੈ: ਤੁਸੀਂ ਬਣਾ ਸਕਦੇ ਹੋ। ਕੰਪਨੀ ਅੱਗੇ ਵਧਦੀ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਵਿਚਾਰਾਂ ਨੂੰ ਕੰਮ ਕਰਨ ਵਾਲੇ ਸਾਫਟਵੇਅਰ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹੋ।
ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਅਸਲ ਯੂਜ਼ਰ ਅਤੇ ਵਧਦੀ ਟੀਮ ਹੁੰਦੀ ਹੈ, ਤਿੱਡਾ ਰੁਕਾਵਟ ਹੁਣ "ਕੀ ਅਸੀਂ ਇਹ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹਾਂ?" ਨਹੀਂ ਰਹਿੰਦੀ, بلکہ "ਕੀ ਅਸੀਂ ਇਹ ਹੁਣ ਇਸ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?"। ਇਹ ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਆਉਟਪੁੱਟ ਤੋਂ ਫੈਸਲਾ-ਸਮਰੱਥਾ ਵੱਲ ਇੱਕ ਤਬਦੀਲੀ ਹੈ।
ਫੈਸਲਾ-ਸਮਰੱਥਾ ਉੱਚ-ਗੁਣਵੱਤਾ ਵਾਲੇ ਫੈਸਲੇ ਅਣਨਿਸ਼ਚਿਤਤਾ ਹੇਠਾਂ ਲੈਣ ਦੀ ਸਮਰੱਥਾ ਹੈ।
ਨਾਹੀਂ ਪਰਫੈਕਟ ਫੈਸਲੇ। ਨਾ ਉਹ ਫੈਸਲੇ ਜੋ ਸਾਰੇ ਖਤਰੇ ਹਟਾ ਦੇਣ ਵਾਲੇ ਸਪ੍ਰੈਡਸ਼ੀਟਾਂ ਨਾਲ ਹੋਣ। ਉੱਚ-ਗੁਣਵੱਤਾ ਵਾਲੇ ਫੈਸਲੇ ਮੌਜੂਦਾ ਜਾਣਕਾਰੀ ਦੇ ਹਿਸਾਬ ਨਾਲ ਵਾਜਿਬ ਹੁੰਦੇ ਹਨ—ਅਤੇ ਜਦੋਂ ਹਕੀਕਤ ਬਦਲਦੀ ਹੈ ਤਾਂ ਕੰਪਨੀ ਨੂੰ ਲਚਕੀਲਾ ਰੱਖਦੇ ਹਨ।
ਟੈਕਨੀਕੀ ਸਹੀਪਣ ਇਹ ਪੁੱਛਦਾ ਹੈ: "ਕੀ ਇਹ ਸਾਫ-ਸੁਥਰਾ ਡਿਜ਼ਾਈਨ ਹੈ? ਕੀ ਇਹ ਸਕੇਲਬਲ ਹੈ? ਕੀ ਇਹ ਸੁੰਦਰ ਹੈ?"
ਬਿਜ਼ਨਸ ਸਹੀਪਣ ਪੁੱਛਦਾ ਹੈ: "ਕੀ ਇਹ ਇਸ ਕ੍ਵਾਰਟਰ ਵਿੱਚ ਕੰਪਨੀ ਨੂੰ ਅੱਗੇ ਵਧਾਉਂਦਾ ਹੈ? ਕੀ ਇਹ ਸਹੀ ਯੂਜ਼ਰ ਦੀ ਮਦਦ ਕਰਦਾ ਹੈ? ਕੀ ਇਹ ਸਿੱਖਣ ਦੀ ਰਫ਼ਤਾਰ, ਰੈVenue, ਰੀਟੇਨਸ਼ਨ ਜਾਂ ਭਰੋਸਾ ਵਧਾਉਂਦਾ ਹੈ?"
ਇੱਕ ਟੈਕਨੀਕੀ ਤੌਰ ਤੇ ਸਹੀ ਫੈਸਲਾ ਬਿਜ਼ਨਸ ਤੌਰ ਤੇ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਣ ਵਜੋਂ: ਦੋ ਹਫ਼ਤੇ ਇੱਕ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਪਰਫੈਕਟ ਕਰਨ ਵਿੱਚ ਲਗਾਉਣਾ ਇੰਜੀਨੀਅਰਿੰਗ ਲਈ "ਠੀਕ" ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਜੇ ਇਸ ਨਾਲ ਉਹ ਫੀਚਰ ਦੇਰ ਹੋ ਰਿਹਾ ਹੈ ਜੋ ਡੀਲਜ਼ ਬੰਦ ਕਰਦਾ ਜਾਂ ਚਰਨ ਘਟਾਉਂਦਾ, ਤਾਂ ਇਹ ਬਿਜ਼ਨਸ-ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ।
ਜਿਵੇਂ ਤੁਸੀਂ ਫੈਸਲਾ ਕਰਨ ਵਾਲੇ ਬਣਦੇ ਹੋ, ਤੁਸੀਂ ਤੁਰੰਤ ਨਤੀਜੇ ਤੋਂ ਪਰੇ ਦੇਖਣ ਲੱਗਦੇ ਹੋ। ਇਕ ਚੋਣ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ:
ਰੀਵਰਸੀਬਿਲਿਟੀ: ਪੁੱਛੋ "ਜੇ ਅਸੀਂ ਗਲਤ ਹੋਏ ਤਾਂ ਵਾਪਸ ਕਰਨਾ ਕਿੰਨਾ ਔਖਾ ਹੈ?" ਰਿਵਰਸੀਬਲ ਫੈਸਲੇ ਛੋਟੇ ਤੇਜ਼ ਬੇਟ ਨਾਲ ਕੀਤੇ ਜਾ ਸਕਦੇ ਨੇ। ਅਣਰਿਵਰਸੀਬਲ ਫੈਸਲਿਆਂ ਨੂੰ ਵੱਧ ਚਰਚਾ, ਪ੍ਰੋਟੋਟਾਈਪ ਜਾਂ ਸਟੇਜਡ ਰੋਲਆਉਟ ਚਾਹੀਦਾ ਹੈ।
ਡੇਲੀ ਦੀ ਲਾਗਤ: ਪੁੱਛੋ "ਰੁਕਣ ਨਾਲ ਅਸੀਂ ਕੀ ਗੁਆ ਰਹੇ ਹਾਂ?" ਕਈ ਵਾਰੀ ਸਭ ਤੋਂ ਵੱਡੀ ਲਾਗਤ ਪੈਸੇ ਨਹੀਂ ਹੁੰਦੀ—ਇਹ ਹੈ ਗੁਆਇਆ ਸਿੱਖਣਾ, ਮੁਕਾਬਲੇ ਦਾ ਫਾਇਦਾ, ਜਾਂ ਹੱਫ਼ਤੇ ਜਦੋਂ ਟੀਮ ਗਲਤ ਚੀਜ਼ ਬਣਾ ਰਹੀ ਹੋਵੇ।
ਫਾਊਂਡਰ ਦਾ ਵਿਕਾਸ ਉਹਨਾਂ ਲੈਂਸਾਂ ਨੂੰ ਲਗਾਤਾਰ ਅਪਲਾਈ ਕਰਨਾ ਸਿੱਖਣਾ ਹੈ, ਤਾਂ ਜੋ ਕੰਪਨੀ ਘੁੰਮਫਿਰ ਕੇ ਨਹੀਂ ਦੌੜੇ—ਬਲਕਿ ਸੋਚ-ਵਿਚਾਰ ਨਾਲ, ਸੰਯੁਕਤ ਤੌਰ 'ਤੇ ਅੱਗੇ ਵਧੇ।
ਸ਼ੁਰੂ ਵਿੱਚ, "ਵਧੀਆ ਇੰਜੀਨੀਅਰਿੰਗ" ਅਕਸਰ "ਵਧੀਆ ਕੰਪਨੀ" ਦੇ ਬਰਾਬਰ ਹੁੰਦੀ ਹੈ। ਸਾਫ ਕੋਡ, ਮਜ਼ਬੂਤ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਪੋਲਿਸ਼ਡ ਇੰਫ੍ਰਾਸਟ੍ਰਕਚਰ ਤੁਹਾਨੂੰ ਭਵਿੱਖ ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।
ਪਰ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਯੂਜ਼ਰ, ਡੈੱਡਲਾਈਨ ਅਤੇ ਘੱਟ ਰਨਵੇ ਹੁੰਦੀ ਹੈ, ਇਹ ਸੰਰੂਪ ਟੁੱਟ ਸਕਦਾ ਹੈ। ਇੱਕ ਚੋਣ ਤਕਨੀਕੀ ਤੌਰ ਤੇ ਸਹੀ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਬਿਜ਼ਨਸ ਲਈ ਗਲਤ ਹੋ ਸਕਦੀ ਹੈ।
ਤਕਨੀਕੀ ਫਾਊਂਡਰ ਅਕਸਰ ਉਸ ਕੰਮ ਵੱਲ ਡਿਫਾਲਟ ਕਰਦੇ ਹਨ ਜੋ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਅਤੇ ਸੰਤੋਸ਼ਜਨਕ ਲੱਗਦਾ ਹੈ: ਸੁੰਦਰ abstraction, ਪਰਫੈਕਟ ਸਮਾਧਾਨ, ਉਹ ਟੂਲ ਜੋ ਤੁਹਾਨੂੰ ਵਰਗਾ ਕਰਨਾ ਹੈ।
ਇਹ ਲੇਜ਼ੀਪਨ ਨਹੀਂ—ਇਹ ਇਕ ਪੱਖਪਾਤ ਹੈ। ਦਿਲਚਸਪ ਟੈਕ ਤੁਰੰਤ ਫੀਡਬੈਕ ਅਤੇ ਤਰੱਕੀ ਦਾ ਅਹਿਸਾਸ ਦਿੰਦਾ ਹੈ, ਜਦਕਿ ਗੁੰਝਲਦਾਰ ਗਾਹਕ ਸਮੱਸਿਆਵਾਂ ਅਸਪਸ਼ਟ ਅਤੇ ਭਾਵਨਾਤਮਕ ਤੌਰ 'ਤੇ ਔਖੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।
ਇਕ ਲੋਕਲ ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਸਿਸਟਮ ਦੇ ਇੱਕ ਹਿੱਸੇ ਨੂੰ ਸੁਧਾਰਦਾ ਹੈ (ਕੋਡ ਕ੍ਵਾਲਿਟੀ, ਟੈਸਟ ਕਵਰੇਜ, ਲੇਟੈਂਸੀ, ਅੰਦਰੂਨੀ ਟੂਲਿੰਗ)। ਇੱਕ ਗਲੋਬਲ ਨਤੀਜਾ ਉਹ ਹੈ ਜੋ ਕੰਪਨੀ ਦੇ ਲਕੜੀ-ਮਕਸਦ ਨੂੰ ਸੁਧਾਰਦਾ ਹੈ (ਰੀਟੇਨਸ਼ਨ, ਰੈVenue, ਐਕਟੀਵੇਸ਼ਨ, ਘੱਟ ਸਪੋਰਟ ਟਿਕਟ, ਤੇਜ਼ ਸੇਲਜ਼ ਸਾਈਕਲ)।
ਫਸਲ ਇਹ ਹੈ ਕਿ "ਅਸੀਂ ਸਿਸਟਮ ਸੁਧਾਰਿਆ" ਨੂੰ "ਅਸੀਂ ਕੰਪਨੀ ਸੁਧਾਰ ਕੀਤੀ" ਸਮਝ ਲਿਆ ਜਾਵੇ। ਜੇ ਸੁਧਾਰ ਗਾਹਕ ਦੇ ਅਨੁਭਵ ਨੂੰ ਨਹੀਂ ਬਦਲਦਾ ਜਾਂ ਅਗਲੇ ਮਹੀਨੇ ਟੀਮ ਜੋਸ਼ ਨਾਲ ਜੋ ਕੁੱਝ ਸ਼ਿਪ ਕਰ ਸਕਦੀ ਉਹ ਨਹੀਂ ਬਦਲਦਾ, ਤਾਂ ਇਹ ਅਜੇ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੋ ਸਕਦਾ।
ਮੌਕਾ ਲਾਗਤ ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਚੁਣ ਕੇ ਗੁਆ ਰਹੇ ਹੋ। ਇਹ konkrete ਹੈ:
ਤੁਸੀਂ ਮੌਕਾ ਲਾਗਤ ਬਾਅਦ ਵਿੱਚ ਨਹੀਂ ਚੁਕਾਉਂਦੇ—ਤੁਸੀਂ ਉਸ ਨੂੰ ਤੁਰੰਤ ਭੁਗਤਦੇ ਹੋ, ਘੁਆਇਆ ਗਿਆ ਸਿੱਖਣਾ ਅਤੇ ਗੁਆਇਆ ਮੁਮਕਿਨੀਤਾਂ ਰੂਪ ਵਿੱਚ।
Refactor vs. ship: ਰੀਫੈਕਟਰ ਭਵਿੱਖ ਦਾ ਦਰਦ ਘਟਾ ਸਕਦਾ ਹੈ, ਪਰ ਇੱਕ ਛੋਟੀ, "ਅੱਛੀ-ਕਾਫ਼ੀ" ਸੁਧਾਰ ਸ਼ਿਪ ਕਰਨਾ ਕੀਮਤ ਜਾਂ ਸੇਲਜ਼ ਨੂੰ ਅਨਗੇoteric validation ਦੇ ਸਕਦਾ ਹੈ।
Infra upgrades vs. customer wins: 50ms ਜਵਾਬ ਵੇਲਾ ਘਟਾਉਣਾ ਮਾਪਯੋਗ ਲਗਦਾ ਹੈ, ਪਰ ਇੱਕ ਸਾਫ਼ ਵਰਕਫਲੋ ਜਾਂ ਮੁੱਖ ਪਾਥ ਵਿੱਚ ਘੱਟ ਬੱਗ retention ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਕਰ ਸਕਦਾ ਹੈ।
ਮਕਸਦ ਇੰਜੀਨੀਅਰਿੰਗ ਸ਼ਾਨਦਾਰਤਾ ਨੂੰ ਨਜ਼ਰਅੰਦاز ਕਰਨ ਦਾ ਨਹੀਂ—ਇਹ ਉਸਨੂੰ ਸਮੇਂ 'ਤੇ ਲਾਉਣ ਦਾ ਹੈ। ਸ਼ਾਨਦਾਰ ਫਾਊਂਡਰ ਪੁਛਦੇ ਹਨ: "ਕੰਪਨੀ ਨੂੰ ਅਗਲੇ ਵਿੱਚ ਕੀ ਲੋੜ ਹੈ—ਅਤੇ ਸਿੱਖਣ ਲਈ ਸਭ ਤੋਂ ਸਸਤੀ ਰਸਤਾ ਕੀ ਹੈ?"
ਇੱਕ ਬੈਕਲੌਗ ਆਰਾਮਦਾਇਕ ਲੱਗਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ 'ਵਧੀਆ ਆਈਡੀਜ' ਦੀ ਸੂਚੀ ਹੈ। ਰਣਨੀਤੀ ਮੁਸ਼ਕਲ ਹੈ: ਇਹ ਤੁਹਾਨੂੰ ਚੁਣਨ 'ਤੇ ਮਜ਼ਬੂਰ ਕਰਦੀ ਹੈ ਕਿ ਕੀ ਨਹੀਂ ਕਰਨਾ।
ਤਰਜੀਹ بندی ਸਰਵੋਤਮ ਰੈਂਕਿੰਗ ਖੋਜਣ ਦੀ ਗੱਲ ਨਹੀਂ; ਇਹ ਕੁਝ ਨਿਰਧਾਰਤ ਬੇਟਸ ਬਣਾਉਣ ਦੀ ਗੱਲ ਹੈ ਜੋ ਕੰਪਨੀ ਦੇ ਮੌਜੂਦਾ ਲਕੜੀ ਨਾਲ ਮਿਲਦੇ ਹਨ।
ਜਦੋਂ ਸਿਰਫ ਤੁਸੀਂ ਹੋ, "ਚੋਣਾਂ" ਵੱਧ-ਘੱਟ ਤੁਹਾਡੇ ਅਗਲੇ ਬਣਾਉਣ ਵਾਲੇ ਕੰਮ ਤੱਕ ਸੀਮਤ ਹੁੰਦੀਆਂ ਹਨ। ਜਿਵੇਂ ਟੀਮ ਵਧਦੀ ਹੈ, ਚੋਣਾਂ ਵੱਧਦੀਆਂ ਹਨ:
ਨਤੀਜਾ: ਬੈਕਲੌਗ ਇੱਕ ਕਿਚਨ ਜੰਗਲ ਬਣ ਜਾਂਦਾ ਹੈ। ਬਿਨਾਂ ਰਣਨੀਤੀ ਦੇ, ਤੁਸੀਂ ਸਭ ਤੋਂ ਉੱਚੀ ਆਵਾਜ਼, ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਟੈਕ ਪ੍ਰੋਜੈਕਟ ਜਾਂ ਜੋ ਵੀ ਆਸਾਨ ਹੈ ਉਸ ਨੂੰ ਡਿਫਾਲਟ ਕਰ ਲੈਗੇ।
ਤੁਹਾਨੂੰ ਇੱਕ ਜਟਿਲ ਸਕੋਰਿੰਗ ਸਪ੍ਰੈਡਸ਼ੀਟ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਦੋ ਸਧਾਰਣ ਫਰੇਮ ਆਮ ਤੌਰ 'ਤੇ ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ:
Impact vs. effort. ਆਈਟਮਾਂ ਨੂੰ ਚਾਰ ਬੱਕੇਟਾਂ ਵਿੱਚ ਰੱਖੋ: high-impact/low-effort (ਕਰੋ), high-impact/high-effort (ਯੋਜਨਾ), low-impact/low-effort (ਸਿਰਫ਼ ਜੇ ਕੁਝ ਅਨਲਾਕ ਕਰਦਾ ਹੈ), low-impact/high-effort (ਨਾ)।
Risk vs. reward. ਕੁਝ ਕੰਮ ਤੁਰੰਤ ਪ੍ਰਭਾਵ ਲਈ ਨਹੀਂ ਹੁੰਦੇ ਬਲਕਿ ਘਾਟ ਘਟਾਉਂਦੇ ਹਨ (ਸੁਰੱਖਿਆ, ਭਰੋਸਾ, ਅਨੁਕੂਲਤਾ)। ਇਸ਼ ਨੂੰ ਖੁੱਲ੍ਹ ਕੇ ਲੇਬਲ ਕਰੋ: "ਇਹ ਬੀਮਾ ਹੈ," ਅਤੇ ਫੈਸਲਾ ਕਰੋ ਕਿ ਇਸ ਕਵਾਰਟਰ ਵਿੱਚ ਤੁਸੀਂ ਕਿੰਨੀ ਬੀਮਾ ਲੈ ਸਕਦੇ ਹੋ।
ਕੁੰਜੀ ਇਹ ਹੈ ਕਿ ਤਰਜੀਹਾਂ ਨੂੰ ਵਿਖਾਉਣਾ। ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ ਤੁਸੀਂ ਕੀ ਛੱਡ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਵਾਕਈ ਤਰਜੀਹ ਨਹੀਂ ਕੀਤੀ।
ਤਕਨੀਕੀ ਫਾਊਂਡਰ ਲਈ ਇਕ ਉਪਯੋਗ ਨਿਯਮ: ਅਗਲੇ ਸਾਈਕਲ ਲਈ ਇੱਕ ਰੂਪ-ਸੰਕੇਤ ਲਕੜੀ ਚੁਣੋ (ਉਦਾਹਰਣ: activation, retention, sales cycle time), ਫਿਰ 2–4 ਮੁੱਖ ਬੇਟਸ ਚੁਣੋ ਜੋ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਉਸਨੂੰ ਹਿਲਾਉਂਦੀਆਂ ਹਨ।
ਹੋਰ ਸਬ ਕੁਝ ਸਮਰਥਕ ਕੰਮ (ਮੁਹੱਤ) ਜਾਂ ਪਾਰਕ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਕਹਿ ਸਕੋ: "ਇਹ ਹਨ ਉਹ ਬੇਟਸ ਜੋ ਅਸੀਂ ਲੈ ਰਹੇ ਹਾਂ—ਅਤੇ ਇਹ ਹਨ ਉਹ ਕੰਮ ਜੋ ਅਸੀਂ ਇरਾਦੀ ਤੌਰ 'ਤੇ ਨਹੀਂ ਕਰ ਰਹੇ," ਤਾਂ ਬੈਕਲੌਗ ਰਣਨੀਤੀ ਬਣ ਜਾਂਦਾ ਹੈ।
"ਪ੍ਰੋਡਕਟ ਸੌਝ" ਦਾ ਮਤਲਬ sticky notes, frameworks ਜਾਂ PM ਵਾਂਗ਼ ਬੋਲਣਾ ਨਹੀਂ ਹੈ। ਤਕਨੀਕੀ ਫਾਊਂਡਰ ਲਈ ਇਹ ਸਿਰਫ਼ ਇਹ ਸਮਰੱਥਾ ਹੈ ਕਿ ਤੁਸੀਂ ਸਮਝੋ ਯੂਜ਼ਰ ਕੌਣ ਹੈ, ਉਹ ਕੀ ਹਾਸਲ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ, ਅਤੇ ਕੀ ਤੁਹਾਡਾ ਉਤਪਾਦ ਸੱਚਮੁਚ ਮਦਦ ਕਰਦਾ ਹੈ—ਨਾਪਣਯੋਗ ਤਰੀਕੇ ਨਾਲ।
ਉਪਯੋਗ ਪਰਿਭਾਸ਼ਾ: ਪ੍ਰੋਡਕਟ ਸੌਝ ਉਹ ਆਦਤ ਹੈ ਜੋ ਕੰਮ ਨੂੰ ਇੱਕ ਮਾਹਤਵਪੂਰਨ ਨਤੀਜੇ ਨਾਲ ਜੋੜਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਵਿਕਾਸ ਦੀ ਵਿਆਖਿਆ Implementation ਦਾ ਜ਼ਿਕਰ ਕੀਤੇ ਬਿਨਾਂ ਇਕ ਵਾਕ ਵਿੱਚ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਅਜੇ ਵੀ ਇਕ ਬਿਲਡਰ ਵਾਂਗ ਸੋਚ ਰਹੇ ਹੋ।
ਸ਼ੁਰੂਆਤ ਵਿੱਚ, ਫੀਚਰ ਬਣਾਉਣਾ ਤਰੱਕੀ ਜਾਪਦਾ ਹੈ ਕਿਉਂਕਿ ਕੋਡ ਸ਼ਿਪ ਹੁੰਦਾ ਅਤੇ ਡੈਮੋ ਆਕਰਸ਼ਕ ਹੁੰਦੇ। ਪਰ ਜਦੋਂ ਅਸਲ ਵਰਤੋਂ ਆਉਂਦੀ ਹੈ, ਕੰਮ ਬਣ ਜਾਂਦਾ ਹੈ ਕਿ ਕਿਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨਾ ਵਾਜਿਬ ਹੈ—ਅਤੇ ਸਫਲਤਾ ਨੂੰ ਰਿਲੀਜ਼ ਨੋਟਸ ਦੀ بجਾਏ ਨਤੀਜਿਆਂ ਵੱਲ ਮਾਪਣਾ।
"CSV ਨੂੰ ਨਿਰਯਾਤ ਕਰਨਾ ਸ਼ਾਮਲ ਕਰੋ" ਵਰਗਾ ਫੀਚਰ ਨਿਰਲੇਖ ਹੋ ਸਕਦਾ ਹੈ। ਸਹੀ ਸਮੱਸਿਆ ਹੋ ਸਕਦੀ ਹੈ "ਮੇਰੀ ਟੀਮ ਨਤੀਜੇ ਨੁੰ ਸਾਂਝੇ ਨਹੀਂ ਕਰ ਸਕਦੀ" ਜਾਂ "ਮੈਨੂੰ ਡੇਟਾ ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਜਦ ਤੱਕ ਮੈਂ ਉਸਨੂੰ ਆਡਿਟ ਨਾ ਕਰ ਸਕਾਂ"। ਹੱਲ ਇੱਕ CSV ਹੋ ਸਕਦੀ ਹੈ—ਜਾਂ ਸ਼ੈਡਿਊਲ ਰਿਪੋਰਟ, API ਐਂਡਪਾਇੰਟ, ਜਾਂ ਡੇਟਾ ਗੁਣਵੱਤਾ ਠੀਕ ਕਰਨਾ।
ਤੁਹਾਨੂੰ ਭਾਰੀ ਐਨਾਲਿਟਿਕਸ ਦੀ ਲੋੜ ਨਹੀਂ। ਇਹਨਾਂ 'ਤੇ ਨਿਗਾਹ ਰੱਖੋ:
ਇਹ ਨਿਸ਼ਾਨੀਆਂ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਕੀ ਕੀਮਤੀ ਹੈ, ਕੀ ਅਸਪਸ਼ਟ ਹੈ, ਅਤੇ ਕੀ ਘਾਟ ਹੈ।
ਤੁਹਾਡੀ ਤਕਨੀਕੀ ਅਨੁਭੂਤੀ ਫਾਇਦੇਮੰਦ ਹੈ: ਤੁਸੀਂ feasibility traps ਵੇਖ ਸਕਦੇ ਹੋ, ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਸਧਾਰ ਸਕਦੇ ਹੋ, ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰ ਸਕਦੇ ਹੋ। ਪਰ ਇਹ ਤੁਹਾਨੂੰ ਸੁੰਦਰਤਾ ਲਈ optimize ਕਰਨ ਵੱਲ ਭਟਕਾ ਸਕਦੀ ਹੈ—ਪਰਫੈਕਟ abstractions, generalized systems, ਜਾਂ "ਅਸੀਂ ਬਾਅਦ ਵਿੱਚ ਇਸਦੀ ਲੋੜ ਪਏਗੀ" ਵਾਲਾ ਇੰਫ੍ਰਾ।
ਪ੍ਰੋਡਕਟ ਸੌਝ ਇਸਦਾ ਵਿਰੋਧੀ ਹੈ: ਹੁਣ ਉਹ ਬਣਾਓ ਜੋ ਯੂਜ਼ਰ ਦੇ ਨਤੀਜੇ ਨੂੰ ਤੁਰੰਤ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਹਕੀਕਤ—ਨਕਲ ਨਹੀਂ—ਦੱਸੇਗੀ ਕਿ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇੰਜੀਨੀਅਰਿੰਗ ਖੁਬੀ ਕਿੱਥੇ ਲਗਾਉਣੀ ਹੈ।
ਸ਼ੁਰੂ ਵਿੱਚ, ਇੱਕ ਤਕਨੀਕੀ ਫਾਊਂਡਰ "ਵਧੀਆ ਆਈਡੀਅਸਾਂ" ਨੂੰ ਹਮੇਸ਼ਾਂ 'ਹਾਂ' ਕਹਿ ਕੇ ਤੇਜ਼ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ। ਜਿਵੇਂ ਕੰਪਨੀ ਵੱਡੀ ਹੁੰਦੀ ਹੈ, ਕੰਮ ਉਲਟ ਹੁੰਦਾ ਹੈ: ਤੁਹਾਡੀ ਮੁੱਖ ਕੀਮਤ ਉਹ constraints ਚੁਣਨਾ ਹੁੰਦਾ ਹੈ ਜੋ ਹਰ ਕਿਸੇ ਨੂੰ ਕੇਂਦ੍ਰਿਤ ਰੱਖਣ। ਸੀਮਾਵਾਂ ਦੂਰ-ਕਰਨ ਵਾਲੀਆਂ ਨਹੀਂ—ਇਹ ਗਾਰਡਰੇਲ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਤਿੰਨ ਅਧ-ਪੂਰੇ ਉਤਪਾਦਾਂ ਬਣਾ ਰਹੇ ਬਚਾਉਂਦੀਆਂ ਹਨ।
ਸ਼ੁਰੂ ਕਰੋ 2–4 ਸੀਮਾਵਾਂ ਨਾਲ ਜੋ ਅਗਲੇ ਸਮੇਂ ਲਈ ਹਰ ਫੈਸਲੇ ਨੂੰ ਆਕਾਰ ਦਿੰਦੀਆਂ ਹਨ। ਉਦਾਹਰਣ:
ਫਿਰ 1–2 ਲਕੜੀਆਂ ਦਿਓ ਜੋ ਇੱਕ ਵਾਕ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਦੋਹਰਾਈਆਂ ਜਾ ਸਕਣ। ਜੇ ਟੀਮ ਇਸਨੂੰ ਨਹੀਂ ਦੁਹਰਾ ਸਕਦੀ, ਤਾਂ ਤੁਸੀਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਰੱਖ ਰਹੇ ਹੋ।
ਵਿਜ਼ਨ "ਕਿਉਂ" ਹੈ। ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਨੂੰ "ਕੀ ਕਦੋਂ ਤੱਕ" ਅਤੇ "ਸੀਮਾ ਕਿਵੇਂ ਪਤਾ ਲੱਗੇਗੀ" ਦੀ ਲੋੜ ਹੈ। ਇੱਕ ਸਰਲ ਪੈਟਰਨ:
ਉਦਾਹਰਣ: "time-to-first-value 20 ਮਿੰਟ ਤੋਂ 5 ਮਿੰਟ ਕਰਨਾ" ਨਾਲ "ਨਵੇਂ ਯੂਜ਼ਰਾਂ ਸੋ ਸਮੇਂ ਸਪੋਰਟ ਟਿਕਟ ਵੱਧ ਨਹੀਂ ਹੋਣੇ"। ਇਹ ਟਰੇਡਾਫ਼ਸ ਨੂੰ ਗੱਲਬਾਤਯੋਗ ਬਣਾਉਂਦਾ ਹੈ, ਨਿੱਜੀ ਨਹੀਂ।
ਫਾਊਂਡਰ ਵਜੋਂ, ਤੁਸੀਂ ਸਿੱਧੇ ਫੈਸਲਾ ਕਰੋ:
ਸੌਂਪੋ:
ਜੇ ਤੁਸੀਂ ਹਰੇਕ endpoint ਨਾਂ ਬਾਰੇ ਅਜੇ ਵੀ ਚਰਚਾ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਟੀਮ ਨੂੰ ਆਪਣੀ ਲੀਵਰੇਜ ਘਟਾ ਰਹੇ ਹੋ।
ਇਹ ਕੈਡੈਂਸ ਦਬਾਅ ਨੂੰ ਸਪਸ਼ਟਤਾ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ—ਅਤੇ ਟਰੇਡਆਫ਼ ਨੂੰ ਐਮਰਜੈਂਸੀ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਗੱਲਬਾਤਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਆਰੰਭਿਕ ਟੀਮ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖ ਕੇ ਜਿੱਤਦੀਆਂ ਹਨ। ਇਸ ਲਈ "ਅੱਛੀ-ਕਾਫ਼ੀ" ਅਕਸਰ "ਪੂਰਨ" ਤੋਂ ਬੇਹਤਰ ਹੁੰਦਾ: ਗਾਹਕਾਂ ਦੇ ਹੱਥਾਂ ਵਿੱਚ ਇਕ ਠੋਸ ਵਰਜਨ ਰੱਖੋ ਤਾਂ ਕਿ ਫੀਡਬੈਕ, ਰੈVenue ਅਤੇ ਸਪਸ਼ਟਤਾ ਮਿਲੇ। ਪਰ ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਕੁਆਲਿਟੀ ਮਹੱਤਵਪੂਰਣ ਨਹੀਂ ਹੈ—ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕੁਆਲਿਟੀ ਦੀ ਲਾਗੂਤਤਾ ਚੁਣਨਯੋਗ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਕੁਝ ਖੇਤਰ ਫੇਲ ਹੋਣ ਨਾਲ ਅਜਿਹੇ ਨੁਕਸਾਨ ਪੈਦਾ ਕਰਦੇ ਹਨ ਜੋ ਵਾਪਸ ਨਹੀਂ ਹੋਦੇ। ਇਹਨਾਂ ਨੂੰ "ਬੋਰਿੰਗ" ਰੱਖੋ:
ਜੇ ਇਹਨਾਂ ਵਿੱਚ ਕੋਈ ਚੀਜ਼ ਟੁੱਟਦੀ ਹੈ, ਤੁਸੀਂ ਸਿਰਫ਼ ਇੱਕ ਬੱਗ ਨਹੀਂ ਭੇਜ ਰਹੇ—ਤੁਸੀਂ ਭਰੋਸੇ ਦੀ ਸਮੱਸਿਆ ਭੇਜ ਰਹੇ ਹੋ।
ਗਾਰਡਰੇਲਸ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਦਿੰਦੀਆਂ ਹਨ ਬਿਨਾਂ ਯਾਦਸ਼ਤ ਜਾਂ ਹੀਰੋਇਕਸ 'ਤੇ ਨਿਰਭਰ ਹੋਏ।
ਇਹ ਬਿਊਰੋਕਰੇਸੀ ਨਹੀਂ ਹਨ; ਇਹ ਜ਼ਿਦੀ ਮੁਲਾਕਾਤਾਂ ਨੂੰ ਰੋਕਣ ਵਾਲੇ ਸ਼ਾਰਟਕੱਟ ਹਨ।
ਤੇਜ਼ੀ ਦਾ ਮਤਲਬ ਗੰਦਾ ਕੰਮ ਨਹੀਂ—ਇਹ ਰਿਵਰਸੀਬਲ ਫੈਸਲਿਆਂ ਦਾ ਚੋਣ ਹੈ।
ਉਦਾਹਰਣ:
ਇੱਕ ਉਪਯੋਗ ਨਿਯਮ: ਉਹਨਾਂ ਚੀਜ਼ਾਂ 'ਤੇ ਕਾਰਨ ਕੱਟੋ ਜੋ ਤੁਸੀਂ ਇੱਕ ਹਫ਼ਤੇ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ, ਨਾ ਉਹ ਜੋ ਇੱਕ ਦਿਨ ਵਿੱਚ ਕੰਪਨੀ ਡੁਬਾਣ ਦੀ ਸਮਰੱਥਾ ਰੱਖਦੀਆਂ ਹਨ।
ਜੇ ਤੁਸੀਂ "ਛੋਟਾ ਬੇਟ → ਸਿੱਖੋ → ਇਟਰੇਟ" ਲੂਪ ਨੂੰ ਹੋਰ ਵੀ ਛੋਟਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਉਹ ਟੂਲ ਜੋ ਤੇਜ਼ ਪ੍ਰੋਟੋਟਾਈਪ ਅਤੇ ਆਸਾਨ ਰੋਲਬੈਕ ਸਮਰਥਨ ਕਰਦੇ ਹਨ ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ। ਉਦਾਹਰਣ ਲਈ, Koder.ai's planning mode ਅਤੇ snapshots/rollback workflow ਪ੍ਰਯੋਗਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਲਈ ਡਿਜ਼ਾਇਨ ਕੀਤੇ ਗਏ ਹਨ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਸੀਂ ਗੈਰ-ਮੁੱਖ ਖੇਤਰਾਂ ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਚੱਲਦੇ ਹੋ ਤੇ ਮੁੱਖ ਪਾਥਾਂ ਵਿੱਚ ਗੁਣਵੱਤਾ ਗੈਰ-ਨਿਗੋਸ਼ੀਏਬਲ ਰੱਖਦੇ ਹੋ।
ਇੱਕ ਤਕਨੀਕੀ ਫਾਊਂਡਰ ਲਈ ਸਭ ਤੋਂ ਤੇਜ਼ ਰੂਪ ਵਿੱਚ ਰਨਵੇ ਖਤਮ ਹੋਣਾ ਪੈਸਾ ਨਹੀਂ—ਇਹ ਧਿਆਨ ਹੈ। ਤੁਹਾਡੀ ਨਵੀਂ ਲੀਵਰੇਜ ਅਚ্ছে ਹਾਇਰ ਕਰਨ, ਲਗਾਤਾਰ ਕੋਚਿੰਗ ਕਰਨ, ਅਤੇ ਸਿਧਾਂਤ ਸੈੱਟ ਕਰਨ ਤੋਂ ਆਉਂਦੀ ਹੈ ਜੋ ਟੀਮ ਨੂੰ ਬਿਨਾਂ ਤੁਹਾਡੇ ਹਰ ਥਰੇਡ ਵਿੱਚ ਹੋਏ ਵਧੀਆ ਫੈਸਲੇ ਕਰਨ ਦਿੰਦੇ ਹਨ।
ਹੈਡਕਾਉਂਟ ਵਧਣ 'ਤੇ, "ਸਭ ਤੋਂ ਵਧੀਆ ਬਿਲਡਰ ਹੋਣਾ" ਗੁਣਾਂਕ ਨਹੀਂ ਰਹਿੰਦਾ। ਤੁਹਾਡਾ ਗੁਣਾਂਕ ਬਣਦਾ ਹੈ ਸਪਸ਼ਟਤਾ: ਕੁਝ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਨਿਯਮ ਜੋ ਦਰਜਨਾਂ ਛੋਟੇ ਫੈਸਲਿਆਂ ਨੂੰ ਮਾਰਗਦਰਸ਼ਨ ਕਰਦੇ ਹਨ।
ਸਪਸ਼ਟਤਾ ਲਈ ਉਦਾਹਰਣ:
ਇਹ ਸਿਧਾਂਤ ਦੁਹਰਾਏ ਜਾ ਰਹੇ ਫੈਸਲਿਆਂ ਨੂੰ ਘੱਟ ਕਰਦੇ ਹਨ ਅਤੇ ਤੁਹਾਡੇ ਬਿਨਾਂ ਵੀ ਗੁਣਵੱਤਾ ਬਣਾਈ ਰੱਖਦੇ ਹਨ।
ਬੋਤਲਨੇਕ ਉਸ ਵੇਲੇ ਬਣਦੇ ਹਨ ਜਦੋਂ ਇੱਕ ਵਿਅਕਤੀ (ਅਕਸਰ ਤੁਸੀਂ) ਹੀ "ਹਾਂ" ਕਹਿ ਸਕਦਾ ਹੈ। ਇਸ ਦੀ ਥਾਂ, ਸੀਮਾਵਾਂ ਨਾਲ ਮਲਕੀਅਤ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ:
ਮਕਸਦ ਸਹਿਮਤੀ ਨਹੀਂ; ਇਹ ਹੈ ਤੇਜ਼, ਵਾਜਿਬ ਫੈਸਲੇ ਜੋ ਕੰਮ ਦੇ ਨੇੜੇ ਕੀਤੇ ਜਾਣ।
ਸਤਹ-ਸਤਹ ਸੌਂਪੋ:
ਇੱਕ ਉਪਯੋਗ ਟੈਸਟ: ਜੇ ਗਲਤ ਫੈਸਲੇ ਦੀ ਲਾਗਤ ਮੁੱਖਤਰ ਰਿਵਰਕ ਹੈ, ਤਾਂ ਇਹ ਸੌਂਪੋ। ਜੇ ਇਹ ਭਰੋਸਾ, ਰੈVenue ਜਾਂ ਰਣਨੀਤੀ ਨੂੰ ਖਤਰਾ ਪਹੁੰਚਾਉਂਦਾ ਹੈ, ਤਾਂ ਨੇੜੇ ਰਹੋ।
1:1s ਨੂੰ ਸਥਿਤੀ-ਚੈੱਕ ਕਰਨ ਲਈ ਨਹੀਂ, ਪਰ ਫੈਸਲਾ-ਗੁਣਵੱਤਾ ਤੀਖੀ ਕਰਨ ਲਈ ਵਰਤੋਂ:
ਜਦੋਂ ਤੁਹਾਡੀ ਟੀਮ ਫੈਸਲਾ-ਸਮਰੱਥਾ ਵਿੱਚ ਬਿਹਤਰ ਹੁੰਦੀ ਹੈ, ਤੁਹਾਡਾ ਸਭ ਤੋਂ ਦੂਖਦਾਇਕ ਸੰਦ—ਤੁਹਾਡਾ ਧਿਆਨ—ਵਾਪਸ ਮਿਲਦਾ ਹੈ।
ਤਕਨੀਕੀ ਫਾਊਂਡਰ ਅਕਸਰ ਉਸੇ ਢੰਗ ਨਾਲ "ਜਿੱਤ" ਕਰਦੇ ਰਹਿੰਦੇ ਹਨ: ਤੇਜ਼ ਬਿਲਡ, ਪੂਰਾ ਸੋਚ, ਧੱਕਾ ਦੇਂਦੇ ਰਹੋ। ਹੇਠ ਲਿਖੇ ਫੰਦੇ ਉਸ ਵੇਲੇ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਉਹੀ ਸੁਝਾਅ ਕੰਪਨੀ ਦੀਆਂ ਲੋੜਾਂ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ।
ਇੱਕ ਕਲਾਸਿਕ ਸੂਚਕ ਇਹ ਹੈ: ਮਿਸ਼ਰਤ ਆਉਟਪੁੱਟ ਪਰ ਅਨਿਸ਼ਚਿਤ ਨਤੀਜੇ—ਰਿਲੀਜ਼ਜ਼ ਪ੍ਰਮੁੱਖ ਮੈਟ੍ਰਿਕਸ (activation, retention, revenue, support load) ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਬਦਲਾਅ ਨਹੀਂ ਲਿਆਉਂਦੀਆਂ।
ਕਿਸ ਤਰ੍ਹਾਂ ਪਛਾਣੋ: ਤੁਸੀਂ ਆਖਰੀ ਸ਼ਿਪ ਤੋਂ ਜੋ ਤੁਸੀਂ ਸਿੱਖਣ ਦੀ ਉਮੀਦ ਸੀ ਉਸ ਨੂੰ ਨਾਮ ਨਹੀਂ ਦੇ ਸਕਦੇ, ਜਾਂ ਸਫਲਤਾ ਨੂੰ "ਸ਼ਿਪ ਹੋ ਗਿਆ" ਮੰਨ ਲਈਦਾ ਹੈ ਨਾ ਕਿ "ਇਸ ਨੇ X ਨੂੰ ਹਿਲਾਇਆ"।
ਸੁਧਾਰ: ਫੀਡਬੈਕ ਲੂਪ ਤੰਗ ਕਰੋ। ਹਰ ਰਿਲੀਜ਼ ਨੂੰ ਇੱਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਬਣਾਓ ("ਜੇ ਅਸੀਂ X ਜੋੜੀ ਤਾਂ ਕੀ ਟੀਮ ਸਹਿਯੋਗੀਆਂ ਨੂੰ ਸੱਦਾ ਭੇਜੇ ਗੇ?")। ਛੋਟੇ ਬੇਟ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਮੁਲਾਂਕਣ ਦਿਨਾਂ ਵਿੱਚ ਹੋ ਸਕੇ, ਮਹੀਨਿਆਂ ਵਿੱਚ ਨਹੀਂ।
ਇਹ future-org ਲਈ ਸਿਸਟਮ ਬਣਾਉਣ ਵਜੋਂ ਪ੍ਰਗਟ ਹੁੰਦਾ ਹੈ: microservices, ਕਠਿਨ abstractions, ਭਾਰੀ ਪ੍ਰਕਿਰਿਆ, ਜਾਂ "ਐਂਟਰਪਰਾਈਜ਼-ਗਰੇਡ" ਹਰ ਚੀਜ਼—ਉਸ ਵੇਲੇ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਅਡਿਗ ਵਰਤੋਂ ਦੇ ਸਰੂਪ ਨਹੀਂ ਹਨ।
ਕਿਵੇਂ ਪਛਾਣੋ: ਤੁਹਾਡੇ ਆਰਕੀਟੈਕਚਰ ਫੈਸਲਿਆਂ ਦੀ ਚਾਲ hypothetical scale ਦੁਆਰਾ ਚਲਾਈ ਜਾ ਰਹੀ ਹੈ, ਜਦਕਿ ਅੱਜ ਦੀ ਰੁਕਾਵਟ ਅਸਲ ਵਿੱਚ ਅਸਪਸ਼ਟ ਪ੍ਰੋਡਕਟ ਦਿਸ਼ਾ ਜਾਂ ਘੱਟ ਮੰਗ ਹੈ।
ਸੁਧਾਰ: ਖੇਤਰ-ਵਾਰ "ਅੱਛੀ-ਕਾਫ਼ੀ" ਮਿਆਰ ਸੈੱਟ ਕਰੋ। ਕੋਰ ਪਾਥਾਂ ਭਰੋਸੇਯੋਗ ਰੱਖੋ, ਪਰ ਹੋਰ ਥਾਵਾਂ 'ਤੇ ਸਧਾਰਣ ਹੱਲ ਨੂੰ ਆਗਿਆ ਦਿਓ। ਜਦੋਂ ਕੋਈ ਸੱਚੀ ਰੁਕਾਵਟ ਦੁਹਰਾਉਂਦੀ ਹੈ, ਤਦ ਹੀ ਸਕੇਲਿੰਗ ਕੰਮ ਮੁੜ-ਵਿੱਚਾਰੋ।
ਅਕਸਰ ਤਰਜੀਹਾਂ ਬਦਲਣਾ ਚੁਸਤਤਾ ਜਾਪਦਾ ਹੈ, ਪਰ ਅਕਸਰ ਇਹ ਰਣਨੀਤੀ ਦੀ ਘਾਟ ਦਰਸਾਉਂਦਾ ਹੈ। ਟੀਮ ਯੋਜਨਾਂ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਛੱਡ ਦਿੰਦੀ ਹੈ ਅਤੇ ਅਗਲੇ ਪਿਵਟ ਦੀ ਉਡੀਕ ਕਰਨ ਲੱਗਦੀ ਹੈ।
ਕਿਵੇਂ ਪਛਾਣੋ: ਕਈ ਅਧ-ਮੁਕੰਮਲ ਪ੍ਰੋਜੈਕਟ, ਬਾਰ-ਬਾਰ ਸੰਦਰਭ ਬਦਲਣਾ, ਅਤੇ "ਤੁਰੰਤ" ਕੰਮ ਜੋ ਕਿਸੇ ਲਕੜੀ ਨਾਲ ਜੁੜੇ ਨਹੀਂ।
ਸੁਧਾਰ: ਬੇਟ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰੋ। ਇੱਕ ਨਿਰਧਾਰਤ ਖਿੜਕੀ (ਉਦਾਹਰਣ: 4–6 ਹਫ਼ਤੇ) ਲਈ ਛੋਟੀਆਂ ਪਰ ਨਿਰਧਾਰਤ ਨਤੀਜਿਆਂ 'ਤੇ ਕੰਮ ਕਰਨ ਦੀ ਵਚਨਬੱਧਤਾ ਕਰੋ, ਅਤੇ ਨਵੀਆਂ ਸੁਝਾਵਾਂ ਨੂੰ ਇਨਪੁਟ ਸਮਝੋ, ਨਹੀਂ ਕਿ ਰੋਕਣ।
ਜਦੋਂ ਹਰ ਮਹੱਤਵਪੂਰਨ ਫੈਸਲਾ ਫਾਊਂਡਰ ਰਾਹੀਂ ਹੀ ਲੰਘਦਾ ਹੈ, ਤਾਂ ਕੰਪਨੀ ਦੀ ਰਫ਼ਤਾਰ ਘਟਦੀ ਹੈ।
ਕਿਵੇਂ ਪਛਾਣੋ: ਲੋਕ approvals ਲਈ ਪੁੱਛਦੇ ਹਨ ਬਜਾਏ ਫੈਸਲੇ ਕਰਨ ਦੇ, meetings ਵਧ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਉਪਲਬਧ ਨਹੀਂ ਹੁੰਦੇ ਤਾਂ ਕੰਮ ਰੁਕ ਜਾਂਦਾ ਹੈ।
ਸੁਧਾਰ: ਸਿਰਫ਼ ਟਾਸਕ ਨਹੀਂ, ਫੈਸਲੇ ਸੌਂਪੋ। ਸਧਾਰਨ ਫੈਸਲਾ ਨਿਯਮ ਲਿਖੋ (ਚੰਗਾ ਲੱਗਣ ਕੀ ਹੈ, ਟਰੇਡਆਫ਼, ਸੀਮਾਵਾਂ), ਫਿਰ ਹੋਰਾਂ ਨੂੰ ਅਮਲ ਕਰਨ ਦਿਓ ਅਤੇ ਨਤੀਜੇ ਦੀ ਸਮੀਖਿਆ ਕਰੋ—ਹਰ ਕਦਮ ਨਹੀਂ।
ਵਧੀਆ ਫੈਸਲਾ-ਸਮਰੱਥਾ ਕਿਸੇ ਵਿਅਕਤੀਗਤ ਰੂਪ-ਰੂਪ ਨਹੀਂ—ਇਹ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਆਦਤਾਂ ਦਾ ਇਕ ਸੈਟ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਸਿਗਨਲ ਨੋਟਿਸ ਕਰਨ, ਬੇਅਕਾਰ ਗਲਤੀਆਂ ਘਟਾਉਣ ਅਤੇ ਐਸੇ ਫੈਸਲੇ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਜੋ ਕੰਪਨੀ ਬਦਲਦੇ ਵੇਲੇ ਵੀ ਚੰਗੇ ਰਹਿਣ।
ਇਸਨੂੰ ਹਮੇਸ਼ਾ ਇੱਕੋ ਵੇਲੇ ਚਲਾਓ। ਛੋਟਾ, ਲਿਖਤ ਅਤੇ ਤੁਹਾਡੇ ਕੋ-ਫਾਊਂਡਰ ਜਾਂ ਲੀਡਜ਼ ਨਾਲ ਸਾਂਝਾ ਰੱਖੋ।
ਸਮੀਖਿਆ ਨੂੰ ਇੱਕ bet ਨਾਲ ਸਮਾਪਤ ਕਰੋ: ਅਗਲੇ ਹਫਤੇ ਤੁਸੀਂ ਇੱਕ ਬੇਟ ਲੈ ਰਹੇ ਹੋ ਅਤੇ ਤੁਸੀਂ ਕਿਵੇਂ ਜਾਣੋਗੇ ਕਿ ਇਹ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਫਾਊਂਡਰ ਨਤੀਜੇ ਯਾਦ ਰੱਖਦੇ ਹਨ ਪਰ ਅਨੁਮਾਨ ਭੁੱਲ ਜਾਂਦੇ ਹਨ। ਫੈਸਲਾ ਲਾਗ "ਚੰਗੀ/ਬੁਰੀ ਕਿਸਮਤ" ਨੂੰ ਸਿੱਖਣ ਵੱਲ ਭਰਦਾ ਹੈ।
\nDecision:\nDate:\nOwner:\nContext (what's happening):\nOptions considered (and why not):\nRationale (why this is the best bet now):\nData used (links/notes):\nRisks + mitigations:\nSuccess metric (what changes if it works?):\nFollow-up date (when we'll review):\nResult + what we learned:\n\n
ਹਰ ਮਹੀਨੇ 2–3 ਪਿਛਲੇ ਫੈਸਲਿਆਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ। ਤੁਸੀਂ ਉਹ ਪੈਟਰਨ ਲੱਭ ਰਹੇ ਹੋ: ਕਿਹੜੇ ਇਨਪੁੱਟ ਤੁਸੀਂ ਓਵਰ-ਟ੍ਰੱਸਟ ਕਰਦੇ ਹੋ, ਕਿਹੜੇ ਜੋਖਮ ਤੁਸੀਂ ਆਣਚਾਨਕ ਘੱਟ ਮੰਨਦੇ ਹੋ, ਅਤੇ ਕਿੱਥੇ ਤੁਸੀਂ ਦੇਰ ਨਾਲ ਫੈਸਲਾ ਕਰਦੇ ਹੋ।
ਜਦੋਂ ਸਭ ਕੁਝ ਸੰਭਵ ਹੈ, ਤੁਹਾਡੀ ਨੌਕਰੀ "ਨਹੀਂ ਹੁਣ" ਨੂੰ ਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਕਰਵਾਉਣਾ ਹੈ।
ਜੇ ਕੋਈ ਟਾਸਕ ਕਿਸੇ outcome ਨਾਲ ਜੁੜਦਾ ਨਹੀਂ, ਉਸ ਨੂੰ ਰਹਿਣ ਦਾ ਮਜ਼ਬੂਰ ਕਾਰਨ ਚਾਹੀਦਾ ਹੈ।
ਲਾਂਚਾਂ, ਗਾਹਕ ਕਾਲਾਂ, ਅਤੇ ਔਖੀਆਂ ਹਫਤਿਆਂ ਤੋਂ ਬਾਅਦ ਇਹ ਪ੍ਰਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ:
ਸਮੇਂ ਦੇ ਨਾਲ, ਇਹ ਆਦਤਾਂ ਤੁਹਾਡੇ ਅੰਦਰੂਨੀ ਸੁਵਾਦ ਨੂੰ ਸੁਆਦ-ਤੱਥ 'ਤੇ ਬਦਲ ਦਿੰਦੇ ਹਨ—ਰੁਚੀ ਦੇ ਬਜਾਏ ਟੈਸਟ ਕੀਤੇ ਗਿਆ ਨਿਰਧਾਰਿਤ ਸਮਝ।
ਸ਼ੁਰੂਆਤੀ ਮੰਚ 'ਤੇ, ਤਕਨੀਕੀ ਫਾਊਂਡਰ ਦਾ ਕੰਮ ਆਮ ਤੌਰ 'ਤੇ ਸਿੱਧਾ ਹੁੰਦਾ ਸੀ: ਜੇ ਤੁਸੀਂ ਜ਼ਿਆਦਾ ਕੋਡ ਲਿਖਦੇ ਹੋ ਤਾਂ ਜ਼ਿਆਦਾ ਪ੍ਰੋਡਕਟ ਸ਼ਿਪ ਹੁੰਦਾ। ਜਦੋਂ ਯੂਜ਼ਰ, ਰੈVenue ਅਤੇ ਟੀਮ ਵੱਧਦੇ ਹਨ, ਹਰ ਬਦਲਾਅ ਗਾਹਕਾਂ, ਸਪੋਰਟ, ਸੇਲਜ਼ ਦੀਆਂ ਵਾਅਦਿਆਂ, ਇੰਫ੍ਰਾਸਟ੍ਰਕਚਰ ਅਤੇ ਹੋਰ ਇੰਜੀਨੀਅਰਾਂ ਨਾਲ ਜੁੜਦਾ ਹੈ।
ਤੁਹਾਡੀ ਸਭ ਤੋਂ ਵੱਡੀ ਲੀਵਰੇਜ ਹੁਣ "ਅਗਲਾ ਆਈਟਮ ਬਣਾਉਣਾ" ਨਹੀਂ ਰਹਿੰਦੀ, ਬਲਕਿ "ਟੀਮ ਨੂੰ ਕੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਕਿਉਂ" ਫੈਸਲਾ ਕਰਨਾ, ਮਿਆਰ ਤੈਅ ਕਰਨਾ ਅਤੇ ਐਸਾ ਸਪਸ਼ਟਤਾ ਬਣਾਉਣਾ ਹੁੰਦੀ ਹੈ ਕਿ ਹੋਰ ਲੋਕ ਤੁਹਾਡੇ ਬਿਨਾਂ ਵੀ ਚੱਲ ਸਕਣ।
ਇੱਕ ਕਾਰਗੁਜ਼ਾਰੀ ਤੌਰ 'ਤੇ ਵਰਤਿਆ ਗਿਆ ਵੰਡ:
ਇੱਕ ਟੈਕਨੀਕਲੀ "ਸਹੀ" ਚੋਣ ਬਿਜ਼ਨਸ ਤੌਰ 'ਤੇ ਗਲਤ ਹੋ ਸਕਦੀ ਹੈ ਜੇ ਉਹ ਉਸ ਫੀਚਰ ਨੂੰ ਦੇਰ ਕਰੇ ਜੋ ਡੀਲਜ਼ ਬੰਦ ਕਰਨ ਜਾਂ ਕਿਸੇ ਮੂਹਤਾਜ ਧਾਰਨਾ ਨੂੰ ਸੱਚ ਕਰਕੇ ਦਿਖਾਉਣ ਲਈ ਜ਼ਰੂਰੀ ਹੋਵੇ। ਮੌਜੂਦਾ ਜਾਣਕਾਰੀ ਦੇ ਸਹੀ ਹਿਸਾਬ ਨਾਲ ਤਰੱਕੀਯਾਬ ਫੈਸਲੇ ਕਰੋ ਅਤੇ ਲਚਕੀਲੇ ਰਹੋ।
ਤਤਕਾਲ ਨਤੀਜੇ ਤੋਂ ਅੱਗੇ ਵੇਖੋ ਅਤੇ ਪੁੱਛੋ ਕਿ ਇਸ ਚੋਣ ਨਾਲ ਕੀ ਹੁੰਦਾ:
ਲਾਗੂ ਕਰਨ ਦਾ ਤੇਜ਼ ਤਰੀਕਾ: ਫੈਸਲਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸੰਭਾਵਿਤ ਨਤੀਜੇ ਅਤੇ ਇੱਕ ਲੰਬੇ ਸਮੇਂ ਦਾ ਲਾਗਤ ਨਾਂ ਦਿੱਤੋ।
ਦੋ ਸਧਾਰਣ ਨਜ਼ਰੀਏ ਵਰਤੋਂ:
ਜੇ ਫੈਸਲਾ ਵਾਪਸ ਨਹੀਂ ਹੋ ਸਕਦਾ ਅਤੇ ਡੇਲੀ ਮਹਿੰਗੀ ਹੈ, ਤਾਂ ਸੀਰੀਜ਼ ਧਰਕਾਰ ਕਰੋ: ਪ੍ਰੋਟੋਟਾਈਪ, ਸੀਮਤ ਰੋਲਆਉਟ ਜਾਂ ਛੋਟੀ ਸ਼ੁਰੂਆਤ ਜੋ ਵਿਕਲਪ ਬਚਾ ਕੇ ਰੱਖੇ।
ਪਹਿਲਾਂ ਟਰੇਡ-ਆਫ਼ਜ਼ ਵਿਖਾਉਣਗੇ — ਆਦਤਾਂ ਨਹੀ ਕਿ täydho rank karna. ਦੋ ਸਲਾਹਾਂ:
ਫਿਰ ਇਕ ਉੱਚ-ਲਕੜੀ ਦਾ ਲਕੜੀ ਰੱਖੋ: ਇੱਕ ਟਾਪ goal ਅਤੇ 2–4 ਬੇਟਸ ਜੋ ਉਸਨੂੰ ਸਿੱਧਾ ਅੱਗੇ ਵਧਾਉਂਦੀਆਂ ਹਨ।
Product sense ਸਾਫ ਸ਼ਬਦਾਂ ਵਿੱਚ: ਯੂਜ਼ਰ ਕੌਣ ਹੈ, ਉਹ ਕੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਕੀ ਤੁਸੀਂ ਵੀਹਲੇ ਤਰੀਕੇ ਨਾਲ ਉਹਨਾਂ ਦੀ ਮਦਦ ਕਰ ਰਹੇ ਹੋ—ਇਹ ਨਾਪ ਸਕੀ ਜਾਂਦੀ ਗੱਲ ਹੈ।
ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ ਟੈਸਟ: ਜੇ ਤੁਸੀਂ ਲਾਗੂ ਕਰਨ ਦੀ ਗੱਲ ਛੱਡ ਕੇ ਇੱਕ ਵਾਕ ਵਿੱਚ ਵੈਲੂ ਨਹੀਂ ਸਮਝਾ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਅਜੇ ਵੀ ਇੱਕ ਬਿਲਡਰ ਵਾਂਗ ਸੋਚ ਰਹੇ ਹੋ।
ਭਾਰੀ ਐਨਾਲਿਟਿਕਸ ਦੀ ਲੋੜ ਨਹੀਂ। ਇਹਨਾਂ ਨਿਸ਼ਾਨੀਆਂ 'ਤੇ ਧਿਆਨ ਦਿਓ:
ਇਹ ਸਿਗਨਲ ਦੱਸਦੇ ਹਨ ਕਿ ਕੀ ਵੈਲੂ ਹੈ, ਕੀ ਅਸਪੱਸ਼ਟ ਹੈ, ਅਤੇ ਕੀ ਘਾਟ ਹੈ। ਹਰ ਤਬਦੀਲੀ ਨੂੰ ਇੱਕ ਸਿਗਨਲ ਨਾਲ ਜੋੜੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਕਹ ਸਕੋ ਕਿ ਤੁਸੀਂ ਕੀ ਉਮੀਦ ਕਰਦੇ ਹੋ ਕਿ ਹਿਲੇਗਾ—ਅਤੇ ਸ਼ਿਪਿੰਗ ਤੋਂ ਬਾਅਦ ਇਸ ਨੂੰ ਰਿਊ ਵ ਕਰੋ।
ਸਧਾਰਨ ਤਿੰਨ-ਹਿੱਸੇ ਦਾ ਪੈਟਰਨ ਵਰਤੋ:
ਇਸ ਨਾਲ ਟਰੇਡਐਫ਼ਸ ਗਿਣਤੀਯੋਗ ਬਣ ਜਾਂਦੇ ਹਨ ਅਤੇ ਵਿਚਾਰ-ਵਟਾਂਦਰਾ ਨਿੱਜੀ ਨਹੀਂ ਰਹਿੰਦਾ।
ਗੁਣਵੱਤਾ ਮਹੱਤਵਪੂਰਣ ਹੈ ਜਿੱਥੇ ਫੇਲ ਹੋਣਾ ਭਰੋਸਾ ਨੁਕਸਾਨ ਕਰ ਸਕਦਾ ਹੈ। ਇਨ੍ਹਾਂ ਖੇਤਰਾਂ ਨੂੰ "ਬੋਰਿੰਗ" ਰੱਖੋ:
ਬਾਕੀ ਥਾਵਾਂ ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਚਲੋ ਪਰ ਗਾਰਡਰੇਲਸ ਰੱਖੋ:
ਫੈਸਲਿਆਂ ਨੂੰ ਸਕੇਲ ਕਰਨ ਲਈ ਸਿਧਾਂਤ ਬਣਾਓ, ਨਜ਼ਦੀਕੀ ਤੋਂ ਨਹੀਂ:
ਮਾਲਿਕੀਅਤ ਲਈ ਢਾਂਚਾ:
ਇਹ ਢਾਂਚੇ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਦਿੰਦੀਆਂ ਹਨ ਪਰ ਸਥਾਈ ਨੁਕਸ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਨ ਦਿੰਦੀਆਂ।