Product News PIE

Brightspace Roadmap and Ideas from PIE

Originally published March 14, 2019.

🗺️ Connect with the Product Roadmap to learn more about the changes coming to Brightspace, Wave, and Creator+ over the next 6 Months!

How Do We Get Ideas for Roadmap?

There are multiple inputs when it comes to D2L making decisions about our product roadmap: PIE/Community, Design Studies, Advisory Boards, Direct Client and Prospect Interactions, and Market Research are just a few.

A visual diagram showing the inputs into our prioritizing / product roadmap. Product Idea Exchange, Design Studies, Advisory Boards, Customer Interaction, Conferences, Community, and Account Management

How Do We Determine What Goes On Our Roadmap, and When We’ll Deliver It?

A roadmap is a living thing. Developing our roadmap involves a thorough but swift process that happens at least twice a year. To start, research is conducted by segment leaders (K12, HE, Corporate, International), segment leaders then prioritize their initiatives for their market; input on initiatives (scope/complexity) is done by product development and design resources; scheduling of our development resources to accomplish priorities across all segments, according to experience and availability; and then, importantly, project managing and communicating the execution of the work.

Diagram showing a continuous cycle of steps: Research by Segment Leaders, Prioritization of initiatives by segment leaders, pressure test from dev and design leaders, scheduling of resources, and execution.

A typical roadmap looks like a set of projects spread out across time and teams at D2L. Some priorities may be in phases (sometimes called Crawl, Walk, Run). Others are accomplished in shorter development cycles (called Sprints). Decisions on which teams work on which features takes into consideration the expertise of the team and experience they might have in a particular tool or technology. Even though something may not seem difficult to do, it may require the team with previous experience with it to become available to make that feature happen efficiently.

For example, on January 1st of the year, a roadmap (with aligned to PIE statuses for context) may look a bit like this:

Diagram showing a 1 year product roadmap, divided into months on the Y axis and team lanes on the X axis. Multiple priorities are scheduled throughout the year for each team. Ideas in Dev are from January to March. Ideas in Plan are from March to June. Ideas in Candidate are June to December.

A Product Manager may be aligned to one or multiple teams or priorities. Product Managers work with Engineering Leads to decide what features/fixes/escalations can be achieved within the defined time allocated to that priority. Product Managers must plan far enough in advance to communicate disruptive features to our clients, yet be flexible enough to use market feedback on released features to make changes to their ongoing plans as needed.

Product Leaders continue to pressure test our priorities with senior leaders on a regular cadence to ensure they remain aligned with our corporate and market goals. Our priorities may change or mature based on these reviews. As needed, we may go through a more involved strategic exercise to ensure that our priorities are still on track.

This means that tools and features that did not make it into the prioritization exercise either at the macro (segment leader) or micro (product manager) level are defined in PIE as simply, Not Planned. Something that is Not Planned may eventually be planned and developed. Something that is Not Planned in January, may end up being in Planning in August after a reevaluation of our priorities and resources.