How a startup builds products

Go to the profile of Tyler Myracle
Tyler Myracle
BlockedUnblockFollow继2018年2月8日之后


每当我们在RigUp的采访过程中与人们交谈时,一个不可避免的问题就是"产品流程是什么样的?"。我们仍然是一个相对年轻的公司,所以我不会说我们已经弄明白了,但我们找到了适合我们的东西。这是一个功能如何从一个人的头脑中的想法到我们客户的手中。

First Things First


从业务目标开始。作为一家公司,我们目前大致每季度设定目标和目标,我们发现这给了我们足够的时间来开展工作,这将在业务中产生有意义的影响,而不会引入过长的反馈循环。一旦明确了未来~3个月业务的最高目标,我们就产品团队如何在当时产生最大影响力进行讨论。这会引发更多的注册吗?专注于保留?改善参与度以推动更多有机邀请和口口传播?我们是否可以降低风险,以便在未来开辟新的销售渠道? NPS或客户满意度不是正确的方向?


一旦我们确定了团队如何最有意义地为业务增长做出贡献,就应该弄清楚我们将如何努力实现目标的具体细节。通常,我们将从产品待办事项开始,确定可以为我们的团队目标做出贡献并相应地重新确定优先级的功能和改进。有时候,如果我们觉得产品积压会留下一些需要的东西,我们也会进行头脑风暴和构思会议。在RigUp,我们确信最好的想法来自多种观点,这意味着打破我们的产品泡沫并与公司的其他团队交谈。

User Feedback


我们的任何产品构思和头脑风暴会议的主要输入来源是用户反馈。我们是Slack的大用户,我们利用一些关键的集成来确保我们能够控制用户的脉搏。用户反馈通过3种主要方式与团队沟通:

  • A dedicated channel named #productfeedback for any ideas and feedback from within the company. Dogfooding wherever possible is crucial.
  • A channel integrated with our CRM that pipes in meeting notes from our sales team. This ensures that we're staying on top of what our customers are asking for, what problems we're not adequately solving, and what new opportunities might exist in the future. Trend spotting is the name of the game here.
  • Intercom has been invaluable to ensuring customer satisfaction and we also have a dedicated channel for all customer conversations. To help with the analyzing a large volume of conversations, our customer success team will make note of anything product related that comes up from multiple people so we can quickly identify trends.

这导致了比我们可能在短期内执行的更多功能想法和产品改进。通常也有一些想法表明虽然重要但不一定与当时企业的主要目标一致。在创业公司工作的一个有趣的部分是,总是火灾燃烧,诀窍是知道哪些要打,哪些要烧。

Prioritization


此时,我们通常会列出在接下来的几周或几个月内执行的潜在功能列表。现在是制定产品路线图并确定将要运送什么以及何时运送的有趣部分。我是Intercom在博客文章中描述的RICE模型的忠实粉丝here
。我们通常通过4个主要标准来查看功能和优先级:

  • Reach : how many users is this work going to impact. This prevents us from working on projects that are "cool", but aren't meaningful to significant portion of our customers. Larger reach = higher score.
  • Impact : how much impact will this work have on each user that encounters it? More impact = higher score.
  • Confidence : how confident are we that this work is going to improve the metric we're targeting? Is this more of an investigative feature or a known shortcoming of the existing product? Higher confidence = higher score.
  • Effort : how much work is this going to take? This isn't just in terms of engineering resources, but marketing, sales, design, and operations as well. Lower effort = higher score.

无论您是否列出并计算每个功能的确切分数都取决于您的团队,但是,应该就每个因素的相对大小达成一致意见,以便团队中的每个人都能明白这一点。通过这个练习,我们的功能通常属于四个桶中的一个:

  • High value, low effort. These are the no-brainers that your team has to do.
  • High value, high effort. These are bigger bets and usually very few of these get executed within a quarterly scope. This one usually comes down to confidence of outcomes and the process of prioritizing these features usually spurs further user research and market analysis.
  • Low value, low effort. These are the "junk food" of product work. They make the team feel accomplished by moving another task into the "done" bucket, but they aren't really impacting the business. Stay away from these.
  • Low value, high effort. This is the stuff that sinks companies. Needless to say, don't venture into this area.

Execution


此时我们已经:

  • Identified the top level objectives for the company
  • Determined how the product team can contribute most effectively
  • Identified the feature work that contributes towards our goals
  • Prioritized features by reach, impact, confidence, and effort to ensure we're operating with as much leverage as possible

现在是时候执行了。如果我们无法发货,那么我们在这一点上所做的一切都不重要,但首先我们需要弄清楚我们将要发送给用户的确切内容。


投入功能规格的工作量取决于所涉及的更改范围。它可以从附带的JIRA卡上经过深思熟虑的描述到具有附带技术规范的多页产品规格。


我们通常在确定特征的优先级时做了一些高级别的范围,我们在这个阶段的目标是识别在运送给定特征时必须存在的功能,以便测试给定的假设。我们的团队利用Google文档编写功能规范,以便于访问和协作。特征规范不是一些宏观且精细的逐像素描述,并且通常不超过6页。


在编写功能规范时,我们的目标是解决以下问题:

  • Background and context: is there anything that will help the reader better understand what's going on here? For us this is typically an explanation of a particular industry specific phenomena.
  • Problem statement: what problem are we trying to solve and why is it important?
  • Proposed solution: how are we going to solve this and why do we think this is a viable solution?
  • Risks and unknowns: we're always making decisions with incomplete information. It's important the known unknowns are shared with the team so we can attempt to minimize them and acknowledge them.
  • Success criteria: how do we know if we got it right? How do we know when we need to move on and try something new?

新功能规格不仅与产品团队共享,而且与整个公司共享。这使每个人都有机会评论和讨论该功能,以确保我们充分利用公司的全部脑力。有些时候,产品团队的功能范围不能完全解决客户成功或销售遇到的问题,这使我们现在可以识别这些更改,而不是在我们已经构建完成后。


现在我们进入设计过程,这可能是整个博客文章本身。我们利用模式库,使我们的设计团队能够保持一致的设计语言,并以极快的速度组合模型。第一轮模型准备就绪后,将与产品和工程团队的其他成员共享第一轮评论。我们利用Invision
在RigUp并发现它非常有助于促进功能设计的对话。在此过程中通常会出现的事情是:

  • Does the functionality exist to solve the problem as described in the spec? Have key aspects of the proposed solution been translated to the user interface?
  • Usability. Are users going to be able to find the feature when they need it and figure out how to use it. Our users span a wide range of computer know-how so it's paramount things are as intuitive as possible.
  • Is everything in the UI technically viable? Where is the data being displayed coming from, what exactly happens when a user performs an action, etc? This is where having engineering involved in the design process is critical.

一旦我们认为设计处于良好的位置,我们就会与公司其他人分享这些设计以征求意见。这对于确保可用性是我们需要的地方特别有用。很容易深入到功能,一切都显而易见。你对自己说"你当然想要做X,你只需点击这里的按钮"。真正的考验是当一组新眼睛审查设计时。他们马上"搞定"吗?如何完成特定任务会有困惑吗?在收集了每个人的反馈意见后,我们通常会在设计中再获得一次通过。


到目前为止,工程团队已经非常积极地参与其中,因此从设计到工程的交接通常是非常无缝的。一旦工程师觉得他们有足够的背景和定义来开始攻击解决方案,我们就会参加比赛。我们让工程经理和工程师以任何最适合他们工作方式的方式分配任务。状态更新每天早上在工程冗余通道中共享,这样团队就可以确保一切正常,并识别任何潜在的阻止程序。


每周我们都会召开一次产品和工程团队会议,我们将聚集在一起讨论项目进展,演示新功能和基础架构变更,以及沟通任何重要的公司新闻或事件。我们还每周在产品导向深潜和技术工程深潜之间进行交替。在每次会议中,我们将讨论即将开展的项目,回顾以及指标和KPI的进展。


我们的开发和部署过程(再次)是一个完整的博客文章,但我将在这里讨论几个关键点。我们利用CI / CD服务进行自动化测试,并在工程师将代码推送到托管存储库时启动。所有代码更改都在新分支上完成并提交以进行代码审查(我们使用Bitbucket
主办和审查)。一旦更改得到审核和批准,并且已经成功构建了该分支,我们就会将其合并到主分支中。任何时候代码合并到掌握这将自动启动将运行所有测试的构建过程,并且如果成功将代码部署到临时应用程序。此临时应用程序允许我们在部署到生产应用程序之前验证生产环境中的更改并在内部进一步测试功能。


一旦功能在内部经过测试和验证,我们就会发送它并开始学习过程。我们通常每天都会对生产应用程序部署更改,我们的CI / CD流程可帮助我们快速发布,同时保持质量和平台的完整性。好的我们发了一个功能,现在是什么?

Keeping Score


我们不仅仅是为它构建功能和编写代码,我们还在努力改善能源行业。要做到这一点,您必须记住您的更改是否按预期方式移动了指标。


我们得到0分只是让一个功能出门...


在我最喜欢的一个blog posts
Slack的首席执行官斯图尔特·巴特菲尔德(Stewart Butterfield)表示,"如果实际上没有为用户提供更好的体验,我们只能获得0分。"如果您没有衡量所发布功能的影响并向用户学习,那么您作为一个产品团队就已经死在了水中。


我学到的一件事就是保持得分往往比表面看起来更棘手,这是我们一直在努力改进的东西。我们倾向于通过高级指标和特定功能指标来衡量功能。这使我们能够快速查看某个功能是否以有意义的方式影响了业务,如果没有,则是功能级别的故障,或者我们对该功能对业务的预期影响是否错误。


为了回答这些问题,我们从3个主要来源获取数据:

  • The database. We make heavy use of SQL queries against a follower database to answer questions around feature adoption and results.
  • Heap and Mixpanel. At the time our team is currently utilizing both. We've been utilizing Heap for a while and love that we can ship something it'll start collecting data before we even know what we want to analyze. We started using Mixpanel recently because it can track across web, iOS, and Android whereas Heap (at least as of now) only covers web and iOS.
  • Mandrill. This is what we use for email and we've written some scripts that make use of their API to pull in data for how emails are performing. Specifically how many times it was sent, the open rate, and the click through rate. We use this to A/B test subject lines and copy where needed.

有些事情很容易衡量并归因于产品变更,例如:在发出建议更改之后,邀请和推荐是否会增加?查看部署之前和之后的计数,您可以快速找出答案。其他人可能会像某个特定队列的注册人数一样混乱。营销是否正在运行一个可能影响到此的广告系列?销售团队是否推出了新战略?这就是为什么清楚地定义你将如何衡量某些东西以及数据的真实来源是非常重要的原因。


建立一套一致的指标和KPI并对其进行报告有助于我们的团队保持诚实。在构建一些东西时,对自己撒谎是非常容易的,你对自己说"我们在这个季度推出了很多很酷的功能,我们已经取得了很大的成就",即使这些功能都没有移动,也会感觉很棒。这是我必须要努力学习的东西,我们不断改进我们如何对自己正在做的工作负责。

Putting It All Together


虽然所有这些听起来都是一个非常线性和一步一步的过程,但实际上更多的是流动和连续的过程。回顾会促进另一轮改进,从而带来更多的设计和工程工作。随着我们了解有关用户和市场的更多信息,功能会在优先级队列中上下移动。我们是一支精干的团队,能源行业是一个很大的空间,需要解决很多问题。最大的挑战之一是确保我们对所有好的想法都说不,这样我们才能追求伟大的想法。


PS您是一名软件工程师,设计师或产品经理,对如何帮助将能源行业带入21世纪感兴趣吗?我们正在招聘!Learn more and apply here
.

查看英文原文

查看更多文章


公众号:银河系1号


联系邮箱:public@space-explore.com


(未经同意,请勿转载)