שני כלי פרודוקטיביות שעובדים

פרודוקטיביות, הגביע הקדוש של המאה ה-21. כיצד נצליח לסחוט ממעט הזמן הפנוי שלנו את המקסימום? העולם שלנו מקדש יעילות ובו זמנית מספק לנו מגוון עצום של הסחות דעת. פייסבוק, טוויטר, אימיילים והודעות טקסט שלא פוסקות חוברים יחד כדי להפריע לנו למקסם את הזמן שלנו.

אחרי שנים של שכלול הפרודוקטיביות האישית שלי, הגעתי למסקנה ששני דברים מכתיבים את רמת הפרודוקטיביות שלי:

1. ניהול משימות - מעקב אחר משימות, תיעדוף וביצוע.
2. ניהול הזמן - ניתוח הזמן המושקע במשימות, הגבלת הסחות והצבת יעדים.

מאות חברות כבר הוקמו לפיתוח כלים לשיפור הפרודוקטיביות וניהול משימות אבל אחרי שניסיתי לא מעט מהם הגעתי למסקנה שיש שני כלים שעובדים טוב בשבילי:

לניהול המשימות אני משתמש ב - todoist.com הפשטות והנוחות של האפליקציה והממשק הוובי הופכים אותה לכלי נוח ויעיל.

לניהול הזמן אני משתמש ב - rescuetime.com, כלי שמנטר את הזמן שהשקעת בכל פעילות במהלך היום ומאפשר לך להציב יעדים ולחסום הסחות.

שני הכלים הם חינמיים עם אפשרות לשידרוג בתשלום (ל - rescuetime שילמתי). מאז שעברתי להשתמש בכלים אלו היעילות שלי צמחה פלאים. 

נסו ותיווכחו.

5 סוגי מתכנתים שצריך להיזהר מהם

מזל טוב, קיבלת צוות חדש. אתה מנסה לחשוב כיצד לגשת אל המתכנתים שקיבלת בירושה ומי עלול להוות בעיה. הנה כמה סוגי מתכנתים שכדאי להיזהר מהם והדרכים לטפל בבעיה.

1.      בונה החלליות

בונה החלליות אוהב הנדסת תוכנה מורכבת והוא רואה אותה בכל מקום. רק ביקשת ממנו לבנות גלגל פשוט והוא חוזר אלייך אחרי חודשיים עם עם ספינת חלל משוכללת שמסוגלת גם להתגלגל אם ממש ממש צריך. כל משימה פשוטה הופכת לבעיה מורכבת שצריך לבחון את כל הבטיה ותיקח לפחות חצי שנת פיתוח.

הפתרון: עצור את כדור השלג לפני שהוא מתחיל להתגלגל שאל אותו כעבור יומיים מה הוא מתכנן לעשות ווודא שהוא בונה רק את הגלגל.

2.      המתכנת שאוהב דיזיין

הוא למד הנדסת תוכנה באוניברסיטה והוא מתעקש להשתמש בכל הכלים שלמד. הוא יגרור אותך לפגישות ארוכות, יכין לך דיאגרמות מפורטות, יפרוט את הדיזיין לפרטי פרטים. הוא רק שכח שאחרי כל הדיזיין צריך גם לכתוב קוד.

הפתרון: הקצב לו זמן מוגדר לדיזיין ותאם איתו מספר פגישות מוגדר.

3.      החברותי

הוא מעולה למורל המשרד. כולם אוהבים אותו והוא כל כך נחמד. הבעיה שמרוב נחמדות וחברותיות הוא מבלה את רוב זמנו בשיחות עם אנשים אחרים ומונע מהם ומעצמו לעבוד.

הפתרון: שים אותו בחדר מבודד ואם זה לא עוזר (וזה לא יעזור, קשה לביית את החיה החברתית) ערוך איתו שיחת הבהרה.

4.      המתפזר

הוא מתכנת נהדר בחמש הדקות שהוא באמת עובד ביום. בשאר הזמן הוא משוחח במסנג'ר, גולש בפייסבוק ובאתרי החדשות ויוצא לארוחות צהריים שנמשכות שעות.

הפתרון: שים את פינת העבודה שלו כשהמסך פונה לכיוון הדלת. לאף אחד לא נעים לעבוד כשהוא יודע שכל מי שעובר ליד הדלת שלו רואה שהוא בדיוק באמצע כתבה בוויינט. אם אתה יכול, צא איתו לארוחות צהריים ושלוט בקצב שלהם.

5.      הבטוח

הוא מלא בטחון עצמי. הקוד שלו עשוי מזהב. אין יותר טוב מזה. הוא כל כך טוב שאין שום סיבה לבדוק האם מה שהוא כתב באמת עובד והוא לא מבין למה מחלקת ה – QA איתו על הקו במשך רוב שעות היום. כנראה שהמשתמש לא לא משתמש נכון/המחשב דפוק/הרצפה עליה מונח השרת עקומה.

הפתרון: בכל פעם שהוא אומר סיימתי שלח אותו לבדוק את הקוד. כנראה שהוא לא יחזור כל כך מהר.

בשורה התחתונה, הרבה nתכנתים באמת באים לעבוד, אבל לפעמים מעט הכוונה יכולה להפוך מתכנת בעייתי למתכנת מעולה.

Aftermath

Time to stop


I've reached my stop-loss (one year) and even two month passed my deadline. When I set out to this journey I decided to give it a year before I quit. Success meant either getting a big user base or getting a seed investment. Now I have to face the hard facts that even though I gave it two more months it just didn’t happen.


The important thing now (and thanks to my wife for pointing that out) is to reach the right conclusions and learn for what I did or should have done.


So here is why I think I failed:


1. Finding the right partner – When I wanted to look for a partner I thought it would be almost impossible to find one. I am a developer, all my friends are developers, where am I going to find someone that understands business? As it turns out I was wrong about everything. It is the other way around. There are lots of business oriented people looking to join a startup and very few technical people. Finding a partner would have been easy if only I had tried.


2. Joining the wrong partner – as it turned out I joined the wrong partner. She was an old friend and also a programmer but I had a feeling she will be a good CEO. Wrong again. Lack of dedication and business skills caused delays, anxiety and deteriorating motivation. we were bad for each other. When I finally asked her to step aside she agreed but demanded to stay with 25% (no investor would agree to that). Five month after we decided to break up we are still fighting. Needless to say we are not friends anymore.


3. Not having a founders agreement – all that happened in the last section could have been avoided if we only had a founders agreement.


4. Not deciding to break up sooner – easy to say, hard to do but I should have done it.


5. Not facing the facts/deducing what we wanted – when we released our first version no one seemed to be interested in it. So instead of pivoting hard we decided that it was because people didn’t understand the potential. What we should have deducted from this is that people don’t really need what we offer and that we should change direction. In the end we spent another 8 month working on the same product only to realize there is no market for it.


6. Iterating slowly – after we released our first version and decided that people didn’t understand it we did some user testing and pointed out what we think is wrong with it. Instead of making a quick iteration and releasing a new version in a couple of weeks we made a huge iteration that lasted 8 month.


7. Not listening to advisors – we met with a lot of people and consulted with a lot of people from the industry. Many of them told us we were going the wrong way. We didn’t listen.


8. Working from home – if you can do it that usually means you are single. We were stupid to try and should have found an office. We did get accepted to a few programs that offered us a co-working space. That was great.


9. Didn’t put order into our work – we were unorganized. Even though we tried to use project management tools we didn’t have a work plan, milestones or budget planning and we missed our deadlines all the time.


10. Not making sure your significant other understands what he/she needs to do – make sure that your spouse knows he or she will see much less of you and that they will have more work at home.


11. Measure everything – we didn’t have enough data on our users. That is part of the reason we misinterpreted our results.


12. Start fundraising too late – unless you have a market validation (millions of users or 10 big clients or any other mean of validation) you are basically raising with a presentation. Don’t try to get the perfect product (it helps but less than you think). Try to get market validation and address a huge market. You don’t need to spend a year of R&D for that. Fundraising takes a couple of month and you can always come back after you have a product if that is what they require. Not many VCs/angels will close the door completely just because you came with a presentation and not a prototype.


13. Losing my life routines – stopped playing the guitar, stopped working out regularly. Even though there is less time find the time to do it or it will hurt your motivation.


14. Going to meetups – you don’t have time to attend all the meetups you want to attend. Choose only those that help you get more information or network with the right people.


15. Not managing our outsourcing – when you outsource something give them a timetable and insist on the deadlines. Try e-mailing them every three days to check on their progress. We didn’t do that at first and we got months of delays and bad code. We also lost a lot of money because we didn’t track their progress.


16. Outsource – never the less we should have outsourced the less important stuff and got thing done quicker. We had the money for it but didn’t use it until it was too late.


17. Didn’t set a hard deadline for stopping – I missed the deadline in two month. That shouldn’t have happened. If I didn’t allow myself to miss the deadline maybe I would have worked harder and made better decisions.


18. Didn’t make sure my spouse knew I appreciate what she has to go through – my wife didn’t go on vacation in two years and we almost stopped going out entirely. A word of appreciation would have gone a long way here.


19. Failed to build a balanced team – two programmers is not a balanced team. One bizdev, one product and one techy is a balanced team.


20. Didn’t research on investors before we met with them – one of the VCs we met told us that we do exactly what another company they invested in did but with less features. Even though they were wrong about that we should have checked their portfolio.


21. Built too many features into our first version – it is not the time that we wasted but the lack of focus that led us to miss what the users really need. We should have focused our MVP on the key feature and remove all the other features.


22. Didn’t register patents – even though we could and got budget for it we didn’t do it. It doesn’t cost that much to get a provisional patent and it really helps with investors.


23. Didn’t look for the right people to help – I spent a few month developing the algorithm before deciding to turn to a professor for help. Should have done it much sooner.


24. Ignored the numbers – if had just done the calculations I would have found out that it will cost us thousands of dollars to keep our servers up. That doesn’t help with investors and cost us some more money.


25. Kept servers running even though we didn’t have traffic – I honestly don’t know why.


26. Built it and they didn’t come – should have built a really simple MVP in three month even before I left my job to get some validation. I just jumped in and started building and building. I could have had a working product in January instead of June. Don't mind the small bugs and the little things. Just get it out. You'll figure out the little thing later.


27. Didn’t manage my time and tasks – read getting things done or use any other method but manage your personal tasks. It will help you clear your mind and focus on your work.


28. Didn’t read the lean startup – should have.


29. Didn’t learn from mistakes – hence the post.


30. Didn’t spend enough time on the product – don’t start building before you have a general idea how the product is going to look like and after you consulted with someone (for instance an intended user) on how it is supposed to look.






In spite of all the above here is what I did right:


1. Had a great presentation and practiced it almost daily until it was perfect – we managed to get people interested by telling a good story and talking fluently and passionately on the product. Though it looked easy, we practiced a lot.


2. Joined a co-working space – sitting with other entrepreneurs was a great experience and we learned a lot just by being with other people. We joined the junction and had great meetings with people and a lot of support.


3. We dedicated all of our time for the project – we quit our jobs and put all of our effort into it.


4. We used ruby on rails and cloud services – using ruby or python is great for fast prototyping. We had a working app pretty fast because we had the right tools.


5. We used a lot of low priced and open-source resources – bought a design template for a few dollars, used all the open source stuff we could get and managed to build something that looks incredible very quickly and with minimal effort.


6. We had shirts printed – should have been earlier but it really helps to draw the eyes of the right people when you are at conventions (one t-shirt per person is enough).


7. I found the right partner – The next partner I found was a very experienced business development specialist and cool guy – he really helped me realize we don’t have a market.


8. We tried getting money from everywhere we could – office of chief scientist, Microsoft AppCampus and every other grant possible got a request from us. We got some decent amounts of money for it that helped us at first.


9. I never missed a chance to learn more – more about developing a startup, more about cloud computing, more about ruby on rails. There is so much I've learned and it was the best part.


10. Didn’t lose hope – even though I got to the conclusion we shouldn’t continue I didn’t break even when things were really tough.


11. I came out a better entrepreneur than I came in.






It was a bumpy ride but I am already waiting for the next one.

GTD - למה אתה חייב את זה

GTD היא שיטה לאירגון המשימות שלך שפותחה ע"י דייויד אלן ומטרתה היא לגרום לך לנהל את המשימות שלך באופן שלא יכביד עלייך
דייויד אלן מציג את מטרת השיטה באופן מאוד מעניין. לטענתו, המטרה היא לא רק הגדלת הפרודוקטיביות, אלא גם ובעיקר  שקט נפשי.
בחיי כל אדם ובפרט בחיי יזם צצות להן משימות שונות בתחומים שונים, שנעות מלעבוד על הצעת הרכישה מפייסבוק ועד לרשום את הילד לגן. המסודרים שבינינו רושמים את המשימות החשובות ע"מ לא לשכוח אותן והפחות מסודרים פשוט מנסים לשמור הכל בראש ללא הצלחה. השיטה הזו, בה נוקטים רוב האנשים, גורמת לכך שתמיד יש משהו שאתה מרגיש שפיספסת (ובצדק) ולתחושה תמידית של לחץ ותסכול ובנוסף לכך פגיעה בפרודוקטיביות.
שיטת GTD מתיימרת לפתור את הבעיה. עקרונות השיטה הם מאוד פשוטים.

צור לך סל "דואר נכנס" שירכז את כל הנושאים הפתוחים שצצים לך בראש. אני משתמש בשלושה סלים, סל פיזי בו אני שם חשבונות וניירת שעלי לעבור עליהם, פנקס בו אני רושם נושאים שצצים לי בראש כשאני בתנועה ותוכנת Astrid שמותקנת לי על הסלולארי ומסתנכרנת לי עם האתר והאייפד, כך שאני יכול לגשת אליה מכל מקום ושם מרוכזות המשימות הסופיות. 

צור לך 4 רשימות אליהן אתה מכניס את כל הנושאים הפתוחים שלך 

•  רשימת מטלות פיזיות - עבור כל נושא פתוח בדואר הנכנס שעלייך לפעול לגביו מצא את הפעולה הפיזית המיידית שעלייך לבצע לגביו, כלומר לקנות מחשב אינה משימה מאחר ולפני שאתה קונה מחשב אתה רוצה לברר מחירים ולפני בירור מחירים אתה צריך להוציא מפרט למחשב ובשביל זה אתה צריך להתקשר לחבר שמבין בתחום ולכן הפעולה היא להתקשר לחבר. את הרשימה הזאת חלק לתתי רשימות עפ"י מה אתה יכול לעשות במצב נתון לדוגמא משימות בתת-הרשימה שיחות טלפון אתה יכול לבצע  בכל מקום עם טלפון בעוד שמשימות ברשימת מול מחשב אתה יכול לכצע רק כאשר אתה מול מחשב. 

• רשימת פרוייקטים - כל נושא פתוח שנדרשות לו יותר מפעולה אחת ירשם ברשימה הזו.

•  רשימת "מחכה ל" - נושאים פתוחים שמחכים לגורם שלישי ע"מ שתוכל להמשיך לפעול, לדוגמא מחכה לעו"ד לחוזה חדש. 

•  רשימת "אולי מתישהוא" - כל פרוייקט שאינו דחוף ושאינך בטוח שאתה בכלל רוצה לפעול לגביו, לדוגמא לקחת קורס בספרדית.

  ועכשיו פעם בשבוע עבור על כל הדואר הנכנס שלך ומיין אותו לארבע הרשימות.

הספר מפרט עוד הרבה אלמנטים בשיטה על מנת ליצור מערכת סגורה ויעילה של טיפול במשימות. מנסיוני שימוש בשיטה מעלה את הפרודוקטיביות ומוסיף הרבה רוגע לחיים של יזם שממילא נדרש להתמודד עם עשרות גורמים ומשימות שניחתות עליו מכל עבר.

קישור לספר

 

המונחון - כדי שתבין על מה מדברים

לעולם הסטארטאפים יש שפה משלו. אם החלטת להיכנס אליו כדאי שתדע לפחות את המונחים הבסיסיים. כשירות לציבור החלטתי לייצר את מונחון הסטארטאפים. מוגש כאן ערב רב של ביטויים ששמעתי במהלך התקופה בה הפכתי ליזם ואני מודה שעל חלקם הגבתי בהינהון מבין ואז הלכתי לחפש בויקיפדיה מה זה אומר.

• pre-seed - שלב השני אנשים ולפטופ. שלב גיוס בו מנסה היזם לגייס סכום כסף ראשוני בדרך כלל על סמך רעיון בלבד זאת על מנת שיוכל להגיע לאב-טיפוס ולעבור לשלב הבא.
• seed - שלב גיוס כספים מתקדם יותר על מנת להרים מוצר פעיל.
• סיבוב ראשון, שני וכו' - כל שאר הגיוסים.
• go-to-market - אסטרטגיית החדירה לשוק. אם מישהו שואל אותך מה ה - go-to-market שלך כדאי שתענה משהו כמו פירסום ברשתות חברתיות בשילוב שיווק גרילה וחבירה ליצרן מוביל או משהו בסגנון הזה.
• bootstrap - סטארטאפ שמוקם  ללא מימון חיצוני.
• אנג'ל - משקיע פרטי המשקיע בדרך כלל בשלב התחלתי של המיזם פרה-סיד או סיד (ע"ע) ובדרך כלל בסכומים קטנים. לדוגמא יוסי ורדי (ע"ע).
• יוסי ורדי - נחשב האבא של אומת הסטארטאפ. אחרי שביצע את האקזיט המתוקשר הראשון במדינה של אייסיקיו התחיל להופיע בכל פינה אפשרית בעולם הסטארטאפים.
• B2B - מוצר המיועד לעסקים.
• B2C - מוצר המיועד ללקוחות פרטיים (כמו דודה שלך מחולון לדוגמא).
• B2B2C - מוצר המיועד ללקוחות עסקיים לעבודה מול הלקוחות הפרטיים.
• Enterprise - מוצר לעסקים ע"ע B2B. הכוונה כאן איננה לספינת החלל ממסע בין כוכבים.
• Executive summary - תקציר מנהלים בד"כ דף אחד או שניים המתאר את העסק.
• VC - קרן הון סיכון.
• FFF - ר"ת של Friends, Family and Fools , אנשים שאפשר לגייס מהם הון ראשוני מבלי שבאמת תצטרך להסביר להם מה אתה עושה.
• Stealth mode - חברה שעובדת על משהו אבל לא מספרת על מה. בד"כ גם הם לא סגורים בשלב זה על מה הם עובדים.
• IP - ראשי תיבות של Intellectual property כלומר כל הקניין הרוחני של הסטארטאפ שלך
• IPO - בלי קשר לסעיף הקודם הנפקת מניות לציבור ידוע גם כאקזיט
• אקזיט - מכירת החברה לחברה חיצונית או הנפקה. אם אתה לא יודע מה זה מה אתה עושה פה?
• אקסלרטור - חממה להאצת סטרטאפים. בדרך כלל נותנים סכום זעום תמורת כ - 8%, אבל משלימים את ההפרש במנטורינג והכוונה ששווים די הרבה.
• חממת מדען - חממה טכנולוגית שמורכבת מקרנות פרטיות ועוד כסף מהמדען הראשי.
• CTO\CEO\CMO - תפקידים בארגון, בהתאמה, מנכ"ל סמנכ"ל טכנולוגיות, סמנכ"ל שיווק (יש עוד אבל אלה האנשים שאתה בדרך כלל נתקל בהם)
• Y-combinator - אקסלרטור בארה"ב שידוע בכך שהוא מוציא חברות מצליחות. אם התקבלת לשם אתה די מסודר.
• גודל השוק - אם המוצר שלך היה מגיע לכל משתמש אפשרי, כמה כסף היית עושה מזה.
• demo day - יום בו מכנסים כמות יפה של משקיעים בשביל להראות להם הרבה חברות במכה.
• Elevator pitch - נאום של שתי דקות שמסביר על מה הסטארטאפ ויכול להדליק משקיע פוטנציאלי במקרה ואתה נתקל באחד לפרק זמן קצר (לדוגמא במעלית
• Slide deck - מצגת שקופיות (זה מה שאתה מציג למשקיעים)
• one pager - דף אחד שמסביר מה אתה עושה (זה מה שאתה שולח למשקיעים במייל)
• ענן - ערימה של שרתים הנמצאים איפשהוא שאתה יכול בקלות לקחת כמה מהם ולפרוש עליהם את האפליקציה שלך. היתרון הוא שאם אתה פתאום גדל מאוד מהר מאוד קל להרים שרתים חדשים.
• UX - מילה שמשתמשים בה בלי סוף ולא תמיד בצורה מוצדקת. הכוונה היא לחווית המשתמש, כלומר כמה כיף ונעים לאנשים להשתמש במוצר שלך. כולל הרבה דברים מאיזה פונט וצבעים להשתמש ועד איזה מסכים ליצור.
• The lean startup - ספר מאת אריק רייס שכרגע הוא התנ"ך של עולם הסטארטאפים.
• MVP - ר"ת של Minimal Viable Product - המוצר המינימלי שצריך לבנות על מנת להוכיח שקיים צורך בשוק. בשביל להבין עוד אני ממליץ לקרוא את הספר מהנקודה הקודמת.
• KPI - ראשי תיבות של Key performance indicator, מדד להצלחת המיזם בשלב מסויים לדוגמא מספר משתמשים חודש לאחר ה - lauch (ע"ע)
• launch - השקת המוצר/הוצאתו לשוק
• Equity - אחוזי בעלות בחברה.
• Vesting - שיטה המאפשרת צבירה של אחוזים בחברה\אופציות לפי מידת ההשקעה של העובד\יזם בחברה. לדוגמא היזם יקבל 25% מהמניות שלו בכל שנה מארבע השנים הראשונות שהוא עובד בחברה.

אני אמשיך לעדכן כשאחשוב על עוד מונחים.

באיזו שפה לכתוב?

אם הסטארט אפ שלך הוא טכנולוגי ואתה איש הטכנולוגיה בחברה (ובשלב זה כנראה המתכנת היחיד) אתה בוודאי תוהה באילו טכנולוגיות להשתמש.
ישנו מגוון אדיר של שפות תכנות כאשר לכל אחת יתרונות וחסרונות (מפורטות כאן טכנולוגיות ווב בלבד):

• #C - שפת תכנות המשתלבת עם ASP.net בעלת קהילה רחבה בעיקר בארץ ותמיכה חזקה ממייקרוסופט. החסרון הוא הסלידה של כל מי שאינו נאמן מייקרוספט מהשפה וקהילת קוד פתוח מצומצמת.
• PHP - שפה בעלת קהילה גדולה מאוד. לא קל למצוא מפתחים בארץ אבל אפשרי.
• Ruby on rails - שפה חזקה מאוד המאפשרת לפתח אתרים במהירות מדהימה, בעלת קהילה חזקה ומתפתחת בקצב מהיר. חסרונותיה הם שכמעט בלתי אפשרי למצוא מתכנתים בארץ.
• python - שפה פשוטה ללמידה ובעלת קהילה חזקה בארץ. פחות פופולארית משפות ווב אחרות.

אם כן באיזו שפה לבחור? התשובה היא, חד משמעית, השפה שאתה מכיר. בשורה התחתונה השפות הן דומות ואתה צריך להוציא מוצר MVP במהירות האפשרית (ראה פוסט קודם: http://www.blogger.com/blogger.g?blogID=609575871991007353#editor/target=post;postID=4543910152704820403) ולכן אל תשקיע שעות מיותרות בלמידת טכנולוגיות חדשות. תבנה את המוצר כמה שיותר מהר ורוץ איתו. 

כמובן שזה לא אומר לכתוב את המוצר באופן חובבני תוך התעלמות מעקרונות תכנות נכונים. אחרי הכל בסופו של דבר תשכור עוד מתכנתים שייאלצו להיכנס לקוד שלך ואחד היעדים שלך הוא שהם יקללו אותך כמה שפחות.

אז עכשיו כשבחרת שפה, צא לדרך, תכנן את המוצר והתחל לכתוב אותו, השאר כבר יסתדר מעצמו. 

MVP - תן למוצר לכוון אותך

הביטוי MVP נזרק לחלל האויר בערך 20 פעם ביום כשאתה בונה את המוצר המשמעות שלו הוא Minimal Viable Product, כלומר המינימום ההכרחי של פיצ'רים במוצר שלך כדי להוציא אותו לשוק.
למה בעצם להוציא מוצר מינימלי?
סיפור לדוגמא, מכר שלי פתח סטארט אפ חדשני ומרתק. הוא עבד עליו במשך שנתיים תמימות כולל הפיתוח, העיצוב, האפיון וכל אלמנט אחר שניתן לחשוב עליו והוציא מוצר יפיפה, מרשים, מעוצב ומדוגם. רק לאחר ההשקה התברר שפרט קטן הוא שכח לקחת בחשבון, אין כל כך דרישה למוצר שלו. שנתיים של עבודה ירדו לטמיון רק בגלל פרט קטן ושולי של הצורך במוצר.
בדיוק כדי לטפל בבעיה הזאת (ובעוד בעיות דומות) כדאי להוציא מוצר ראשוני. המוצר לא צריך להיות מושלם. הוא לא צריך להיות שלם ולא מעוצב (אפשר להסתפק בעיצוב מוכן שניתן לרכוש בעלות של פחות מחמישים דולר). מה שכן חשוב במוצר זה שהמשתמשים הפוטנציאליים יבינו על מה המוצר, איך הוא עובד ומה הוא נותן להם.
לאחר שמוציאים את הגרסא הראשונית מתחילה העבודה הקשה. דבר ראשון צריך לגייס כמה עשרות משתמשים ולנהל איתם אינטראקציה צמודה של משוב והיזון חוזר. ישנם מספר אתרים שישמחו לשלוח את המוצר שלך למגוון משתמשים בחתכים שונים על מנת שיבדקו את המוצר דוגמאות נבחרות הן:

• https://www.usertesting.com/
• http://www.feedbackarmy.com

אתרים אלו יתנו לך משוב חסר פניות לגבי המוצר שלך. כמובן שאם יש לך אתר בטא (לדוגמא, אצל הלקוח הגדול שהשגת לפני שבכלל הקמת את האתר אם היה לך את השכל והמזל לעשות כן) תוכל לקבל משוב מיידי ומדוייק יותר.

מעבר להפצת האתר לכמה עשרות משתמשים, כדאי לשבת עם לפחות שניים שלושה משתמשים כתף אל כתף ולבחון את התגובה שלהם למוצר ממקור ראשון. אם הם מגיבים לפיצ'רים מסויימים או חס וחלילה לכל המוצר בעיוות פנים מיוסר סימן שעשית משהו לא טוב. חשוב לתחקר אותם היטב במהלך העבודה על מנת להבין מה הם אוהבים ומה הם לא סובלים על מנת שיהיו לך נתונים להמשך.

אתה יכל לשלוח את האתר למשתמשים ולהתחיל לקבל פידבקים וכבר תרגיש שהמוצר שלך מתחיל להתקדם קדימה, אבל כדאי לעשות עבודת הכנה קודם לכן.

• הכן שאלון לבודקים על מנת שתוכל לקבל את הפידבק שאתה רוצה ולא משהו בסגנון, "אתר סבבה" שלא תורם לכלום.
• הכנס מדידות באמצעים טכנולוגיים. Google analytics, יכול לעזור במקרה זה.
• החלט על מדדים מספריים, דוגמת כמה משתמשים ביום, מספר פעולות של משתמש, כמות לייקים וכיו"ב.

אם עשית את כל זה כנראה שקיבלת כבר כעבור כמה ימים די הרבה מידע שיעזור להתאים את המוצר שלך למציאות, בתקוה שההתאמה לא אומרת לזרוק אותו לפח, בכל מקרה גם אם התגובות היו חיוביות מה שאומר המשך כך וגם אם היו שליליות מה שאומר הפסק עכשיו ותחשוב מחדש, יש לך פה כלי מדהים לעיצוב מוצר - המשתמשים.