从项目到产品化转型,从产品到运营和SaaS服务构建(201116)

标签: IT咨询 | 发表时间:2020-11-16 08:03 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi

今天谈下在进行产品规划的时候,从产品化到运营化方面转型的一些思考。

产品化和运营

对于大部分的软件企业来说,最希望实现的就是产品化,简单来说就是将自己开发的软件变成一种通用型的可以类似光盘快速零成本负责的产品,这种软件产品只需要少量的现场服务或支撑就能够方便客户快速的开始使用,类似微软的操作系统和Office办公软件。

对于企业应用服务市场,各个垂直业务领域往往个性化差异都很大,这也是导致产品化本身有相当大的难度,这对于核心业务价值链相关系统最难,相对来说对于OA,HR等支撑类应用,平台等中间件等相对容易。

类似可以看到的上市公司包括了做中间件的东方通,普元软件,宝蓝德,做工具类软件的福昕软件,这些都是相对来说比较容易实现产品化的软件。

还有就是广联达,这家做建筑软件信息化的公司很早就听说过,原来一直很奇怪为何能够支撑这么高的估值,因为对于这种做企业信息化的公司一般不会给出这么高的溢价。后面才发现这家公司卖一个标准化的工程造价软件,这个软件每年可以收大量的license和维护费用,只要是稍微大点的工程项目估计都用的这套软件。

这就是一个典型的软件产品化后带来的具体价值。

但是实际上也可以看到,真正做到如此产品化的相当少,更多的还是产品软件+实施的模式。这也就导致大部分软件公司其实很难挣钱。

一个软件产品要做到真正的产品化,首先需要底层的业务模型和技术模型更加复杂以满足各种个性化和差异化的扩展需求。在有了这个底层灵活模型后,还需要做到。

  • 业务可配置:能够通过前端界面灵活的进行各种配置,以满足差异化需求。
  • 接口可开放:所有接口开放,方便客户就能快速的进行二次开发定制。

产品,不是技术或能力的输出。技术和能力是属于你的,产品是属于用户的。--刘润

从项目到产品化转型,从产品到运营和SaaS服务构建

 

从项目到产品化的转型,核心仍然是构建公司的技术平台+产品平台,基于平台来开发和定制上层的客户差异化功能。做到80%左右的可复用即可。其次就是尽量做到一前一后统一和集中管理,包括了集中化进行方案设计,其次是所有项目集中化运维。

对于产品化的思考,不仅仅需要考虑技术和能力提供,这些技术和能力应该如何进行整合为用户提供有价值的输出,这种输出不应该是单一的,而应该是一个完整的解决方案包。

一个解决方案本身包括了咨询规划+产品+实施,以产品为核心,但是有围绕上下游进行展开,实现整个解决方案本身的可落地性。

对于咨询服务同样也是产品,需要的是对已有咨询经验进行总结和抽象,形成适合客户需求的方法论,知识库和模式库。

你可以观察下埃森哲的IT规划,完善的IT规划方法论,而且观察后发现对于电信运营商行业就形成了一套完整可复制的规范咨询方法,可以快速进行复制。

当前产品化思路不应该是传统固化单一产品的思路。

而应该是形成一个完整地覆盖了咨询规划,产品,实施各个维度的知识库,子产品库,只要这些基础库可复用,那么我们就很容易根据客户需求快速的去复用和集成已有能力。

而上面这个思路可以看到整合也是SOA架构的核心思想。

从产品化到运营

从项目到产品化转型,从产品到运营和SaaS服务构建

 

一个完整的产品不一定就可以运营,一个产品是否可以运营,还需要看这个产品本身是否具备足够的独立自治,能够将其能力以通用化的服务提供,如果满足这个产品才具备基本的可运营的能力。

产品要可运营必须对产品进行各种服务化改造,其中最重要的就是增加运营管理类能力,类似基本的产品,服务,订单,计费,运维等基础运营和运维监控能力。其次就是关键的多租户改造,以满足一套产品服务满足诸多企业用户的基本需求。

一个产品如果最终做到可运营,那么这个产品本身已经能够做到产品化和产品可配置化,而且这种产品化的要求往往比单独的私有云部署产品更加严格,由于是单套产品服务部署,因此产品的变更或升级将影响到所有的企业和用户,更加需要考虑产品本身的通用性和可配置化,建设各种个性化需求改造和配置。

当你是按照类似SaaS运营模式来规划产品的时候,那么往往就会放弃一些客户,包括客户的个性化差异需求。即经过可配置也无法解决的个性化差异需求,这些需求本身没有共性,那么你去支撑这些需求就没有意义。

产品化和可运营是大部分软件企业的产品规划和发展方向,但是真正要走到这步仍然很难,一个是本身做一个产品化的产品需要更多的研发投入和改造,另外一个就是企业本身没有大量前期实践积累,连要做一个产品化产品的业务和技术通用模型也无法抽象出来。

产品-运营-生态-模式

从项目到产品化转型,从产品到运营和SaaS服务构建

 

对于软件公司简单来说就是实现软件,软件是产品,也可以是服务,可以标准化,也可以根据客户进行定制,因此这就形成了各种产品的形态和推广模式。简单来说包括了:

  1. 纯粹的软件人力外包公司
  2. 软件项目型公司,按人天报价定制化软件,接客户项目,软件难产品化
  3. 产品化的公司,工具产品或重产品+轻实施
  4. 软件产品运营类的公司,即我们常说的SaaS软件即服务,将软件真正转变为服务运营
  5. 内容运营类的公司,构建一个软件平台,以内容运营为主,类似电商平台

对于第一种和第二种基本是人头的方式,第一种方式更加纯粹,而且没有太大的资源闲置压力,只是从软件公司来说从每个人头上获取差价,要扩大营收和盈利必须不断扩大公司人员规模。这种公司本身最大的风险就是人员流失,由于人员流动极大,因此人员管理和人员的招聘入职是关键,因此这类公司HR岗位就是很关键岗位。

大部分软件企业实际为第二种模式,项目型公司,本质还是堆人,只要是按人天报价,那么公司要大幅盈利就必须规模化发展,但是规模化后最大的风险仍然是人,万一业务缩减人员如何处理就是大问题,软件类公司看似轻资产运作,实际却是重资产,人员如何管,人员空闲如何处理?如何缩编都是大问题。

如果要给软件公司能够做到产品化,或者说60到70%部分能够做到产品化,那么日子相当来说好过,即报价模式变化了可以是产品+定制开发实施一起报价。在产品研发出来后的销售基本就是零成本,因此这种模式解决两个问题。一个是盈利能力增强了,能够分享产品规模化的收益;其次就是人员团队规模可控了,不会类似原来模式在拓展规模的时候要大幅地扩编人员。

那么产品化后公司的问题体现在哪里?

在产品化后你会发现实际上销售成本会上升,其次就是在竞争中产品价格会下降。一个软件产品只要产品化后,就不会让你一直能够卖高价。否则还不如完全找个团队进行定制开发。

第四种就是aaS软件运营类公司,但是我们实际看到最近几年SaaS类软件运营公司发展的并不是特别好,一个SaaS运营类软件需要研发团队,运营团队,销售团队,同时需要购买云数据中心资源,这些都是硬成本。一个软件变成SaaS模式后价格会进一步降低,因此必须用户到一定规模才能够进入到盈亏平衡点。

对于国内两大传统ERP厂商用友和金蝶,可以看到最近几年都在加速软件软件和实施朝云服务的转型,包括了金蝶云苍穹和用友NCCloud和用友数字化服务平台,各个领域云服务平台。从用友公布数据,19年实际云服务营收增长132%,20年也继续保持高速增长状态。

当前用友市值1500亿左右,是少数的几个市值上1000亿的软件企业。如果仅仅是做传统软件项目和实施定制很难支撑这个市值,但是云服务却带给市场足够的想象力。

但是很多SaaS类软件公司可以看到,很难真正跨过这个盈亏平衡点。

就拿在线协同和项目管理类软件来说,这几年好几十家都在做,最终存活到现在的已经不多,竞争很激烈,有些SaaS软件还是免费模式,因此收费价格不可能高,那么你要迈过盈亏平衡点对用户规模基数的要求就更高。

其次我们也可以看到,对于SaaS类软件,单纯地从提高效率角度很难真正大面积和推广,人们很多时候并不愿意在效率上面投资,而更多愿意在类似获利或降低成本上投资。所以你可以看到对于类似crm和商机发布类的SaaS应用软件往往来说运营的很好。

最后就是我们说的内容运营类公司,比较典型的就是电商平台,当然还有很多类似的平台,但是核心仍然是电商。简单来说你可以通过平台卖货,或者卖服务,而这些内容本身是可以不断持续发展的,可以不断的产生和运营新内容,但是软件平台本身并不用大变动。

这类平台解决两个问题,一个是资源,你可以理解为买方资源和卖方资源你都要去考虑,有了资源才能够产生流量,有了流量才可能促成最终的交易,有了交易你作为平台运营方就可以进行分成,这个分成可以带来持续不断的运营获利。

拿简单的美团外卖来说,一开始是商家,消费者,骑手多方补贴,最后形成流量和交易后进行抽成。或者你也可以看到这个时候软件平台在哪里已经不是最重要的,而且一开始的业务规划,商业模式的设计,软件平台只是其中的一个支撑平台。

因此可以看到,真正能够不断的规模化,能够持续盈利的都是运营类软件平台公司。但是这些真正的创业机会点基本被寡头所占据,小的创业团队很难再有机会。你的创业项目可能是一个好项目,但是流量入口不在你这里,你要获取流量就要烧钱,但是及时烧钱你也很难真正形成优质高粘度的流量。

这也是为何19年大家都在谈流量,特别是更多的人在谈私域流量,你微博,头条,公众号有多少粉丝,你访问量和转化率如何?如果是做微商的你直接或间接管理了多少微信群。流量本身即价值,我们原来谈知识变现,实际上本质是流量变现。

作为个人或自媒体运营,一个重点就是运营好你的流量,你可以通过不断优质的内容创造来持续积累你的流量和高粘度粉丝群。这是你变现的一个点,你带货或变现的时候可以说是知识变现,好物推荐,也可以说是间接割粉丝韭菜,都没毛病。

如果你现在做一个软件平台,你就要考虑如何引流的问题,我们原来看到过类似在行,小鹅通知识分享平台等应用,可以看到实际本质是通过大V帮自己引流。

简单来说你一开始不但不能抽成,你还得考虑返现,来完成大V私域流量朝你公域流量的转变。一个现实类似的例子就是大商城招租,你要去招租类似绿茶,海底捞这种商家,你一定是免租的,这些商家的入驻本身就是为你商城带来巨大的流量。私域流量朝你公域流量的转变后,你平台才可能拥有更多的薅羊毛机会。

把这个想明白,我更容易去思考当下的社群和连接,简单来就是进一步的私域流量交互,相互薅羊毛。当然你也更加容易去理解类似瑞幸咖啡的裂变营销,也是让个人的私域流量转化为平台的流量。因此低成本地找到愿意出卖自己私域流量的个体,一定是一种很好的平台引流模式。

互联网运营和SaaS服务

从项目到产品化转型,从产品到运营和SaaS服务构建

 

可以先看下百度百科对互联网产品运营的一个说明,即:

互联网产品运营要对用户群体进行有目的的组织和管理,增加用户粘性、用户贡献和用户忠诚度,有针对性地开展用户活动,增加用户积极性和参与度,并配合市场运营需要进行活动方案策划。因为需要能对产品和市场数据进行分析,并以此为依据推进产品改进,并且始终保持敏锐的用户感觉。

而对于互联网运营的大框架,一般的总结会包括五个方面的内容,即:

1:获客 2:认可 3:付费 4:体验 5:传播 五个核心阶段

根据每个阶段设置合理连贯的用户路径。而这五几个阶段正好也是一个持续迭代,持续优化改进提升的过程。最终的目的是实现用户消费产品,持续产生价值创造。而对于运营工作指标而言,更加精简的总结就是三拉新、留存、促活。我们经常谈到的的用户数,用户日活数,用户平均停留时长,用户转化率等基本都是围绕着三个指标展开。

在传统的市场营销里面我们会讲到市场和营销两个方面的内容,而市场则主要针对市场活动策略,品牌推广等方面,而销售则主要针对在有潜在的销售机会后具体的销售机会跟踪,一直到最终的项目立项,合同签订过程。而对于互联网产品运营可以看到,对于运营角色更多的是覆盖了市场销售两个方面的能力,同时实现了两者之间的平滑衔接。

比如我们做的关键节假日的市场策划活动,我们微信公众号推广的文章属于市场层面,但是这些最终活动和传播最终会带来新用户的注册,也就是所说的获客,但是获客只是第一步,用户注册并不代表用户马上产生消费行为,因此下一步还得跟踪用户的,留存用户,让用户获得很好的体验,最终促成消费和购买行为。而这也就是我们经常说的运营里面的一个关键指标,即转化率。没有转化率,那么一些用户数,日活数都无法产生真正的价值。

对于互联网产品运营人员,和传统的市场和销售人员最大的区别就是,运营人员往往对最终用户是透明和不可见的,用户并不需要知道有运营人员,运营人员需要的是直接建立用户和产品之间价值纽带,你需要在用户体验,产品易用性,售后服务等多方面下功夫来加强这种价值纽带。最终达到的效果就是用户愿意在你平台上多停留,多买东西,这就是最终的目标。这是和传统企业的市场和销售的一个区别点。

第二个区别点,就是互联网产品更多都是软件即服务模式,通过软件我们更好的实现数据的采集和记录。那么互联网产品运营来说,一个核心就是真正形成基于数据驱动的运营持续迭代。所有的用户登录行为,浏览行为,消费购买行为软件平台都有记录,你都可以进行初步的分析乃至后面的大数据分析。

因此互联网产品运营完全可以说是数据驱动的运营,所有的问题往往会通过数据反映出来,运营要做的就是如果通过数据表现出来的现象看到更加本质的内容,比如我们用户体验如何改进,产品如何改进,服务如何改进,我们的活动策划如何更加细分和有针对性,所有的这些都可以通过数据运营来给出更加合理的改进方案。

对于运营里面的留存和促活,简单来说就要首先要让低频用户变成高频用户,其次就是让高频活跃用户变成实际产生价值消费的用户。低频变高频,简单来说就是要先产生很好的用户浏览体验,产品的易用性要好,产品的个性化推荐要有针对性,这样用户愿意多停留使用。而当低频用户变成高频用户后,你需要的是考虑产品和服务本身的针对性和性价比等,让用户产生实际的消费行为。

类似当前大的互联网产品,下面的一些信息可能也是你会经常收到的。

  • 滴滴如果经常不打车,会收到好久不见,送你一张7折券的推送信息。
  • 电商平台会收到再购买满几单,可以收到多少的优惠券等。
  • 在线教育的,经常有19元10节课还送书的广告推送

所有这些都在解决引流,成单,留存和促活的问题。而这些一个方面是需要有一个强大的大数据分析后台,一个是需要有大量的人工运营和销售人员跟进。

从互联网运营到SaaS产品服务

对于互联网产品,要意识到向用户卖的很多时候已经不是一个产品实体,而是产品提供的服务,一个产品可以为一个用户群体提供服务。

其次,市场营销和销售过程本身存在差异,传统方式是从销售机会产生到形成订单,核心是销售转换和订单形成。而在互联网产品下变化为了先获取用户,然后再促使用户形成订单完成转化过程。同时我们还看到这两个过程本身即可以关联,也可以分解。

即我们说的拉新可以是独立的,留存和促活可以是后续行动。

再次,由于互联网产品提供的是服务,因此这个服务是不断在使用的,而且这个使用过程我们还能够不时的得到用户操作和行动上的反馈,而这些反馈本身又帮我我们进一步优化和改进产品。这也是互联网产品运营更加的强调数据驱动分析来促进产品持续改进和优化。

在做互联网产品的时候,产品是基础,运营才是真正的面向客户贴近市场持续让产品创造价值的手段。运营真正起到了衔接产品和用户之间的关键桥梁,其目的是让产品为用户创造价值,也间接地使互联网产品本身体现了自己该有的价值。

对于运营,我们经常会听到一种方法就是我有多少用户,你和我对接我可以直接导入多少用户给你,这个看起来挺不错,也符合我们前面说的运营的关键第一步拉新上面。但是实际上如果导入的用户本身不活跃,或者说没有最终进行消费和订购,那么仍然没有产生价值。这个也是我们常说的,运营往往最关键的还是在用户活跃度和用户持续的消费和订购产品和服务上面。

如何做到?

简单来说就是我能够根据用户的使用和行为习惯,持续的优化我们的产品和服务,并持续的推送体现产品核心价值的服务能力。让产品具有吸引力是其一,让产品本身促进用户高度粘性是其二。而真正要做到这点就相当不容易,里面涉及到用户行为数据分析,操作数据采集,大数据分析,产品优化改进,定向针对性推荐,产品策划和推广,互联网营销,市场线下活动,市场需求收集和反馈给产品部门等一系列的事情。

只有真正将这些事情从市场需求,到用户,到最终的产品价值提供形成一个完整的闭环,并持续优化,我们的运营才可能真正做好。运营我始终觉得不在于理论,而在于实操,没有任何放之四海而皆准的标准,而在于我们的运营人员是否真正的贴近了用户,并熟悉了产品,只有这样你才能够去考虑产品和用户之间的价值连接如何建立才是最有效的。

传统产品朝运营转型的一些思考

从项目到产品化转型,从产品到运营和SaaS服务构建

 

都觉得做项目化软件建设和实施很辛苦,也都觉得做SaaS运营服务是趋势。但是实际上真正朝运营转型却不是容易的事情。

为何说做SaaS运营很困难,个人理解主要包括以下几点:

其一就是你想做的SaaS运营服务,可以说大部分都被别人做了,你要后来居上进入,那么就必须有明确的产品核心竞争力或者确定的市场。比如你已经明确签订了一个大市场范围的合作,或者说你规划运营的产品有一个核心技术价值很大。

其二是软件公司或团队本身的持续运作问题,一个软件公司最重要的仍然是有稳定的现金流,能够活下去,但是大部分运营项目至少都是1到3年的长时间亏损,那么是否有这么多钱投入。很大做互联网运营类企业最后由于后续融资不顺现金流断掉而倒闭得太多。

其三就是传统技术公司转运营的时候,思维没有转,仍然是技术驱动。你会发现真正的SaaS运营很重要的还是运营模式,市场策划,引流方法,宣传推广方式等。你产品再好,没有用户和流量,那么所有努力都是白费。

其四就是你本身运营的产品或服务的技术壁垒,实际上对于大部分企业仍然很难有这个壁垒。对于很多创业或做SaaS运营的,经常会面临一个问题就是你做的东西很好,如果被BAT盯上了介入,你如何应对?BAT有钱有流量,如果看上一个好方向你基本没有化解的方法,最好的归途反而是自己被BAT收购。

对于我们主要做SOA,微服务和云原生解决方案,实际上可以看到这个本身朝运营转型有难度。那么是否有朝运营转的一些思路,自己初步思考如下:

构建一个可运营的能力中台

这个我在前面强调过,即我们做一个能力聚合平台,将各类接口服务能力聚合起来形成一个统一的能力对外暴露。API接口服务本身即商品,可以进行运营,可以按调用的次数或周期进行收费,如果是类似商品订购类接口服务还可以按实际的流量进行提成。

这种能力聚合后形成的服务能力开放平台本身价值就在于平台本身做寻找下游可用能力并接入的事情,同时做了大量的API接口服务的适配和标准化,方便第三方的消费方能够快速的消费和使用这些能力,避免和多家下游供应商对接的工作量和麻烦。

构建一个面向公有云的DevOps支撑平台

我们完全可以将我们的DevOps平台在完善后部署到公有云环境,形成一个面向所有企业团队,第三方开发者的PaaS服务能力平台。而我们平台本身又或部署在类似阿里云,腾讯云等公有云IaaS环境下。

实际上我们看到对于以上公有云本身也提供了类似DevOps的支撑工具和环境,那么我们再做这个的价值在哪里?你可以理解为整个平台是衔接企业内部私有云和公有云的一个关键衔接和适配平台,帮助企业构建一个完整的基于云原生的混合云架构。其次就是对接和适配到阿里,华为,腾讯多个云,可以实现这些公有云间的快速迁移和切换。

从toB的福利平台来构建社交电商

从项目到产品化转型,从产品到运营和SaaS服务构建

 

对于公司的SaaS运营的福利平台,我前面专门写博客文章介绍过,但是更多的是toB的一个SaaS平台,当然先入驻企业,企业是独立的租户,然后是企业员工使用,也可以理解为一个B2B2C的一个平台。

当前的福利平台,已经接入了衣食住行,吃喝玩乐等各类下游服务商后实际上已经变成了一个强大的能力中台,因此福利平台本身也就不再局限于只能够为企业端服务,更多的也可以直接面向C端服务,而这个面向C端服务更好的借鉴就是一个社交电商或导购类服务平台,比较典型的例子就是类似大V店的模式,而非什么值得买APP的导购模式。

大家可以看下知乎,当前已经推出了可以维护自己的商品橱窗的功能,即别人访问你的回答或者你的知乎主页的时候可以看到你推荐的商品,如果通过你推荐的商品产生的购买行为,那么你可以得到相应的提成。而我们完全可以借鉴这个思路来考虑如何在当前已有的能力中台基础上来做一个社交电商的服务平台。

从18年开始我们就看到,谈得最多的词就是流量和私域流量,有流量就能够带货,最终依靠个人的品牌和人气来产生最终的购买行为。谁掌握了流量往往就掌握了话语权,那么当你做一个运营平台的时候,一种获取流量的方式就是找有流量的人合作,利益共享。

在我们做产品和服务的运营过程中一定要借力,而这个借力最不能忽视的就是个体崛起。

在福利平台本身提供了足够的下游服务商接入,同时本身接入的产品和服务具有了价格优势后,剩下的关键就是基于社交电商的思路来考虑如何进行产品和服务的推广,直接到C端客户的引流。

如果我是一个掌握了流量的大V,那么可以看下实际上从平台功能上需要提供的包括:

我自己能够开店,简单来说我能够从你的能力中台上选择产品和服务放到我自己的店铺上,我只负责引流,实际的支付,物流等我并不关系。我需要根据实际的引流和交易情况来分成。

如何推广,实际上包括了多种方式,常见的实际上两种。

  • 微信群推广:直接发送商品的链接,通过链接进入到商品购买页面。
  • 发朋友圈:直接发图片,通过识别二维码进入到商品购买页面。

可以看到对于发朋友圈的情况下,一定不能是简单额发链接,而最佳和最醒目的方式就是发图片,然后有具体的价格对比,然后是醒目的给出识别二维码进入到购买页面的方式。在有人通过链接或识别二维码进入到购买页面的时候,需要代入你自己的userid信息,方便后续根据实际的交易情况进行提成。

在最终的用户进入到购买页面后,实际上在购买前仍然需要先注册,因此这个注册过程必须足够的简单,注册后就成为平台最终的用户,在购买前还需要维护相应的地址信息,最终的支付直接对接常见的微信或支付宝支付即可。

在最终用户产生购买行为后,这里一方面是会让用户之间关联相应的微信公众号,以后可以直接进入公众号看到自己的订单和物流信息。或者就是用户还是通过链接或二维码识别进入到购买页面的时候,能够很容易跳转到商品首页和个人中心,以方便查看相应的订单物流。

在完成第一次引流并产生购买行为后,一个好的社交电商平台要做的就是能够根据后续的运营,产品的推广等让最终的用户产生二次购买行为。也就是在能够产生独立的二次购买行为私域流量会转化为平台流量。简单来说你并不需要烧钱去引流,而是让利的方式进行引流。



 

相关 [项目 产品 转型] 推荐:

互联网转型中的项目思维VS产品思维

- - 互联网分析沙龙 - 干货
很多人说,互联网转型就思维方式的变化,只有思维方式变化了任何的制度才能真正落地执行,不然就永远是空谈. 其实写下这个话题,并没有什么结论性的举措或者方法,只是说说我在项目和团队运作中遇到困惑时的思考. 首先先来定义下什么是项目思维和产品思维,再来说说从这两种思维方式中延展出来的问题. 项目思维就是以项目为牵引,通过一个个有时间节点要求的任务来完成目标交付物.

从项目到产品化转型,从产品到运营和SaaS服务构建(201116)

- - 人月神话的BLOG
今天谈下在进行产品规划的时候,从产品化到运营化方面转型的一些思考. 对于大部分的软件企业来说,最希望实现的就是产品化,简单来说就是将自己开发的软件变成一种通用型的可以类似光盘快速零成本负责的产品,这种软件产品只需要少量的现场服务或支撑就能够方便客户快速的开始使用,类似微软的操作系统和Office办公软件.

Google+项目负责人分享产品细节

- Fung - TechCrunch中文站
TechCrunch的资深记者MG Siegler上周预先专访了(或许是被约谈)负责Google+项目的两位高层Vic Gundotra和Bradley Horowitz. 按照他们的描述,Google+不仅是一款社交产品,甚至超出社交战略的范畴,它是Google自身的延伸,所以叫做Google+.

迅雷CUED:如何孕育新产品项目,从无到有

- - 优设(UISDC)
接手一个新产品,就像孕育一个新生命过程. 设计师既是产品经理,又是用户. 如何把好点子,通过设计包装成优秀产品. 当你接到一个新产品时,是否彷徨无助. 作为一个设计师,既是产品,也是用户. 需要面临的问题与待解决的问题也就更多. 新产品更像一个已命名的作文题,需要在有限的内容里做题.此时最让你头疼的是什么呢.

一些做产品的项目经验:立项、流程、文档

- - IT技术博客大学习
标签:   立项、流程、文档. 到目前为止,虽然我们只做了一个蝉游记,其实还做了另外四款App的设计,只是没时间研发,先搁着. 立项的过程是这样的,通常由我先提一个想法,跟大家聊聊;如果没遇到强烈反对,再跟几个亲朋好友聊聊. 我心里有点底的时候,一边看同类产品一边出Axure原型——这很快,不会超过两天.

产品迭代中的项目流程有哪些

- - 人月神话的BLOG
问题:对于一个全新的产品,可能需要商业需求文档、竞品分析报告、市场调研报告之类的,等待各项评审过关后,还需要找项目申请立项等等. 但是对于一个很成熟的产品,只不过是每个月进行正常迭代也需要搞这么繁琐吗. 之前我们在迭代过程中只是提交功能概要设计,VP评审后就是详细功能设计了,再之后就是交互设计并交付开发,但是新的项目流程出来后就需要搞得和开发一个全新产品一样,还需要提交竞品分析报告、商业需求文档、进行立项等有这个必要吗.

产品经理也应该了解项目管理(一)

- - 人人都是产品经理
大家很多时候会因为与软件工程师,以及软件项目经理沟通不畅而烦恼.       “为什么你们的计划是这样排的,老板要求我们什么时候要上线,为什么你们要那么久.       “为什么你们的进度总是有问题.       “为什么你们bug这么多.       “为什么在这个阶段你就不能修改我们提的需求.        这些问题可能很多项目经理都会遇到,那么很多人遇到问题后,沟通不畅很多人会觉得很沮丧,很多人会很不解,当然有些人就会觉得这个工作没意义受夹板气.

产品实例:某项目APP后台系统设计

- - 人人都是产品经理
今年有幸参与了某度假屋项目从0到1的设计过程,展示给用户的是精致的APP,然而APP背后却是逻辑比较复杂的后台系统. APP的使用体验,很大程度上是由后台系统决定的,后台系统逻辑的合理性决定了APP的核心流程. 简要介绍一下此项目的业务流程如图1所示:. 业主购买度假屋并由物业管理公司托管,业主购买度假屋有三种类型:全套、分权、分时,全套即业主购买整套度假屋,分权即业主购买度假屋部分产权,分时即业主购买某季的居住权.

腾讯产品项目流程的七个阶段

- - IT瘾-tuicool
“腾讯”是产品经理的黄埔军校. 笔者有幸学习到腾讯产品经理对产品项目的流程管理,特此整理并结合实际工作经验分享给大家. 长话短说,腾讯产品项目的主题流程划分成了七个阶段,“概念阶段(CONCEPT)”、“提案阶段(PROPOSAL)”、“原型开发阶段(PROTOTYPE)”、“产品开发阶段(ALPHA)”、“内测阶段(CLOSE BETA)”、“正式运营阶段(OPERATION)”和“结项(CLOSE)”..