总结一下抢票和红包项目Wrapping Up the Ticket-Grabbing and Red Packet Projects
红包和抢票项目分别是什么这里就暂且不表了，反正这个博客没人看，也没人在意我到底写了什么。说起来抢票项目一路执行下来，确实一地的鸡毛，最终的数据效果也欠佳。红包项目虽然目前还没有看到数据，但是单凭用户的热情我也知道数据效果大概会是怎么样所以我就先过来总结一下，反思一下哪些是问题，怎么优化；哪些是长处，怎么发扬—我真特么是个罗里吧嗦的人
—这次在抢票和红包项目里主要学习到的有三个方面
- 项目管理能力；不得不说，如果没有这两个项目的锻炼，我连自己项目管理水平是高是低都不知道，逞论发现问题了。这里主要说的是项目进度和风险的把控
- 部门沟通能力；我并不擅长言辞，这里说的是跨部门沟通的流程和方法
- 运营和资源和市场，这些产品后期的工作：很长一段时间以来，我都只需要想好怎么做产品，怎么把控产品的用户体验。其实对于这两个项目来说，产品的传播和体验一样重要。对于非工具类产品而言，运营和前两者，也同样极为重要
—说在前面：任何项目开始之前，一定要对项目有充分的了解和思考，如果项目时间紧张，无法进行充分的思考，那么至少要对项目的目标以及项目本身有足够的了解。如果是一个功能需求的项目，在充分明确项目目标的情况下，最低要求是了解用户的痛点何在(包括真实的用户和老板)，了解用户痛点的基本解决方法如果连这个都做不到，那至少多使用竞品，充分把握竞品的功能和逻辑。总之，了解的越多，站得才越高，看得才越远。项目管理部门沟通，都是对产品成功的辅助。项目或者产品想要顺利的进行，最重要的还是对需求本身的把握，由于和本文主题关系不大，这一点暂不展开。先说项目管理弄明白目标
请一定一定搞清楚，这个项目的目标是什么。老板可能会告诉你一个大而抽象的目标，比如用这个拉新拉活(特么做啥功能都可以说是拉新拉活啊！)，或者告诉你用这个功能蹭热点(这意思就是这波蹭上了就算，其实说到底还是拉新拉活)。这个时候你需要自己拆解老板的目标。这个过程其实是公司和用户两个方向进行重合的过程。大部分产品经理可能工作久了会比较偏向业务化，会以KPI为导向，做产品就会偏向简单粗暴，这个时候的产品经理，就忽略了公司和用户两个需求方向的重合。其实大部分产品经理在还不是产品经理的时候反而能想明白：
一个用户产品经理，最终是为用户服务的。这个用户包含老板，更包含真正的C端用户。
上面那一句自己是一段是因为我觉得很重要。好了回到正题，请务必在立项之前弄明白老板的目标是什么，结合你的产品细化到数据指标上是什么；务必弄明白用户的需求是什么，用户最大的痛点是什么，用户不care的点是什么。想清楚这两个问题会直接影响到你的产品形态和子项目优先级的排列和时间的分配，而这两点是决定项目成败的关键。
老板说要赚钱，所以你就拼命插广告，这样是罔顾用户的需求；老板说要赚钱，你誓死不从，这是罔顾老板的需求。两个后果都很严重。
—我觉得我这么罗里吧嗦的写很可能会烂尾，我就简单总结一下我遇到了哪些坑立项
- 对项目有充分的了解确实非常重要，我说的充分包括但不限于对需求的了解，对实现方式和业务流程的了解，对竞品的实现方式和产品逻辑的了解。了解真的很重要，深入的了解会帮助你把项目把握的更清晰更透彻。请务必抛弃一边做一遍了解的想法，这样做给你带来的麻烦不仅仅未来有可能打乱产品进度，还有可能直接导致开发和测试的重复工作量，给自己挖坑没商量。
- 思考到什么程度，可以说思考的全面了？我觉得主要是1，项目目标的达成方式 2，产品的基本形态以及实现 3，基本推广和传播模型 这三个问题想明白了，就可以立项了
- 如果你的项目涉及到部门合作(这真他妈是个大坑)，那就要分两类来说了。如果外部合作只是你项目的一部分，那么请准备好Plan B，做好外部合作GG的准备。如果外部合作是你项目的重要组成部分，或者你的这个项目就是为了配合这个外部合作而生(比如引入其他产品的一个能力)，那么请做好当一个项目经理而不是产品经理的准备。另外，老板们谈合作的时候请一定不要被黄色笑话吸引，会议纪要请一定事无巨细的全部记下来。
- 补充说一下第二点里提到的产品的基本形态以及实现
What exactly the red packet project and the ticket-grabbing project are, I’ll leave aside for now; nobody reads this blog anyway, and nobody cares what I actually write. Truth be told, the ticket-grabbing project was one long trail of feathers on the floor from start to finish, and the final numbers were underwhelming. As for the red packet project, I haven’t seen the data yet, but from user enthusiasm alone I can already guess roughly how the numbers will turn out, so I’m coming over first to sum things up: reflect on what the problems were and how to optimize, and what the strengths were and how to build on them—I really am one damn rambling person
—This time around, the ticket-grabbing and red packet projects mainly taught me things in three areas
- Project management; I have to admit, without the workout these two projects gave me, I wouldn’t even know whether my project management skills were good or bad, let alone spot the problems. What I mean here is mainly keeping a grip on project schedule and risk
- Interdepartmental communication; I am not gifted with words, and what I mean here is the process and method of communicating across departments
- Operations, resources, and marketing, the late-stage work of a product: for a long time, all I ever had to think about was how to build the product and how to keep its user experience under control. In truth, for these two projects, how the product spread mattered as much as how it felt to use. And for non-utility products, operations matters every bit as enormously as the other two
—Up front: before any project begins, you absolutely must understand it and think it through fully. If the timeline is tight and full deliberation is impossible, then at the very least understand the project’s goal and the project itself well enough. If it is a feature-request project, then with the goal made fully clear, the bare minimum is to understand where the users’ pain points lie (that includes both the real users and the boss) and the basic ways those pain points get solved. If even that is out of reach, then at least spend plenty of time in competing products and get a firm grasp of their features and logic. In short, the more you understand, the higher you stand and the farther you see. Project management and interdepartmental communication are only aids to a product’s success. For a project or a product to run smoothly, what matters most is still your grasp of the requirement itself; since that strays from this post’s topic, I won’t expand on it for now. First, project management. Figure out the goal
Please, please get clear on what this project’s goal is. The boss may hand you a big, abstract goal, say, use this to pull in new users and boost activity (damn it, any feature whatsoever can be described as pulling in new users and boosting activity!), or tell you to ride a trending moment with this feature (meaning that catching this wave is the whole point, though at bottom it is still about new users and activity). At that point you need to break the boss’s goal down yourself. This process is really one of bringing two directions, the company’s and the users’, into overlap. Most product managers, after long enough on the job, drift toward the business side, steer by KPIs, and start building products in a crude, blunt way; a product manager in that state has lost sight of the overlap between the company’s needs and the users’. The irony is that most product managers could see this clearly back when they were not yet product managers:
A consumer product manager ultimately serves the users. Those users include the boss, and even more so the real C-side users.
That line above gets a paragraph to itself because I think it matters. All right, back to the point: before the project is green-lit, make absolutely sure you understand what the boss’s goal is and, mapped onto your product, what data metrics it comes down to; make absolutely sure you understand what the users need, what their biggest pain point is, and which points they don’t care about. Thinking these two questions through will directly shape the form your product takes and how sub-projects are prioritized and time is allocated, and those two things are the keys that decide whether the project succeeds or fails.
The boss says make money, so you cram in ads for all you’re worth: that disregards the users’ needs. The boss says make money, and you refuse to your dying breath: that disregards the boss’s needs. Either way the consequences are grave.
—I suspect that writing at this rambling length I’ll very likely trail off unfinished, so let me just briefly sum up the pits I ran into. Green-lighting the project
- Fully understanding the project really is crucial, and by fully I mean including but not limited to understanding the requirement, understanding the implementation approach and the business flow, and understanding how competing products implement it and how their product logic works. Understanding truly matters; deep understanding helps you hold the project more clearly and thoroughly in your grip. Please abandon any thought of learning as you go along: the trouble it brings is not only that it may throw the product schedule into disarray down the line, it may also directly cause duplicated work for development and testing. It digs you a pit, no two ways about it.
- How much thinking counts as thinking it through? I’d say mainly 1. how the project’s goal will be achieved 2. the product’s basic form and its implementation 3. the basic model for promotion and spread once these three questions are clear, the project can be green-lit
- If your project involves cooperation with other departments (this one really is a goddamn huge pit), it splits into two cases. If the outside cooperation is only one part of your project, then have a Plan B ready and be prepared for the cooperation to go GG. If the outside cooperation is a major component of your project, or your project exists precisely to serve that cooperation (say, bringing in a capability from another product), then be prepared to work as a project manager rather than a product manager. Also, when the bosses are talking over the deal, do not, whatever you do, get drawn in by the dirty jokes; take the meeting minutes down in full, every last detail.
- A word more on the product’s basic form and implementation mentioned in point 2
Comments