谁也无法预料产品未来的发展，不可能什么事都想得尽善尽美。

在产品工作中，我们经常会遇到这样一种情况，等到需要搞运营或推广活动的时

候才发现缺失了必备的产品功能。本来没计划的功能，又变得特别着急，即使立

刻启动开发，也已经来不及。 

出现这种情况虽然可以理解，谁也无法预料产品未来的发展，不可能什么事都想

得尽善尽美。但如果一味的以功能缺失为由拒绝需求，恐怕也有点不太现实，别

人可能还会误以为是你产品经理的能力不足。所以就需要有一些方法来解决这样

的问题，弥补功能上的缺失。

说一个我身边的产品案例，之前我们跟别的公司合作的一个项目。技术已经进入

到开发末期，很快就要结束了，但当时跟对方的技术人员沟通一个实现方案的时

候，双方出现了一些分歧。内容聚合页面的背景图不能在客户端中写死，也就是

说只能从服务器中读取，这样保证图片随时可以更换。可当时我们确实是把图片

放到了客户端的文件包里。

很不幸，由于沟通问题，彼此也都是第一次合作，对于彼此做事的方式缺少了

解，这个问题暴露的太晚。而且我们的后台也没有让运营人员上传这张图片的功

能。如果临时修改，一来产品经理要重新设计后台功能，同时也会给技术人员增

加开发量，拖延项目的上线时间，不管从哪个角度讲都不合适。

可没办法，毕竟人家是甲方，执拗不过，我们也必须作出修改。当时我们想到了

一个折中方案，将这个页面中排序第一的内容的封面图作为整个页面的背景图，

这样背景图会随着内容顺序的调整而变化，而内容的封面图是从后台读取的，并

且在后台可以修改。这样相当于背景图就是从服务器中获取，算是达到了目的，

过了这个坎。

用H5页面是一种非常常见的方式，相比较APP来说H5的好处是功能和内容能够随

时更新，即使出了错也能很快改正。

还是拿我做过的一个项目来说，当时要新上一种新的内容，对于这种新的内容类

型，已有的页面排版设计无法很好的展示信息。甚至是说不能突显出内容的最关

键信息，这对内容的销售来说显然是很不利的。可要是对产品重新改版，时间会

很长，如果一直等待的话，内容没法上，也就意味着耽误了赚钱，所以我们当时

就用H5页面作为了内容的详情页。

为了节省效率，还把这类页面做成了模板，版式相同。新上一个内容，只换一张

封面图和页面中的文字即可。

我曾经看过一个APP，当时没有活动中心的模块，就用H5页面做了一个专题的聚

合页面作为所有活动的入口。不仅活动是H5页面，活动列表也是H5页面。

有些功能虽然短时间内不能开发完成，但可以通过运营手段来达到目的。

举两个例子，一个是当时我们想对平台上售卖的产品在商品图片上打上“折

扣”的标识，吸引用户点击。但是系统没有这样的功能，所以就用了一个笨办

法，让设计师把“折扣”的字样做到了图片上，达到了目的。

其实最终效果跟我们开发功能的结果是一样的，只是这种方式需要设计做图，比

较麻烦，而且针对少量商品的话还可以。如果商品的数量很多，工作量很大，这

种方式显然就不可行了。

其实利用图片表达信息这种方式在行业内也算比较常见。之前看过一个APP，估

计是想要在轮播图上标识内容类型，这样便于用户知道推荐的内容是什么类的。

本来可以在管理系统中做个功能，运营人员在后台设置后，APP的图片上自动显

示内容类型的样式。或许也是由于这个功能还没开发，所以这个APP也是把标签

做到图片上。

我们产品中的限免功能，原本计划是不上的，但是由于运营活动所需，这个功能

又要的特别急。所以当时我们想了一个办法让运营人员直接在后台把价格改为0

元，等到限免时间结束后，再把价格改回来。纯人工手动的方式，虽然笨拙，但

关键时候也确实有效。

要提醒大家的是，通过运营手段虽然能够实现某些功能，但毕竟只是暂时的。这

种方式也会遭到运营同学的吐槽、抱怨。长期来看还是要把产品功能做好，一劳

永逸。

首先要明确技术可以补救的范围都包括哪些：

第一点是内容数据，技术人员可以通过修改数据库或代码中的文字来帮你修改页

面上显示的内容和数字。比如说某个商品的图片需要修改，而系统又没有这功

能，技术人员可以靠修改数据库的方式来解决；

第二是如果某个功能已经存在，并且是从后台系统中读取的信息，那么靠着开发

后台的功能就能达到目的。比如说某些内容已经是从系统后台中读取，运营人员

想调整这些内容的排列顺序，那么就可以在后台中增加调序的功能实现目的。

你可以理解技术是万能的，但如果利用技术方式进行补救的话却不是什么都可以

实现的。产品已经在线上了，代码上较大的改动会有风险，容易引起别的问题。

而且这种方式非常麻烦，有时候会造成改错的情况。所以这种方式保留，免死金

牌，轻易别使用。