Ideas in the wild

Quickly capture and classify ideas that matter.

Building product is equal parts intoxicating and overwhelming. Ideas of different shapes, sizes, and relative value whiz past all day, like exotic birds flapping and squawking around the room. The team is excited after a promising customer call. The hurried “what if we just built (insert ten new features)” debrief conversation commences. Creating wireframes reveals unresolved data access questions. A partner proposes a new technical integration. Head buzzing, you walk to grab coffee and realize a user can’t distinguish file types with the current design, but how do we fit that on mobile? Pandora’s box is open, and it isn’t even lunchtime.

So, what do we do with all of these ideas?

The art of product management is based in rapid sense-making and prioritization that supports creativity, collaboration, and learning. Some of these wild idea-birds matter, and some don’t. Some are important today, others are more critical for future work. A few will poop on you eventually if you ignore them (security and compliance). But how do you know the difference? How do you quickly harness that value without moving into a state of overwhelm and developing an intolerance for creative ideation?

Alfred Hitchcock’s The Birds (image)

Here is the Capture & Classify framework that I use:

Capture: Give it a name

I assign the idea a descriptor (scribbled on a post-it or sent to myself as a Slack message) so that it doesn’t disappear or distract me from what I need to focus on right now. For example, “User Box Account” or “Welcome Email Walkthrough” or “My File vs. Shared File”. This is the product equivalent of tagging an animal and then re-releasing it into the wild. My anxiety is reduced just by knowing I can find it again when I need to.

Feel free to use David Attenborough’s voice to narrate: Here we see the idea-bird trying to impress the female. Photographed by Tim Laman for Planet Earth.

Classify: Key characteristics & value

When I have time I take the idea through a classification process. I mentally walk through some or all of these questions: (These are technology product specific; modify to meet your work!)

1. Who — What — Why
Who is this idea about?
What should they be able to do that they can’t do now?
Why is that capability valuable?

For example… “My File vs. Shared File”
Our app users need to be able to distinguish file types so that they know which files they have ownership over (can modify), and which are the property of others.

2. Where
What areas of the product are related or impacted? Examples include…
· User Interface
· Data Model / API
· Data Storage
· Third Party Integrations
· User On-boarding
· Product Support Materials

For the My File vs. Shared File example, the User Interface and API are directly related.

3. Stage
What stages of product development is this idea touching today?
Stage 1: Research
Stage 2: Definition & Design
Stage 3: Development
Stage 4: Launch
Stage 5: User Testing & Feedback

For the My File vs. Shared File example, the discussion is in Stage 2: Definition & Design. Mocks and user feedback are needed before development.

4. Importance
How important is this idea for our product, users, and company today?
Very High Priority — Must handle today
High Priority — This week
Medium Priority — This month
Low Priority — This quarter
Unknown Priority

The My File vs. Shared File idea is a Medium Priority. Users can test the product without this distinction, but will find it confusing as files are added.

After running through these questions I can describe the idea in clarity.
For example:

An app user can easily see the difference between files they created and files that someone else created so that they don’t get confused about ownership and editing permissions. This feature is currently in the design stage and is related to both the user interface and the API. It is a priority this month and the next step will be creating mocks and testing for usability.

Capturing and classifying an idea means I am better prepared to take the appropriate next step — often creating an engineering ticket, sharing with my CEO, or exploring in-depth in a feature brief (using additional frameworks like the CIRCLES method). Sometimes it also means re-releasing the now less “exotic” idea back into the wild until it comes up again, at which time it will feel familiar and can be acted on quickly.

I need our team to feel confident that important ideas aren’t being missed so that we can continue to execute without losing our creativity.

In doing so we protect the joy and curiosity that brought us to the work in the first place — two critical ingredients for product success.