Add "Product Review" protocol before "Code Review"

Our core workflow has been:

* Work in feature branch.
* Open GitHub pull request for code review.
* Make changes based on teammate feedback.
* Merge into master.
* Push to staging.
* Get feedback on the product in-browser from teammates.

This generally works well.

However, when something isn't quite right with the product
and the developer needs to make changes,
the feedback loop is too slow.

Fast-moving startup teams may want to blame code reviews for causing problems.
However, fewer or sloppier reviews lead to
problems like bugs and hard-to-change code.
We still highly value code reviews.

Our hypothesis is that the root problem is that the steps are out of order.
What if we performed "Product Review" before "Code Review"?

![Product before Code](http://f.cl.ly/items/1k2b2T1b3v2O1d0A0p3z/Screen%20Shot%202013-05-19%20at%204.57.03%20PM.png)

Moving "Product Review" before "Code Review" in our core workflow
can be solved in different ways.

The most effective is when [teammates are available in person.
However, that's not always feasible.

Many teams value remote work due to teammates' choices of
where they want to live and when they want to work.

In the absence of *always* having teammates
who are *always* available in person,
we have [experimented with approaches] for about 18 months.

[experimented with approaches]: http://botcave.thoughtbot.com/ssh-tunnels-for-sharing-development-branches-in-browser-development-platform-as-a-service-and-more

This pull request captures the conclusions of the successful experiments.

protocol/ios/README.md

@@ -41,7 +41,12 @@ Install the app's dependencies.
 Git Protocol
 ------------
 
-Follow the normal [Git Protocol](/protocol/git).
+Follow the normal [Git protocol](/protocol/git).
+
+Product Review
+--------------
+
+Follow the normal [Product Review protocol](/protocol/product-review).
 
 Code Review
 -----------

protocol/product-review/README.md

@@ -0,0 +1,46 @@
+Product Review
+==============
+
+Cut down cycle time and focus on the user
+by getting a teammate to review your changes to the product
+before you get a code review or deploy to staging.
+
+For each change, choose one of four techniques:
+
+* In-person
+* Screencast
+* SSH tunnel
+* Video chat and screenshare
+
+In-person
+---------
+
+If they are sitting next to you,
+have them review the changes in person.
+
+Screencast
+----------
+
+Use [Licecap] to share a screencast gif in the project's [Slack] channel.
+
+[Licecap]: http://www.cockos.com/licecap/
+[Slack]: https://slack.com/
+
+SSH tunnel
+----------
+
+Use [ngrok] to set up an SSH tunnel to your work in progress on your laptop:
+
+[ngrok]: https://ngrok.com/
+
+    ngrok -subdomain=feature-branch-name 3000
+
+Then, share the ngrok URL in the project's Slack channel.
+
+Video chat and screenshare
+--------------------------
+
+Start a Google Hangout in the project's Slack channel:
+
+    /hangout
+

protocol/rails/README.md

@@ -44,14 +44,19 @@ Use [Foreman](https://github.com/ddollar/foreman) to run the app locally.
 
     foreman start
 
-It uses your `.env` file and `Procfile` to run processes just like Heroku's
-[Cedar](https://devcenter.heroku.com/articles/cedar/) stack.
+It uses your `.env` file and `Procfile` to run processes
+like Heroku's [Cedar](https://devcenter.heroku.com/articles/cedar/) stack.
 
 Git Protocol
 ------------
 
 Follow the normal [Git Protocol](/protocol/git).
 
+Product Review
+--------------
+
+Follow the normal [Product Review protocol](/protocol/product-review).
+
 Code Review
 -----------