One of my fears is that the first impression is so important. It's very hard to make people try your product for a second time. Reviews get written and it's not like people are gonna update their reviews when all the issues have been fixed.
That's how Cuil, the company that tried to build a search engine to compete with Google, blew it. Big PR push, huge initial traffic, initial product sucked, traffic disappeared, product got better but nobody cared, VCs pulled plug, company bankrupt. I got to watch that one happen.
There seems to be endless goalpost moving around this though. Do you release as soon as you possibly can and learn and validate, or release a relatively polished product and have a strong initial base of customers help finesse it?
It's also kind of hard to get meaningful feedback without some kind of big PR push.
The way I approach it is as a pyramid. First version, really shitty, I just need to get few customers/users and get him/her interested. if they see big holes, go fix it and come back. Work on fixing smaller holes and other features, collect feedback from a slightly larger audience. Repeat such feedback/iteration cycles.
As product becomes more mature, increase size until you have a 1.0, at which point you have a loyal fan base that loves the product and is willing to pay. Then you go full PR, market like crazy and burn VC money in growth.
The point is at each stage you are still validating and gathering feedback without the risk of losing out on a large number of customers.
>It's also kind of hard to get meaningful feedback without some kind of big PR push.
In my experience, you can get meaningful feedback by watching one, or ten, or a hundred users use your app. Indeed, given the level of tailoring that you can (and should) do to pick the first batch of users, you should be able to give them very close attention
If you don't have evangelists in your early-alpha userbase, then something is probably wrong.
It's not an either or - the second (money) merely is a lot easier if the first exists. I've seen startups soon dominated by thoughts of the private jet for the executives and all thoughts dominated by money, wealth and power. Guess what suffered: Actually developing the f...ing product. Lots of internal power struggles, because fast growth leads to a lot of fancy new job titles and offices.
If money is the #1 motivating factor you'll create the company mirroring your goals. Doesn't mean you won't be successful - one of the companies I didn't mention was eventually sold for hundreds of millions (but that was down from billions of projected value earlier after they screwed up due to what I mentioned) - but you can increase your chances of success if your actual product is actually important to you, and if it solves an actual problem.
I think this is less important on the web than native. Iterative releases feel natural on the web. If something solves a real problem I'll use it while they work out design kinks.
I completely agree, one of the reasons that we've been reluctant to release is that we've been developing a native app. Considering how long it takes to push a bug fix, with Apple approving and all, you can expect 4 days of downtime if you really screw up.
If you compare that with web, as many pointed out my article had a lot of spelling errors but that was easily corrected.
The real challenge is testing your assumptions without ever releasing an app or website :)
I used to agree with this but it's unlikely a MVP will get enough traction to truly damage a software brand. Of course, this depends on the medium (computer software [harder to update] vs website service) and target audience (investor vs public) and if your audience understands it's a MVP.
Question is: should a user come by your MVP now or in six months when it's "done"? The earlier people see your product and not like it, the earlier you can hone it for future users. Plus, a final version could be rebranded if the MVP was that bad.
Granted, I fell into this trap with my website. I kept putting it's release off and now am learning how to refine it as I see how it's used by others.
For instance, I thought the news section of my site (http://www.survivalscout.com/news) would be really popular but almost no one visits it. It's my favorite part but I seem to be in the minority according to the logs. If I had known that earlier, I may have spent less time making it.
I'd say it's most important that you are solving an important problem. If you solve the problem well, no one will care if the product is ugly as shit. So long as you are the only or the best solution out there, it doesn't matter. :-)
The solution to that is to properly set expectations. If you're releasing an early preview or MVP as if it's a polished final product then yeah, you'll get bad reviews. If you set expectations of "This is a preview release to get feedback so we can make changes to meet YOUR needs" then you should get feedback. If you've set expectations properly and get bad reviews at that point you should be able to go back to them and note that the review was for an early-stage trial balloon.
If you get a 2 star average on yelp on grand opening of your new restaurant, a lot of people won't even bother coming even if you fixed most of the complaints.
You solve that by doing a limited first release. Don't advertise to the whole world or pay for a TV commercial. Target some customer groups you think would like the product and have a few of them use it. The early feedback is invaluable.
Even after you have a mature product, you can trickle out new features this way. Sometimes customers will come to you a feature request and even ask to help you beta test it, because they want it so badly.
Interesting! I've been showing my project to people and I get really strong first impressions - people love it immediately. Which, i guess is great - but what I really need to know is if it's actually useful and solves problems for them, which has been harder to gauge.
I've encountered this problem too. People will say nice things to you when you pitch or show them something because it's easy to be nice and they want you to succeed. Maybe they imagine their optimal future self using your product. But things may not work out that way. There's also the issue of solving a genuine problem but later finding out that it's not a valuable problem.
There is a solution: stop showing people your product and start casually asking them about their problems. Then you can begin to understand if you are solving real problems and how much people care about them, e.g. if they have already parted with money (or time) trying to solve them. Don't ask leading questions, but do prompt them for specific details about their actions. Don't ask anything where the answer is to any degree hypothetical. It only takes five minutes, just don't mention your product!
Of course this requires you to be in the same room as your potential evangelist early-adopter customers. Go put yourself in that room ASAP.
I also enjoy that the HN title has a different typo than the article - "Unkown Unknowns" vs "Unknown Unknows". And the heading in the article is "Unkown Unknows". I can't tell if these are deliberate or not...
Submission titles get updated if either the author (within a time limit) or a mod notices that there's an error in the title. The mods don't see everything, but do respond to email. If a title needs updating, you can contact the mods via the Contact link in the footer.
I used to say you could release stuff often if it wasn't safety- or security-critical. The latter should be reviewed & hit with various scenarios before any release. The model of non-critical software seems to be purely time-to-market, adding features, sometimes subtracting them as a differentiator, and lock-in. This combo created several multi-billion dollar firms plus lots of other shops raking in the big cash. Minus the lock-in, the model drives the successful projects in FOSS. The bugs can be fixed later with patches which can even be sold to customers. You win then win again.
These days I'll add any non-regulated, security-critical product to the list of things to rush simply because most of them are crap. The likes of McAffee and RSA Inc. got to the top with the security "features" w/ correct extra stuff (eg tie-in's to Microsoft stack), sales teams, support, and so on. They didn't do a lot on "assurance" that what they delivered was secure itself or worked despite clever adversaries. So, if you want money or market share, just do exactly what they did.
I will add that there's methods for developing software that still move quickly while reducing defects. Particularly, if unreliability might hurt you, follow Cleanroom methodology's take on testing by focusing on usage-driven testing. Come up with as many scenarios as possible representing how users will actually use the product. Make sure all those scenarios pass. That means the defects that slip through are those average user might never see. Obviously, things like memory-safe languages, interface checks, and quality libraries from 3rd parties help, too. This collectively gets you better defect rate than most of industry with hardly any extra work.
And, as he mentions, release as much as possible without writing a single line of code. Code gets expensive quickly. Expensive to scope, expensive to write, expensive to change, expensive to maintain.
I wish I shared that sentiment. I am a non technical wannabe. I think I have done a lot of important work so far in terms of figuring out what works, but I feel like it will never get anywhere. Geez. And I envy the coders, who seem to get so much more done.
All I can tell you is that my co-founders weren't technical but the relationships and market research they'd done made it far easier to build the right product when I (as technical co-founder) came on board.
This is only good advice if you have a really good handle on what "too painful" is. Interestingly, this isn't just a matter of operations either. On the software development side we have exactly the same problem. People are unwilling to invest in improving their build systems, test systems, deployment systems, etc, etc. You end up never hitting the sweet spot where you can rapidly advance your capability.
For example, if it takes 3 hours to deploy using a manual system that is prone to errors, then you will only deploy once a week. There is no incentive to improve the system, because you think you can only save 3 hours a week. But the impact is far greater than that. If you can only deploy once a week, then that deployment must be successful. It's really hard to recover from a mistake. So you need to take a far more rigorous approach for testing. It also means that you have to be far more conservative in what you do. You have to take smaller pieces.
The result is that you have substituted your programmers coding time with planning time. They have a very small amount of code they can deliver (to keep the risk low) and they can only do it once a week. And instead of writing code, they are sitting in meetings arguing about the best way to ensure that nothing gets broken.
If you can get your deployment completely automated with a good regression test suite and an ability to easily roll back mistakes -- then you can take on much more risk in development. Instead of playing a virtual game of Jenga with your servers and being very, very, very careful not to break things, your programmers are concentrating on writing code.
Of course it's not free. The programmers must spend quite a lot of their time building infrastructure. You often (almost always???) find organisations trying to control the amount of infrastructure work from the top down. The idea is to focus effort on revenue generating activity. However, the decisions are usually made in the wrong place because often the best balance is not visible by those who don't do the work.
This post is long enough, but I've also found that avoidance of automation in operations can cause serious long lasting damage to an organisation. A really good example is reporting -- which seems like a good candidate for going manual as long as possible. However, as the organisation gets older, and the IT systems get more complex, you get to the point where you need a good, flexible, and accurate reporting system but that the IT systems have absolutely no capability of delivering it. So if you never ask the question, "At what point will it start to be painful to add reporting capability to this system" the chances are that you will completely miss it. And even if wait until the last minute, the chances are that you will have no free capacity to add that functionality.
I stopped flossing for a while (forget why) right before a check-up. The "gum quality" numbers (scale of 1-5) that the hygienist called out for each tooth gap were conspicuously worse than usual. I hadn't told them I hadn't been flossing. After that feedback, I regained flossing religion. Come next check-up, the numbers were back in the normal range.
Feel free to file this anecdata as appropriate to your needs.
I absolutely hate flossing and never do it. I bought one of those dental pressure washer things to compensate, and I love it. It blasts piles of food gunk out from between your teeth, way better than flossing will ever hope to accomplish, as well as flushes under the gumline. Plus, it takes less time than flossing. The dental workers have commented that I floss very well, joke's on them. ;-)
Electric toothbrushes are also great for keeping your teeth very clean, and can penetrate between your teeth depending on the design.
Just because there is no medical evidence, it doesn't mean that you don't benefit from flossing, it just means nobody has spent the money to prove the benefits of flossing.
Yes. People might balk at your Vox link, but I'd advise anyone to look into it themselves. There's little good research about flossing: http://skeptics.stackexchange.com/a/9611
My personal belief is that flossing does something since you can clearly see food bits or whatever on used floss, but that's different from believing those food bits wouldn't be removed by normal brushing anyway or that they even cause harm.
"... In a discussion of the earthquake and tsunami that produced the 2011 Fukushima nuclear disaster in Japan, Taleb writes: “Not seeing a tsunami or an economic event coming is excusable; building something fragile to them is not.” And in the case of the Fukushima disaster, authorities seem to be responding appropriately: not by developing better predictive models, but by building smaller and less vulnerable reactors."
source: Nassim Nicholas Taleb on Accepting Uncertainty, Embracing Volatility
"4. Do not let someone making an “incentive” bonus manage a nuclear plant – or your financial risks. Odds are he would cut every corner on safety to show “profits” while claiming to be “conservative”. Bonuses do not accommodate the hidden risks of blow-ups. It is the asymmetry of the bonus system that got us here. No incentives without disincentives: capitalism is about rewards and punishments, not just rewards."
The Tokyo District Public Prosecutors Office, including tsunami and earthquake experts had been investigating for years and concluded that it was not predictable. There may be different opinions, but so far no clear evidence shows that it was predictable.
I don't think this post was limited on side projects. Many people reading this are working, or will work in environments where safety and correctness are important, if not critical.
Very few software projects have potential consequences on the scale of a nuclear reactor disaster. If your project does, then "release early" and many other popular software practices will probably not apply.
Relatively few, but they're everywhere -- Auto-pilot on airplanes. ABS brakes. Self-driving cars.
"Releasing early", in the sense of getting these things into the real world as early as possible so they can be iterated on with real-world data is actually pretty crucial if you think about it.
The key here is figuring out how to release gently. The greater the risk, the more iteratively and more gently you should be releasing. If you were building landing gear controllers for passenger planes and your plan for release was to spend a really long time planning really carefully, testing like crazy in non-real-world conditions and finally doing a world-wide, all-commercial flight roll-out at once, I'm likely to pass on air travel for a while (and keep a lookout overhead).
When people talk about releasing early, they're not talking about big bang releases at all. There are alphas, betas, feature toggles, a/b tests, and dark paths for a reason.
I think that's actually kind of debatable. There are plenty of things that happen online that can, for example, expose kids to pedophiles, give channels for illegal and/or immoral activities, etc.
We are currently wrestling with questions that can be personal catastrophes due to the existence of personal tech, such as teens sexting each other and sending each other sexy photos and being charged with promoting child pornography or crap like that. If the phones and apps did not exist, they would probably be showing each other their bits in person instead and (in many cases) this would be perfectly legal. Get a phone involved, suddenly one or both of them can potentially go to jail.
But you just keep believing that software development is harmless, good clean fun. Yeah.
Sorry, didn't mean to be snarky. Chrome 57 supports grids, but I am aware that support for grids is far from common. Hope you could enjoy the article anyway.
* First minimum viable product (core features) - clearly label as such
* Take feedback from /customers/ (and those who claim they'd be if X were a feature; 'market research')
* If possible use any existing off the shelf process**
if there's a concept of how the process might be streamlined / optimized / customized / automated in full.
What if you don't even know what your "market" is or your "value" ie. what you're selling?
edit: haha Dunning-Krueger effect, been a while since I used/looked at that "word"
You don't floss? Gross haha. Can't say all the time but inevitably there's crap in between your teeth. Oh well to each his own. I guess it depends where you are/if floss is common thing to have.
Why did you separate A K A? Is that how it's written, time to Google.
