Planning your product's release journey

When working in an agile environment (or an environment that aspires to be agile) defining a product roadmap through a series of iterations is crucial to the success of the effort and the team.  The iteration milestones largely determine the external and internal feedback points, along with which comes the ability of a project to adjust its approach to the product.  Therefore, the choice of iteration milestones, their position in time and in the problem space, and their separation and cadence can both enhance and detract from a project’s likelihood of success.

When discussing the process of forming a product roadmap, one often hears of the analogy of planning a long journey.  The overall plan for the trip represents the overall product roadmap.  Waypoints in major cities represent Iteration milestones.  And the first major city stopover represents the MVP (minimum viable product).

However, this analogy breaks down in several key ways.  First, when experiencing an actual trip, the traveler experiences and receives feedback while en route.  Whereas this feedback from the users/market is not provided in a product journey, unless explicitly solicited and acquired.  And even when the feedback is acquired, its validity is sometimes difficult to ascertain, unlike the validity of the feedback received by our traveler.

Second, on an actual trip that most travelers take, the type of feedback that we get rarely makes a material difference in the subsequent stops.  Whereas feedback from the users/market can (and should) have real impact on the product plan, both in the tactical sense (e.g. usability) and in the strategic sense (e.g. certain modules receiving outsized usage).  The type of feedback received on a product journey is much in common with to the information gathered on a travel-based mystery, when an investigator moves from place to place based on clues found along the way.

And lastly, given our familiarity with the physical world and its realities, the traveler never plans a trip without some contingency and margin for error.  Whether it be the amount of time that we allow for a connecting flight at Heathrow, the predictably difficult traffic in Noida, or delays on the local subway, we intuitively allow for a certain amount of friction and are very aware when we are operating with a reduced margin of error.

Therefore, when planning your release journey, consider the following:

• Gain user feedback absolutely as early as it is possible to gather it through real-world testing.  The critical qualifier here is “real-world”.  This means that surveys don’t fully qualify, nor does testing involving wireframes or click-through demos.  These mechanisms don’t test the real users in a real context.
• While qualitative feedback is interesting, quantitative feedback is actionable.  This is literally as simple as the difference between the objective and the subjective.  So identify measurements, instrument the system to capture them, and analyze accordingly.
• Getting to production quickly with a truly minimal MVP is perhaps the single biggest risk reducing gift you can give to a product.  Going live ensures that all sorts of non-functional considerations get attention and, most importantly, exercise the deployment mechanism, production infrastructure, and support processes.
• Sequential milestones do not necessarily need to focus on the same area.  That is, there may be benefit to alternating milestones between areas of functionality/scope.
• The more frequent the milestones, the more opportunities for feedback.  And more frequent milestones necessarily triggers a focus on smaller release sizes (all other factors being equal).
• Maintain high quality during release milestones.  In addition to accruing technical debt, allowing quality to slip generally invalidates feedback and will require another release to obtain that effective feedback.

While there are certainly other items to consider when crafting a release roadmap, these are some that have proven valuable in my experience.