3 Phases of Roadmapping

Lots of stories around roadmaps & planning have been told. Neither being interested in repeat one, nor having a solid, “book-ready” framework myself, I still want to share my experience in working on roadmaps and describe the most effective process & framework I’ve found for myself.

Not a silver bullet, so please don’t hold me to it. Every product is similar & different in its own.

The immediate advantage of my framework that it is so simple that I was able to sketch it myself. (No fancy charts or drawings though, sorry).

My roadmap process is not “one size fits all”. It takes into consideration different phases of product lifecycle and maturity, and it’s split into 3 phases. (In fact — 4, we we’ll talk about the last one later.)

  1. First phase is a “problem driven approach”. 
    When? It’s most commonly used when you are starting something, going with an MVP, testing product/market fit, or your hypothesis. 
    It is often high level (mind you, this is roadmap, not a backlog) and may sound like: “One-click sharing of content into N social networks for professional users”. It defines problem, environment & user keeping it abstract enough to remain actionable but leaving enough of wiggle room.
  2. The second phase is a “persona driven approach”. Once you nailed down a problem, you are ready to define personas of your product (most likely you’ve got more then one). 
    When? I like to use to define end to end experience, complete user journey, full user life cycle within your product.
    It actually has quite a few “sub-structures” by itself. You can use personas, you can use “roles” (personas might have “1 to many” roles) or you can even “personify” features. This roadmap item may sound like: “Luxury lover persona”, “Publisher role” or “The accountant screen”. As I mentioned previously, it defines persona or role.
  3. The third phase is a “metrics driven approach”. This is your “trial and error” one.
    When? I like it within “growth hacking” context. Growth marketing, marketing engineering, experimentation — you name it.
    This one has to be more specific: it should be easy to understand, you should know what you are comparing it to & it should define whether it’s habit/behavior changing. Beware: that’s a tricky one. Don’t abuse: it does indeed encourage “trial and error” culture that can be damaging (e.g. don’t test something that you know will fail anyway, intuition is a skill given for a reason to PMs!). Also, make sure you don’t leave the big picture out. Improvement on one metric should be carefully weighted with understanding of incurred loss on another.
  4. Last but not least is the ? phase. 
    When? There are going to be cases when the strategic/alliance decision has to be made to achieve goals that are not directly addressed/represent value to the customers of the product. Something that you might call “technical debt” in engineering. Although it’s not technical. And not necessary is a debt. :)
Note: triangle does not define substructure, but merely the scope of the roadmap item you want to cover. Thus “persona” approach is not sub-section of a “problem”. They do exist in parallel.

Finally, I would to briefly touch on planning time-window. I never have more than 3 buckets: next 1–2 quarters, next 12–24 months, and everything else. The names/tags for these buckets are extremely vague. You can easily name them: now, next, future. As long as you take a good care of actualization of these, you got it.

Do you find this framework useful? Have you used something different? Challenge me. :)