营销
我们是设计师和开发人员。我们想设计和开发软件。在我们能做这些之前，我们需要找到雇佣我们的客户。以下部分介绍了我们的营销流程如何运作，以及一些常见客户问题的答案。
总体流程是：
- 某人联系我们。
- 我们请他们填写我们的新项目表单。
- 我们打电话或者约他们来办公室。
- 合格／不合格：我们适合客户吗？
- 合格／不合格：客户适合我们吗？
- 理解客户的愿景。
- 对预计的产出达成一致。
- 预估迭代。
- 为迭代安排人手。
- 签订合同。
- 付第一个迭代的款项。
- 我们开始工作。
线索
我们的线索通常来自客户的推荐和 Google 搜索。
我们在「Sales」看板的「Contacted」列表记录所有的线索。
我们为个人介绍的项目手工建立卡片。我们的新项目表单会自动创建卡片。Zapier 会为我们从主要电话线中收到的电话留言创建卡片。
通常进来的线索会指派给管理总监，不过每个人都可以负责这个线索，通常负责的人会发一个简短的邮件或者打电话给潜在客户，来看双方合适不合适。在做这个之前，他们要把自己加到对应的 Trello 卡片上。
我们一般会结伴来打这个电话，一个设计师和一个开发人员一起打电话。这样让我们可以从不同角度知道这个项目有多适合或者多不适合我们，可以尽可能好地回答设计和开发问题，并且帮助我们培训和改善我们的营销流程。
理解产品愿景
我们的目标是在我们正式开始项目前群体思考客户的产品。一些典型的问题是：
- 这个产品的独特之处是？
- 这个产品带来什么好处？
- 这个产品解决什么痛点？
- 谁当前在购买这种产品？
- 你希望谁来买这个产品？
- 顾客会喜欢你产品的哪方面？
我们在团队全员参与营销流程。潜在客户应该有机会和他们将要一起工作的人交谈。对于要开始的项目，我们应该在管理总监不能及时响应的时候也可以应付得来。
我们使用内部工具来管理我们的日程表和可用性。我们不记录时间，不过我们确实做每周的增进计划。
保密协议
如果客户让我们签订保密协议，我们会这样回应：
我们可以不签保密协议先聊聊？我们已经为数以百计的客户服务过。每年我们都和数以百计的客户接触。我们不可避免地会听到相似的创意。
如果保密协议对于客户来说是非常重要的，我们让他们充分解释下业务，确保这和我们现有的或者过去的客户不冲突。如果我们没发现冲突，项目又很合适，而且保密协议是双向的，我们就签署。如果不是双向的，我们就使用我们的保密协议。
角色
我们提供一个由设计师、Ruby 开发以及 iOS 开发人员组成的团队。并分配一个顾问来辅助团队，他每周在团队工作几个小时。每个人都是 T 型人才，在某个领域有专长，并能够跨越职业和他人协作。
我们是人而不是「资源」，避免这么称呼彼此，因为我们知道我们是人与人之间的合作。
设计师设计用户和产品之间的交互。他们写用户界面代码。
开发人员让应用可以工作。他们写代码让应用变得「智能」。他们致力于让产品没有缺陷。他们监控性能因为速度是所有产品的一个共有特性。
开发人员让产品可以运行。他们做架构决策，并和现代化的主机公司例如 Heroku打交道，他们的员工数量是我们外包的运营团队的两倍。
开发人员实现功能。他们编写和维护 HTML、CSS、JavaScript、Ruby、SQL 以及其他代码。他们设置并达到开发规范，保持持续集成构建通过，并评审彼此的代码。
顾问提供一个公正的角度。他们进行每周会议保证周到周的持续沟通。他们对项目的高层次的目标保持关注，这对他们来说更容易一些，因为他们不必每天身处细节之中。他们在和团队同甘共苦，并在项目失控时帮助解决问题。
在合适的时候，他们和客户沟通来增加或者减少人手来正确地处理项目。
顾问不是项目经理。其他的成员不用向他报告。顾问也不是技术或者设计的负责人。顾问不必是管理总监或者 CXO，但是因为时间的灵活性通常是他们担任。在 thoughtbot 任何人都可以顾问一个项目。如果主要销售人员不是顾问，那么应该平滑交接一下。
虽然每个人都有自己的角色，团队必须要称为团队。
每个人都有责任每天提交高质量的工作，忠诚于产品的愿景，沟通他们的计划和安排，做出艰难的决定，如果时间和能力有限无法完成任务时要及时移交工作，保持团队士气高涨，坚持不懈。
不做固定预算竞标
有的咨询项目是以一份需求文档或者招标书（Request For Proposal, RFP）开始的。需求文档常常十分详细。
但是这份文档能够包含最理想的功能集合的概率是极低的。最佳的功能集合是在用户访谈，原型制作，交付实际代码以及从真实用户处得到反馈过程中获取的。
基于这份文档，客户常常会期待咨询公司提供一个精确的时间范围和报价。这种合同风格注定了从第一天开始客户和咨询公司之间就是互相对立的。他们不是关注设计产品，或者评估哪些假设是错误的，而是在纠缠文档中很久以前写下的一句话究竟是什么意思，或者是一些随意制定的截止日期。有时候这比谈判更糟糕，因为大家各自有不同的印象，为了追根溯源争论不休。
所以你可以想象的到，我们不做固定报价的投标，固定功能集合的提案。
预算
我们需要知道客户的预算。客户通常是不愿意提及他们的预算的，不过预算有助于确定可以做多少工作。可以节省时间。如果他们不知道自己的预算，我们考虑其他方式。
我们将产品面世分为不同的阶段，在产品的每个阶段我们做如下的工作来提高成功的机会：
- 集中在一个小的功能子集上。
- 设计有价值的用户体验。
- 和用户之间建立有价值的关系。
- 为市场活动做预算，让用户了解产品。
- 为产品设计交互，让用户引导更多的用户来使用产品。
费用
我们按照每个人每周来收费。我们每周为客户工作四天。我们对于设计师和开发人员收取同样的费用。每周需要完成的工作会指明需要哪些技能。需要的人数就决定了费用以及每周能完成的工作。
在解释我们的收费模式的时候，有时候我们会告诉我们的潜在客户「时间和物料」和他们招聘一个年度员工是基本一样的，只不过对他们来说风险更小，因为：
- 我们的团队更有经验。我们可能面试了上千人来找出现在这样一群有天分的成员来一起工作。
- 我们一起做过很多项目。我们有熟悉的合作方式。
- 短期项目需要的费用更少。
- 我们的时间可以预计（4 天／星期）并且保持不变。
- 如果有人生病、离职或者有新队员就绪，我们可以快速调整人员。
我们不会提供详细的发票条目。客户通过项目管理工具（Trello)、聊天室（Slack）、版本控制系统（GitHub）以及持续的沟通，总能及时了解项目的进展。
典型项目
我们的典型项目：
- 产品设计 Sprint，两个人，一星期
- 「零到第一个版本」，两个人，四个星期
- 「填补内部成员空缺，直到招到合适的人」，2 个人，3 个月。
- 「现有内部团队的人力资源扩充」，3 个人，6 个月。
- 「维护团队」，按月付费模式。
很多时候我们的客户预算就到做「第一版」。他们随后进行一轮 beta 版邀请，花时间进行市场推广，再融一轮资金，或者做几个月的营收。他们再次回来做下一轮的设计和开发，这时他们对于产品要往什么方向走有更清晰的认识。
从功能集合并不一定能够推导出开发它所需要的时间。有时候一个简单的产品，我们需要迭代非常多次。我们喜欢和这样的客户合作，他们懂得伟大的产品需要足够的时间来打磨。
作为回报，我们知道我们绝不可以滥用客户对我们的信任。我们应该竭尽全力让我们的时间产生最大的价值。诸如「Research」看板，「Code」内部聊天室，以及共享的 dotfiles，确保问题出现时，我们已有一套最高水准的工具和技巧。
合同
我们用 Dropbox 存储合同，目录分为待定、进行中、老客户、流失客户。
咨询提案和合同包含 ：
- 一页纸的预定工作概述
- 我们的每周费率
- Net 15 支付条款
- 预付前两周费用才开始工作
- 两周之后，每周工作结束后，周六早上本周的发票就会发出去
- 双方约定当客户支付了本周费用之后他们就拥有本周工作的源代码
- 双方约定彼此都不使用侵权的材料
- 双方约定都不想 web 主机提供商提交滥用或者不道德的内容
- 双方约定合同是双向自由的，任一方可以在一周结束后决定停止合作
- 一个签字页
发票
我们使用 Harvest 在每周结束后给客户发送发票。
它可以自动发送周期性发票，这样我们就不会在一周结束时忘记收费。它可以自动发送迟付费通知，这样就可以避免一些关于账单的尴尬对话。
客户可以通过支票或者转账付费。
在 Harvest 的项目信息中，我们会登记谁应该在这个项目中收到佣金。我们常常给参与营销阶段的两三个人分 5% 的佣金。