Whenever I am asked, “What is your biggest take-away in your journey to becoming a product manager?”, I am now able to answer, “make sure you wrap your teams’ conversation around The Trio of Product Management”, or “产品管理的三驾马车” in Chinese. The Trio are, user value, business logic and engineering viability. This blog post outlined my journey and discovery on The Trio of Product Management, how use them to drive your product teams’ collaboration, and answer the many ‘why’ that follow.

The Journey

Everything I did on product management started in 2009 when I worked on my 1st product, a receipt printer with a web API.

Initially, I tried to approach product management like software engineering. I tried to adopt the Agile Methodology in managing team work, which worked well only for our software team. We’ve been struggling to get sales via online marketing and only by chance we figured out a sizable deal with Danone Waters in (Guangzhou) China, our 1st big corp client. We were then able to iterate our product and scale our sales with this client alone. By then, I realized that there is a bigger cycle above the Agile workflows within the software team, user value identification, and how to drive the product to offer such identified user value.

It’s not easy for a small team (7 people) to run sales with big corporate clients. We spent almost a year from start to finish, and get paid, by delivering product and service to our 1st corporation client. Our financial was in a dire mode as a result because of the lengthy sales cycle with big corp. This prompted me to think, “Where did we go wrong?”

It’s the business logic part in iterating a product. In our case, it was the sales channels, our market funnel (which was too small), and the pricing. We didn’t have a sales VP. CEO and I were both engineering minded folks who believed that we were able to become good sales. But we were not. We were just trying our luck in whatever resources at our disposal at the time.

Since we started out as a team of software and hardware engineers on a for-developer product, evaluating engineering viability had never been an issue, until we realized that we could have spent way too much resources in perfecting product edges or features that didn’t matter the most. This alone could have contributed to delayed releases and pro-longed time-to-market cycles.

Fast forward to late 2012, we met Wilson Wang, who owns and runs ifanr.com, a tech media covering China’s consumer trends on tech products. He came up with a new idea, a vending machine that allows mobile phone (WeChat) users to instantly print a photo from their phone. Then we decided to join force to build a startup around this idea. By the time we started this product as our main business, I, as a product manager, was able to empathize with user value, business logic, and engineering, The Trio of Product Management. I called myself Jack-of-All-Trade in my teams, and was able to put together team reporting routine that help all functions to empathize each other’s work. I was able to offer founders/top leadership the whole picture of a product and the service delivery to clients, and how to manage the iterative design, development, and delivery of the product’s value to our customers and end-users.

It so happened that I came across Andrew Chen and his essays on product management and startup growth (hacking). I felt great resonance with Andrew’s insights on managing growth, product, and were able to look at entire product cycle from the highest level possible.

The Practice

Let’s assume that your product company have 3 teams, sales or user growth, product and engineering (software development). To effectively drive your teams’ daily conversations, which in turn drives your teams to make great products, make sure your agenda in the all-hands meetings are structured around The Trio of Product Management.

In EACH and EVERY all-hands meeting, you shall encourage your 3 teams to share their perspectives, around The Trio,

User Value, Business imperative/logic and Engineering Viability.

Here is how the magic happens. Your sales or user growth managers are typically good at capturing the latest on user value that your next version could offer. Your CEO or product director/manager may be able to elaborate on all of the The Trio. Your engineering lead can elaborate on the engineering viability or tech solution on design or requirements in question. Make sure all of them are listening in over what others think or say, and drive all members to empathize one another.

As face-to-face meeting is increasingly expensive nowadays, if your agenda are not urgent or has lower priority, you could share it via Slack and wiki, so that all your teams can finish the empathy exercise over the design/topics. Most important of all, make sure all members leave their comments or thoughts on the same wiki page.

Overtime, or during the typical cycle of your product’s iteration period, say every 3 months, honoring The Trio while communicating product plans among your 3 teams is absolute key to drive your team to make your NEXT BIG THING happen.

The Playbook (The SCRUM How-to)

To integrate The Trio into your teams’ day-to-day product work, it’s key to have a Playbook that guides them on the how-to. Since each team operates in different corporate context, here I only outline the general thoughts and steps.

SCRUM is probably the most practical Agile framework, and it’s the one I’m promoting among teams at ifanr.com. I took below steps to get them started with SCRUM,

1. Identify key business domains towards which I can apply SCRUM and The Trio, for example, corporate clients project(s) that have been lasting at least for 1 year and repeating.
2. Identify key members, PO (Product Owner), SM (Scrum Master, myself in ifanr.com’s case), and Dev Team (all members involved in actually building the products for customers).
3. Get to know each and every key member and her expertise domain, personal traits, and current job roles.
4. Identify the over-lapping areas for growth shared by both the company and a given member, to ensure enough personal buy-in over the SCRUM practices I’d like her to adopt.
5. Get things rolling. Act, observe, adjust my action, observe…keep adjusting.

I started practicing Chinese Martial Arts (or Chinese Kong Fu) as a kid. One can never become a Kong Fu master without enough practicing. It’s not just the Muscle Memory, it’s about connecting your action, results and output, with your learning on all above.

Wish you a great time in learning and practicing The Trio of Product Management.

产品管理的「三驾马车」

本文改写自 The Trio of Product Management。

每当有人问我：「在你成长为产品经理的过程中，最大的收获是什么？」

我的回答是：「我学会了用产品管理的「三驾马车」框架驱动产品开发」。

产品管理的「三驾马车」是指：用户价值、业务逻辑、工程可行性，这高度概况我对产品管理的根本认知，并作为我讨论产品管理中许多「为什么」的起点。

旅程

我的产品管理职业生涯的一切都始于2009年。当时，我开始做我的第一个产品：一款带有开放接口/ API 的小票打印机的联网产品。

起初，我试图用软件工程方法论来管理产品。我试着采用「敏捷方法论」来管理产品和团队的工作，但是，结果证明这只对我们的软件团队有效。我们当时曾一度努力通过网络营销获得销售订单，直到一次偶然的机会，我们与达能中国水事业部（广州）谈下一笔可观的订单，达能成为我们的第一个大客户。于是，我们借助此客户实现产品的迭代和销售的规模化。当时我意识到，在软件工程团队内部的敏捷工作流之上，还存在一个更大的闭环：识别用户价值并推动产品版本迭代以帮助用户实现他们所需要的价值。

当时我们的7人小团队要紧跟大企业客户跑销售，着实不容易。我们花了将近一年的时间，从开始谈到结束订单结款，才算完成一个企业客户订单的交付并完成配套服务。由于大企业客户的销售周期过长，我们的财务状况也因此陷入了困境。这促使我不断思考，「我们哪里出了问题？」

问题出在我们的产品迭代所隐含的「业务逻辑」。在这个亲历的案例中，这个业务逻辑是我们的销售渠道、销售漏斗（太小）和定价规则。我们当时也没有所谓的「销售副总裁」。CEO 和我都是工程思维的技术人，我们自信能通过努力和不断学习把自己变成合格的销售。但我们的确不适合做销售。事实是，我们当时只是在利用手头的一切资源在市场上不断碰我们的运气。

因为我们一开始就是软件和硬件工程师组成的产品团队，所以对于评估任何设计和产品功能的工程可行性，从来都不是问题。但这个认知因为缺乏和用户价值、市场定位的脱节，导致我们花了过多的资源完善产品，尤其是打磨一些不重要的功能和细节之上。这种认知偏差本身，就是我们产品周期和发布工期过长的根本原因。

快进到2012年年底，我们遇到 Wilson，爱范儿的老板，一家报道中国消费科技产品和趋势的科技媒体。Wilson 提出了一个新的产品想法：一个可以让手机（微信）用户即时打印手机照片的自动售货机。于是我们决定组建一家初创公司来实现这个想法。此时，当我们这个产品作为主营业务的时候，作为产品经理我已意识到团队的沟通必须围绕用户价值、商业逻辑、工程可行性这「三驾马车」。在团队面前，我自称「万金油」工程师，能够结合团队情况梳理出合适的汇报套路，帮助所有职能团队同感彼此的工作和思维方式。同时，我也能够为创始人/公司高层总结产品迭代的整体进度、并推动工程团队持续发布和交付，最终持续交付用户价值。

也正是这个期间，我开始阅读 Andrew Chen 关于产品管理和「增长黑客」系列博文。我对Andrew在用户增长、产品迭代等方面的话题很有共鸣，并最终帮助我们构建产品管理和团队沟通的基本框架。

实践

为简化讨论，我们假设您的产品公司有3个团队：销售或用户增长、产品管理和软件工程（软件开发）。

为了有效推动 3 个团队之间的日常沟通，推动团队做出优秀的产品，我们需要确保 3 个团队能围绕产品管理的「三驾马车」展开：

用户价值、业务逻辑、工程可行性

任何新版本、产品计划，都需要鼓励三个团队的负责人充分反馈自己的评审结果和观点，并促成新设计和版本规划最终共识的达成。

随着产品的持续迭代，神奇的事情会逐步发生。

那是因为：你的销售或用户增长经理更擅长捕捉最新的用户价值，你的 CEO或产品总监/经理则必须充分把握关于某个新版本的「三驾马车」，你的软件工程负责人/ CTO 则擅长分析新版本的工程可行性和技术方案。大家各司其职、充分融合不同角色的专长，并加入当前资源限制条件等因素，确保团队的共识和决定是平衡的。围绕「三驾马车」，不同团队的负责人都能同感其它团队的上下文、现状和对未来的看法，并带动所有人主动同感彼此。

如今，组织面对面的全员会议越来越昂贵。如果你的产品新版/新计划的沟通不紧急或者优先级较低，你也可以通过 Slack 或 wiki 分享某个新版本的看法，这样，所有团队都能够围绕新版本和新设计彼此同感。最重要的是，确保所有成员在新设计的同一个wiki页面留下他们的评论或想法。

在产品迭代周期内，例如 3 个月一次，推动团队全员围绕「三驾马车」形成沟通习惯，将帮助我们更有效、更快地构建和发布产品。

The Playbook（产品管理How-to）

要想将产品管理的三驾马车思想融合到团队的日常产品开发工作中，关键是要有一本属于他们的 Playbook，以便统一团队思想和行动并持续实践。

由于每个团队都处于不同的企业背景，这里我只概述一下大致的思路和步骤。SCRUM 可能是最实用的敏捷框架，也是我在 ifanr.com 团队中推广的敏捷框架。我使用以下步骤让团队开始使用SCRUM，

1. 确定我可以应用 SCRUM 和「三驾马车」思想的关键业务领域，例如，企业客户的项目，这些项目已经持续了至少一年，并且在重复进行；
2. 确定关键成员，PO（产品所有者），SM（Scrum Master，在 ifanr.com 的案例中就是我自己），以及 Dev Team（所有参与为客户实际构建产品的成员）；了解每一个关键成员和她的专业领域、个人特质和当前的工作角色；
3. 了解和识别公司和某位成员共同成长的重叠领域，以确保个人对我希望她采用的 SCRUM 实践有足够的认同；
4. 把事情做起来并持之以恒：行动，观察，调整行动，再继续观察……不断调整行动。

我从小就练习中国武术（或中国功夫）。没有足够的练习，永远不可能成为一个功夫高手。这不仅仅是肌肉记忆的问题，更要把你的动作、结果和输出关联到你所相信的「武道」。

产品管理也一样。

祝愿你和团队在共同实践产品管理的「三驾马车」中取得丰硕的回报！