Product Roadmaps in Asana (and at Asana)

projects
productroadmap

#1

Asana co-founder Justin Rosenstein wrote an article in the latest issue of Wavelength in which he discusses Roadmap Week at Asana. I feel inspired to share some of his thoughts with you and also ask how you all manage Roadmap weeks - or the equivalent depending on your processes or industry - in Asana.

Key workflow-y quotes from Justin’s article include:

Ultimately, organizations exist to accomplish goals. Succeeding at those goals comes down to being clear about exactly what you’re trying to accomplish (“clarity of purpose”) and how you’re going to get there (“clarity of plan”).

Learn from your failures…We look carefully at our ideas and goals set forth during our previous Roadmap Week, and inevitably, many of them won’t have come to fruition.

But also from your successes… Looking at how ideas were implemented successfully means we can use similar approaches that will lead to more successes.

Once we identify the ideas that have staying power, we sketch out a realistic work plan, and put individual next steps in Asana.

At Asana we track most of our work, and that means most if not all of our Roadmap week work, in Asana. We are able to track our failures and successes to a tee because we record who is doing what by when in Asana. Now, this doesn’t mean people are inherently punished if something goes awry (sometimes accountability makes people feel afraid). Instead, it means that we can use Dashboards and advanced search to track our work and monitor how we’re progressing overtime and at designated checkpoints. The gift of tracking our work in this way is it allows us to hit our Roadmap week goals, learn, adjust, and be more realistic for future endeavors when we need to be. You can learn how this translates into product launches in this webinar with an Asana PM.

I’m curious to learn how you run Roadmap or Planning weeks at your companies and how you execute these processes in Asana. Based on what you read in the article, how are our processes similar to yours? What works well for your team that you think could work well for others?


#2

I can see the value in committing to an “episode” of work without allowing distractions. Can you elaborate on how you maintain the ability to change course during an episode when something is clearly not working out, or respond to externalities so you don’t seem out of touch or lose ground to a competitor?


#3

Great question, Craig! We actually have something called a mid episode check in. During this check in we determine how we’re tracking on our goals and if we need to adjust. This is a formal method for ensuring we’re on the right track. However, we maintain weekly or bi weekly status updates to gut check how things are going. We definitely wouldn’t want the structure of episodes to make us lose touch from important signals, so we have lots of habits for checking in on our progress and determining if we like where we’re heading or we need to adjust.


#4

Thanks for this @Alexis. I thought I’d share my experience in case it’s of any interest to others.
I’ve worked with a similar pattern but it was a quarterly cadence. Between each 3 month quarter I created a “boundary iteration”. The boundary iteration allowed 3 days for the teams to do activities like a longer terms retrospectives and future-spectives as well as retrospective-of-rectrospectives (shared learnings from across teams and identification of common pain points / joined up initiatives to make things better). In addition the teams could look forward at the upcoming period and check that they had things like dependencies, constraints and other risks identified as far as possible and put coverage plans in place.
I encouraged a “rolling wave” approach to planning by the Product Managers and Team Product Owners so there was rarely any need for big planning. New initiatives got incepted at the time that made sense for them to come into the world. The quarterly cadence was more a chance to press the pause button, step back and take a reality check on everything (test for ongoing alignment, etc).
Finally on the Thursday + Friday we did a hackathon type activity where the focus was on trying to work with people you haven’t worked with before and do something that was different to what you normally do day to day. There was no requirement for the work to be related to the company products at all.
Other things could go on in the boundary iteration: running an Open Space; carrying out teams self-selection re-organisation; doing a coding dojo; holding an unconference; etc.