我一直觉得,非技术人员和技术人员的创业切入口是不同的.各种人,想创业,或参与创业,一定要选择适合自己的入口,各自发挥自己的优势和特长.
技术人员,要发挥和利用的是自己的技术优势. 所以,技术人员,如果独立创业,很多会是从技术方面的创新入手,发现一些技术市场的需求.所以,他们的完全的独立创业,很多应该是从技术创新.技术微创新入手,做和技术市场相关的,成功几率才会比较大. 如果,技术人员要进入到某个行业,做业务创新,模式创新,应用创新,应该是本来对那个行业已经有相对深入的了解和研究. 或者对这个行业感兴趣后,对这个行业做过深入细致的研究.
确实,阿北是技术人员出身,他做出了豆瓣,那是因为,他对读书,音乐本身非常感兴趣,长期写乐评,也在各个论坛和人交流这些的过程里,抽象出这方面的深层次的一个需求,发现在读书,音乐方面的交流模式上还有需求没有被很好地满足.他不仅从读书角度,还从业务本身的角度有研究. 他自己是产品+技术.而一般技术人员,没有行业背景,和对这个行业市场的充分研究,做自己不擅长的,对需求了解不够,自己不能真正做好产品设计,擅长的是技术设计,进入行业时,失败的几率就大了很多.有些即使能做出不错的东西,没有随后紧跟而来的运营和宣传能力,失败的几率也大.
而非技术人员,要创业,一定是对行业有相当的了解,不仅作为一般的用户,还需要作为一个产品专家的角度. 是对细分市场,垂直行业的垂直市场的需求,甚至,对产品各个细节的要求点,都想的很深很透,一定要有很细致的琢磨. 设计出有核心价值,又有足够差异化的产品.如果,一个非技术人员,想着是一个天马行空,完全从技术角度要去实现的创新,那就完全和他擅长的违背,因为,他完全无法判断,这样的技术的可能.基本,是一定会死掉的一个项目.
一个团队,应该是好的产品,好的技术,好的运营几方面的人才的组合.各自发挥自己的优势,做好自己的定位.各个角色要彼此信任,彼此配合.当然,如果,你能身兼数职,那是最好.起步时,还没壮大到可吸引更多人才时,你自己能身兼数职,确实可能就会更容易一些.但这种可能比较少.所以,团队的合力非常重要.
我在和技术人员打交道的过程里的感受是,有些技术人员,当他们决定参与一个非技术创新,属于业务创新的创业项目时, 他们往往因为,觉得自己这是在创业,而很容易变了初衷和初始的角色定位,不是从技术角度着手,不是从技术实现的角度着手,不是把自己定位在技术总负责,而是希望自己能完全决定自己并不太熟悉的产品方向,或者,运营方向. 他们不是从技术角度去和产品人员讨论产品和需求如何实现, 而是会从自己的角度很强势地去设计自己可能还不太熟悉的产品,去规划自己不太熟悉的需求,设计自己不熟悉的运营.
每一个创业团队的人,以积极的态度,尽可能主人公的参与,重大问题,所有关键人员一起参与讨论,这个是非常正确的.但各自还是需要有相对明确一些的角色定位,在对某个方面具体的细节的有争论时,决定还是应该由擅长和负责这个方面的人,做决定. 彼此要对对方在这方面的能力给予相当的信任. 求同存异.按应该对该部分负责的人的方案,敏捷迭代,做出东西来,收到反馈,修改.
就如,产品人员不应该替后台程序员决定,他应该用什么框架,是用hibernate还是ibitas,还是JDBC. 哪怕是作为创始人的产品人员,在讨论到这些时,也只能是提供一些其他人的建议做参考.可以在事先对一些问题和技术人员聊聊,对这个人的技术思维有些大致的了解.但一旦选定了,开始了,技术上如何实现的这些就应该交给技术人员,由他来做决定. 而不是技术外行的产品人员做决定.产品人员只用关心,自己设计,自己的需求,是不是被完好准确地实现了.要充分相信,和自己搭档的技术人员,只是在尽可能的范围内,帮助他们.但绝对不是干预本来该他们做决定的事情.
而反过来,后台技术人员,如果,在业务逻辑上,产品设计上, 有自己的看法,提出建议自然是很好的,但要是一个技术和产品是各自有比较明确分工的团队,最后是由本来定位在技术的技术人员来主导产品和需求,那么要么是产品人员有问题,不值得信任,这个产品人员应该离开,要么是技术人员,过于信任自己,或者是有误会,以为只有主导产品的方向,才是真正参与了创业.其实,不是只有idea重要,不是只有设计重要,技术,在让一个idea真正能实现时,是非常重要的. 从技术角度去考虑,一样是真正的创业.是参与打造产品.当然,前提是,你要对于,与你合作的产品人员,有足够的信任,如果,这个产品人员是创始人的话,你要对这个创始人有足够的信任.有时,甚至,就是一种纯粹的,无来由的绝对信任.
我自己遇到的现实问题就是, 我希望的是有创业激情的技术人员对在做的事情有个基本的大的方向的认可下,作为技术人员来一起参加.结果,在和那些有点创业愿望的技术人员交流时,经常遇到的就是,一些事先对这个领域一点没有研究,完全仔细琢磨过这个领域需求的人,他能在10多分钟,半小时,2小时,半天,最多1-2天内,在对你的需求构思还没有真正完全明白的时候,就已经觉得非常了解.
其实,10多分钟半小时就决定放弃,那是一点不足为惜. 可是,有的明明表现出了很强烈的参加热情和欲望,却在并不太了解或略又了解时, 花很长很长时间去和你争论需求,产品方向,是强烈地想参与,却又强烈地否定你的思路,想按自己的想法主导需求和产品方向,你要费很多劲去说服为什么你这么设计,为什么确实是有这样的需求. 而且,多数时候,因为,他们很快就有了主意,你还很难说服. 这个真的是很让人费神.
我现在,其实,不是缺的产品人员, 我自己就是产品人员,我确实知道自己想做什么,要做什么,对市场和需求也有足够的信心.我也确实很希望来参与的技术人员,有很强的主观能动性,能很深入地参与讨论,但我真的是希望,在现在,我已经花了足够的时间琢磨产品以后,在我们现在这个阶段,我们的时间是更多地花在讨论如何实现上,而不是过多花在争论产品方向和需求的角度. 选定了方向,剩下的需要的就是执行.
我现在,真的是承认,我的idea不重要,好的执行力很重要.
我现在真的很怀疑,我是不是真的能找到,这样,能对我的产品能力和其他非技术能力有足够信任,又有我希望的能力的想创业的技术人员.我不知道,我能不能遇到一个,真的肯把自己的一小段未来,哪怕是几个月时间,完全信任地交给我,去拿一小段时间的努力工作,赌一个可能未来的技术人员.
我一直希望,我能有个执行力强的技术型的技术人员做搭档, 现在,我发现,想创业的技术人员,可能都是有很强的产品意识的产品型技术人员:) 而我,不太可能在目前这一小阶段,去让技术人员来主导我自己想做的产品方向,在将来,是可能的.
我在想,也许,我不应该是找创业人员,就是找来工作的人员. 也许,那样,是执行力更强的.虽然,他们少了主动性.
顺便说一句, 昨天,不,前天晚上新来的小伙子,今天讨论后,决定离开.
确实是比第一个小伙子更快:)
小伙子觉得我们对产品的认识不一致.
是我不对,我应该在小伙子决定来之前告诉他我在做什么的.可是他没问. 他可能觉得来了后,了解更清楚一些.
技术人员,要发挥和利用的是自己的技术优势. 所以,技术人员,如果独立创业,很多会是从技术方面的创新入手,发现一些技术市场的需求.所以,他们的完全的独立创业,很多应该是从技术创新.技术微创新入手,做和技术市场相关的,成功几率才会比较大. 如果,技术人员要进入到某个行业,做业务创新,模式创新,应用创新,应该是本来对那个行业已经有相对深入的了解和研究. 或者对这个行业感兴趣后,对这个行业做过深入细致的研究.
确实,阿北是技术人员出身,他做出了豆瓣,那是因为,他对读书,音乐本身非常感兴趣,长期写乐评,也在各个论坛和人交流这些的过程里,抽象出这方面的深层次的一个需求,发现在读书,音乐方面的交流模式上还有需求没有被很好地满足.他不仅从读书角度,还从业务本身的角度有研究. 他自己是产品+技术.而一般技术人员,没有行业背景,和对这个行业市场的充分研究,做自己不擅长的,对需求了解不够,自己不能真正做好产品设计,擅长的是技术设计,进入行业时,失败的几率就大了很多.有些即使能做出不错的东西,没有随后紧跟而来的运营和宣传能力,失败的几率也大.
而非技术人员,要创业,一定是对行业有相当的了解,不仅作为一般的用户,还需要作为一个产品专家的角度. 是对细分市场,垂直行业的垂直市场的需求,甚至,对产品各个细节的要求点,都想的很深很透,一定要有很细致的琢磨. 设计出有核心价值,又有足够差异化的产品.如果,一个非技术人员,想着是一个天马行空,完全从技术角度要去实现的创新,那就完全和他擅长的违背,因为,他完全无法判断,这样的技术的可能.基本,是一定会死掉的一个项目.
一个团队,应该是好的产品,好的技术,好的运营几方面的人才的组合.各自发挥自己的优势,做好自己的定位.各个角色要彼此信任,彼此配合.当然,如果,你能身兼数职,那是最好.起步时,还没壮大到可吸引更多人才时,你自己能身兼数职,确实可能就会更容易一些.但这种可能比较少.所以,团队的合力非常重要.
我在和技术人员打交道的过程里的感受是,有些技术人员,当他们决定参与一个非技术创新,属于业务创新的创业项目时, 他们往往因为,觉得自己这是在创业,而很容易变了初衷和初始的角色定位,不是从技术角度着手,不是从技术实现的角度着手,不是把自己定位在技术总负责,而是希望自己能完全决定自己并不太熟悉的产品方向,或者,运营方向. 他们不是从技术角度去和产品人员讨论产品和需求如何实现, 而是会从自己的角度很强势地去设计自己可能还不太熟悉的产品,去规划自己不太熟悉的需求,设计自己不熟悉的运营.
每一个创业团队的人,以积极的态度,尽可能主人公的参与,重大问题,所有关键人员一起参与讨论,这个是非常正确的.但各自还是需要有相对明确一些的角色定位,在对某个方面具体的细节的有争论时,决定还是应该由擅长和负责这个方面的人,做决定. 彼此要对对方在这方面的能力给予相当的信任. 求同存异.按应该对该部分负责的人的方案,敏捷迭代,做出东西来,收到反馈,修改.
就如,产品人员不应该替后台程序员决定,他应该用什么框架,是用hibernate还是ibitas,还是JDBC. 哪怕是作为创始人的产品人员,在讨论到这些时,也只能是提供一些其他人的建议做参考.可以在事先对一些问题和技术人员聊聊,对这个人的技术思维有些大致的了解.但一旦选定了,开始了,技术上如何实现的这些就应该交给技术人员,由他来做决定. 而不是技术外行的产品人员做决定.产品人员只用关心,自己设计,自己的需求,是不是被完好准确地实现了.要充分相信,和自己搭档的技术人员,只是在尽可能的范围内,帮助他们.但绝对不是干预本来该他们做决定的事情.
而反过来,后台技术人员,如果,在业务逻辑上,产品设计上, 有自己的看法,提出建议自然是很好的,但要是一个技术和产品是各自有比较明确分工的团队,最后是由本来定位在技术的技术人员来主导产品和需求,那么要么是产品人员有问题,不值得信任,这个产品人员应该离开,要么是技术人员,过于信任自己,或者是有误会,以为只有主导产品的方向,才是真正参与了创业.其实,不是只有idea重要,不是只有设计重要,技术,在让一个idea真正能实现时,是非常重要的. 从技术角度去考虑,一样是真正的创业.是参与打造产品.当然,前提是,你要对于,与你合作的产品人员,有足够的信任,如果,这个产品人员是创始人的话,你要对这个创始人有足够的信任.有时,甚至,就是一种纯粹的,无来由的绝对信任.
我自己遇到的现实问题就是, 我希望的是有创业激情的技术人员对在做的事情有个基本的大的方向的认可下,作为技术人员来一起参加.结果,在和那些有点创业愿望的技术人员交流时,经常遇到的就是,一些事先对这个领域一点没有研究,完全仔细琢磨过这个领域需求的人,他能在10多分钟,半小时,2小时,半天,最多1-2天内,在对你的需求构思还没有真正完全明白的时候,就已经觉得非常了解.
其实,10多分钟半小时就决定放弃,那是一点不足为惜. 可是,有的明明表现出了很强烈的参加热情和欲望,却在并不太了解或略又了解时, 花很长很长时间去和你争论需求,产品方向,是强烈地想参与,却又强烈地否定你的思路,想按自己的想法主导需求和产品方向,你要费很多劲去说服为什么你这么设计,为什么确实是有这样的需求. 而且,多数时候,因为,他们很快就有了主意,你还很难说服. 这个真的是很让人费神.
我现在,其实,不是缺的产品人员, 我自己就是产品人员,我确实知道自己想做什么,要做什么,对市场和需求也有足够的信心.我也确实很希望来参与的技术人员,有很强的主观能动性,能很深入地参与讨论,但我真的是希望,在现在,我已经花了足够的时间琢磨产品以后,在我们现在这个阶段,我们的时间是更多地花在讨论如何实现上,而不是过多花在争论产品方向和需求的角度. 选定了方向,剩下的需要的就是执行.
我现在,真的是承认,我的idea不重要,好的执行力很重要.
我现在真的很怀疑,我是不是真的能找到,这样,能对我的产品能力和其他非技术能力有足够信任,又有我希望的能力的想创业的技术人员.我不知道,我能不能遇到一个,真的肯把自己的一小段未来,哪怕是几个月时间,完全信任地交给我,去拿一小段时间的努力工作,赌一个可能未来的技术人员.
我一直希望,我能有个执行力强的技术型的技术人员做搭档, 现在,我发现,想创业的技术人员,可能都是有很强的产品意识的产品型技术人员:) 而我,不太可能在目前这一小阶段,去让技术人员来主导我自己想做的产品方向,在将来,是可能的.
我在想,也许,我不应该是找创业人员,就是找来工作的人员. 也许,那样,是执行力更强的.虽然,他们少了主动性.
顺便说一句, 昨天,不,前天晚上新来的小伙子,今天讨论后,决定离开.
确实是比第一个小伙子更快:)
小伙子觉得我们对产品的认识不一致.
是我不对,我应该在小伙子决定来之前告诉他我在做什么的.可是他没问. 他可能觉得来了后,了解更清楚一些.
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
