我是一个相当差的产品经理。这不是我擅长的东西，所以我没有任何可以称得上熟练的技能。事实上，我很容易被产品最重要的部分分心。我经常很幸运的和非常优秀的PM合作 — 但是有时候这不是一个好选择。

当我需要披上产品的外衣时，有一些简单的方法可以使用。这不是专家建议，只是一些技巧，来帮助我在做产品经理时不要太无用。

进行影响面分析

这个技能需要长期计划；当我需要从一堆想法中帮助一个团队做决定，决定需要在哪些想法上集中注意力时，我就用这个办法。

我这招是从 Craig Kerstiens学的，当我跟他一起在Heroku工作时。这项技能最开始他同Heroku Postgres团队合作时使用。你把潜在工作列在格子图上，映射到困难与影响。

当我做这件事的时候，是非常愉快的；我们不需要太在意困难和影响的定义；我们只是快速的把事情丢到矩阵中。
值得关注的是，那就是计划的全部了。左上方的项 — 高收益，低付出 — 显然赢了。右下角的项目 — 高付出低收益 — 显然是不该去做的。 然后你从中间选择一小部分项目，因为你想做更多的工作，这就是计划。

在使团队在短时间内同意做一系列工作的事情上，这个技能有奇效。看看Craig’s发出来的细节吧，有机会尝试一下。你不会后悔的。

难以估计的工时

在我写了一系列估时文章之后，一个问题出现了，怎样去处理庞大未知的工作呢？例如想一想将遗留的代码库融合进来：任何做过这个项目的人都知道前方一切未知。很难准确的知道需要什么任务。

在这个例子中，我用timeboxing法：选择任意长的时间—一周或者两周，经常只是看看我们到那了。在timebox的最后，我们对工作就会有更多的概念。我们可以回顾进度，然后关于如何推进做出更明确的决定。

Timeboxing非常给力，因为他从一个不同的方向去做预估。代替了“会用多久？”，timeboxing会这么问“我们两周能做什么？”

Timeboxing对那些在合理时间内无法完成的项目也非常有用。例如，考虑有大量的bug。花费所需的时间去把bug消灭为0似乎不太可能，但是每周花一天时间把bug数降下来是可行的。

Timebox在项目进度方面也是一个好办法，尽管前方有山一样的工作或者未知的坎。

在运行自动化之前写写操作手册

最后，是流程自动化。大部分软件开发者都知道自动化的诱惑：当我们看到一些手工的耗时操作时，把它转化为代码非常有诱惑力。

不幸的事实是，自动化也不总是像我们想象的一样好用：

很多同事被卡在这： 我们知道自动化过程不是我们想象的那么容易；但是我们也知道，这个过程是复杂的，易错的，乱的，甚至不如手动测试。

操作手册是这些情形的中间立场。当我看到一个过程后，我首要做的是些操作手册，而不是什么也不做或者直接去写码。操作手册是一系列执行任务的指令 — 像一份菜单。关键是要尽可能具体。如果这是某种包含代码的任务，你甚至可以包含点代码或者shell命令，看执行手册的人可以拷贝粘贴。

这离自动化的目标又近了几步 — 一致性，重复性，可靠性 — 通过付出少部分的努力。如果你后面决定自动化值得去花时间，操作手册可以作为详尽的说明来用。