As part of my 3-article series on Product Management, this article talks about Customer Journey Map and Product Roadmap. You can read the first two articles here:
Overview – A product roadmap visualizes and communicates the plan for how your product is going to meet a set of business objectives. It details the direction of your product and the work required to get there. Product roadmap creation is often a huge topic of debate for a lot of organizations. The best way to start this conversation is by explaining what a product roadmap is not.
What is Not a Product Roadmap?
In my experience I’ve seen some product roadmaps that communicated expected releases with specific dates two years out... That kind of communication can get a Product Team in a lot of trouble and potentially create hardship with the business team for not meeting delivery dates (that is not to say you cannot plan to address a major opportunity several quarters down the road) specifically in an agile environment. Furthermore, a product roadmap is not a developer schedule plan. I’ve seen roadmaps that communicated to the business team engineering task that would take place in the following month.
Sally in sales doesn’t care about databases migration or refactoring of an API. While communicating migrations and refactoring are important it can create a ton of noise in a product roadmap. Lastly, a product roadmap should not be viewed as a very rigid contract with the business team. Agility and flexibility need to be considered when analyzing the right roadmap, which is why thematic roadmaps have become so popular over the past couple of years.
Evolution of Product Roadmaps
In the early days of technology product roadmaps were merely a Gantt Chart with features and timelines that extend past a year. The problem with this way of thinking is that the product roadmap does not communicate the problem that it’s trying to solve and essentially communicates to a targeted audience that thinks in terms of features versus solutions. In my experience, this type of paradigm shift is critical and must be adopted on all levels of leadership.
Product roadmaps should address the opportunity from a business perspective. Historically, the further out in time a roadmap extends the lower the confidence level of that specific solution being built. This has a lot to do with market changes, client commitments, evolution of technology and shifts in priority. To address this problem software development has transitioned from Waterfall to Agile. Agile allows teams to react to market and user changes rapidly. Unfortunately, over the years Product Roadmaps have not kept up with the evolution of Agile Software Development. A lot of this has to do with the need of a paradigm shift in the company culture of business teams understanding agile and being in constant communication with product leadership as to what is currently being developed and what will be developed in the near future.
Prioritization – In the previous article we discussed Opportunities and Discovery. Within that conversation we mentioned the importance of prioritization in order to ensure teams are spending their time in discovery of high valued opportunities. I can’t think of a conversation about product roadmaps where prioritization does not come up. Once opportunities find its way to a product backlog and user journey maps have been created, it is time to conduct another round of prioritization. This second round of prioritization is necessary due to changes that may have been uncovered during discovery (brain storming activities and models may be used before in-depth discovery of an opportunity. In other words, this can be done as part of the first round of prioritization). A widely used model and one that I have used in the past to help in prioritization is what's called a Kano Model. Named after the Japanese professor from Toyko. This model was originally used for Six Sigma and evaluation of quality and control. This model can be used in the technology space to evaluate customer satisfaction based on the level of functionality. Opportunities in the upper most right-hand corner should be prioritized higher than the rest in other quadrants also taking into consideration the business goals.
Audience - In my experience there is no silver bullet for a roadmap visualization. Often, product roadmaps can take on different views depending on the audience. It's not uncommon to have C-level executives that want to see a roadmap extend past 1-2 years or an engineering team that ABSOLUTELY wants no commitment to dates or a client that would like for you to hit a specific milestone. That is why not all product roadmaps are created equal. I personally try to stay away from communicating specific dates. However, not all Product Managers have the leverage to push an organization to stay completely away from dates (that is the harsh reality of product and roadmaps). There are some great software solutions out there in the market that allows roadmaps to be transformed based on the audience that you are communicating to.
Developing Product Roadmap
The below are Github and Slack’s product roadmap. Both organizations use a Kanban style product roadmap. Github communicates in terms of a time range within a quarter, whereas Slack communicates timeframes without dates. The only right way is one that communicates a shared understanding of the problem the team is trying to solve.
GitHub’s Product Roadmap
Slack’s API Product Roadmap
Customer Journey Map
Overview – The customer journey map is one of the most critical visual display tools in the product/UX space.
It serves several purposes:
- It is a great exercise for the team, and everyone involved in understanding a specific persona and its user phases.
- It helps build a shared understanding on the users' actions.
- It calls out pain points and opportunities for that specific user during the different phases.
When I first started this exercise in my product career, it was not uncommon to use sticky notes in a workshop like environment and then post the results on a word document and convert it to a PDF. However, some companies are now outsourcing this task to different agencies using a specific software to craft and tailor a user journey map that can be shared throughout the organization. Whether you’re using the scrappy approach or a slick visual design approach, what matters most is the details.
The biggest misconception in my opinion about Customer Journey Maps is that it is a “one and done” exercise, meaning it is rarely revisited. If you’re in the product space, Customer Journey Maps should not be a new concept, but what can be a little refreshing in how you think about this is to revisit the journey map within a certain cadence to see if anything has changed. There have been times when I’ve worked with clients who were very excited to tell me they have a Customer Journey Map. However, whenever I started to questions around the journey map that is when things became tricky. This task is an art, but validation of assumptions is a science, and this is something that should be part of a definition of done when creating this artifact.
Persona and Phases - In the previous article we discussed the importance of building a persona profile. Things can get tricky when building a persona profile especially in a B2B environment. An accountant for a small CPA firm can have totally different duties, responsibilities, and pain points from someone at an enterprise size firm. This is where organizations must be cognizant of market segmentation and how they impact personas and call it out in the Customer Journey Map.
When documenting phases or a process it is essential that the team calls out the “big actions.” A good ice breaker exercise before a team starts creating the customer journey map is to look at the process of getting up in the morning and getting ready for work. Think about all the steps it took to get to work from getting out of bed to brushing your teeth to taking a shower, to putting on clothes and to driving your car to work. Think about the experience you had with every step in the process. Now think about how you felt in every step. Were you mad, happy, sad, excited or indifferent? Now think about all the task involved in each step. How long did each step take (on average) and where their opportunities to shorten your shower time? What actions could you have been taken? These are all related questions that you would want to answer in a Customer Journey Map.
Pain Points and Opportunities – Like stated previously with our “Get to Work” example, each step in the process will present some pain points. I know for me spending time to make breakfast is not enjoyable. I don’t like the time it takes to make breakfast. It makes me feel upset. Therefore, this can be considered my pain point. I am sure by now you’re probably thinking of several opportunities for improvement.
Below is a great example of a Customer Journey from Quarloo.com. It shows Michael's journey to find contact information for an agency or electrical official. The following key components are represented in the Customer Journey Map:
- Pain Points
We have explored the details of building Product Roadmap and Customer Journey mapping. The details about Product Roadmap and User Journey mapping unveils why is it important for business and product teams to plan things before jumping the gun. While the plan and roadmap do not always stick to the hard and fast number timelines, it gives readymade action plan to change things with agility whenever required.
At Qentelli, we work with clients to infuse product mindset in teams to go beyond the development process and break the traditional outsourcing model by product-led approach to software delivery partnerships.