此前我写过一篇《如何洞悉隐性需求》，算是从开发的角度提示一些可能会被产品同学漏掉的需求细节，在需求沟通方面，可以作为本篇的补充。
一、技术思维之可行性
策划产品的初期，原则上是不应该受可行性的干扰，先想到好点子，剩下的交给技术解决。
但是，到了具体的产品需求文档形成之前，可行性就成为最后一道门槛了。是时候找开发哥聊聊，到底能不能做了！这时候，产品同学最怕的就是开发哥甩过来一句：实现不了……
那么到底能做还是不能做，是不是就只有开发说了算呢？当然不是！至少还有老板~
然而，作为一个小产品，总把老板搬出来也不是个事儿。况且，不是每个需求都有老板关注和授权，狐假虎威肯定是要出事情的。
那么，在日常无穷无尽的小需求中，如何防止被开发『忽悠』就是最核心的技能了。如果不想被『忽悠』，首先自己要做足功课。自己负责的产品、相关的平台已有功能、基础能力等，都要了如指掌，否则如果对于自己的产品细节都不够了解，怎么去提新需求？
思维提示
新开发的系统，尽量熟悉平台已有的基础能力，再来看新特性；使用外部开放平台的，一般都有现成的文档，虽然未必全懂，但至少大概知道平台能力；别人家已经做好的效果，总不能说实现不了吧？如有差异，至少要给我讲清楚；关注不同端的巨大差异，很多实现不了的，其实是终端差异的局限；理解从芯片、硬件厂商、操作系统不同、手机厂商不同、机型不同、浏览器不同、语言不同等造成的种种差异。
二、技术思维之角色分工
评审需求的时候，很多产品最头疼的，可能就是区分『前端需求』还是『后端需求』了。前端开发和后台开发有什么区别？到底哪里是前哪里是后？这些改动到底要拉前端还是拉后台？
这里首先我们要明确一下『前』和『后』是相对于什么的：
假设用户打开浏览器，看到了一个网页，那么用户第一眼看到的这些，就是所谓的『前端』——即与用户面对面的前。
再说说『后』，这个『后』就是背后你看不到的一切的一切，可以远到地球另一侧的某台服务器上运行的代码，也可以是隐藏在你桌上电脑中的逻辑。
至于中间的地带，就有点暧昧了。不同的公司对于前后端的定义不尽相同，对于所谓『前后端分离』架构的产品，那么至少页面层级一定是前端的工作了。而对于某些『服务端渲染』架构的产品，即使是页面，也可能是后台同学的锅。
因此，对于自己负责的产品，要先弄清楚基本的架构，才好确定一个大概的界限。目前在互联网行业，整体的趋势都是趋于『全栈』——即前端也能做后台，后台也能搞前端，那么区分角色分工，就难上加难了。
思维提示
熟悉自己负责的产品的基础架构；页面结构及样式相关，往往需要前端参与，最好拉上前端；页面无法访问，或者直接输出错误信息，往往要拉上后端或运维同学；实在分不清，只能一起约了。
三、技术思维之极限情况
产品思维，需要考虑产品的形态、受众群体、交互流程等等，这些已经很伤脑筋了。
可是到了开发这里，却总是各种钻牛角尖，什么小破输入框输入 1000 个字怎么办？什么同时 10000 个人访问怎么办？什么 500 个账号薅羊毛怎么办？
严格意义上来说，这些确实不是产品人员需要考虑的，到了『测试用例评审』这一步，自然会有专业的测试人员提出这些问题。但是，假如这些类似的问题你之前都没有思考过，那么也可能被测试人员怼得很惨。
要想表现为专业的产品经理，需要你对研发流程的各个环节都成竹在胸，不至于一问三不知，或者一看就根本没有深入思考过。
这些极限情况也可以称之为『异常流』，有些异常流可能用户感知不明显，而有些异常流则会对用户造成很大的影响。因此，当出现这些异常的时候，如何给用户更好的提示和引导，或者引领用户去找客服寻求帮助等，就显得尤为重要了。
