mvp中的m作用
by Howard Lo
霍华德·罗
Years ago, I thought I knew what my minimum viable product (MVP) was. But I was wrong, and ended up building way too much.
几年前,我以为我知道我的最低可行产品(MVP)是什么。 但是我错了,最终导致了太多的构建。
Months ago, I thought I knew what my MVP was. But I was still wrong, and ended up building too much, but not as much as before.
几个月前,我以为我知道我的MVP。 但是我还是错了,最终建造了太多东西, 但没有以前那么多 。
As you get practice building products, estimating “viability” does get easier. But you still need to be vigilant. Otherwise, you’ll disappear into your laptop for several months, only to emerge with a product nobody wants.
在练习构建产品的过程中,估计“生存能力”确实会变得更加容易。 但是您仍然需要保持警惕。 否则,您会消失在笔记本电脑上几个月,然后出现一个没人想要的产品。
The sky is the limit in development. You can code the hell out of something. You can end up with the world’s prettiest and most animated button. The pitfall is that this seem like a worthwhile effort at the time, because you’re putting in work and seeing results.
天空是发展的极限。 您可以用一些东西编写地狱。 您可以得到世界上最漂亮,最生动的按钮。 陷阱在于,这在当时似乎是值得的,因为您正在投入工作并看到成果。
But there’s an important concept called diminishing marginal returns. At some point, the work you put in isn’t going to move the needle enough to matter.
但是有一个重要的概念叫做边际收益递减。 在某些时候,您所做的工作不会使针移动得足够重要。
If you go far enough, the work you put in isn’t going to move the needle at all. And if you’re not careful, you won’t notice that unmoving needle until you’ve just expended a ton of effort.
如果走得足够远,那么您所做的工作根本不会移动针头。 而且,如果您不小心,直到花费了很多精力之后,您才会注意到动不动的针。
So when you’re building your startup — or adding a major feature to your started-up — how are you going to know when to stop? At what point will you realize that you’ve took things too far?
所以,当你建立你的启动-或增加的一大特色,以您的起点ED-UP -你怎么知道什么时候停止? 在什么时候您会意识到您所做的事情太过分了?
For starters, you should have a general idea of what you think is necessary and what isn’t. You can organized these into two mental lists: must-haves and nice-to-haves.
对于初学者,您应该大致了解自己认为什么是必要的,什么是不必要的。 您可以将它们组织成两个心理清单:必备清单和必备清单。
Once you satisfied your must-haves list, thats when you stop, and voila, MVP achieved.
一旦您满足了必备清单,那就停下来, MVP达到了。
If you are not embarrassed by the first version of your product, you’ve launched too late. — Reid Hoffman
如果您对产品的第一个版本不感到尴尬,那么您上手太晚了。 —里德霍夫曼
No matter how hard you tried, you probably ended up spending too long working on your MVP before releasing it.
无论您多么努力,最终发布MVP都可能花费了太长时间。
But how long is too long? I wish I could tell you. The best I can do is: it’s too long until it’s too short.
但是多久会太久? 我希望我能告诉你。 我能做的最好的事情是:过长直到太短。
Though I can’t give you a straight answer, I can tell you what I learned on my most recent creation, Rabbut, which makes it easier to build a mailing list on sites like Medium.
尽管我不能给您一个直接的答案,但我可以告诉您我在最近的创建中Rabbut中学到的知识 ,这使在Medium等网站上建立邮件列表变得更加容易。
After launching Rabbut, it became apparent what we needed vs. what we didn’t. Take what you can from the my Rabbut story — I’m just passing this along as an example in hopes that it will get you thinking about what features your MVP can do without.
启动Rabbut后,我们明显需要什么与不需要什么。 从我的Rabbut故事中获取最大的收益–我只是作为一个例子,希望它可以让您考虑一下MVP可以没有的功能。
Since we have user accounts with passwords, it stands to reason that one day someone will forget their password (me included). This was on the list of things that absolutely needed to happen, because people will get pissed if they can’t get into their dashboard.
由于我们拥有带有密码的用户帐户,因此可以说有一天某人会忘记他们的密码(包括我)。 这是绝对需要发生的事情,因为人们如果不进入仪表板就会生气。
This didn’t get built simply because I couldn’t figure out how to set it up. Sorry early users!
之所以建立它,并不是因为我不知道如何设置它。 对不起,早期用户!
Rabbut didn’t have password resets. Not even for admins — no one at the company could reset any password.
Rabbut没有重置密码。 甚至对于管理员来说也是如此-公司里没有人可以重设任何密码。
To prevent people from getting logged out when closing the browser, I set the cookies to expire after a year and removed the “sign out” button. I had to buy as much time as I could.
为了防止人们在关闭浏览器时注销,我将cookie设置为一年后过期,并删除了“退出”按钮。 我不得不花尽可能多的时间。
What happened? Nothing.
发生了什么? 没有。
No one forgot their password for 5 months. Granted the first month didn’t have a huge influx of new users, but a feature that finally got used 5 months out definitely falls into the “don’t need it now” list.
5个月内没有人忘记密码。 授予第一个月并没有大量新用户涌入,但最终使用了5个月的功能肯定属于“现在不需要”列表。
At the 5 months mark, a poor old man wrote in and said he had forgotten his password, and didn’t know how to access his dashboard. I apologized, told him it was a bug (heh), asked him to give us a few days, and patched the live site with a very 1990's password reset process.
在五个月大关时,一个可怜的老人写信说他忘记了密码,也不知道如何访问他的仪表板。 我向他道歉,并告诉他这是一个错误(heh),请他给我们几天时间,然后使用1990年代的密码重置过程修补了实时站点。
You can check out our reset password interface to see how unpolished the entire process is (you will need to create an actual account first if you want to go through the workflow). You might also notice that it looks strangely like every other part of our site, because it’s recycled code (more on this point later).
您可以查看我们的重置密码界面,以了解整个过程的情况(如果要完成工作流程,则需要先创建一个实际帐户)。 您可能还会注意到,它看起来像我们网站的其他部分,因为它是可循环使用的代码(稍后将对此进行详细介绍)。
Let it be known: I am not a lawyer. Let it also be known: this is probably bad advice and you shouldn’t do this.
众所周知:我不是律师。 还要让大家知道:这可能是个坏建议,您不应该这样做。
Let it finally be known: Rabbut survived without a Terms of Use and Privacy Policy (no lawsuits), and you probably will too, until you start getting big.
终于让人们知道了:Rabbut在没有使用条款和隐私政策(没有诉讼)的情况下幸存下来,而且在您开始变得壮大之前,您可能也会幸免。
The honest truth is, hardly anyone reads these, even though they say they do (though they probably should). And hardly anyone will remember what any terms of use or privacy policy says, even if they did take time to read it.
诚实的事实是,即使有人说他们做到了(尽管他们应该这样做),却几乎没人读过这些。 几乎没有人会记住任何使用条款或隐私政策的内容,即使他们确实花时间阅读它也是如此。
So who cares?
那么谁在乎呢?
Pop quiz!
突击测验!
We put in the terms of use and privacy policy for Rabbut because we got cold feet one day — not because anyone complained about it. You don’t need to pay hundreds of dollars for a lawyer to draft one up for your zero-traction company if no one even knows you even exist.
我们之所以加入Rabbut的使用条款和隐私权政策,是因为有一天我们感到冷漠,而不是因为有人抱怨它。 如果没有人知道您甚至不存在,您不需要为律师为起草一家零牵引公司而花数百美元。
Do this later, and in the meantime be a good samaritan and be careful with other people’s private information.
稍后再执行此操作,与此同时,要做好事,并注意他人的私人信息。
Here is where all the righteous developers will pull out their digital crosses. You didn’t write a full test suite for your code? See you in hell.
在这里,所有正义的开发人员都将拉出他们的数字十字架。 您没有为代码编写完整的测试套件? 地狱见。
Tests run your code through a series of…tests… to make sure that any new code you add hasn’t screwed up something critical in your project.
测试通过一系列测试来运行您的代码,以确保您添加的任何新代码都不会破坏项目中的关键内容。
If I could snap my fingers and have all my tests written, I’d snap my fingers.
如果我可以拨动手指并完成所有测试,则可以拨动手指。
But if you can avoid spending time you don’t have writing tests up front, don’t write them. Especially if you’re the only developer, or if the project is pretty small. Because if something does break, you are probably familiar enough with the small codebase to know how to fix it, or revert your changes if necessary.
但是,如果您可以避免花费时间,而不必事先编写测试,请不要编写测试。 特别是如果您是唯一的开发人员,或者项目很小。 因为如果某件事确实发生了问题,您可能对小型代码库已经足够熟悉,知道如何解决它,或者在必要时还原所做的更改。
You also don’t need tests if your product’s direction is still flexible. The worst thing about pivoting is throwing away the old code. If you pivot, you’ll probably throw away most of your tests, too.
如果您的产品方向仍然灵活,您也不需要测试。 数据透视最糟糕的事情是扔掉旧代码。 如果您进行数据透视,您也可能会放弃大多数测试。
Once you have traction or a big development team, you can write all the tests your heart desires (or hire a test engineer to do it for you).
一旦有了牵引力或强大的开发团队,您就可以编写自己心中想要的所有测试(或聘请测试工程师为您完成)。
In the beginning, things change fast. Keep your code lightweight so it can change just as quickly.
刚开始时,情况变化很快。 保持您的代码轻巧,以便可以快速更改。
If it’s all the same to you, write scalable code. If you’re stuck on something for more than half an hour because you can’t come up with a solution that will support 100,000 concurrent users, just write something hacky/unscalable and move on.
如果您都一样,请编写可伸缩的代码。 如果由于无法提供支持100,000个并发用户的解决方案而在某件事上停留了半个多小时,则只需编写一些骇人听闻/不可扩展的内容并继续前进即可。
I’m not the worlds greatest developer. Things that are easy to some developers take me way longer than they probably should. This includes writing scalable code.
我不是世界上最伟大的开发商。 对于某些开发人员而言,容易完成的事情花了我更长的时间。 这包括编写可伸缩的代码。
Yes, I would like code that doesn’t break down when I go from 10 users to 10,000,000.
是的,当我从10个用户增加到10,000,000个时,我希望代码不会崩溃。
Yes, I would like the developers who join my company later to marvel at my coding prowess and god-like foresight.
是的,我希望后来加入我公司的开发人员惊叹于我的编码能力和神灵般的远见。
But all of that requires researching and understanding the latest methods of developing efficiently. And might I add, your use of best practices won’t be appreciated by anyone other than the developers on your project (and at the moment, that’s probably just you).
但是,所有这些都需要研究和理解有效开发的最新方法。 而且我想补充一下,您对最佳实践的使用将不会被您项目的开发人员所赞赏(目前,可能只有您自己)。
And best practices change often, which is why the shelf life of StackOverflow answers is so short. Staying on the cutting edge is a rough, endless pursuit.
最佳实践经常更改,这就是为什么StackOverflow答案的保质期如此短的原因。 保持最前沿是一项艰巨,无止境的追求。
Where you can — if you can — write scalable code. Otherwise, make it work, ship it, then worry about optimizing it later.
在可能的地方(如果可以)编写可伸缩的代码。 否则,请使其工作,发货,然后再担心对其进行优化。
We didn’t really use a staging server for testing until we had to test payments. And even then, we could’ve tested them on our local machine (laptop) by using Stripe.
在必须测试付款之前,我们实际上并没有使用登台服务器进行测试。 即使那样,我们仍然可以使用Stripe在本地计算机(笔记本电脑)上对其进行测试。
Pro tip: if you value your sanity, use Stripe for all your payments.
专家提示:如果您重视理智,请使用Stripe支付所有款项。
Staging servers are nice, and they don’t take too long to setup. But if you’re still in the early stages of discovering your product’s identity, they aren’t necessary.
登台服务器非常好,并且安装时间不会太长。 但是,如果您仍处于发现产品标识的早期阶段,则不必这样做。
Most developers sleep late, and push buggy code during the dead hours of the night and test on the live server. It isn’t the end of the world if that one user on your site at 4 a.m. has a diminished experience as a result of a buggy push.
大多数开发人员会睡得很晚,并在夜晚的死时间内推送错误的代码,然后在实时服务器上进行测试。 如果您的网站上的某个用户在凌晨4点有错误的推送而导致体验减少,这不是世界末日。
This isn’t a marketing strategy or a pricing strategy.
这不是行销策略或定价策略。
Start free, because it takes time to set everything up.
免费开始,因为设置所有内容都需要时间。
If you push out payments, you’re going to need a pricing page to tell people what they get from paying vs. not paying. If you don’t, your users will contact support and your customer support team (probably also you) will hate you, which sucks.
如果您推迟付款,您将需要一个定价页面来告诉人们他们从付款还是不付款中得到什么。 如果您不这样做,那么您的用户将与支持人员联系,而您的客户支持团队(可能也是您)会讨厌您,这很糟糕。
You’re also going to need to code the payment forms and payment systems, which sucks.
您还需要对付款表格和付款系统进行编码,这很麻烦。
You’ll need to setup HTTPS immediately, because most payment platforms won’t allow you to accept money unless you’re secured.
您需要立即设置HTTPS,因为大多数付款平台都不允许您接受付款,除非您受到保护。
Then you probably need a corporate bank account. Banks suck.
然后,您可能需要一个公司银行帐户。 银行糟透了。
Depending on how much you trust your team, you might also need to incorporate, or setup an official “business.” Incorporating is expensive, and sucks.
根据您对团队的信任程度,您可能还需要合并或成立正式的“公司”。 合并是昂贵的,而且很糟糕。
Not to mention, if you screw up anywhere in the math or code — like forgetting to add in shipping costs — you might actually lose money on your transactions. This happened to me, and it really sucked.
更不用说,如果您在数学或代码中的任何地方搞砸了(例如忘记增加运输成本),您实际上可能在交易中亏损。 这发生在我身上,真的很烂。
All of that is just extra time you’ll need to launch.
所有这些只是您需要启动的额外时间。
Humans made it to the moon by getting to orbit first. Start free.
人类首先进入轨道进入月球。 免费开始。
You don’t need security in the beginning.
您一开始就不需要安全。
Before you put on your tin hats and cry “what if I get hacked!?” remember: you need to be popular before you get hacked.
在您戴上铁皮帽子并大喊“如果我被黑客入侵!?”之前, 切记: 在被黑客入侵之前,您需要变得受欢迎 。
Most hackers want the best bang for their buck. Why would they hack your obscure project with 10 users when they can focus on places that have 100 million users?
大多数黑客都希望获得最大的收益。 当他们可以将重点放在拥有1亿用户的地方时,为什么会用10个用户入侵您晦涩的项目?
Remember the hacker who leaked a ton of celebrity intimates? Ever wonder why he didn’t bother leaking yours?
还记得黑客泄露了许多名人知情者吗? 有没有想过他为什么不理会您的泄漏?
Another prime example is Facebook. They didn’t have HTTPS until they got reprimanded and required to from the FTC, nearly a decade after they launched. By then, they had sensitive information of millions of people.
另一个主要的例子是Facebook。 他们没有HTTPS,直到他们受到谴责并要求FTC提出要求,也就是他们成立近十年之后 。 到那时,他们已经拥有了数百万人的敏感信息。
You won’t get in trouble for a long time, but HTTPS does make some of your users feel better about your site. I don’t suggest you pull a Facebook and wait a decade, but get HTTPS when you need it (payments) or when your users — or the FTC — complain too much.
您不会在很长一段时间内遇到麻烦,但是HTTPS 确实会使您的某些用户对您的网站感觉更好。 我不建议您拉一个Facebook并等待十年,但是当您需要HTTPS(付款)或您的用户(或FTC)抱怨过多时,请使用HTTPS。
“What constitutes an MVP” changes from year to year. It depends on people’s expectations.
“ MVP的构成”每年都在变化。 这取决于人们的期望。
In the early 90’s, an MVP website was probably just plain text with a single popup ad. Today, an MVP needs to satisfy a crowd with higher standards. So here are some things you should do, aside from no avoid popups:
在90年代初期,MVP网站可能只是纯文本和一个弹出广告。 如今,MVP需要满足更高标准的人群。 因此,除了避免弹出窗口外,还有一些您应该做的事情:
You can write crap code. Your server be held together by rubber bands and chewing gum. But your users should never feel it.
您可以编写废话代码。 您的服务器通过橡皮筋和口香糖固定在一起。 但是您的用户永远都不会 感觉到 。
If your webpage takes 20 seconds to load, fix it. MVP or not, if it affects usability, it matters.
如果您的网页加载需要20秒,请对其进行修复。 是否MVP,如果它影响可用性,那很重要。
When it comes to MVPs, UX is the exception, because “viable” products need to feel polished, at the minimum. People today expect even beta applications to be functional and not frustrating. Blame all those overachievers that came before you.
对于MVP,UX是个例外,因为“可行的”产品至少需要摸上去 。 如今,人们甚至希望Beta版应用程序能够正常运行,并且不会令人沮丧。 怪罪所有摆在您面前的成就。
Keep your design simple, so you have less to code and less to design. Lately the clean/flat look is in, so this should be easy.
保持您的设计简单,因此您无需编写代码,也无需进行设计。 最近出现了干净/平坦的外观,因此这应该很容易。
You don’t need fancy animations or interactive easter eggs, but you should spend some time on your front end so it looks and feels modern.
您不需要精美的动画或交互式复活节彩蛋,但您应该在前端花一些时间,以使其外观和感觉很现代。
Use pre-made nice-looking CSS frameworks like Bootstrap to cut down on development time.
使用预制好的外观CSS框架(如Bootstrap)来减少开发时间。
Reuse HTML components as often as possible, as long as doing so doesn’t lead to confusion. Repurpose button designs, forms, and other components.
只要不引起混淆,便尽可能地重复使用HTML组件。 重新利用按钮的设计,表单和其他组件。
Your MVP won’t look the way it did in your dreams, but thats a luxury for version 2.0+.
您的MVP看起来不会像您梦dream以求的那样,但是对于2.0+版本来说,这就是一种奢侈。
Fool your users into thinking your app is more polished than it actually is.
让用户误以为您的应用比实际更精致。
This may seem like a “nice-to-have” to many people, but I think it is necessary even for an MVP, because it will save a ton of headaches down the road.
对于许多人来说,这似乎是“必备”,但我认为即使对于MVP也是有必要的,因为这将节省很多麻烦。
I hate migrating data or making surgical changes to it later. It’s unnerving, risky, and most of the time, it’s hard to see what’s going on (unlike front end or design).
我讨厌稍后迁移数据或对其进行手术更改。 它令人不安,充满风险,而且在大多数情况下,很难看到发生了什么(与前端或设计不同)。
Disorganized and fragmented data can slow down your site (UX), make development a huge pain (Developer Experience), and complicate every step you take henceforth.
杂乱无章的数据会减慢您的站点(UX)速度,使开发工作陷入沉重的痛苦(Developer Experience),并使以后的每个步骤变得复杂。
I take extra time to think about how to store my data in a way where it makes sense for my current product and any foreseeable pivots.
我花了更多时间考虑如何以对我当前的产品和任何可预见的枢轴有意义的方式存储数据。
You don’t want to go overboard on schema design, but seriously — don’t half-ass your database. Whole-ass it.
您不想在架构设计上投入过多,但是请认真对待-不要半估您的数据库。 全屁股。
The truth is — yeah, I reveal the truth after you read everything — you won’t know until you’ve done it. It’s better to come up short than to waste time doing work that won’t matter.
事实是-是的,在您阅读完所有内容后,我才揭示了事实-直到您做完之后,您才知道。 比起浪费时间做无关紧要的工作,总比让时间短要好。
And you won’t know what doesn’t matter unless you come up short.
除非简短,否则您将不知道什么都没有。
Don’t worry about embarrassment, because even if your nudes were leaked, you’re probably a semi-anonymous dreamer like the rest of us, and nobody out there will care. Theres startup advice in there somewhere.
不必担心尴尬,因为即使您的裸照被泄露,您也可能像我们其他人一样是半匿名的梦想家,那里没有人会在意。 在某处有启动建议。
Finally, no matter how badly you blow your MVP…
最后,无论您的MVP表现多么糟糕……
( •_•)( •_•)>⌐■-■
(•_•)(•_•)>⌐■-■
…you can always write about it after.
…您以后可以随时写它。
(⌐■_■)
(⌐■_■)
I made rabbut.com, a tool that lets you collect emails here on Medium (and other places). Oh look, here is one now:
我制作了rabbut.com ,该工具可让您在Medium(和其他地方)的此处收集电子邮件。 哦,看,现在是一个:
Looking for my older stories? I’ve got some. Here.Looking for older stories is a PITA on Medium. Click here for a shortcut.powered.by.rabbut.com
寻找我的老故事? 我有一些 这里。 寻找较旧的故事是中级的PITA。 单击此处获取快捷方式。 powered.by.rabbut.com
Also, I’m giving away a few copies of my eBook on starting up a startup. Especially good for people who don’t know how to startup a startup:
另外,在启动公司时,我还会赠送一些电子书。 对于不知道如何启动创业公司的人尤其有用:
First 10 people to subscribe get my free eBook.How to startup your startup as a nobody.powered.by.rabbut.com
前10位订阅者可获得我的免费电子书。 如何以无人启动您的启动。 powered.by.rabbut.com
Man, these rabbut things are like everywhere now. I wonder where you could get one…
伙计,这些拉布特的事现在到处都是。 我不知道你能在哪里买到……
翻译自: https://www.freecodecamp.org/news/putting-the-m-in-mvp-71e036034ed9/
mvp中的m作用