The development backlog is not your road-map. The road-map is a visualization of the strategic product plan, which in turn drives the [product] development backlog. Think of it this way: The road-map is the ‘why’ and the ‘what’. The development backlog is the ‘how’. Why is that important?
When people mistake the [product] development backlog for the road-map, development goals become internally focused. Focus shifts away from the user problems, and towards the technical aspects of building the solutions. How technically sound a feature is means nothing if the feature isn’t being used. Products are built for the user, not for us [developers].
A Startup’s road-map
Have you ever had to draw up a pitch deck for an investor? I’m sure you had to, at least, go through this process as an exercise. Of course, there’s a host of resources for that out there. Our purpose here is not to describe how it’s done; it’s merely to clarify how it’s used.
An investor’s point of view
All investors looking for business opportunities will review a shipload of applications before they select a handful of them to invest in. And the reason why only a handful make it through this first step is, during their evaluation, investors need to factor in a great deal of different things to the equation, before they make a decision. Now, you may have described everything perfectly well in your 25 page research/report/product presentation/marketing pitch deck. But that is actually the problem, isn’t it? Most of the times, it’s all of the above in one, bulky package. Not quite the perfect pitch, is it?
Investors are busy people. They can only give each applicant a few minutes to make their case. That’s regardless if you’re standing in front of them, or you have just sent them your slides over, in a nice email. In all actuality, they only want the facts, a few numbers and some info about you and your plan. So where does the road-map come into the picture?
The quest to a great road-map
Imagine you’re planning to go on a road trip. You’ll fire up your favorite Maps application, set up a series of destinations and then try to plot the best route to travel them all, as best as possible. The specifics of where you’ll be staying or eating, where you’ll be going shopping for groceries or memorabilia may be pretty unclear until you’re actually there, isn’t it? Well, it’s a great analogy for a business road-map; that’s where it gets its name, after all.
Ideally, your road-map would be a very high level description. It would describe what you’re planning to do in the next, say, 2-3 years. And it would briefly go over the reasons why. Mind you, we mean “briefly” – just the destinations (called milestones), remember? For all we know, your whole road-map could be a straight line with dots and labels over them.
Believe it or not, that’s just enough info for your investor. As you may have already guessed, there is no room in there to indulge yourselves in the specifics of how you’re planning to realize everything. Besides, if you think about it, you actually don’t have the slightest idea about how to do most of these things on that road-map of yours. And that’s absolutely normal!
If you’re doing this the Lean way, you shouldn’t even worry about what you don’t know. The Lean Methodology is one to help you define everything in greater detail, as you go. The only thing you need is a starting direction.
The product development backlog
So, you got your shot and you’re setting up shop to get started on this great new adventure with your team. Kudos to you and your friends! It’s a great time in the life of your startup; it’s when you’ll build up your drive towards a common goal. Enjoy it, cease it, live it!
Once you’ve set up your team and given everyone something great to do, you shall realize there are two basic categories in which every role belongs. That’s “product development” and “business operations”. During the first stages, none of it is easy. However, product development is something you can’t actually feel your way through. And while you can make informed decisions, based on your business operations, which by the way include communication with prospective customers, you need to keep it on track.
Agile development
To do that, most product development teams use some implementation of Agile Development. That’s especially if you’re a SaaS company, working, of course, on a software product. And one of these implementations is called SCRUM (no, not the one in rugby).
According to the SCRUM methodology, to handle your bigger goals, you need to break them into immediate and future goals; and then in smaller, more manageable ones. The immediate small goals get more detailed specifications than the future ones. As mentioned before, that’s normal. As your operations provide you with more information about your market, your customers and what real problems you need to solve and how, you can shed more light on more of these specifications and detailed descriptions. Don’t bother to fully describe everything beforehand. The quality of knowledge you’re going to have right before you need to start working on anything, will render any prior specification obsolete, or useless even.
What’s with the product development backlog?
Now that you’ve got your goals broken into more manageable pieces, you can start working on some of them. And to do that, you need to have everyone on the team work on some aspect of it. That’s actually your task-setting process. During this process, you set tasks towards that goal, calculate what is needed to get it done and approximately how long it may take you to get there. But what does all this get you, you may ask? And what’s a product development backlog? Glad you asked!
Well, first of all, a product development backlog is a log, a chronicle, a historic testament to things that you haven’t got around to doing yet. 🙂
In all seriousness though, it’s essentially a long list of all the little steps you need to take before you reach each of your milestones. These little steps are, essentially, the tasks delegated throughout your team. But let’s go back to what all this task-setting process will get you.
Measurability
Task-setting makes everything more measurable. That’s a feature that may benefit you in many different ways. You can perceive the business value in every little bit of work that needs to be done; or justify its relevance in the present or at a future stage. Perhaps you’ll need to reschedule a task for when you have more information about it, or for when your users have solved all the problems that come before the one this specific task is trying to solve. And that’s a secondary benefit to measurability, one that is prioritization. Your product development backlog just got better!
Attainability
Inherently, it makes things more attainable throughout your product development backlog. That goes to say it’s easier for everyone in the team to wrap their head around a task (or goal) that takes 1-3 days to completion, than one that needs 5 people a month to do. The mindset is different, the psychology is better and the criteria to evaluate the end-result are simpler and more straightforward. That’s how you turn your product development backlog into something attainable with team-work.
Clarity
In favor of order, it keeps things clean and tidy in your product development backlog. Everyone knows what they have to do, there are no excessive hand-offs, hence less or none of these unwanted bottlenecks. And that’s how you can get your pace really, really soon. Most teams settle down to a pacing of 2-3 weeks, because it’s an interval that makes sense in developing, testing and releasing a full unit of code that is immediately of value to users. And, by the way, this 2-3 week step, which is called a Sprint, also contains a you guessed it a backlog. Only this time it only refers to your Sprint, not your entire product development.
Manageability
If you have someone from outside your team come in and help you decide business value vs timing vs cost of delay vs capacity and overhead, having to deal with a milestone level goal will usually leave everyone in utter confusion. Having your milestones broken down to smaller goals and these goals to tasks and sub-tasks in your product development backlog will work wonders in managing them more efficiently. Even for someone outside your team, who is only here as the voice of reason, just to help you avoid veering off course.
How do we do it then?
Too long – didn’t read, I can hear some of you mumble. Clearly, it’s your loss. It took us a while to figure these things out in practice. And our purpose today, was to try and help clarify the difference among consecutive levels of detail, but also between theory and practice. However, if that’s how you’d have it, here it is in a few words:
Try to populate your product road-map with your most important milestones. Everything in-between these milestones will gradually and naturally make its way into your product development backlog as a secondary milestone, broken down into larger and smaller goals, broken down into tasks and sub-tasks, delegated throughout your team. Do it the Lean way and populate each task with new information as it comes in and be “all the wiser” for it!
[newsform label=”Learn more about your startup”]
And if you found this useful, just go ahead and “smash” that like button over at Soundcloud, or drop us a comment, so we can keep them coming!
