Unkown Unknowns: Why you should release early(danielk.se)
danielk.se
Unkown Unknowns: Why you should release early
https://www.danielk.se/post/releaseearly/
93 comments
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.
That's not what "release early" means (to me at least). Once you have big PR push you better have your product ready...
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.
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.
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.
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.
So, ask yourself, are you just trying to make money? Or are you trying to solve a real problem and think you have a better way?
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.
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.
Surely all successful entrepreneurs are in it to help mankind and make the world a better place. What else could possibly motivate them?
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.
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.
Sex, drugs and rock and roll.
But, mostly, money.
But, mostly, money.
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 :)
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.
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.
Good site!
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.
There are a lot of people.
Sure, but the first people might build the momentum, or not.
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.
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.
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.
The saying is true: "money talks and bs walks". Can you charge them for your project?
Clever title :) By releasing the article early, the typo is spotted quickly.
Aaaand... it's been corrected :) I wonder now if the author meant to do that? Are they iterating even on blog posts?
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...
I was looking at this too, surprised it was not fixed on the HN side yet considering how often submission titles get updated here.
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.
The title on the blog post page itself seems to be corrected now, but not on the user's home page.
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.
Write code when doing it manually is too painful.
Write code when doing it manually is too painful.
In some sense this is the biggest strength of nontechnical cofounders: defaulting to finding a way to test their hypotheses without writing code.
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.
The grass is always greener...
The grass is always greener...
Haha. Coders can get a lot of things done, but are they the right things? Sometimes it can be so fun to build that you don't actually ship.
I am still not shipping. I also make a lot less money than coders.
Six of one, half dozen of the other...
Six of one, half dozen of the other...
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.
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.
Mark Twain apparently did not say the opening quote.
https://newrepublic.com/minutes/126677/it-aint-dont-know-get...
The link within the link: http://quoteinvestigator.com/2015/05/30/better-know/
https://newrepublic.com/minutes/126677/it-aint-dont-know-get...
The link within the link: http://quoteinvestigator.com/2015/05/30/better-know/
How I would define 'early':
* 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**
Don't confuse this with releasing buggy code (don't do that, it's really hard to recover from), it's about features.
Sometimes you'll have a really good product, that no one wants ... See Silicon Valley TV series.
It's unclear what product or company on Silicon Valley or the show itself you are referring to.
I'm referring to the fictional PiedPiper product in the show
http://www.piedpiper.com/
The show itself is also great.
The show itself is also great.
The problem with realeasing early is that -early- is not clearly defined for your project...
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.
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.
Typo
Typo: "your wrong" => "you're wrong".
Modern CSS that doesn't support my browser but the author is still a human (;
Modern CSS that doesn't support my browser but the author is still a human (;
Thank you for pointing out the typo, after devastating shame I have now fixed all instance of it, I hope :)
One benefit of running your own blog is being able to use the CSS you want ;)
One benefit of running your own blog is being able to use the CSS you want ;)
Oh I know about breaking things with CSS for fun, this is mine: https://picnicss.com/
I'll probably reference this post later on, good topic and well applied to software dev.
I'll probably reference this post later on, good topic and well applied to software dev.
Huh?
Thanks, maybe I released a bit to early :)
It's never just one typo. :-P
preferrably → preferably
Unkown → Unknown
Unknows → Unknowns
a.k.a → a.k.a.
it’s is → it is
erraneous → erroneous
preferrably → preferably
Unkown → Unknown
Unknows → Unknowns
a.k.a → a.k.a.
it’s is → it is
erraneous → erroneous
This reminds me of an article I read about a week ago: https://hackernoon.com/the-mvp-is-dead-long-live-the-rat-233...
Reads like the spiral dev model.
> Your browser does not support grids. Upgrade or suffer the subpar layout.
Chrome? But OK, snark at me anyway..
Chrome? But OK, snark at me anyway..
Have you restarted it recently? CSS Grid support without flags in mainstream is very recent (last week?).
37% isn't exactly mainstream... to contrast, flexbox is at 97%
http://caniuse.com/#search=grid
http://caniuse.com/#search=grid
latest version, not mainstream as in a lot of browsers support it.
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.
Unknown unknowns also is a reason for the opposite - to be more careful releasing things that might be dangerous.
Often dangerous failures that happen are unknown unknowns. Fukushima is just one example for this.
Often dangerous failures that happen are unknown unknowns. Fukushima is just one example for this.
Fukushima wasn't an unknown unknown. The consequences of that event were fairly preventable.
http://mdcsystems.com/fukushima-dai-ichi-black-swan-event-or...
http://mdcsystems.com/fukushima-dai-ichi-black-swan-event-or...
"... 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
http://knowledge.wharton.upenn.edu/article/nassim-nicholas-t...
source: Nassim Nicholas Taleb on Accepting Uncertainty, Embracing Volatility
http://knowledge.wharton.upenn.edu/article/nassim-nicholas-t...
It was preventable, but as the Tokyo District Public Prosecutors Office says, it was not predictable.
Aftermath is easy :)
> it was not predictable
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...
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...
it is better: Taleb (2009) https://www.edge.org/3rd_culture/taleb09/taleb09_index.html
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."
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."
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.
Are you planning on building a nuclear reactor as your next side project by any chance?
You say that like it's some crazy idea. It's not.
http://www.bbc.com/news/10385853
https://en.wikipedia.org/wiki/Taylor_Wilson
Several dozen amateur physicists have accomplished it.
http://www.bbc.com/news/10385853
https://en.wikipedia.org/wiki/Taylor_Wilson
Several dozen amateur physicists have accomplished it.
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.
Did you just compare a nuclear power plant explosion to releasing an app in beta...?
Depends on what the app is about. Not necessarily as crazy as you make it sound.
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.
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.
"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.
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.
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.
[deleted]
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.
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.
[deleted]
> I know flossing is good, my dentist even claims it is essential. I don’t doubt he’s right.
The medical evidence for the efficacy of flossing is fairly scant: http://www.vox.com/2016/8/2/12352226/dental-floss-even-work
The medical evidence for the efficacy of flossing is fairly scant: http://www.vox.com/2016/8/2/12352226/dental-floss-even-work
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.
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.
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.
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.
Anecdata of course but my dentist always seems to remove little food bits flossing during a checkup that weren't removed in brushing just before.
After the last checkup he recommended an automatic flossing machine (Waterpik).
After the last checkup he recommended an automatic flossing machine (Waterpik).
[deleted]