Feature Ideas and Product Management

[peytoncraighill]

The feature idea process in the Canvas Community has evolved over time, and it will probably continue to evolve, but I thought I might offer some perspective from the product team on the value of feature ideas, because that value really hasn’t changed in the six years I’ve been here.

Canvas product managers are tasked with relatively large portions of Canvas to manage. “Manage” in this case means everything from researching and facilitating big projects to keeping bug counts down, and there’s a lot of stuff in between. Here’s what my team -- Learning Structures -- owns at the moment:

Canvas Decoder Ring

This is a screenshot from our “decoder ring,” which is what we use internally to know who owns what and how to reach them. This is super useful because Canvas is big, and ownership of all the things evolves with the platform. The RCE is too much for my team to own anymore with everything else, for example, so we’re in the process of spinning up a new team to handle that and some other things. That means a new product manager has to dive into that problem space and do what they can to understand it and improve it. This is where feature ideas in the community come in really handy.

There are two things I do before anything else when I “own” something new in Canvas.

First, I read the Canvas guides so I understand how a feature works. Our documentation team understands Canvas in a way that literally no one else on the planet does. (I’ve learned that long introductory sections indicate either a really complicated feature or some problem we didn’t solve correctly, or both. I’m looking at you, blueprint courses guide for admins.)

Second, I read all the feature ideas and comments that I can find related to that thing. Some feature ideas are crazy, and those tend to be reined in via comments about why they’re crazy. Some feature ideas are good but controversial, and the comments tend to raise nuances that we’d need to understand if we were to do something about them. Some feature ideas are slam dunks, and the comments tend to be stuff like “you guys are the worst” or “what’s the point” or “you never listen.” (Frankly, I understand that perspective. The reality is we tackle a lot of these, but we don’t tackle all of them, and when we don’t tackle the thing you care about, the obvious conclusion is that we don’t listen or we don’t care, and that’s a bad feeling. If you ever feel this way, just message a product manager. We may or may not do what you want in the end, but at least we can understand each other better.)

So let’s say we don’t work on something. Your feature idea may still get done, because the magic of an open platform means that someone else can jump in. Sometimes via pull request, and sometimes in other ways. Recently we added the ability to toggle Student View from more places during a hack week, which came from a feature idea, which had been solved for Chrome users via @dan_baeckstrom’s browser extension. These contributions give me the warm and fuzzies.

Regardless of the category, feature ideas give us a great jumping off point for product development. They can point out low-hanging fruit for us to tackle in a hack week, and they can point out fundamental problems with the way Canvas behaves. The more complex the problem, the more likely it is that we reach out to understand the nuance when we’re looking to improve something.

So. Whether you’ve got a crazy idea, a controversial idea or a slam dunk idea, when you post in the community, you help the product team make Canvas better. Even if we’re not actively working on something, your contributions are still getting read and reread and referenced in future work.