指南针和地图

在一个 较早 帖子之后,我们为敏捷软件开发项目设计了一个框架(internally consumed vs. revenue 顾客s; single 顾客 vs. mass market)以识别 产品所有者需要的产品经理级技能。我们还介绍了用于收益软件项目的模型。

In this second of three posts, we’ll look first at 内部使用的软件 and then at the squishy intermediate case of software-enabled services.

可运营的非收入应用

我将项目/程序分类为“内部使用的软件”如果它没有为公司带来收入;其主要用户是员工或内部系统;并且可以满足非战略性的运营需求。这可能包括费用报告(美国运通(American Express)出售此类服务),恢复扫描(除了光辉渡轮), 发货跟踪 (联邦快递除外)和文档访问控制(除了国家安全局 )。 看到 “什么’s Your Strategic App?”

内部应用细分

通常,开发团队被称为“信息技术” or “Technical 服务 ” rather than “product development” or “R&D.”这清楚地表明该公司的收入方面没有涉及。

由于内部软件没有大规模的市场,但我可以重新标记水平访问的范围,以使其更具针对性,但可以有许多具有不同需求和优先级的消费群体。

布置一些项目类型

As we did with revenue software, let’s situate different kinds of projects along the internal 顾客 spectrum:

内部分歧内部使用软件的客户差异

[1] 我们理想的项目有 一个部门的用户 ,以及负责管理该小组的直接赞助商和直接的业务价值。“作为在线技术支持的负责人,我需要我的支持工程师在我们的支持数据库中拥有更强大的关键字搜索/索引,以便我的团队可以从相似的案例中快速找到解决方法。如果将速度提高20%,明年将为我们部门节省50万美元。我正在指派最好的高级支持工程师与产品负责人/技术团队合作,并找到解决方案。还有我支持团队中’想要使用改进的系统可以调出。”

这和任何内部项目一样好。 只要一个解决方案的成本不超过10万美元,并且指定的SME可以周到地代表类似的用户,我们就会步入正轨。顺便说一句,顺便说一句,我们假设有人已经提出了业务理由。我们的赞助商很可能会估算自己部门的节省,游说IT主管,并一式三份提交各种财务文件。并且可以坚持要求她的支持工程师切换到新解决方案。

AFAIK,所有介绍产品所有者的讲习班/书都假定这种最佳情况:明确赞助商和用户,明显节省内部成本,愿意的主题专家,明确的预算授权和合理的交付期望。会一直如此吗?

[2] 当员工可以时,事情变得更加复杂 选择是否使用内部系统。例如,一个新的费用报告应用程序直接输入到Finance中,减少了手动数据输入,并更快地向员工提供了报销支票—但仅适用于找到/安装/学习/使用它的员工。 (我们很可能会继续接受旧的Excel模板以及后期采用者和销售人员的复印件收据。) 或HR的新健康福利注册Intranet。或者我们的创新计划与Jive / Yammer / Chatter / SocialText网站相关。

这些系统的成功在很大程度上取决于 让人们持续使用它们。仅仅一封首席执行官写的鬼邮件是不够的。这些产品所有者应具备的一些产品经理的技能:

+能够描述明显的好处 个人用户 (而不仅仅是公司),并说出话来

+确定利益相关者代表(在人力资源,财务等方面),他们将负责持续的宣传,员工提醒,竞赛以及其他鼓励参与的方式

+持续的工程计划,因为没有应用程序真正完成或没有错误

+在管理的支持下,旧方法的寿命终止计划(无论多么不受欢迎!),以便后期采用者最终必须加入。这使我们不再支持旧的解决方案。

交付好的软件不是, 通过它自己 , 成功。回报来自使用该软件。产品所有者需要像消费者营销人员那样思考。

当系统涉及多个部门或职能部门的行为变更时,项目风险会越来越高。正如David Taber在“Salesforce.com成功秘诀,”迁移到新的CRM解决方案需要认真协调和激励那些’对参与非常感兴趣。他的圣人忠告:

  • 唐’一次获取系统上的每个部门。从一个小的核心开始,然后随着对系统的信心增强并建立用户热情,逐步将其扩展到其他组。
  • 数据比其所在的系统更有价值(和更昂贵)。代码和功能不具备’无论数据是否垃圾,都应关注准确的信息和易于访问/更新的信息。
  • 避免大刘海。随着早期用户淘汰新系统,计划进行几轮技术调整。设置敏捷的待办事项列表,以对正在进行的增强进行优先级排序。

因此,这些大型部署增加了更多产品管理技能:

+与新应用程序的个人用户不断交流收益

+设计促进参与的财务激励措施/惩罚措施

+序列化推出以赢得早期胜利并进行积极的内部宣传

+坚持不懈地强调整个公司的目标,以便高管们不会无意间取消中游

唐’t plan on moving to another project for several quarters after initial deployment.内部应用范围内部软件项目对产品经理的需求

最后, [3] 包括 集中化技术组织,试图对众多业务部门之间的应用程序进行标准化。我看过很多“common ground” or “共享基础架构”努力挣扎,因为他们无法预期他们的多样化需求/优先级“customer” business units.

我在Yahoo!上花了一年时间在这样的项目上。我们需要标准化用户个人资料的检索(“获取此用户的昵称,位置,年龄,性别和照片”),以符合法律和技术要求。但是,每个50多个业务部门都有自己的发展路线图,优先级和资源承诺。  Shopping.yahoo.com 正在增加假期的容量; FantasySports.yahoo.com 正在为即将到来的棒球赛季实施新的球员选秀机制; Movies.yahoo.com 正在与一家大型电影制片厂设计联合促销活动,等等。我的基础架构升级必须使50个业务部门的开发人员脱离其创收工作,并且没有立即产生产品级收益。您可以想象延迟,升级,哄骗和重新安排的设计会议。

推动此类公司范围内基础架构的产品所有者需要广泛的内部营销和政治技能,才能:

+确定该程序是否足够重要,足以证明其将消耗的所有资源和精力

+确定(或发明)合作业务部门的价值

+制定激励措施,并为早期采用者提供激励和行政认可

+安排非正式的工程师对工程师会议,以宣传该计划的技术优势

这看起来可疑地像是高端商业软件的企业销售模型。

基于软件的服务:模糊的中间立场

如果您是负责公司关键服务核心技术的产品负责人–但不打包直接销售的软件– product challenges are more like revenue product than 内部使用的软件.  Plotting a few points:

支持软件的范围

战略服务支持软件对产品经理尼斯的需求

[1]基本技术架构。 大多数企业越来越以技术为基础。如果您在FedEx或UPS的团队可以大大提高包裹跟踪的准确性,那么这将对广泛的产品和服务产生影响。移动应用将需要更新;审查服务保证;加快数据库轮询;营销声称虚高。一项关键内部技术的产品所有者希望像基于商业API的服务(例如Amazon Web 服务 )那样思考。这需要与架构师或云产品经理类似的技能:

+确定重大胜利。我们(和我们的合作伙伴)可以建立哪些激动人心的新服务?

+寻找定义竞争的新方法。我们是否可以提供新型设备的服务,或者以10倍的更新速度显示价值,或将资源减少70%?

+提取价值。我们应该在哪里提高价格(这些服务元素的产品经理是谁)?

+规划向后兼容性。我们数百个使用中的应用程序能否在不被修改的情况下获得额外的价值?

[2]可见的功能级别改进。 即使您要收取其他费用,软件也可以体现您的服务。例如…如果您负责在线股票交易服务的某些部分,则大多数更改都是客户可见且与客户相关的。您应该问如下问题:

+我们是否已将最受欢迎的交易的点击次数和决策次数降至最低?例如,应该有一个“happy path”轻松购买美国股票。

+ Where are users getting stuck? Where do they click HELP, call 顾客 support, abandon transactions or loop back through?

+网站变更是否会带来额外的收入交易?多少钱?例如,关于国际债券的更好的研究报告应该鼓励投资者购买一些。

+ Is my information consistent? 的iPhone app, web page, 顾客 support phone system and monthly statement should deliver exactly the same data.

总结第二篇文章

先前 ,我们考虑了各种收入产品以及产品所有者可能需要的产品管理技巧。在这里,我们对一些内部使用的应用程序进行了打包,并指出,更复杂的内部受众(自愿用户和不愿意的业务部门)使产品所有者的问题复杂化,除了敏捷体验之外,还需要市场风格的技能。启用软件的服务看上去很像收入软件。

本系列的最后一篇文章将总结产品所有者在移动时需要的产品管理技能“up and to the right”面向大众市场的商业软件。并考虑我们如何找到– or grow – such skills.