Planbox is glad to present Matthew Smith, who was kind enough to submit this article to us, which was originally Posted on tinydotmedia.com
Matt has over ten years of experience helping technology and media companies grow; specifically from a business and product perspective. He approaches business and product challenges from the same angle; break things down to simple ideas, know the customer, understand the value of the solution, and adjust quickly. Matt spends his spare time focusing on photography, writing, and helping other folks get their ideas off the ground – which is how Planbox got in contact with him!
—
Everyone has a boss; whether it’s the director of product (assuming you are a PO), or the CEO (assuming you are the director of product), or the board (assuming you are the CEO), and we all have to be able to explain what we are doing and when we plan on doing it.
In most cases people above you expect timelines.
“What are you doing and when will it be done.”
The idea behind the question is OK, i.e. I want to know what’s going on, but the issue arises when they expect actual dates. This is the timeline-trap.
If you buy into the idea of timelines, all you are doing is setting yourself up for failure and an angry conversation with your boss. Yes, it’s true that you can hit certain dates, but chances are, that more often than not you will miss a date for one of a hundred reasons; all very reasonable reasons too. But, your boss wont care about the why, all they will care about is the fact that you missed a deadline.
Avoid The Timeline-Trap
Instead of timelines, we suggest roadmaps. The main differences between a timeline and a roadmap are:
- Priorities versus deadlines
- Needs versus wants
When we look to prioritize the needs versus wants, we like to break things down into two categories:
- Rocks: The big things, overarching directional products
- Sand: The small things, product tweeks, tech debt, design tweeks
Once you have need over want, make sure that the number one thing you need is at the top, the number two thing you need is second, and so forth.
Communicate The Plan
Now it’s about conversation – you should always set expectations accordingly, and make sure everyone is on the same page. Get buy-in. ”We know that we want to focus on Advanced Search first, so that’s what we are going to do. After that we think we want to focus on our signup process, but that could change.”
Everything past the number one item is subject to change as time goes on, and that’s ok. Being agile is not just about software development and two week sprints and having releasable code at the end of the sprint. It’s about a business mentality that starts at the top and trickles down to everyone.
Once we know what our number one thing is, we focus on that until we are satisfied that our goals/objectives have been met. We don’t know how long that will take because we don’t know exactly what we will be doing, until we kick things off. Staying true to agile development means focus, quick releases, customer feedback, and iterating. Based on feedback what you end up creating is most likely going to be vastly different from what you thought you were going to be doing on day 1. And again, that’s ok; that’s the point.
When you are done with number one, you can move on to your number two or adjust your plan based on what took place during working on thing number one.
And let’s not forget about the sand. The sand get’s prioritized just like rocks - based on a need vs. want process. Every now and then you find that a developer has some free time; enter the sand. Pick off the little things when you can, so long as they are the number one little thing and don’t distract the larger effort of the number one rock.
Visualize
Above is our Visual Product Roadmap; a template that we use to help us communicate effectively to our board members. You will notice that once you get past Q1 everything starts to fade. We want to visually show that we are committed to thing number 1 and less certain about things (rocks and sand) past Q1.
Things change, priorities change, what we do changes, and so long as we have a plan and so long as we know that the plan is subject to change, we are in a good spot to have a healthy conversation about prioritizing. Healthy conversation, getting people on board, and understanding the process outlined above is a good plan of attack.
Matt SmithTags: agile project Management, kanban, Product management, scrum

[...] This post was mentioned on Twitter by cmeck19 and gonsfx, Mathieu Gagné. Mathieu Gagné said: Roadmaps vs. Timelines in an Agile World http://bit.ly/hVUQOi [...]
This is Great. Appreciated.
Hello, really great blog you have created. I enjoyed reading this posting. I did want to publish a comment to tell you that the design of this site is very aesthetically pleasing. I used to be a graphic designer, now I am a copy editor. Anyway, Thank you for the information!
Major thanks for the blog article.Really thank you! Fantastic.
Matt,
How is the Product Road Map in your example generated? Is that something that was put together in Word/similar tool or is that from a software product?
We generate the Road Map in Fireworks, it allows us to be flexible with moving pieces around and with making sure it’s visually represented the right way.
Matt
Excellent post! Glad to see you have guest bloggers joining in!