怎么从engineer的角度定义/提升产品价值？

大家好！最近有个问题一直在困扰我，希望地理的小伙伴能帮我解答一下！（希望认出我的小伙伴不要揭穿我的身份！！）


先介绍一下背景，人在亚麻，sde2，做的是一个internal service，peak的时候customer会达到200左右，monthly average大概七八十，是帮internal BA/Finance Mgr去算数据，比如零售增长率之类的。


这个问题一直追溯到今年年初亚麻的第一波layoff。我们的sr sdm跟我们组所有的engineer开了个会，用了一些自制的user metric当datapoint说我们组的产品因为customer很少所以“no value” （对，是他的原话）让我听起来很受伤。（我觉得他就是想如果L8要交layoff名单他要那我们出去献祭。印度sr sdm，我们组全是中国人）但我想就事论事的分析一下。在我的视角里，他只是拿“自以为”的dp去证明，没有实地的去要customer feedback，比如customer说这东西不好用，他们觉得没有用之类的。一个产品的value不应该仅仅取决于用户数量，应该是有多方面考虑因素，比如这个产品的output会产生什么样的contribution，能为customer提供什么样的便利。这不仅仅是一个tech的问题，更应该是一个business方面的问题。但当时因为layoff想夹着尾巴做人所以就没和他argue。


之后，今年Q1我们组去年launch的一个比较大的project慢慢的没人用了，当然这个因素是多方面的，比如当时写model的人离职了，之后算出来的数据不准。away team也没有给我们提供必要的support，比如data。我不觉得我们sde哪里做的踩大雷，因为当时launch的时候我们收到了各种非常好的feedback，PM的要求从来都是指哪打哪。因为现在没人用了，Sr mgr就跑过来跟我们说这东西是你们的锅，你们没dive deep BRD（business requirement doc），你们不清楚这个东西的scope，当时你们就应该觉得这东西scope小，没人用直接push back。你们之后接pj的时候要多想想这东西的scope有多大。我：？？？首先你们mgr， leadership approve的东西 我们engineer能直接就说不做了？我觉得说了的第二天我就会被PIP。其次，我们engineer是没有direct access to customer的，所有的content都是从PM，mgr那里得到的。我觉得会有不少PM会把这个项目说的天花乱坠拿funding/resources，最后launch了拿到credit拍拍屁股走人，最后让maintain的sde背锅。


上面只是这个mgr对我们组做的事的冰山一角，还有很多，但不在这个帖子的讨论范畴。（我觉得这个mgr就是在针对我们组和我们组的产品，我已经拿到别的offer准备和他杠到底）但想就事论事的探讨一下，怎么从engineer角度提升产品的价值？


我能想到的就是

• 在拿到BRD的时候多问一些why，比如这个产品的初衷是什么，会产生什么样的效果，有多大的scope，但我觉得这种事情更应该是high level的人去考虑，大头兵的视角真的有限，不过如果想往上面走确实是要训练自己这方面的能力。不知道想的对不对，希望听听小伙伴们的意见
• 站在customer的视角去考虑怎么优化用户体验。比如我想快点得到result，把这个按钮设在这里好不好，etc。这里就会影响到我们的design，比如怎么优化算法/怎么选更适合这个产品的service，怎么去设计UI，etc。我觉得这里sde能做的还是挺多的。
• （joke）吹牛逼。东西好不好全靠一张嘴。我说这东西有用他就是有用，我说他scope大他就是大。你觉得这东西no value，给我提供dp我就是嘴硬都给你反驳回去。

我暂时能想到的就是这么多，希望大家能分享一下，你们是怎么定义产品的value的，你们拿到pj之后会不会考虑上面的这些问题，以及从engineer的角度怎么提升/优化这个产品的value？评论都加米！

我觉得一个产品business方面的价值不是engineer努力工作就能掌控的，但engineer可以通过跳槽和换组来掌控自己手头项目的价值…

最基本的会计公式：Profit = Revenue - Expense，做infra的不会直接产生revenue，那就只能想办法减小cost呗，比如你们的工具对于做strategy planning很重要，直接减小budget variance by xx%，或者你们的工具可以提升员工开发效率，on average direct labor cost reduced from xx hours to yy hours，或者你们的工具省算力，原来需要x个CPU跑y小时出来的结果现在你们用十分之一的x*y就能算出来，这些都是实打实的数字
我其实一直想和engineer说，impact未必能转化成$，但是$天然就是impact。

我们组最近做了一个和compliance相关的工具，给VP做demo的时候，我们提出了以下value:
第一，这个工具业界很多customer都提出过疑问，现在我们把他们的concern visualized and addressed，于是帮公司增加了xx潜在客户和留存了yy续约客户。
第二，这个工具和compliance相关，本身自带safeguard company intangible asset的属性
第三，这个工具能让我们高效率发现潜在开发漏洞，根据业内过去五年的统计，因为数据丢失造成的损失有四十多亿美元，那我们这个产品是可以帮助公司avoid contingent liabilities的。

报告完了我觉得效果是不错的，VP也是很正面的回应。

当然，上面这些内容大概是经理和PM该做的内容，SDE2应该不需要想到这么数值的层面。

亚麻as飘过。理解处境。两个建议：
1. 不能只看activate user，尤其是内部用户，数量肯定不会多。你要看downstream impacts/effect,即incremental value. 这也是CDO最推崇的概念。我们组也有对内的ds产品，但owner就很能吹，说是ta这个模型和以前的baseline control比，准确度高了多少多少，这还不要紧，以前模型错判，但新模型识别出来的客户，每年贡献多少m的revenue。虽然明眼人知道这几百万的revenue不能算在ta头上，但毕竟数字很唬人，马上就显得nb轰轰了。
2. 你们sdm感觉不会吹牛，听你的描述ta好像也是个老中。anyways，老板一个重要的职能就是对外画大饼，跟lt证明没自己组地球就不转了。sdm干不了这个，你试试看找pmt, pm之类靠近stakeholders的。按说他们的饭碗和你们的产品高度绑定，他们也会有动机去证明没了你们🌍就不转了。

补充内容 (2023-07-26 12:43 +08:00):
补充一下，business significance 应该不是你们sde该背的锅。如果sdm不能给你们找饭辙，反而还给sde扣这种“产品没用”的帽子，你得考虑下要么跳船要么划水要么玩政治，总之别较真，也别跟自己过不去了。

jonesG 发表于 2023-07-25 12:17:47
我觉得一个产品business方面的价值不是engineer努力工作就能掌控的，但engineer可以通过跳槽和换组来掌控自己手头项目的价值…

跳槽和换组是有成本的

没有那么多为什么，都是职场上都是自己拿credit走人，等你到那个位置，也可以这么干。

匿名用户 发表于 2023-07-25 20:40:51
跳槽和换组是有成本的

死守一个没前途的产品也是有成本的

MarteeZZZ 发表于 2023-07-25 22:15:12
最基本的会计公式：Profit = Revenue - Expense，做infra的不会直接产生revenue，那就只能想办法减小cost呗，比如你们的工具对于做strategy planning很

降本是一个方向，但别忘了rev-cost有一个下限，0：如果带不来效益，大不了不做。所以在讨论工作的意义的时候，大方向永远是先说带来了什么value，提升了什么价值，再讨论省了多少成本。更何况没有流量，没有scale的时候（楼主的处境），成本的大头来自人工，也就是说，降本最有效的方法，是砍人😬。所以降本我不认为是个有效的argument.

LT的思路也是一样，先谈价值，再谈成本。没有价值，再便宜也没意义。

本人老UX researcher，我的工作就是中立地搞清楚用户需求，以及早期评估产品原型是否有价值。
你这个情况看起来组里没有UX researcher，都是PM去搞。调研方法是否严谨另说，所有的function的lead应该都被share out到用户的需求是什么，有多大scale，use case是否频繁是否有价值。然后根据需求的产品如何设计。不过通常eng只有该项目的tech lead/manager会参与这些早期讨论，Junior一点的engineer在下游基本没什么话语权。

首先产品取消了，一定会有人背锅，PM/sdm/engineer，所有人都逃不掉，越低级别责任越小，除非没好好干。
其次，从上面的描述来看，产品价值200人，但是要乘以每人每年创造了多少价值或者节省了多少时间多少钱，再减去养一个组的engineer和scientist，再减去基础设施，才是正向价值。而且200人是现有客户，有没有后续拉来客户的潜力？你们的工具是否客户缺了就不行还是nice to have？
再次，你们的项目管理为什么会有single point of failure, 为什么一个人离职就造成model不准？
继续，UX并不是一个产品的核心价值，这里的核心价值是model。不去围绕核心价值进行优化，做再多的UX改进也没用。
最后，sdm和PM会有很多engineer不知道的信息，也不一定会讲的。