Published on | Prototyping: From UX to Front End — Medium Agustin Soler

What should we do next? That might be the most important question a product decision maker has to answer, several times a year.

Originally posted at MURAL’s blog

Although there are many prioritization methods out there shared by different “experts”, it’s still really hard to decide what projects your team has to face next.

Over the years, we went back and forth with the way in which we decided what to build next at MURAL. In this post, I’ll be summarising our current product planning process.

At MURAL, like at many other companies, we plan our product releases on a quarterly basis. We divide each year into four quarters (Qs): Q1, Q2, Q3, and Q4.

During the last week of a Q, we start to plan a product release for the next one. This planning process takes up to 2 weeks. The output of the planning stage is a list of things to be done per team (Backlog and Big Projects) that are aligned to the objectives and metrics (OKRs*) of each team, of product in general and of the whole company.

*OKRs (Objective and Key Results) is a framework for defining and tracking objectives and their outcomes.

The planning process at MURAL has 5 stages:

Review
OKRs definition
Big Projects definition
Backlog definition
Presentation

1. Review

We start the planning process by learning from last quarter’s OKRs. We schedule a meeting in which product managers and the head of product review last quarter’s OKRs. “Did we manage to improve our KRs?”, “Do these Objectives still make sense?” are typical questions that we ask.

During this phase, we run a simple retrospective in which each product manager has to mention one thing that went well and one thing that went wrong during the last 3 months. Sometimes, we mention more than one item, but ideally we have to mention just one thing. We use MURAL to run this activity (link to template).

Q1 Retrospective

Once we finish the retrospective, we define action items to be completed during the next Q. It’s simple, but we feel it works really well.

2. OKRs definition

Once we finish with the review of the previous quarter, we start defining OKRs for the next 3 months. Even though each product manager has multiple ideas that they would like to pursue, they need to keep those ideas on hold and wait until the next stage.

The first step is just to define the product objective and the metrics that will indicate whether we reached that goal.

For example, last Q we used this objective:

A complete and easy-to-use experience that drives enterprise sales

Where do our goals come from? We define them in a collaborative fashion with the CEO and management team. And, we use the following documents to support our decisions: product positioning, job map, and scenario.

Here’s an excerpt of our current positioning statement:

Positioning statement

In MURAL we design using two Personas. These help us better understand our users and their goals. I can’t emphasise how important this is. Take a look at Alan Cooper’s book About Face if you want to learn more about Personas.

Personas

We combine a scenario with a job map to describe the ideal flow of the persona, and identify gaps in the solution. Within each stage of the scenario, we have identified different metrics that our personas use to evaluate how well we are solving their problems.

Job map + Scenario

We define the objectives of the product by paying attention to these artifacts.

Once the objective is defined, we work on key results. We normally take about a week to properly define our KRs. A key result we’ve used in the past is a ratio of the number of users who have used the product at least once in 3 different weeks in the last 4 weeks, over monthly active users (MAUs).

3/4 week users ratio> X

This metric indicates how many engaged people are actually using the product. MURAL is not a product that is used every day. We understand that weekly usage is enough to get value from the product.

Once we define the objectives and key results for Product, we do the same for each product team.

For example: To have more engaged users, we know that there is a high correlation between users who’ve used the product more than once in the first week, and engaged users. With this information, a team could have a goal focused on improving the onboarding flow and a key result such as:

First week retention for new sign ups > X

Once we define the OKRs for each team, we setup a dashboard with the metrics to be measured during the Q.

Key results in a dashboard

We are then ready to define the Big Projects.

3. Big Projects

Big Projects are the largest initiatives we want to tackle. Due to their importance, these have to be communicated throughout the entire organization.

To begin, we bring to the table every piece of information that could help us make better decisions about what to do to impact each OKR.

Gather leadership team’s feedback and priorities: We interview the CEO and the Sales, Support, and Customer Success managers so they can share their perspective on what our product priorities should be.
Backlog of opportunities (icebox): We have a large list of opportunities, features, and improvements that was built based on a ton of research. Each PM reviews what we already have listed.

Metrics and feedback: Each PM looks at the product metrics to find whether there is any bottleneck that prevents us from reaching our KRs.

In addition to having the OKRs, we already have the perspectives of Sales, Customer Success and the CEO. With this information, the product teams define a prioritized list of big projects for the Q.

This list is shared throughout the company and we iterate it together with the management team and the CEO. A subtle negotiation goes on until we get to a list of projects in order of priority that directly target the defined Key Results.

5. Backlog definition

We know it’s not possible to do every single project. So far, we have a prioritized list. We then estimate the projects based on effort points, and we calculate how many effort points we have available for big projects this quarter.

To do this, we first define how many effort points we have available in a Q. Then, how many of these effort points are we going to assign to improvements, bugs, refactors and security. In addition, we know that there are always estimates that we miss, and things that appear that we have not contemplated. That’s why we also assign a buffer for this. By subtraction, we calculate how many points we can devote to Big Projects (see green in the image below).

Backlog estimation spreadsheet (Link)

With this information, we go ahead and decide which big projects we will actually tackle during the Q. With this updated list, we make a final revision with the CEO and the dev leads, as well as leaders in relevant areas.

Once the projects have been agreed upon, each PM prepares the backlog for the quarter. It is not necessary for everyone to agree with every decision. When in doubt, the CEO and the head of product have the final call.

5. Presentation

The Q starts with a presentation of the OKRs and projects for the quarter. We do this in an All Hands meeting where the whole company is present.

Roadmap for the Q

Once the quarter starts, we keep a board that we update weekly so that the entire company always knows the status of the different big projects. Here is the link to use the template.

Continuous improvement

This process has evolved over time, and surely there are many things to improve. It’s highly probable that in a few months we will make changes to the way that we plan. What is shared above is exactly what we do today. Suggestions are always welcome!

Planning a product release at MURAL was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Planning a product release at MURAL

Cool stuff, every week

More Articles