diff --git a/HowToBuildFPR.md b/HowToBuildFPR.md
index 52ee0c5..a86ad4f 100644
--- a/HowToBuildFPR.md
+++ b/HowToBuildFPR.md
@@ -34,7 +34,7 @@ These build instructions are always subject to change. You should be familiar wi
     * **Warning:** if you don't do something like `git update-index --skip-worktree netwerk/protocol/http/OptimizedFor.h`, this change will end up in any pull requests you issue and _we won't accept them_!
 1. (Optional) If you want to change the reported version numbers, alter `browser/config/version.txt` for the reported browser version, `browser/config/version_display.txt` for the _displayed_ browser version (this is where we usually put the long FPR string), and `config/milestone.txt` for the reported Gecko version.
     * We don't allow these changes in pull requests either! Consider setting `skip-worktree` on these files also if you change them!
-1. Once you're ready, if you are cleaning out an old build, be sure to `rm -rf configure obj-ff-dbg/` first. Then,
+1. Once you're ready, if you are cleaning out an old build, or you need to "clobber" the current build, be sure to `rm -rf configure obj-ff-dbg/` first. Then,
 
         autoconf213
         gmake -f client.mk build 
@@ -42,7 +42,8 @@ These build instructions are always subject to change. You should be familiar wi
 ## Known build issues
 
 * Until [issue 202](/classilla/tenfourfox/issues/202) is fixed, you will get spurious errors setting up the Python environment. You can ignore these for now.
-* If your build seems to intermittently crash with an `internal compiler error`, you may be running out of memory. Restarting the build will usually get past the block (it will pick up where it left off). Alternatively, remove `-j2` from the `.mozconfig` build flags: this will only run one compiler instance at once, so the build will be slower, but it will be much less likely to experience memory pressure.
+* If your build seems to intermittently crash with an `internal compiler error`, you may be running out of memory. Resuming the build with `gmake -f client.mk build` will usually get past the block (it will pick up where it left off). Alternatively, remove `-j2` from the `.mozconfig` build flags: this will only run one compiler instance at once, so the build will be slower, but it will be much less likely to experience memory pressure.
+* If you get a message saying you need to "clobber" your build, clean your previous build as instructed above.
 * If you are making an optimized build, you will get warnings about `N_SECT` while linking and stripping XUL. These are harmless. If you actually get an error and it doesn't build, then somehow you are using the original `strip`. Check your binaries carefully. 
 
 ## Running and debugging
@@ -67,4 +68,4 @@ If you built on 10.5 with a compiler that was also built on 10.5, your built bro
 
 ## Keeping up
 
-Your repo is now a fully functional clone of the TenFourFox source repository, and you can simply `git pull` to get new changes (merging them with your local changes as appropriate).
\ No newline at end of file
+Your repo is now a fully functional clone of the TenFourFox source repository, and you can simply `git pull` to get new changes (merging them with your local changes as appropriate). You can then incrementally update your build with `gmake -f client.mk build` to incorporate the new changes. Make sure the browser isn't running!
\ No newline at end of file