我们之前的两个帖子指出 您的开发团队永远也不会足够大 追上你的梦想(推动我们 无情的优先权定律 ) 然后 所有利润都在第n个副本中 (从而 一次建造,多次出售的定律 )。

第三部分从观察开始 我们发布的软件不是产品。 相反,他们是 部分 产品的我们可能会庆祝发布代码,但是’一家软件公司需要更多的钱才能赚钱。就像给一个饥饿的人喝一罐汤,却没有开罐器。那还有什么呢?

给我讲一个故事

销售和营销团队真正想要的是一个连贯的,与市场相关的高层 故事 帮助客户了解使用我们的产品(做他们已经做过的事情)如何改善他们的生活。一旦我们开始讲故事,我们就会发现我们的软件没有填补的空白。突然,我们发现我们需要开罐器才能汤。哦,碗可能不错。和勺子。可能也想稍后再洗碗。

或者,也许我们是第一次约会喝汤–我们希望碗里说“你应该完全和这个给你喂汤的人约会,这是一个拥有很棒的碗的人,并且会是一个很棒的灵魂伴侣。”解决 快乐味mis汤 我饿了,寂寞了 问题,不是 给我一个汤 问题。

科技产品也是如此。我们的B2C云文件备份应为用户提供深刻的安全感’未完成的小说和全家福–通过轻松的应用程序。我们的网络故障排除工具使网络管理员的英雄们可以立即修复当前的生产问题。我们的小型企业薪资服务应消除基于AI的表格填写问题而为兼职员工支付错误金额的麻烦。 我们需要一个对我们的观众重要的故事,并引起我们的关注.

我们以主要收益(即不仅仅是功能),成功案例或社会证明,客户投资回报率计算器,详细的用例,竞争分析和名人认可来讲述这个故事。正确的故事使准客户有理由感到兴奋,引起我们的注意,忽略我们的缺点并注意到其他人的怪癖。为了感情投入。

作为分析技术人员,我们希望相信一个纯粹理性的购买者世界:正确识别自己所有需求的客户,搜寻相关产品的市场,仔细比较每个数据表的背面(规格存在的地方),确定优先级并在电子表格中称量结果,然后选择最适合的结果。

在那个世界上,销售仅意味着与潜在客户共享技术规格并等待收集采购订单。顶级销售代表’赚不到软件架构师的两倍。公司会’在营销和销售上的投入是开发的两倍。而产品经理只会“collect”要求:从现场接受采访(例如雏菊)。

Here on Earth, competitors are always offering similar products. Marketers are telling 更好 stories. Sales teams are finding internal champions, highlighting 的 risks in wrong choices, and buying lunch. Our underlying 软件 is necessary but not sufficient to make money.

细分以获取乐趣和利润

产品策略取决于对谁的清晰,清晰的描述( 恰恰 )我们’重建,什么问题( 恰恰 )我们 choose to address, and how ( 恰恰 )我们比其他解决方案更好地解决了他们的问题。分割。我们是针对跨国公司,企业还是单店中小型企业?滑雪爱好者还是偶尔的雪兔子?便利驱动的有机食品杂货店购物者或使用优惠券的储户?专业会计师还是周末簿记员?它’很少能瞄准“城市双收入千禧一代。”

必须进行周到的细分 之前 我们过于深入开发周期,或者我们’会建立一个不适合任何人的怪兽。未能吸引任何特定的受众。 (返回并阅读 劳拉·克莱恩(Laura Klein) 要么 埃里克·里斯 如果这不是’t top-of-mind.)  最紧急的是,我们必须确定一个狭窄的细分市场,该细分市场不仅喜欢我们的概念,而且愿意为此付出代价。每个初创公司(和每个Scrum团队)都可以找到几个感兴趣的客户,但是软件的经济性要求 客户。

因此,要取得商业成功,首先需要出色的市场思维和真实的客户故事,以便最终我们可以进行出色的营销/销售。但是我们经常急于开始构建软件,因为’s what we’re good at.

我的广泛但不科学的分析通过这种方式来分解产品故障:

失败派

差的选择解决的问题,不好解决的问题以及无法理解/表达我们的差异性的原因占一半。市场营销和销售灾难覆盖了下一部分。纯工程故障(灰色区域)仅代表最后一个季度。换一种说法, 产品的大部分成功取决于我们分配第一位开发人员之前 或填写我们的第一个故事卡。 出色的工程技术并不是解决不良市场思想的方法。

<analogy>如果我们在错误的地方开始钻探,则工程学无法将我们排除在产品/市场问题之外。如果可以的话’讲一个关于石油与太阳能的好故事,我们可以’最好找工程学讲故事的人。</analogy>

 

但是我的公司正在构建API…

许多成功的公司都将其他开发人员作为客户。这使您的开发团队与您的客户更加轻松。但是,适用相同的规则。对于每个 特威里奥 要么 松弛 ,还有数十位还没有签署备受瞩目的早期采用者的人;不能’建立一个充满活力的开发者社区;高估了他们的入门级服务;没有’不了解他们的生态系统;或假设“better”API自然会导致更多的采用。营销API仍在进行营销。

因此,回到我们最初的主张,即我们发布的软件位仅仅是任何解决方案的一部分,我们得出了……

整体产品定律

客户购买了包括软件在内的解决方案,但这些解决方案以仔细的细分和出色的营销/销售为框架。我们希望提供最短的平均上班时间(MTTJ),以便客户找到我们,尝试我们,立即看到我们的价值,并在适当的细分市场中向其他人赞扬。

作为高管,我们申请 整体产品定律 通过将激励措施与客户成功而不是原始收入相结合;打破组织孤岛;并使营销/销售部门与产品/工程部门保持密切联系。

您有完整的产品吗?这是确定的一种方法…问几个客户。他们会告诉您缺少的内容。以及您的产品故事是否与软件版本匹配。

(法律链接 #4)


(顶部图片是从 http://www.psdcovers.com/can008/can008r2/ )