What product management course would be complete without a discussion about roadmaps? We've talked about the scale friendly methods and how they're extremely plan driven. Everybody loves a plan because it creates at least the appearance of certainty and emotionally we crave that certainty. In innovation friendly methods and certainly in agile, we work in small increments with lots of observation about what's really working and we iterate from there. Now, that said, there is a need for strategic direction and focus and certain intermediate visibilities as we go along. And, the key things, I would say, are to have a view of your happy place. How do we do really great on this dimension of desirability building wonderful product, what does that mean? So for example with Enable quiz, it might mean a leadership position in technical skills assessments, in this general area of skills management. And then, how do we do really great on these feasibility dimensions? Building a nice, durable yet flexible technology infrastructure, and this dimension of viability, make a lot of money. It's important to have a view of that and that everybody understands like where are we headed, what's the destination. Because emotionally, we need that, it answers a lot of practical questions about where we should focus and how we should develop our capabilities and our talent as a company, and so you will probably need to help with that. In the short-term, we're doing these agile iterations, we're watching what's happening, we have a very tactical view of how we iterate. And then, what about the middle here? Say maybe six months out. Well, it may be helpful first your internal and external stakeholders, your customers, to understand well what problems are we going to generally solve. So for example with Enable quiz, maybe they say that we're registering a lot of discontent among your customers with having to create so many logins to the systems, so we are going to focus on enterprise single sign on. And we don't know yet if it's going to be around the Microsoft Active Directory stuff, or the Google apps, or some HR Learning Management System, but that's where we're headed in the next six months. And that may help your internal dev teams, your external customers have an idea about what's coming and that may be useful. To go to much more detail, I think it's really important to look at the individual stakeholders we're trying to serve with this and what problems we're trying to solve for them. Customers may have a certain need for visibility about where you're headed. They have their own plans they need to make, and they may over blow that a little bit sometimes, but that may very well exist for your particular product. Stay focused with them on the specific decision they need to make, and how they need to make it, and do your best to service that. What won't benefit either of you is if you just lock everything in. Because even if they say the customer says they think they want that, they're not going to like it when in six months there's some hugely critical thing that you both think would be a great addition to the product, but you can't do it because you've already locked yourself in. Your sales and marketing team will sort of presumably kind of a mirror of that and they work with them to communicate this idea and this focus and make it work and get feedback from them about how it is working, and focus them on the problems we need to solve for the market, and what underlying need really exists there for the customer. So that you do the best you can, to give them the visibility that they need. If we look at finance and management, they have pretty similar needs around externally setting expectations about what kind of revenue the company is going to create, what kind of costs they're going to have, what the earnings picture is, and also managing internally how people are doing and what's going on. They would love to know every dollar of revenue you're going to create over the next two years and how much money you need to invest to get there, obviously, they probably understand that you don't know that either. Create the best forecast and model you can for them based on your visibility. And if you will need to do this to the third decimal place, that visibility you don't have, just don't waste a lot of time on that. Create estimators, or heuristic tools to just create those estimates, rather than spending a lot of time, A, creating a false sense of visibility they don't really have, and B, wasting valuable time you could be investing in making more money, making better product. For the internal purposes, you have your metrics that you're focused on, it is important to relate those to management objectives. OKR, Objectives and Key Results is a popular framework for doing this. Just make sure that you're managing upwards to bridge the distance between the metrics you're focused on with the development of your product, and the objectives the company has as a whole. Make sure you're able to bridge that distance. Your delivery teams will say data science and development and you're working with project management. They would love to know every feature you're going to need to build over time so that they could make choices about their technology infrastructures, they also know that you don't have that visibility yet and it's not in everyone's best interests to specify those things. But if you give them a good idea of what problems you are trying to solve for the customer over time and where you're headed, the best case scenario is you have a rich interchange with them where they're bringing you ideas about what they're seeing in terms of the tool sets and the technologies that you all are using, that may create opportunities you weren't even aware of. So that's what I would look for there, help them make the decisions they need to make, give them the best visibility you can. Project management will presumably be a partner in this if they're doing agile, they're just trying to make this more iterate view of things work, but visibility will help them as well. There isn't a simple solution to this but there is a process that will work which is to look at your stakeholders individually, make sure you're focused on solving the right problem for them, rather than making a lot of work and creating a false visibility for everyone about things you don't really know about. That's where I would focus your work on the roadmap. Good luck.
