To Go Anywhere, At Least Four Things Are Useful
Any of these four may actually be challenging to acquire.
There’s probably as many ways to do product roadmapping and define feature priorities as there are product managers. Most any skilled product manager with any degree of experience is familiar with both Waterfall and Agile methods, at least in concept. Not everyone has necessarily been formerly trained in either or both. Most often, a true pro will at least seek out self-learning resources to really understand their chosen method. They may choose to diverge from full on formal Work Breakdown Structures, (in the case of Waterful), or may not be using formerly defined Scrum methods, (in the case of Agile).
Regardless of method, in most smaller development efforts some basic ideas have to start somewhere. Whether this is with a defined Product Manager role, a product oriented CEO, the Marketing Department or wherever, you’re still at the very, very early idea stage. Long before an idea even gets to any kind of Sprint planning meeting or a line item in a Project Plan, there’s probably a high level gut check first. In smaller start-up organizations, a lot of times these are first generated in simple spreadsheets; be they Excel or increasingly something shared such as a Google Docs spreadsheet. Of course, there’s been an explosion of tools from the basic idea level through the full development life cycle, but nevertheless, there’s some very basic, simple judgments that are useful first.
Leaving aside fancy tools for a moment and sticking with a relatively simplistic model, a method I’ve found to work reasonably well both at some prior full time positions and with various clients has been based on a method expressed by Bruce McCarthy. It involves Goals along with Value and Effort judgments to maybe get you in the ballpark. I’ve developed a simple Google Sheet I’ll share with you in a moment. First, take a look at this presentation:
As you can see, this is a really basic tool for getting your head around some basic features. This can all be done very quickly. (Or not. You can do as much research as you would like prior.) The thing is, you can do this fast before you clutter up Jira or Trello or whatever you’re using with tons of Backlog items that just end up in an Icebox forever. I’m looking forward to Bruce’s company releasing a final version of their Reqqs tool. But in the meantime, let me share with you this Google Doc Sheet you can copy to your own Drive or into Excel or whatever you’re using. It follows Bruce’s basic concept, though I’ve added some additional tabs if you’d like to use those as a poor person’s priority planning sheet. The additional tabs are for things like a Competitive Grid, some quick feature explanations, info about Competitors and so on.
Let me know if you have any issues with the sheet or suggestions for improvement. I remind you that this isn’t intended to be overly fancy or sophisticated. Just fast.
You’ll quickly see you that you just dump a bunch of ideas in here and sort out where they may fit in your overall priorities. There are tools for this stage as well. While I’ve not tried them out yet, Aha! and ProdPad are two that I’m aware of. Both integrate with Jira, GitHub and others when you’re ready to port one or more of the features into a Backlog for Sprint planning.
Product Roadmap = Strategic | Product Backlog = Tactical
What it really gets down to is that roadmapping is – generally – more Strategic. Whereas the moment you get into actual build, it’s tactical. One basic premise of Agile is that you’re iterating towards a goal in a universe with potentially quickly changing requirements. This is – supposedly – one of its advantages over Waterfall Methods that – again supposedly – are more static and don’t anticipate change as well. Of course, even though all the cool kids use Agile these days, Waterfall still has its place for some project types. And you really ought to be careful about using Agile as a buzzword to describe your Evernote To Do list vs. actually using proper Agile methods.
Anyway, just because you’re using Agile methods does not at all mean someone somewhere shouldn’t be looking at a very large picture of marketplace and customers. Sprint planning is not where you’re likely to be trying to get upper management, customer or vendor buy in on basic ideas. In a more serious formal environment, it’s not where your’re calculating Net Present Value (NPV) of potential investments, or asking fundamental value questions with regards to a competitive marketplace or customers. That should have come earlier. This doesn’t mean that you as a Product Manager are doing all this alone. There’s no reason not to involve others early in this process if your organization can be inclusive that way. At the same time, you don’t want to waste tons of engineering time on such things either. You may need to involve engineering at some level or another to get a really high level idea of costs, but this part of planning is your job. Maybe with the CEO. Maybe with marketing. Whomever. It comes before Sprint Planning.
By the time you’re ready to actually expend production resources, you probably should be able to answer for whom your building a feature, the value or what’s driving the purpose, (maybe a regulatory requirement or whatever), how you’re going to measure impact, and possibly more.
Because you owe it to your team. Yes, of course you owe it to your company and your boss to be trying to do the right things all the time. And of course as well to stockholders; which you yourself may be in the form of those Magic Jelly Beans Stock Options. But there’s something more. The Creatives and Engineers and others with whom you work also owe the Company the same things you do. You all owe your best work as a matter of economic principle. Still… there’s still something more. You also have a social responsibility within your team. Their individual areas of expertise are what allow for the actual Creation of Some Thing(s). They need to do this well. But for those things to succeed in the marketplace, YOU, as a Product Manager/Owner/Leader, need to have properly chosen the RIGHT things to do in the first place. The things that provide value. The things that allow you and your boss and your colleagues to pay their mortgage/rent, buy food and so on.
Neither Waterfall nor Agile methods determine what these right things to do might be. Competitive Strategy, Pricing and general New Product Development are each alone and together wholly separate and deep topics. Together and with other disciplines as well, they inform your product feature considerations and roadmapping prioritization long before you start expending production resources towards build. Agile methods to create with an eye towards changing requirements in a changing world does not negate a product owner’s responsibility to at least try to get it right in the first place. Iteration towards value is of course wonderful chocolately goodness. Using it improperly as a crutch to make up for lack of proper planning is… yes… you already know, very bad.
So use product roadmaps. Find a technique that works for you and your organization. You’ll be glad you did. As will your boss. And your Colleagues. And your Clients. Even some of your Facebook friends. (Not sure about Mom and Dad. They still might not quite understand what you do for a living.)