Quest Product Release Process

Photo taken from: https://www.hackerearth.com/blog/developers/top-women-programmers-history/

Taken notes from:

Quest Product Release Process

Goals is to get the product out the door.

How do we do this while getting everyone involved and making sure people dont feel sad that their feature didn’t get built this time?

Process:

Every two weeks, or week, we have a brainstorming meeting where there is no time cap, but the goal at the end is to agree on what is going to be built in the next two weeks.

Step 1. Decide on a product person. That person is responsible for making sure our product meets our goals and gets the product out the door.

Step 2. We decide on our KPIs, or metrics.

I propose:

1. New content
2. New users
3. Retained users

Step 3. We host the Product Sprint Meeting. We write down all:

1. NEW FEATURES
2. BUGS
3. TESTS WE WANT TO RUN

We go in a circle and each person says what they think will move our KPI’s that week in these categories. No idea is debated. Everyone just throws in ideas.

Step 4. We have CTO, or whoever is in charge of building things, to estimate “EASY” “MEDIUM” “HARD” to build.

Step 5. We choose the HARDS first to spec out. We then pick the MEDIUMS to spec out, and then the EASY to spec out.

Step 6. We then choose what we are going to do that week — we can sometimes choose one HARD as a group, or more mediums.

Step 7. We don’t leave until we agree.

WHY DOES THIS WORK?

• Because you know there will be another meeting in two weeks, you don’t need to be salty about your idea not being picked that sprint.