34 天前 / mr7
点击蓝字关注我们 本文合并了另一篇 Spotify 有意思的博文：Rethinking Spotify Search 这一切是怎么开始的？一切就好像洗冷水澡一样 故事从 5 年前开始，那时候的 Spotify 有了一个问题：增长速度太快。 对于大部分人来说，这是一个特别好的"困扰"。但增长速度太快并没有让我们的团队增长也增快，雇佣更多的人让我们的团队效率变得低下。 我们的工程部门主管 Pia Nilsson 有一个指标是专门用来评估团队效率的：看一个工程师需要花多久来完成十次的 pull request。 当时的指标很糟糕，我们的测试结果是：60 天。
74 天前 / 凯凯刘
这次介绍的人物是 Nick Fogle，一个 Indie Maker，做的产品是 Wavve，产品其实有点小众，是一个将音频转为有动态效果，并能在社交媒体上可以分享的工具。 Nick 有一天在 twitter 上发布了一条消息，说卖掉了自己的产品 WAVVE，实现了自己的”财务自由”，图片左边的是 Nick 和他的合伙人一起举着啤酒，背后是电脑屏幕的转账记录。他还分享了自己的这段经历，在收到第一个报价后，并没有急于出售产品，而是冷静的分析；在遇到新冠疫情的影响下，更加的专注，逆势增长；解决用户流失问题等等，有很多地方是值得我们学习。下面是文章主要内容。
144 天前 / ThoughtWorks
有了产品负责人，还需要业务分析师吗？2021 年 2 月 26 日 by 亢江妹 1 CommentPO（Product Owner，产品负责人，以下简称 PO）作为敏捷转型的实践之一，当前已被业界广为接纳。根据年度敏捷状态报告，大约有一半以上实施敏捷的组织设置了 PO，这与当前我们在国内敏捷咨询中感受到的比例相同。 我们已经很少会被问到“需不需要 PO”的问题，但却经常被问到“有了 PO，我们还需要设置 BA（Business Analyst，业务分析师，以下简称 BA）吗？如果需要设置 BA，那么 PO 和 BA 之间该如何合作呢？” 回想我第一次对这个问题的答复，与今天的答复也不尽相同...
183 天前 / 凯凯刘
这张图很流行，在很多地方都能看到。很多人也是看完之后会心一笑，但却很少人真的能遵循这样的 MVP 原则来开发自己的产品。下面我们就来解释下图片背后到底是在说什么？ 第一种示例：错误的方式 第一排的图片是错误的方式开发产品 很多的项目的失败是因为直到产品 100% 完成之后才发布。然而，人们普遍会产生疑问 - 谁会花钱买个半成品？ “先生，这是我们的第一个版本的产品，一个轮子，你觉得怎么样？” 用户肯定会说“你为什么给我的是一个车轮子？我要的是一辆汽车！你让我那个车轮子当独轮车吗？” 当每次的产品接近完成的时候...
203 天前 / WriteOnRead
1. 前言以前在不足百人的小公司待过，产品需求的研发并没有什么正规的流程，通常是产品提了需求之后，技术部门简单评审一下就开始写代码，本地和测试环境没问题就直接发布线上了。 后来去了某二线互联网公司，大概几千人。虽然跟一线大厂还差很多，但需求的研发流程跟大厂大同小异。 前段时间运营小姐姐找我了解一些开发相关的内容，就跟她讲到了我们的开发流程。这里简单做个小结。 2. 整体概述一个相对完整的需求研发流程大致如下图所示： PS: 该流程仅供参考，不同公司可能会有所不同，但主流程大体相似。 下面简要介绍各个环节的主要内容。
259 天前 / 凯凯刘
《The 7 Day Startup》是 Dan Norris 写的一本关于从 0 到 1 构建盈利产品的书，亚马逊评分 4.5。 Dan Norris 自己一度想放弃开发产品变现，因为没有收入，都快养活不了自己。尝试了很多的项目，踩过了很多的坑，但是，改变却从一个决定开始的，就是决定 7 天内做出一个产品，如果不成功，自己就老实的去大城市打工。幸运的是，Dan 因为这次的改变，也改变了自己后面的人生道路。他把自己这些的成功和失败的经验总结成书，下面就详细了解下 Dan 是如何 7 天逆袭的呢？ 7 天的成功逆袭 2000 年的时候，Dan 刚毕业，20 岁，被一本 HR 方面的书所吸引...
283 天前 / 凤凰牌老熊
一、简介 亚马逊的强大能力大家都有目共睹，除了构建了一个庞大的全球电商帝国，亚马逊还打造出很多顶尖的产品，如 AWS、电子阅读器 Kindle、智能音箱 Echo 等。这些创新产品都让人耳目一新，成为各自市场的领导者。那 Amazon 是用什么方法来取得产品上的成功呢？这不得不提到亚马逊基于逆向思维的秘密武器——“逆向工作法（Working backwards）”。 在 2008 年贝索斯致股东的信中，提到了逆向工作法，原文如下： 在此全球经济动荡之际，我们所秉持的基本做法依然未有改变。谦虚谨慎，关注长远价值，顾客至上。
330 天前 / 九卷
什么是奇点物理学认为宇宙从无到有始于一个点，这个点叫做“奇点”，它积聚了形成现有宇宙中所有物质的势能，当这一个点的能量平衡被破坏后，宇宙大爆炸发生，从而生成我们现在的宇宙。如果把宇宙比作我们的产品，奇点就是这个产品赖以出现与存在的关键点。 产品创新与奇点理论一个问题奇点是这个产品赖以出现与存在的关键点，那么第一个需要回答的问题是：“你的产品的奇点是什么？”。一个企业就是一个产品，那么使命就是这个企业的第一原理点，价值观就是这个企业的奇点，是这个企业赖以存在的关键点。
330 天前 / 凯凯刘
找到了用户需求痛点，花了几个星期或者几个月开发了产品，这时候最需要的是什么？ 是一个产品展示的落地页。 不管是售卖在线服务、数字产品、电子书、还是在线课程，都需要一个产品的展示页来向用户展示你提供的服务，用户通过这个页面来达成购买。你需要设计、配色、文案、编码等才能完成一个优秀的页面，要花费不少的时间。 为了提高效率，很快的完成一个漂亮的落地页。整理了 30 个免费的落地页模板提供给大家，这些模板： 可以在线预览开源的可免费下载适合数字服务、电子书、在线课程适合订阅服务适合 Sass 产品适合移动端 App 这些模板是 100% 完全免...
337 天前 / 跨界架构师
这里是 Z 哥的个人公众号 每周五 11：45 按时送达 当然了，也会时不时加个餐～ 我的第「156」篇原创敬上 这篇是之前发过的《懂程序员的产品经理是什么样子？》的镜像篇，这次是程序员视角。 两个相爱相杀的岗位，想要更好的达成共识、更好的合作，自然不仅仅是一方的事情。这次 Z 哥先会带你看看产品经理眼中的程序员是什么样子。然后给出一些我的建议。 直接进入正题吧。 从产品视角是怎么看程序员的呢？我根据我自己的经历以及与其他产品经理的交流下来看，吐槽的主要是以下几点： 这个功能实现不了。
339 天前 / 影浅
最近开始也陆续接了一些项目在做，聊一下项目管理相关的事情吧。从业也有 13 年了，也陆陆续续接触过不一样的项目管理，基本上来说的一点，没有任何一个项目管理方式可以解决所有问题，还是要根据团队本身做不同程度的调整。 说起软件项目，大致的流程就类似下面这张图 在软件项目实施的过程中，我们总是能碰到这几种人 产品经理 对于互联网公司来说，产品经理是一个非常重要的角色，一个好的产品经理可以做出不断让用户喜爱的产品，一个差的产品经理可能就会让团队陷入各种需求返工和大量的资源浪费。 但产品经理的入门门槛低，但做好却异常的困难。
342 天前 / 凯凯刘
做产品的过程中，都会遇到一个颜色选择、搭配的问题。如何选择一个配色，能让产品整体的效果更漂亮？很多人都无从下手，尤其像天天敲代码的我们，每天最舒服的配色就是编辑器里的“黑”、“白”。其实，有很多非常实用的工具就在我们身边。下面就给大家整理了市面上 10 个最好用的在线配色站，都是免费的，需要的时候直接使用就好了。 1、Gradienta 网址： https://gradienta.io/ 比较特别的展示方式，选定颜色组合后可以实时在线预览看到效果，有当下比较流行的颜色组合推荐，可下载效果图片和复制 CSS。
344 天前 / 杨琼璞
自 2017 年开始，就有想塑造些优质个人产品；目前仍继续在维护的倾城之链，就是对这一夙愿的实践和坚持；在「倾城」的设计和运营中，接触了蛮多工具型产品，颇受启发的同时，也起到了很大帮助；此篇文章，旨在跟朋友们分享下那些神器、以及对工具 vs 产品、知识 vs 思维相关思考。 超棒的样机生成器 Choose from ready-made templates to generate mockups, screenshots and video previews and for your app. All screenshots are ready for App Store and Google Play 推荐语：Previewed.app：一个非常漂亮的样机生成器网站；它上不仅能够快速生成 App S...
380 天前 / 梁桂钊
在开始正文之前，我们先来说一下 Linux 的系统权限设计。在 Linux 系统中，为了保证文件的安全，对文件所有者、同组用户、其他用户的访问权限进行了分别管理。其中，文件所有者，即建立文件或目录的用户。同组用户，是所属组群中的所有用户。其他用户，指的是既不是文件所有者，也不是同组用户的其他用户。每个文件和目录都具有读取权限、写入权限和执行权限，这三个权限之间相互独立。 在 Linux 系统中，每个文件的访问权限可以用 9 个字母表示，每 3 个字母表示一类用户权限，分别代表文件创建者、同组用户、其他用户。
380 天前 / 九卷
阿里妹导读：在考虑如何对业务模型进行抽象从而建立领域模型之前，必须解决业务与产品、开发之间“沟通”的问题。如何让业务人员和开发人员顺畅沟通，在业务流程设计中不遗漏成败攸关的业务场景？如何才能让业务沟通的过程顺畅过渡到架构设计、编码乃至测试？阿里巴巴技术专家李建结合团队的实际案例，分享了他们在使用 Event Storming（事件风暴） 进行领域建模时的经验、收获和思考。 一 软件研发的困境 “失效”的语言交流 日常研发过程中不同角色经常需要进行各种交流：沟通业务需求、讨论产品原型、讨论设计方案等。