惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

M
MIT News - Artificial intelligence
雷峰网
雷峰网
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Last Week in AI
Last Week in AI
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
阮一峰的网络日志
阮一峰的网络日志
月光博客
月光博客
博客园 - Franky
腾讯CDC
T
Tailwind CSS Blog
Recent Announcements
Recent Announcements
V
V2EX
N
Netflix TechBlog - Medium
量子位
Jina AI
Jina AI
Y
Y Combinator Blog
The GitHub Blog
The GitHub Blog
G
Google Developers Blog
爱范儿
爱范儿
博客园 - 叶小钗
D
Docker
MongoDB | Blog
MongoDB | Blog
D
DataBreaches.Net
T
The Blog of Author Tim Ferriss

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
国际物流项目的启发与思考
Leam · 2024-09-06 · via 人人都是产品经理

在设计英国仓清关转运项目的过程中,作者深刻体会到了亲身体验和理解业务流程的重要性。通过实际操作和调研,作者不仅解决了业务问题,还收获了乐趣和成长。这个过程体现了产品经理在面对问题时的判断力和创新能力,也展示了团队氛围对个人行为的影响。

设计产品方案,是一个非常有趣的过程,要完美地设计出某个东西,你就必须先熟悉它,真正了解它,这需要投入很大时间和精力,需要反复咀嚼回味,而不只是囫囵吞枣,一旦缺少投入的体验,设计的过程便会少很多乐趣。

而这一点,近期在设计英国仓清关转运项目的时候,感触颇深。

01

国际物流中,卡车转运是很常见的运输模式,很多电商公司通常会把买家的碎片化订单,通过海运/空运的方式,把货物整合运输到目的国港口,完成清关缴税后,再通过卡车或尾程快递的,发往目的地。

这样的过程链路很长,涉及的角色众多,派送给消费者的路上也有很多不确定性,所以能做到所有链路都把控的公司很少,大多都会选择与承运商合作,各自完成自己擅长的事情。如卡车公司,海外仓,尾程快递/邮局(如皇家邮政)等,组合一起来完成派送,这样最高效。

(英国机场)

如上述英国四个机场中,我们的仓库在希思罗机场(Heathrow)附近(伦敦左侧),因为航司不同,货物散落在不同的港口,为了把货都提到仓库,就需要统计不同港口的货量,预估需要的卡车数量和车型,并根据预计到岗时间和卡车路途时间,提前预约卡车,分配卡车让他们按时间提货,并在这个过程中做到成本、时效最优。

简单来说,就是既要便宜还要快,比如货物到了Heathrow港口后,能上午拉回来就不会拖到晚上,能一趟车拉回来,就不会定两台车。毕竟英国一辆普通小卡车跑一趟的费用高达 200 英镑。而产品经理的职责之一,就是搭建系统,帮助业务角色高效完成这些动作,并且协同仓库和卡车供应商,做好数据交互以及费用结算。

以往做类似的方案时,第一件事情是找到关键人员调研:找清关经理和调度人员了解业务流程,梳理他们的卡点,明确方案目的等。但近期在做这个方案的时候,即便做好了上述三个环节,方案依然会被业务吐槽:太想当然了~

02

有一次开会展示方案,我说达曼彻斯特(英国北部机场)距离仓库 330 英里,如果明天 16:00要提货,系统可提前创建提货任务,通知业务人员,今天要预订卡车去机场提货。

但业务质疑我说,因为路途堵车或者提货点拥堵的情况,曼彻斯特机场的货,一旦超过 12 点到港,当天就不能够在仓库关门前,把货提回来,得安排后天大清早的卡车,而且,这还是港口不拥堵的情况的保守估计。

我没有去过英国,没有亲身实际的感受当地运输货物的情况,容易把流程都当做是理所应当地发生,所以被吐槽之后的第一感受是,借此机会跟着业务走一遍流程。

于是静下心来,在谷歌地图上把英国港口都标记了下来,看看他们的位置,并在不同时间段,看看仓库到港口之间的卡车耗时(谷歌地图会显示拥堵情况),并根据业务提供的货量用表格统计卡车数量,按照实际操作的步骤分配车辆,线下发邮件预约卡车,并跟进从预约到提货到仓的时间。

(实操一遍)

有了这样的过程,脑海中开始对卡车路径有了点轮廓,而且还收获了很多的乐趣,比如要从不同港口提货到 LHR 仓库,MAN(英国北部机场)和STN(伦敦东北部机场)的时间都是14:00,这样既能大概率提货到仓,还不会产生高额的等待费。

后来方案修改通过后,回家路上突然想到Shopify产品总监的一句话,大致意思是优秀的 PM 面对问题时都会说我知道用户需要这个,而不是等我调研一下先。

但产品经理做出这样判断,往往很难,就像开头说的那句话一样:我们大多数时候都会想着优先解决问题,而不是花时间体验,投入地感受事情本身。且能否花时间感受事情本身,跟能力没有太大关系,而是跟我们工作、创造的环境有关。

因为环境会塑造出共识,会影响人的行为,而背后的塑造过程,更是跟直属团队及共事的人有直接关联。我发现,如果在一个注重体验,注重产品创新的团队氛围中工作,人往往更容易去感知业务/用户现状,共同探讨方案,会自发地收集市场的反馈。因为很多方案的灵感,往往源自于对事情本身的理解和还原,是对事情原貌的窥探,而不是过多的设计。

而这样摸索的过程,也是产品经理设计解决方案的乐趣之一。

本文由 @Leam 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。