app相比较pc、H5、小程序有独立的体验、传播、服务封闭的好处。如果要尽可能玩转用户流程与时间，app是最好的产品形态。曾经在2017年小程序传闻推出后，许多人认为app会消失。实际上在用户主流场景和体验上，app是不可替代的。
可是对于一个有限资源的互联网研发团队，如何快速开发一个自己的app，并且还要验证业务模型的准确。
今天以PMTalk旗下HotMind产品的app设计来分享下我们如何做这款产品的MVP与研发工作。
MVP前，先做最深最全的需求
一个产品的MVP形态，不是第一次需求调研就可以完成的。作为产品经理更应该基于最全、尽可能最深的业务发展方向去思考产品的MVP。
如果你都不知道产品的未来扩展方向和具体的功能，MVP显然是无法定义的。
在设计HotMind的时候，其实我们已经考虑到了产品未来半年的版本计划。包括功能能会有多少个？用户路径分别有什么？用户的购买流程是什么？产品的商业模型是什么？
在前期需求与原型完成后，参与的产品经理基本可以在脑海思考如果自己是用户会主要用什么功能？
围绕着北极星指标：增长和变现，产品在MVP版本下如何实现这2个方向？
一个产品的MVP版本完整的压缩了产品研发时间。同样一个产品的MVP版本也应该实现最全量的商业模型价值。
Native与H5的混合使用
PMTalk产品经理社区是一个内容社区，社区有无数的文章、应用、应用问答数据类型，所以对应的移动端app，仍然是以这类内容为主。减少开发时间最好的方法是能够减少前端开发的页面开发工作。
无论IOS还是H5，在相同的功能与业务逻辑下。如果能够用一套UI，或差异不大的前端样式，还可以减少UI设计、测试时间
所以我们选择该尽可能用Native去封装H5。虽然会要求之前的H5页面带上IOS端口参数，增加了IOS与H5联调时间。但总的来说会比重新开发要快得多。
市面上许多产品也会按照这类设计处理。
如下分别是掘金、与淘宝的聚划算。通过H5的方式，保持内容无论是在PC、还是在微信浏览器移动端、还是在客户端，都可以达到一致体验。
内容产品做H5的好处还有利于传播，将内容传播出去。因为H5本身就有跨平台的天生优势。
唯一要注意的是在微信授权下的访问地址和普通浏览器的访问，会要求产品经理注意用户判断。
高保真原型的“迭代”
UI上线后，产品经理尽可能的利用高保真原型完成模拟操作。通过模拟操作和类似跳转交互，我们可以判断当前MVP的不足，以及优势在哪里。
许多互联网研发团队，如果采用瀑布流的研发管理方式。设计团队会非常反感出了设计图之后再变动。所有的变动应该放在下一个版本需求里，就会开始出现我们所谓“甩锅”现象。
“这是产品经理你的原型这么做的，现在没时间改”
在PMTalk团队中，我们以敏捷方式管理研发流程。每周二需求评审固定，需求评审的研发工作不会超过1周。
同时与开发沟通清楚哪些页面或功能逻辑可以先行，没有想清楚的地方或有UI调整的地方在什么时候补齐。
这样就算在新版本UI调整，也算MVP版本下的一次“迭代”
放过酷炫的动效或交互
移动端的开发，在IOS和安卓2个系统阵营的影响下导致了许多开源的交互组件或部件产生。
但每个产品经理最擅长以及最想做的都是做一套适合自己产品的“酷炫”交互效果，以独特的交互方式吸引用户。
但站在开发的角度上，每一个交互动效背后的时间、条件、显示边界都需要花时间调试。
以soul为例，这是一款主打90后、00后陌生人社交的产品。在用户匹配上推出了类似宇宙星期的交互效果。因为酷炫的交互效果满足了目标用户的好奇心理。带来了良好的增长
在MVP开发期间，若要验证MVP版本。我们不能一刀砍断所有的酷炫交互，但要在交互效果上学会做MVP。像上述这类星期的动画效果，前期可以在动画效果上使用开源现成的，产品经理在先有的开源库寻找与自己需求表达最切近的交互效果。
在动效、页面数量、逻辑都尽可能复用。我们可以更改前端的样式，但不更改数据类型与数据处理逻辑。相信一个app会落地的更加快速高效，帮助产品经理验证从0到1的商业模式
文章来自社区签约作者：kevin
