大家好，我是 哈士奇 ，一位工作了十年的"技术混子"， 致力于为开发者赋能的UP主, 目前正在运营着 TFS_CLUB社区。
💬 人生格言：优于别人,并不高贵,真正的高贵应该是优于过去的自己。💬 📫 如果文章知识点有错误的地方，请指正！和大家一起学习，一起进步👀 🔥 如果感觉博主的文章还不错的话，还请 👍 关注、点赞、收藏三连支持 👍 一下博主哦 🏆 CSDN博客专家认证、新星计划第三季全栈赛道MVP 、华为云享专家、阿里云专家博主 🏆
专栏系列（点击解锁） 学习路线（点击解锁） 知识定位 🔥Python全栈白皮书🔥 零基础入门篇 以浅显易懂的方式轻松入门，让你彻底爱上Python的魅力。 语法进阶篇 主要围绕多线程编程、正则表达式学习、含贴近实战的项目练习 。 自动化办公篇 实现日常办公软件的自动化操作，节省时间、提高办公效率。 自动化测试实战篇 从实战的角度出发，先人一步，快速转型测试开发工程师。 数据库开发实战篇 掌握关系型与非关系数据库知识，提升数据库实战开发能力。 爬虫入门与实战 更新中 数据分析篇 更新中 前端入门+flask 全栈篇 更新中 django+vue全栈篇 更新中 拓展-人工智能入门 更新中 🔥全域运营实战白宝书🔥 运营角色认知篇 初识运营，明晰运营的学习路径 高转化文案速成篇 三种文案形式，抓住特点才能下笔如有神。 策划活动与执行篇 更新中 新媒体运营篇 更新中 社区运营篇 更新中 私域社群运营篇 更新中 运营数据分析篇 更新中 低成本渠道推广篇 更新中 网络安全之路 踩坑篇 记录学习及演练过程中遇到的坑，便于后来居上者 网安知识扫盲篇 三天打鱼，不深入了解原理，只会让你成为脚本小子。 vulhub靶场漏洞复现 让漏洞复现变得简单，让安全研究者更加专注于漏洞原理本身。 shell编程篇 不涉及linux基础，最终案例会偏向于安全加固方向。 [待完结] WEB漏洞攻防篇 2021年9月3日停止更新，转战先知社区等安全社区及小密圈 渗透工具使用集锦 2021年9月3日停止更新，转战先知社区等安全社区及小密圈 点点点工程师 测试神器 - Charles 软件测试数据包抓包分析神器 测试神器 - Fiddler 一文学会 fiddle ，学不会倒立吃翔，稀得！ 测试神器 - Jmeter 不仅是性能测试神器，更可用于搭建轻量级接口自动化测试框架。 RobotFrameWork Python实现的自动化测试利器，该篇章仅介绍UI自动化部分。 Java实现UI自动化 文档写于2016年，Java实现的UI自动化，仍有借鉴意义。 MonkeyRunner 该工具目前的应用场景已不多，文档已删，为了排版好看才留着。
文章目录
- ❤️🔥 产品思维 VS 技术思维
- ❣️ 看待 "问题" 的角度不同
- ❣️ 看待 "产品" 的角度不同
- ❣️ 看待 "价值" 的角度不同
- ❣️ 看待 "体验" 的角度不同
- ❤️🔥 产品思维 与 技术思维 并不是 "非黑即白"
为了各位技术小伙伴能够更好的理解产品思维，接下针对 “产品思维” 和大家所熟悉的 “技术思维” 做一个对比。所以，今天这个章节，我们将花费少量的篇幅，专门介绍一下 “产品思维” 与 “技术思维” 的共通性，同时也了解一下二者的区别。
❤️🔥 产品思维 VS 技术思维
这里先说一个题外话，在大概三个月之前计划写该专栏的时候，曾经做过一次小调研，目的就是想知道大家对于 “产品思维” 是否具备一定接受度。
从结果来看，有相当一部分技术小伙伴是非常认可 “产品思维” 的；当然了，也依然有部分小伙伴认为 “技术才是王道” 。
直到现在，我依然坚持当初的观点：无论是 "产品思维" 还是 "技术思维" 都只是立场与角度的不同，二者甚至有一些共通性。那就是这两种思维最终都需要去 "关注逻辑"、"关注目标"、"注重持续" 的把问题解决的更快更好 。
当然了，除了这些共通性之外，还存在这如下这些不通的地方。
❣️ 看待 “问题” 的角度不同
相比之下，“产品思维” 更关注一个问题发生的原因，“技术思维” 则更热衷思考问题背后的解决方案。
这两点的区别主要来源于产品经理可能更多思考的是事情发生的背后，到底用户遇到的痛点是什么？基于如此的原因，去提出更好的解决方案是产品经理所期望的。至于最终的解决思路，可以是 “A” 也可以是 “B” 。其实对于产品经理而言，是否是 "A" 或者 "B"，他们并不关心...
而技术小伙伴则不然，技术小伙伴的确定性要求是非常高的。在这种情况下，往往是需要 “产品经理” 来确定一个技术的解决方案，那些模棱两可的描述是绝对不行的。
这就是两者在 "看待问题的角度" 层面上的区别。
❣️ 看待 “产品” 的角度不同
- 产品经理在设计产品的时候，会更多的关注产品使用者的都会有什么困境，从人的角度出发去思考问题的解决方案。
- 而相对的，技术小伙伴的 “技术思维” 怎会更侧重具体的问题和被解决问题的本身，问题解决完成之后是什么人用？如何用？这是技术小伙伴不怎么关心的，只要这个问题能够完美解决就足够了。
❣️ 看待 “价值” 的角度不同
对于 “产品经理” 来说，完成一件事情会带来一定的价值，对于这种价值会看重一些，尤其是未来所带来的价值；
“技术小伙伴” 则不然， “技术思维” 呢则会更加的脚踏实地一些。关注当下、关注实现成本，而不会关心太远的事情。
❣️ 看待 “体验” 的角度不同
擅长运用 “产品思维” 的人肯定会关注 "体验"，即 "体验为王"， 他们期望能够为用户提供更好的服务并为此而努力着。在此基础之上，拥有 “产品思维” 的人很容易就会提出一些 "超前的想法"；
而 “技术思维” 则会更加的关注一件事情完成的质量，尽量的为完成一件事情、解决一个问题更稳、更顺，不出什么问题。同时这也更加的务实一些…
❤️🔥 产品思维 与 技术思维 并不是 “非黑即白”
说了上面这么多的不同，其实这两种思维没有对错。 这也对应了上一章节我们所提到的 “产品思维” 里的 “不是非黑即白，而是中间有灰度的这种辩证思维方式了”。
如果是犯了上一章节我们提到的 "不是产品思维" 的集中极端认知问题，就很容易引起 “产品经理” 与 “技术小伙伴” 之间的矛盾。
“产品经理” 与 “技术小伙伴” 之间真的是水火不相容的么？其实不是这样的，无论是 “产品思维” 还是 “技术思维”，都只是立场与角度的不同，甚至总结下来 二者甚至有一些共性 ，就像文章开头提到的那样 这两种思维最终都需要去 "关注逻辑"、"关注目标"、"注重持续" 的把问题解决的更快更好 。
也是基于此，想借这一章节的近千字尽可能的想各位技术小伙伴传达一个观点，我们要尽可能的发挥我们的 “技术思维” 的优势，然后结合 “产品思维” 的特点与效果，从而达到我们成长的 "最优解" 。
