当软件公司缺少开发人员（或架构师或测试自动化工程师，DevOps专家，技术撰稿人或产品经理）时，我们在内部看，但也在外部招聘。我们可能会从其他部门挖来一个好人，或者从队伍中晋升，但是 大多数新人才来自招聘。建立职位空缺迫使我们写下所需的技能/经验/职责/才能/风格。
不过，在众多软件公司中，我们 不要’t hire 产品拥有者s。一世’ve seen scores of agile teams created 与 out any 产品拥有者, or unofficially 借用 folks who keep their full-time day 职位 , or grabbing random folks 与 out regard to skills/experience so that someone can “play 产品拥有者”.
一些经常重复的短语，恕我直言突出了一种严重的功能失常行为的模式：
- “Who’s available that we can borrow as 产品拥有者 for this project/product? It’s a role, not a job.”
- “Her manager won’t free her up, so we’这会成为兼职/短期的事情。”
- “我们需要一个比任何最终用户都更了解我们产品的超级中小企业。已经知道我们客户需求的人。”
- “它能有多难？ 询问利益相关者他们想要什么并确定其优先级。“
- “We’会告诉您该软件应该做什么。只需编写所有故事，并确保所有内容都能正常工作。”
- “的team does all the work. You make sure they meet their deadlines.”
I’m arguing for some professionalization of 产品拥有者ship。产品工作很重要：对构建产品至关重要 对 东西。好的优先次序需要上下文和理解以及一些策略。我们需要深刻的知识 向用户提供他们所要求的一切，以及他们所要求的是我们无法使用的过时软件的最快途径.
For me, 产品拥有者ship today is where software 产品管理 was 30 years ago.
产品所有权是一种技巧：在给定的情况下获取和应用技能。产品负责人需要与他们的团队以及客户/用户建立深厚的关系；应用批判性判断；成为他们工具的专家。他们所做的不只是反驳各种利益相关者的需求。 产品所有者的经验会变得更好。 深思熟虑地决定 什么 和 为什么 至少和 怎么样 团队实施。
特设 internal 借用 can work well for agile pilots and pioneers. We scan the organization, grab an appropriate 产品经理 (or business analyst or customer-savvy tech lead or support engineer), and jump into our new agile adventure. Our first volunteers are enthusiastic, energy is high, 和 y can ignore their “old” 职位 for a while.
但这不’可以扩展到大型产品或大型组织。 的“borrowing”模特倒下了，因为我们不’t回填借入的头寸。例如，全职产品所有者的产品经理开始忽略销售电话，定价策略会议，分析师简报，与市场有关的收益，竞争分析，启动计划，用户小组会议，停产/迁移，RFP和设置零件编号/订购信息。当一个人完成太多工作时，所有这些工作都会受到影响。
我们还利用内部人才库获得了越来越少的回报。找几个好人 产品所有权 简单。但是，每次增量选择都会变得越来越困难：我们越来越多地没有客户体验，担心争议或相信“我的用户与我完全一样。”想象一下，如果我们必须在内部招聘所有用户体验设计师。
最后，内部伪雇用使我们变得懒惰。从内部窃取某人意味着不必明确定义我们需要谁/什么。没有书面工作说明，我们公司永远不会聘请应付帐款经理或技术培训师，但我们让随机的人来定义我们的产品。
那么，公司实际上拥有产品所有者吗？
那’这是一个市场问题。一世’在过去的一年中，我的研究团队多次去工作委员会搜寻“product owner”列表，并查找标题为的职位描述“product owner.”（我们为 “产品经理” 职位 last year.)
在整个美国，几乎没有招聘职位“product owner.” 在6/3/14，它看起来像这样： 
With hundreds of thousands of agile teams, a scant few hundred 产品拥有者 职位 are open nationwide. As of this morning, 确实 showed 23 产品拥有者 listings in the SF/Bay Area —软件世界的中心。 （自己尝试。）产品所有者不是’人事部门知道的一项工作，这意味着’没有职业道路，没有薪资规模，并且假设PO’s将很快移回公认的职位。不投资于经验，培训或寿命。没有直接通往专业的途径。
几份招聘信息告诉我们什么
We downloaded and analyzed about 40 产品拥有者 postings specifically from tech companies (i.e. software/systems vendors, not internal IT 组织机构) to hear what the market says about 产品拥有者s:
- 大约三分之一的样子 经典技术产品经理：具有技术背景和业务背景，曾担任过产品经理/所有者，MBA，需要与多个客户群互动并了解市场需求。这看起来像标题替换。
- One third specifically say that the 产品拥有者 works 与 an existing 产品经理. These are 执行委托 角色：专注于工程流程，在sprint级别工作，产品经理确定产品级别的优先级和策略。初级，影响产品方向的能力有限。
- 的rest are a mixed bag of sprint-level activity 与 no connection back to customers, products, markets or strategy. Hermetically sealed 与 in engineering teams and providing scant market direction.
最令我震惊的是： 这些职位大多数都没有指定任何工作经验或可行的招聘标准。 几乎一半没有要求 任何敏捷 经验;一半没有’t调出任何以前的位置或度数。如果您是根据这些职位描述面试应聘者，那么您’会迷路。这强化了这样的想法，即任何人都可以经过几天的培训成为产品所有者。
公司在做什么？
如果公司不是’t hiring 产品拥有者s, they must be doing something else. Here’s what I’最近在大型软件公司中看到了数十个/数百个敏捷团队：
- 有些团队没有’t have any 产品拥有者. 我大多耸耸肩或感到困惑 “Who is your 产品拥有者?” 当被按下时，他们解释说开发经理或架构师正在编写用户案例并轻描淡写地优先处理积压工作。
- 旷工. Some 产品经理 (or SME or analyst or stakeholder) is supposed to be playing 产品拥有者, but doesn’经常出现。用户故事简直是废话，积压的事情一团糟，没有接受标准，但是团队继续 编写代码并跟踪故事点.
- 致命的时间片。 One 产品拥有者 is assigned to four teams —或两支球队，再加上一份既有的工作。深夜，脾气暴躁，故事平庸，并倾向于缺勤。
- 旋转门。 Volunteer 产品拥有者s come in for a few sprints, 和 n go back to their “real 职位 ”当新的志愿者到达时。没有连续性，优先级不一致，对预期用户的分歧， 在敏捷体验池的浅端无尽飞溅 。工程界一如既往地努力做到最好。
提示：我’我对这些都不满意。
Development teams should be rioting in the hallways about underpowered 产品拥有者ship. (Perhaps some are.) 旷工 means we’浪费宝贵的能源为误解的用户建造错误的东西。 无舵敏捷使我们制造错误产品的速度是以前的两倍 。 和 开发者理所当然地讨厌那个.
顺便说一下，一支由8人组成的美国Scrum团队每年会使您的公司损失150万美元。如果您有20个团队的sprint级和产品级指导不足，那么您的CFO和VP Engineering应该提出一些令人不安的3,000万美元问题。
该怎么办？
这是多个层面的问题。我们应该…
- 当我们（作为执行人员）决定一个庞大的工程组织将“go agile,” let’s do the up-front math. 1000 developers implies ~125 scrum teams, which screams for 75+ full-time 产品拥有者s. Not time-sliced, not borrowed, not interim, not hand-waved, not hypothetical, not covering their 旧 职位 during nights/weekend, not budgeted for a year from now. 其中一些可能是可借的，但大多数是增量负责人。我们是否想每年在敏捷团队上花费2亿美元，但不分配任何人员来指导产品？
- 确定这是否是 仅委派角色 （由产品经理或利益相关者做出所有产品级别的决定），或者我们的产品所有者是否必须在市场细分市场和竞争激烈的销售团队之间进行政治上敏锐的权衡。这将极大地改变我们的选择流程以及他们需要多少管理权限。
- 询问我们需要什么技能和经验。 至少，非新手应该具有一些敏捷的经验。担任产品负责人/产品经理一段时间；足够的技术知识，以避免开发团队回避；以及一些专业知识。对真实客户的同情心；良好的沟通能力；体面的组织能力；并具有量化价值的经验，将非常方便。即使从未发布过职位描述，也要写下。有思想，有选择性。
- A two-day CSPO workshop does not make anyone a 产品拥有者, any more than a weekend at a dude ranch makes you a cowboy. ( 抱歉 .) Build a plan to help new 产品拥有者s learn their craft. Look inside and outside for product-specific coaches/ 导师 。花一些培训经费用于LeanUX，产品管理，质量指标，财务建模以及为什么企业销售困难的原因。
- 唐’让您的客户请求清单成为您的路线图。卡诺分析告诉我们 让当前客户为您排定优先顺序会导致市场失败。唐’t let your 产品拥有者s confuse “这就是增强要求的内容” 与 “了解和解决实际的客户问题。”
- 问 teams if they can name their 产品拥有者s. Then ask those 产品拥有者s if they are dedicating the majority of their time/energy/love to the new role. If not, hire someone who can.
声音字节
We’re filling 产品拥有者 slots internally, 与 out much regard to skills or long-term success. Or leaving these slots open for development teams to fill as they may. 那’通往市场失败的道路。我们要 be thoughtful, intentional and organizationally savvy about picking and 导师 ing 产品拥有者s.