Unkown Unknowns: Why you should release early
danielk.se
danielk.se
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 :)
If the first, yeah, dude, you are basically toast. If the second, you may be able to rise from the dead again. It just may take a while.
But, mostly, money.
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.
It's also kind of hard to get meaningful feedback without some kind of big PR push.
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.
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.
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.
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.
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.
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.
Write code when doing it manually is too painful.
The grass is always greener...
Six of one, half dozen of the other...
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.
The medical evidence for the efficacy of flossing is fairly scant: http://www.vox.com/2016/8/2/12352226/dental-floss-even-work
Feel free to file this anecdata as appropriate to your needs.
Electric toothbrushes are also great for keeping your teeth very clean, and can penetrate between your teeth depending on the design.
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.
After the last checkup he recommended an automatic flossing machine (Waterpik).
https://newrepublic.com/minutes/126677/it-aint-dont-know-get...
The link within the link: http://quoteinvestigator.com/2015/05/30/better-know/
Often dangerous failures that happen are unknown unknowns. Fukushima is just one example for this.
http://mdcsystems.com/fukushima-dai-ichi-black-swan-event-or...
How do you explain the fact that this exact scenario was predicted in advance then? E.g.: https://news.usc.edu/86362/fukushima-disaster-was-preventabl...
TEN PRINCIPLES FOR A BLACK-SWAN-ROBUST WORLD
"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."
source: Nassim Nicholas Taleb on Accepting Uncertainty, Embracing Volatility
http://knowledge.wharton.upenn.edu/article/nassim-nicholas-t...
http://www.bbc.com/news/10385853
https://en.wikipedia.org/wiki/Taylor_Wilson
Several dozen amateur physicists have accomplished it.
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.
"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.
Before self-driving cars hit public urban areas, self-driving trucks have been working on private mining roads (https://qz.com/874589/rio-tinto-is-using-self-driving-416-to...). Auto-pilot on airplanes can still today be turned off or on as desired.
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.
Chrome? But OK, snark at me 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**
The show itself is also great.
Modern CSS that doesn't support my browser but the author is still a human (;
One benefit of running your own blog is being able to use the CSS you want ;)
I'll probably reference this post later on, good topic and well applied to software dev.
- "If your not a domain expert..."
- "No, it’s not the techniques your lacking."
preferrably → preferably
Unkown → Unknown
Unknows → Unknowns
a.k.a → a.k.a.
it’s is → it is
erraneous → erroneous
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.