1关于滴滴里针对老人打车的模块想了解下，对于司机接单老人打车滴滴公司是否有相应的补偿，在三线城市怎么避免司机接到老人打车拒单的情况，我们打车有时候还会因为派单远或者司机不想接就打电话过来说需要多久多久（意思就是您取消吧）老人打车是不能拒单还是怎么解决的？老人这块的用户量怎么样？年龄范围多少可以打老人线
2我作为产品小白来讲，平时会忽略商业这块，怎么进行商业需求分析，或者商业思维的锻炼 看到好多人提到跳单的问题，说一下自己的理解（以顺风车为例） 说明自己的观点：现有的产品架构和流程是没法避免的，堵不住、疏也很难。原因：这是个零和游戏，没有损失，平台就没有收益。 所以，面对这种情况，我们作为产品层面能做的很有限，但也不是不作为，说下我的想法： 我们可以把需求分组，对于一些固定时间、地点的顺风车，例如：上下班等，基本可以放弃，因为无法避免用户去跳单。但是对于一些临时的拼车需求，可以避免的。方法：需求端用户先付费，再向供给端用户发需求进行派车。 当然了，可以提供一些附加服务，例如：安全性需求、拼友选择优化（这个第一次管用，后面也有可能失效） 还有就是对顺风车的商业模式进行调整，既然提成不行，那就可以对司机端进行一些服务，比如：修车、保险等等而非现在的抽成，等等。 另外，我觉得和可以利用目前的拼车站点和物流结合一下，用户带着快件去拼车，放到目的地，然后减点车费，想法待验证。 
主要有两个问题哈：
1.一款非社区的产品，如果想要做社交化的功能，需要考虑到哪些点，有什么样的产品方法论或者经典案例可以借鉴？另外，社交对于互金产品来说，又能有什么好的突破点？ 
我是经常做顺风车的说一下我的感受 1、顺风车司机经常要求走私单，脱离平台，不然有时候会拒绝承载。 2、司机协调好车上只有3个人，最后做了四个人，如何处理？ 3、车主与乘客时间匹配规则有冲突，车主接单了，临近出发车主变卦如何处理？ 4、定位谈好接送地点，出发前告诉你要到哪里我去接你，你那去不了。如何处理？ 5、节假日顺风车出行车主在半路等12点的免费告诉好几个小时影响我们的出行时间如何处理？ 6、我做过的车并且五星好评，下次匹配的时候会不会优先推荐？ 做顺风车遇见很多问题，作为乘客非常的被动，即使投诉也没有解决方案 作为节假日必回家的我现在只能找以前做过不错的司机提前私下预定，实在没有车了才会考虑滴滴，难道我不是滴滴的目标用户? 
只坐过一次城际顺风车，勉强算是可以大力发展的用户，顺风车去掉了 用户从家到汽车站，再从汽车站到目的地的麻烦，但拼车的成功率不太高，时间是拼车成功最大的阻碍条件，另外选择顺风车的人和最终上车的人有可能不是同一人，这对同行的人来说，其实会传递不安全感。
另外， 同城顺风车， 我坐过十来次，后来放弃了。原因也是，拼成率不高，接单的师傅少。时间一般是早高峰，很多人各自忙着上班，完全顺路的情况其实不多，这一块上，建议优化解决方案，比如，给开顺风车较多的师傅一些星级，让他们更容易拼成。另外，顺风车和快车存在一定的互补也存在一定的竞争，建议强化互补，减少竞争。 
滴滴顺风车的典型用户之一，想用更低价的价格换取更好的乘车服务，但是目前滴滴顺风车的接单率与接单速度很低，个人体验顺风车多次，主要出现的问题有两个，一是主城区车主车源太少，或者说匹配的太少，其二是即使很多匹配率（85~95%）高的也不愿意接单；目前增加感谢费是一个手段，对于车主来说回报增加了，对于乘客来说也比快车划算，除了上述说到的方式，请问对于这个问题还有其他规划吗？ 
看到题目的一瞬间就让我想到汽车大王亨利福特的名言：“如果我当年去问用户他们想要什么，他们肯定会告诉我：一匹更快的马。显然，如题所说的忘掉产品就像亨利福特当时并没有真的去埋头想办法去找一匹更快的马来满足浅层眼前的需求，而是选择忘掉用户口中所说的马（产品），专注到用户心理深层的需求，所以才会有了下面的一段对话：
福特：“你为什么需要一匹更快的马？” 用户：“因为可以跑得更快！” 福特：“你为什么需要跑得更快？” 用户：“因为这样我就可以更早的到达目的地。” 所以用户需要一匹更快的马真正的用意是“用更快的方式、更短的时间到达目的地！”然后福特就用创新发明的汽车满足了用户的真实需求。 到这我们也不禁的会想是什么促使福特当时会发起上面的一连串提问呢？ 是不是有时候用户也不知道自己到底想要什么，或是被某种思维或环境局限住了呢，这种跳出常规思维、用户洞察力需要如何去提升，该如何通过用户浅层的需求中挖掘的出深层真实的需求？ 
其实我也是顺风车（司机端）的忠实用户，我有个比较头疼问题就是。 1 想要自动抢单，可是每次的匹配都不太让人满意，只能总是盯着屏幕，人工挑选，及其不方便。我觉得匹配的要素里，最好可以加入路况的因素，或者最好给司机一个地理范围划分，你觉得这不是更合理吗？ 2. 关于顺风车的联系用户功能，有时候跟一个顺路的用户，其实时间有一点点出入，可是要接单才能跟用户沟通，沟通不成功还要取消订单。又或者，去比较远的地方，想沟通能不能改一下下车地方，也不好操作，都是要添加用户才能沟通，我清楚知道，也许这样是为了用户造成不必要的骚扰，但也造成很多重要的功能不好展开。觉得这是不示很合理的。我觉得是应该加入一些常用的沟通选项，或者人工智能审查对话内容，而是直接废除接单前沟通这一环节。 
我是做公交调度的产品经理，工作设计产品过程中，更多的是偏向于业务方面，解决公交调度实际的运营过程中一些问题，比如车辆行驶在站点的定位，视频监控和公里数等一些报表的数据生成。这篇文章写到了不同软件行业的产品的差异性以及偏向点的不同，但共性是通过角色，场景的一种思维方式来解决用户使用软件的问题，其实后端产品也需要注重用户体验，但因为数据量比较大，所以优先考虑系统的流畅性和时效性，无论是前端还是后端，都有很多相通的地方，还是觉得得多学习，多了解各行业软件的产品，根据实际工作场景来运用。
滴滴顺风车之前自己上班的时候还经常使用，身边也有部分同事在使用，在用的过程中，我观察到一个现象。
针对于上下班这种场景，由于用户和车主上下班的时间和地点都比较固定，所以当找到最佳搭档后（即用户和车主都觉得对方不错，愿意经常乘坐或搭乘对方的车辆），就会选择绕过平台方，直接通过微信来联系，从而绕过平台方的抽成。 所以理论上在上下班这个场景中，有一部分车主和用户，最终会找到最佳搭档，绕过平台方，不知道对于这个问题，滴滴是怎么看待的。 
“不要过于局限于书中或者是网上、甚至是团队本身对产品经理的定义和局限，而是应该根据自己所处的行业特点，把重心放在解决用户真正地问题上。
比如说，如果你是一个做社交产品的经理，那么你会把怎么洞察用户在社交上的心理，怎么驱使用户跟别人发生交流作为最重要的部分。如果你是工具型的产品，比如说是微信的产品经理或者是邮箱的产品经理，你最重要的技能就变成了他要思考工具如何做的更好。如果你是做客户系统的产品经理，你也许会做打通信息流，把客户的信息、用户的信息、业务的信息怎么整合到一套信息流里面的工作。” 
用户画像基本是一切产品出发的源点和支点，了解用户才能有针对性的设计产品，然而相对于C端的个体即用户，B端存在使用对象分散的问题，传统的人口学属性、使用场景等用户画像建模方法无法满足对B端的业务处理，针对此问题我们采取过两种方案：
1.采集企业交易属性作为建模维度：企业规模、交易量、产品构成……但此种建模方法无法深入到B端产品的实际操作场景 2.采集具体业务人员的属性作为建模维度：人口学属性、操作场景……但此种方法无法关联企业属性，只能针对操作个体开展功能，个体间的联系被切断
我们做的是音乐线上教育类的产品，目前可能要做一个大的核心功能的改版，由于方向是十分明确，用户访谈与调研都已经结束，因此我们已经制定了一个产品的方案，而且这次的改版和相较于原本的核心功能提升非常的打大。但是牵扯的方面特别多，所以又想要在MVP的模式下进行一定程度的迭代，但是做mvp的情况可能无法满足实际效果，或者是用户的期待，可一旦将整个产品大改研发周期有较长，进度控制比较困难。所以想要了解如果说滴滴在遇到这种问题的情况下是否还会选择mvp的模式，或者
跟不少司机聊过跳单问题。往往出现在 1.地点上：长途，顺风车是重灾区。一单被抽成太多。 2.时间上：晚上加价之后，也是觉得平台抽成太多。 现在滴滴的策略是抑制司机各种跳单行为，但无论规则多缜密，多复杂，惩罚多严厉，也没法从根本上解决这个问题。 因为司机和乘客总要见面，只要见面就总有漏洞可钻。 那其实防止跳单问题是一个预期利益和服务满意度之间博弈学问题，而不是表面上的规则多严密的问题，必须要从感化司机服务司机的角度考虑。 不知道滴滴从这个方面出发做过哪些产品上的努力？ 比如： 1.降低远距离抽成比例，技术上形成动态抽成，合理的动态抽成可通过降低跳单率来提高总收益。 2.给司机本身提供其他行程中的附加服务，让他觉得这个服务是值这个抽成价的。比如fm？比如车队组建？ 堵不如疏。 当然我能想到的其他经验丰富的pm也能想到，只是好奇从这个角度出发做了哪些... |
|
|
来自： 产品经理是条狗 > 《PMCAFF优质问答》
