“野路子”产品成型记

“这个技术，你给找找应用场景，要跟咱们的业务结合起来······”

“好的。”

各位看官，技术驱动业务是一种怎样的体验，大概就是让怕死的人去吃螃蟹吧。

说笑了：），在这个ai当道的时代，怎样将尚不成熟的技术用到已经很稳定的业务上去试错，怎样让业务方愿意配合（不要疑惑，现在花2万块能搞定的事，很多人还真不愿意花20万去试错一个可能有长期发展性的方案），除了来自高层的举荐，还可以怎样推动？作为某技术的“代言人”，分享一点自己的感悟。

深入了解业务，寻找应用场景

技术推动业务，本质是一项伟大的试错。

相信每一样技术，都是基于公司战略层面的判断而推动研发的，如同自嗨型的产品需求不可取一样，自嗨型的技术同样是没有发展前景的，结合实际进行长远考虑，也是对资源的浪费。反过来也说明，一项技术被研发出来，一定是拥有应用场景的，具体怎样跟业务结合起来，需要技术的产品经理依据技术本身的重点去业务中寻找。比如老板目前在跟的某新技术，底层是图片识别，那么这项新技术怎样应用到业务场景中呢？就可以从业务中与图片相关的场景出发，发现适配的痛点。其实这里也说明在大公司里，即使怎样做内部平台化的信息分享，总是大部分人不知道其余大部分人在做什么，所以某些痛点一直“悬而未决”。

寻找到应用场景后，需要跟该场景有关的一线业务人员做深入沟通，确认该痛点真实存在避免自嗨，搞清楚业务规则避免踩雷，“标新立异”也需要“入乡随俗”。

明确产品形态，确认资源需求

摸清楚业务痛点及运营规则后，需要确认产品目标及形态，产品是要解决怎样的问题、比起其他解决办法优势在哪里、产品的长远发展会是怎样······均需有一个清晰的答案，这也是“忽悠”业务方配合的法宝，毕竟谁能更好地解决问题，业务方才会选择跟谁合作。

当产品的形态确认后，需要梳理产品逻辑，确认依赖项。前端、后台、算法、数据······根据产品逻辑一一明确资源需求，然后找到对应负责人沟通合作意愿。这里有一个问题是，合作双方之间的重点可能不一致，有些资源支持虽然存在但实效性难以保证，说不准排期就被别的需求挤到猴年马月了，如何取得平衡，目前感觉只能自上而下推进了······

梳理项目流程，推动立项研发

流程虽繁琐，但在很大程度上能防止出错。

确认产品可行性后，需要根据既定的项目流程推动立项，这里不乏要明确项目roi，提交brd评审等，虽然目前项目还未推进这一步，但可以预想到这将是艰难的一战，毕竟某些优化体验类的项目，很难评判可以带来的转化量······还是那句老话，想要顺利得“试错”，来自上层的支持是最给力的。

一些小贴士

具体的产品形态怎样确认？

竞品分析、用户调研是最佳的方案。

这里面有很多技巧，比如针对用研，大部分用户是不知道自己想要啥的，或者说不知道自己想要的解决方案是什么。所以用研的重点不应该是就现有的解决方案进行，而是就是否存在这个问题，对这个问题的看法和期待是怎样的来进行，这样也可以明确产品的必要性及是否真的优于其他解决方案。

不能不算的roi怎么破

对于roi，必须要有，但可以不是“真金白银”，比如某些间接指标的提升，对核心指标也是有促进作用的。但如果必须要换算成money，建议根据历史项目经验结合指标换算得出，比如根据用研中需求强烈的用户比例，估算产品会有x的使用率，产生使用行为的用户，可能有20%的用户会进行下一步，最终转化建议再乘以20%（二八定律嘛），如果有历史项目经验，那就更精确了～

总之，发掘使用场景并转化为产品需求本身已是不易，能够推动项目落地更是需要天时地利人和，而我们在其中能做的，就是把自己能做的都做了～