About · Posts · Categories · Projects · Mailing List

As a Product Manager, one of my biggest challenges is kicking off development for a big project. Whether it's a new feature, process, or product, an endless list of unknowns and "what ifs" make starting the project daunting. It's easy to become intimidated and procrastinate the project.

Part of the challenge is not knowing where to start. Do I start by meeting with the development team? Or key stakeholders? Do I know which questions to ask so that the meeting is productive. What are the decisions that need to be made, questions that I need answered?

It feels like a writer staring at a blank page. Unsure which words to write first to start the piece. For writers that are unsure of where to begin, the advice I most often hear is to just start. Start putting words down and see where it goes. The action of starting is the trick.

For software development, I've come up with a system that helps me get started when faced with a challenging project. The system is based on a 5 column workflow table.

The columns are:

  1. Action
  2. Requirements
  3. Questions
  4. Discussion Notes
  5. To dos

Action is the specific action or event that takes place. It's a simplified list (an outline) of steps a user will follow (or events they will experience) when using the new feature. Each action should be short and easy-to-understand.

Here are three sequential items that would go into the action column:

  1. Select new Academic Year
  2. Classes and Students reset to 0
  3. Teacher accounts carried over without any class enrollments

This column is your starting point. The cumulative list of actions represents your ideal workflow. Write all actions you can think of prior to completing the other columns.

Requirements are the unofficial acceptance criteria for each action. Here you get into the details of what happens during each action.

Questions are the open questions relating to each action. Add your edge-cases and unknowns here. Add any items that require stakeholders to decide upon.

Discussion Notes is for tracking meeting notes. As you meet with stakeholders to discuss the new project/feature, take notes on what was discussed and decided regarding the action.

To dos are the list of things that need to be done.

Here is an example of an action event:

Action

Requirements

Questions

Discussion Notes

To dos

Classes and Students reset to 0# Class and Student lists for new academic year are blank
# Students do not appear in the new academic year until rosters are uploaded
# Should Student list be carried over from the previous year?
## Downsides to this approach?
# Ops prefers that returning students appear in the new student list# Andrei to meet with Operations to discuss additional requirements
# Dev team to investigate what process was during previous year

Once you've completed the first draft of your table, share it with relevant stakeholders and schedule a time to go through it. Cover each action and make note of the relevant discussion notes, questions, and to dos.

You likely wont finalize everything after one meeting, but you'll at least have a clearer direction of what the project needs to move forward.

Remember that the first version is a draft. Be flexible, move actions around. Your goal is to initiate a structured conversation about the project.