How I Prioritize Product Features From the CEO & Founder

A Simple Way to Prioritize Product Features

It was like clockwork. The CEO would message me daily, if not hourly, on new feature requests, slightly changing product direction each time. He messaged me on every communication channel you can think of: Slack, iMessage, WhatsApp, and email. Whenever it was the most convenient for him, regardless of time of day, he would send me these requests.

These emails contained not only vague future ideas, but small tweaks and non-critical bug fixes, etc. Essentially, anything that came up mid-sprint, he would send me a quick note with his ideas.

A big reason why I enjoyed working with him was his excitement about the product we were building, and he was constantly thinking of new ideas. However, that came at a cost. I was drowning in new things to build, and I didn’t know how to focus these requests.

I appreciated his willingness to share his ideas, but at the same time I had to make sure we were building the right things. I wasn’t necessarily in a position to say no to these new features, even when I was only halfway done with the features we started weeks prior. I actually did care about what he wanted to build, I just didn’t think many of these features were the right decision.

I needed to ruthlessly prioritize our feature requests. But, again, who was I to decide what feature was right or not? So, I thought of something to help me alleviate this pain.

Inbox System Is the Answer

After a few panic attacks, I created what I called the inbox system. This was a place in our project management board where I collected all of his, and the team’s, ideas. It gave me a chance to say, “Great idea! Let’s discuss later.” He knows that his idea isn’t lost, and I don’t feel the pressure to act immediately.

In the next sprint planning meeting, we would go through all of these ideas, weigh them against all of the other issues (i.e. features, bugs, cards) in the backlog, and prioritize the things that will have the biggest impact towards achieving our company’s objectives.

The inbox system aims to solve the problem of changing the plan mid-sprint and allows you to slow down and consider your next steps. You don't want a reactionary engineering team where the latest ideas from the stakeholders are implemented over things that have been planned for weeks.

So, it would look like this:

1. CEO sends feature request (and wants it built ASAP).
2. Acknowledge her feature idea and document the request in your project management board (AKA, the “inbox”) before committing to building the idea.
3. During the sprint review meeting, instead of asking the validity of the idea ad nauseum, discuss the priority of this request compared to everything else that needs to be built or fixed.
4. Make a decision as a group.

It was a small tweak, but it made a substantial impact. I was heard. He was heard. And together, we made the best decision for the product and the company.

Some Features Just Aren't Worth Building, Regardless of How Genius It Is

I operate under one model: Every feature can certainly not be a winner.

This isn’t 3rd grade where everyone gets a participation trophy and feels like a winner at the end of the soccer match.

Implementing the wrong feature can significantly impact the trajectory and traction of your app. Not just because users don’t like it, but for simply how much effort and time it took to complete.

As a Product Manager or Project Manager, you’ll get a lot of input from your stakeholders. For us, it’s our clients. For businesses, it could be your CEO or boss. It used to give me anxiety when I heard all these lofty feature requests: I felt like I needed to implement all of the ideas my CEO threw at me over email, text, or Slack.

Many ideas sound amazing in the moment, but the luster wears off quickly. If it’s still a great idea during the next sprint planning, then consider implementing it. If not, then discard it—that’s okay to do, it’s part of innovation. All ideas can’t be winners!