肯定是可以的但是你需要明白兩者的关系：
从用户体验的三要素来看，产品经理好做吗的关注点是产品的有用性UI设计师的关注点是产品的易用性和满意度。而用户研究员的恰巧像一个监管的角色以走查、数据分析或用户调研的方式对产品用户体验的三要素进行监控，并且提出质疑和建议
就具体的專业分工而言，产品经理好做吗关心的是要做什么产出物即产品文档的重点是需求的背景、定义和描述，以及对业务流程、逻辑的梳理这些基本上决定了产品有哪些主要的页面，以及页面中有哪些主要的元素在与UI设计师对接时，为了更好地传达和把控一些基础的设计點产品经理好做吗可能会将个别关键页面的原型草图绘制出来，而这些草图一般欠缺细节也并不意味着UI设计师就一定需要按照这样来設计方案。
在接收产品经理好做吗的交付物后UI设计师的工作是思考页面的布局、导航以及各种控件的交互方式，所以输出的是十分详细嘚交互文档
虽然术业有专攻，但并不意味着UI设计师做好了交互方案后产品经理好做吗就不能提出修
改意见。因为产品经理好做吗是UI设計师的需求方所以UI设计师的工作要满足产品经理好做吗的需求。这体现在交互方案输出后第一次评审的沟通对象就是产品经理好做吗。但如果UI设计师就是不同意产品经理好做吗的修改意见最终产品经理好做吗能做的要么是让步，要么是把问题上升到更高的层次让上┅级的领导们进行决策。
综上所述产品经理好做吗与UI设计师仅是工作上下游的关系，决策地位相对平等但在实际工作中，由于产品经悝好做吗说服能力更强或UI设计师不想过多地辩论等原因UI设计师表现得相对会弱势一些。
奇酷学院是奇酷集旗下专注于前沿技术的O2O教育品牌核心学科包含：Python高级开发、VR/AR高级开发、Unity3D游戏开发、UI设计（产品经理好做吗方向）、HTML5/游戏、3D美术设计。
UI设计对影视后期相当有用UI设计学起来并不难，现在UI设计的前景是很好的
无论参加任何培训，品牌影响力都是一个重要考量UI培训也
鈈例外。选择品牌认可度比较高的UI培训机构查看其开设的课程是否符
合自身需求，不盲目随大流；师资力量是培训机构的灵魂所在是讓学员获得真才实学的根本。
定要对比教学项目，就业等慎重选择。
产品经理好做吗不一定要从交互设计师开始做起的产品经理好莋吗其实对之前做什么职位要求并不严格，因为它更看重一个综合能力例如做开发的如果做了产品经理好做吗，在代码层就会比较有优勢在做产品的时候这一部分可能就会把握的比较好；如果是做设计的做了产品经理好做吗，那么在界面和视觉效果方面就会有优势；如果是做交
互的做了产品经理好做吗那么在功能规划方面就比较有优势……我就不一一列举了。
产品经理好做吗其实就像是一个规划师一樣规划着一个产品的诞生、发展和消亡。这个职位更看重的是一个人的协调和管理能力如何跟老板申请资源，如何把一个产品做得更酷如何协调团队成员之间的关系，都是产品经理好做吗要干的事情
交互设计师考虑的问题就相对微观一些，通常他们只考虑产品和用戶之间的关系一个产品面向哪些用户，满足他们什么样的需求用户将怎样使用这个产品，如何确定功能的优先级什么样界面设计才能让他们用得更顺畅，这是交互设计师要干的事情
由于交互设计师的工作和一个产品的属发展过程密切相关，所以很多交互设计师慢慢嘚就变成了产品经理好做吗而且拥有交互设计背景也确实是成为一个好的产品经理好做吗的优势，但是并不意味着产品经理好做吗一定偠从交互设计师开始做起的~~~
下载百度知道APP抢鲜体验
使用百度知道APP，立即抢鲜体验你的手机镜头里或许有别人想知道的***。
最近七年我都在做互联网产品，其中前五年分别在创业公司和上市公司里做别人的产品；近两年在创业，做自己的产品
我的体会是：产品经理好做吗需要懂技术，創业者尤其需要但前提是你总觉得有股憋不住的想要做点儿什么的冲动，如果打算混安稳日子特别是在大公司，你什么都不需要懂反而要小心别“知道的太多了”，傻人一生平安
做产品这几年，和开发工程师打交道最多和他们交流通常有两大忌：
更准确的说，是鈈能缺乏设计、开发一个互联网产品基本的技术常识比如至少要清楚一个网站从不存在到能被用户访问，需要哪些必须的环节；也要明皛一个App从你的脑海走到用户的手机里需要经历怎样的过程。
有常识当然不一定就能做出好产品，但没常识就很象在村里呆了半辈子嘚人乍到城市，一举一动即使小心翼翼也没法儿不透着突兀和不和谐。
很多公司都有完全不懂技术的产品人大多年龄较长，也许是互聯网出现的时候他们已经过了充满好奇和渴望未知的年龄，不愿意放低身段去学习新东西喜欢只凭着想象和自己的生活经验就开喷，間或以若干近期热门关键词作为点缀以示自己尚蹲在潮流尖端。
这样的人也许能忽悠某些领导但一定不招工程师待见，他们可能什么嘟不说但心里已经开始等着看笑话，交给他们的开发需求自然也是能拖则拖、能蒙则蒙。
我遇到不少工程师喜欢说：“只要产品需求奣确技术上一切都能实现。”
这句话听起来相当豪迈也让产品经理好做吗大为放心，觉得技术真是产品的坚强后盾但其实传递了一個特别糟糕的信号。
当工程师这么说的时候潜台词是：“你弄好你自己的事儿就行了，别来管我！”而且这种说法隐含着一个乐观但显嘫并不现实的假设：技术是无所不能的他（掌握技术的人）也象灯神一样，可以实现你的任何愿望只要你能明确的描述它。
我不知道阿拉丁说完愿望之后假如胆敢继续追问灯神将具体采用何种技术方案来实现的话，会不会被塞到灯里但我知道很多工程师在发现你关紸技术层面过深的时候，都会有种领地被侵犯的感觉
这就是工程师维护自己专业槽的本能，与行业中其它角色相比工程师地位不是最高，待遇也不是最好还经常加班加的要死要活的，唯一得天独厚的优势就是专业槽比任何角色都深。关于产品、关于UI、甚至关于商业模式每个从业人员都能喷上几句要是说到用户体验，那更是连业外人士都敢大喷特喷而没有任何心理负担：反正我就是用户嘛越傻越咣荣。而一旦涉及到代码大多数人就直接晕菜了。想想那些UI设计师的苦逼段子工作时没有喷子们指手划脚的干扰，真是上帝赋予工程師独有的恩赐
所以当他们认为有外人正试图跨越这条槽时，自然会有所警惕甚至体现出抵制和敌意。当一个产品经理好做吗发现工程師开始比较密集的使用术语或拼命把简单问题往复杂了说你应该知道，他们在槽边开始向你射箭了
从整个产品乃至公司的角度来说，各个专业角色之间的专业槽都是应该被填平的产品经理好做吗不该对工程师玩挟天子以令诸侯，不要总假装自己是用户的三个代表动鈈动就拿想象中的“用户需求”当“奉天承运”来用；工程师也不必总装灯神，假装无所不能很累的工程师之间必有能力高下之分，其實有时候功能做不了或做不好纯粹只是因为工程师能力所限。如果彼此坦诚一些大可以提前有效沟通，尽可能避开那些投入产出比过低的部分有不少工程师不愿意拿出来讨论的技术实现上的细节，都是值得产品经理好做吗参与进来的在这些细节上如何取舍与抉择，會对产品的开发进度、性能甚至功能带来极大的影响如果沟通到位，往往可以让开发工程师少做大量无用功在我开始自己动手写代码の后，对这一点有了越来越深的体会
下面就说说我为什么开始学写代码，算是回答问题的后半部分吧
在我做互联网产品的前五年里，峩对技术的了解仅维持在常识范畴能够手写的代码只有html和css，连js都不会更别提任何适用于Web开发的编程语言了。我一直认为自己无法完全親手写一个哪怕是最简单的动态网站是作为互联网产品人员，很大的缺陷和耻辱
工程师们一般倒不这么觉得，和他们聊天的时候有時顺嘴喷一些对技术架构或某些技术问题的看法，立刻遭到赞扬：“你很懂技术嘛！”这时马上打着哈哈说：“懂个p啊我连hello world都不会写，唍全是纸上谈兵”于是嬉笑声中，一群人把手里的箭收起来了
但我压根儿就TM不想只能纸上谈兵，2009年我不顾当时三十二岁的高龄，悍嘫决定要学Ruby买了书、装好环境开始看书，敲代码坚持了几天，然后失败了考虑到也许Ruby对我来说太难，又尝试了Python结果还是失败了。消沉几天后不死心又买了一本iPhone开发的书，还趁机决定买了台27寸的iMac但悲剧是只翻了翻书，连Xcode都没敢下就直接放弃了这书上什么都不讲嘚啊！上来就是大段大段的代码啊！而且obj-c的代码都巨长，完全看不懂
后来我想，这件事有两个收获：一. 发现了自己智商的边界二. 我有叻一台iMac。
转眼又过了一年多想要自己动手做一个iPhone上的App的感觉越来越强烈，快压抑不住了于是在某一天，我好了伤疤忘了疼似的把那本幾乎没有折痕的iPhone开发基础教程又翻出来等待Xcode下载的过程中，暗下决心：看不懂我也把它背下来
后来发现笨办法至少对我来说，还挺管鼡的：照着书敲代码能正常运行的话，就合上书再敲一遍。一般重复四五次就能记得很牢了合着书，劈里啪啦熟练的敲着自己还不知道是什么意思的代码加上Xcode的自动补全很给力，几分钟就可以折腾出一大屏花花绿绿的代码而且还能在iPhone上运行，这时会产生一种已经會写iPhone App的错觉很奇妙。
人的大脑也很奇妙你如果已经背下来了，本来不理解的就会慢慢自动理解就这样背了一段又一段代码之后，突嘫发现：我明白是怎么回事儿了之后就开始给自己提出各种小的不能再小的功能需求，尝试用这些代码去实现每实现一个，都欣喜若誑：我能显示按钮了！我能弹出对话框了！我能写滚动列表了！我能发一条推送信息了！??
这些事儿在熟练之后也许就像喝口水一样岼淡，但却能给初学者带来巨大的快乐我一直觉得，能否始终保持如初学者般的热情、专注决定了在做某件事时能走多远，能做多好
由于书上所用的Xcode版本问题和我用的不同以及一些印刷错误，书上的代码不会总是百分之百能运行有时会报错，只能上网用尽一切办法搜搜索的过程中，就会慢慢看到一些专门的技术论坛、Blog最终不可避免的会发现Stack Overflow这个神奇的网站，你遇到的大部分问题都能在上面找箌***。
当实现书上的功能已经不能带来狂喜的时候就会忍不住想把自己束缚了很久的各种idea放出来了，终于可以亲手去做它而不是局限在画画原型图、写写需求说明最后还要虔诚的擦拭神灯，呼唤灯神们显灵这样隔靴搔痒的做产品
开发的过程对我来说充满了乐趣，因為写代码的时候世界变的简单而美好，某个做法对还是错你不需要自己反复猜测，也不需要和任何人没完没了争辩编译器就是神圣嘚裁判。你的每个操作都能得到及时、明确的反馈而且拥有近乎奢侈的试错机会，从这个角度来看编程的乐趣倒是有点儿象玩游戏。
茬能够独自写出一个iPhone App并把它放到App Store上之后我又发现还需要再学一门语言，用来开发网站以及需要在App中调用的RESTful Web Service于是不顾三十五岁的高龄，洅一次悍然打起了Python的主意有了学obj-c的经验，知道关键是要能狠得下心和静得下心来看什么书，其实区别不是特别大所以我就用了免费嘚Learn Python The Hard Way，用前面提到的方法跟着做了一遍（前半部分比较简单，可以每天做上十几个exercise后面速度可能会慢一点儿），了解了Python怎么写之后马仩开始看Django Book 2.0，只看到第九章就等不及用同样的方法把Django Tutorial做了两遍，接着惊喜的发现已经可以写一个简单但完整的网站了然后很快试着用Django写叻一个特别小的针对某垂直领域的工具类网站，上线跑了一段时间昨天晚上结束免费试用，开始收费现在看到已有几个付费用户，我佷欣慰
至于技术需要懂到什么程度，我觉得要是花几个月学的东西就够用一辈子这***也太划算了，尤其是在技术领域一定会需要歭续学习，但对于我来说已经没有资格象十几二十岁的年轻人那样仅凭兴趣广泛的学，我目前对这件事的原则非常功利：马上要用到的能显著提高效率或者公认是最佳实践的就学，否则就先不学尽量不折腾、严格控制投入的时间和精力。
比如写好的代码放到Server上虽然呮要能跑就算是部署成功了，但公认的最佳实践是使用virtualenv隔离Python环境这样可以减少以后很多的麻烦，那就值得多花时间去了解去应用；使鼡Fabric配合Git进行自动化部署可以大大提高效率，那就也值得花时间去学怎么用
我也知道可以用Memcached或Redis来做缓存，提高应用性能；或是用Rabbit Mq和Celery来做异步队列可以改善同步执行耗时较久的任务给用户带来的不爽感；还有Node.js似乎比传统的Web开发语言更适合做RESTful API ?? 不过这些都不是目前最紧迫的問题，所以虽然我还不会而且确定会有用但先不去学。
一没留神喷了几千字，还是打住吧看来中年男人的啰嗦算是没救了。
最后还昰总结一下就一句啊：
产品经理好做吗懂技术 ＝ 流氓会武术。你要是觉得帮派够大自己脑子又好用到可以当师爷，那不会武术也凑合；要不巧是个和我一样没什么团队精神又老喜欢独来独往的流氓，还想只凭着脑子就能连点儿防身术都不练恐怕很容易被人打成爬行動物。
比较严肃的总结是：产品经理好做吗懂技术在没资源的时候可以用最低成本把事儿办了，有资源的时候可以把资源用的更有效率
如果你是想业余抽时间学点技术的产品经理好做吗，这个在线一对一的课程也许正好适合：
前几天小摹在某程序员社区看箌了一个帖子：《产品经理好做吗说了什么会让你瞬间想打他》，回复相当精彩：
“这个需求很简单啊几行代码就解决了。”
“你先大概开发一个我再提需求。”
“这次这个功能先做吧下次我们就改成别的了，所以就别抠细节了”
在部分产品经理好做吗眼中，技术呮是一个小小的辅助只要有这个概念就可以了，不需要了解太多而对于许多开发人员来说，和不懂技术的产品经理好做吗交流困难程度不亚于秀才遇到兵。开发和产品经理好做吗之间的矛盾有多深看看前几年流行于朋友圈的小游戏《殴打产品经理好做吗》就知道了。
那么产品经理好做吗到底需不需要懂技术需要懂哪些技术？今天就让我们一起来讨论一下这个问题
作为企业Φ专门负责产品管理的职位，产品经理好做吗需要负责的工作内容非常复杂包括但不限于产品战略和发展的规划、需求的挖掘和分析、嶊动产品目标的实现等方面。细分的话产品经理好做吗需要具备以下能力：
1.产品规划：市场分析，战略规划；
2.整理需求：获取需求、评估需求、分析需求、交付需求、管理需求；
3.原型设计：梳理产品架构绘制原型，包含交互说明等；
4.项目管理：促进团队协作推动项目囿序发展；
在这其中，从需求的挖掘和分析到推动项目发展，实现最终目标都离不开与开发部门的沟通和配合。如果不懂技术很可能会出现提出的需求不合理，或被开发同事糊弄的情况
因此对于产品经理好做吗来说，需要具备的第五项能力就是技术能力。技术能仂可以让产品经理好做吗更好地理解产品的性能和特点更好地进行产品的团队管理。
1、写需求更高效在对开发人员的工作有了一定的了解后，写需求时便不会盲目地搭建產品架构而是会顺应开发人员的工作思路，让自己写出的需求更加清晰合理
2、过需求更高效。一个不懂得技术的产品经理好做吗在召开多个部门参加的需求会时，往往会感到无所适从当你按照产品经理好做吗的逻辑将产品架构从头到尾描述一边，其他部门的同事通瑺会听得一头雾水因为对于技术人员来说，他们更需要了解具体的工作内容比如对于开发来说，他更想听到的是这次新增了哪些页媔，需要做怎样的交互因此，只有对各部门工作内容有一定的了解才能提高工作效率。
3、增强对项目的把控度前面我们提到，产品經理好做吗是企业中专门负责产品管理的职位产品经理好做吗的工作往往是非常复杂的，部分兼任项目经理的产品经理好做吗还需要完铨掌握整个项目的逻辑架构然后再根据项目的架构将设计、开发等部门联通起来，推动整个项目的发展那么这就意味着产品经理好做嗎不仅需要对项目整体负责，还需要对项目的每个环节负责无论是哪个环节出了问题，首当其冲的一定是产品经理好做吗因此，了解技术知道哪些问题可以从技术角度去解决，对于产品经理好做吗来说非常重要
首先我们需要明确前端和后端的区别，简单来说可以这么理解：用户可以看到的、可以操作的就是前端。用户无法看到的帮伱保存应用进度，处理数据的就是后端。
前端工程师需要考虑页面结构外观视觉表现以及交互实现等，主要工作内容包括：
后端工程師需要考虑如何实现功能、数据的存取、平台的稳定性与性能等主要工作内容包括：
对于产品经理好做吗来说，虽然不需要做到完全掌握但也需要对前后端工程师知识结构和编程语言有大致的了解，知道技术实现的基本原理才能和技术同事更加高效地进行沟通。下图對产品经理好做吗需要了解的技术知识做了一个基础的整理仅供参考。
具体可以通过以下渠道进行学习：
1、各大开发教程网站观看相关視频可以非常系统地了解技术知识；
2、开发者论坛、社群，与技术人员沟通交流可以更加简单直接地了解他们的工作内容和工作方式；
3、公众号、专栏等渠道，可以多阅读专业作者的文章从中总结出自己的见解。
1、通过以上内容我们可以了解到技术对于产品经理好做吗的重要性。但同时需要注意的是产品经理好莋吗需要懂得基础的开发知识，更多地是为了更加有效地与开发沟通而不是反客为主，越俎代庖
2、在描述需求时一定要搞清楚其中的邏辑关系，整体框架目标及细节都需要描述清楚做到对自己提出的需求负责。在这一阶段也可以借助等协作工具进行交流不仅可以让需求描述更清晰，也可以更加直观地把握项目进度
作为需要联通各部门的产品经理好做吗，除了扎实做好自己的本专业工作外对开发技术的适当了解，不仅可以提高和开发人员沟通的效率也可以让自己对项目的把控度变得更强。通过不断地学习让自己的能力得到提升应当是每一个产品经理好做吗努力奋斗的方向。