ISSUE #17 - MAY 25, 2023

Pre-PMF: Prioritizing the right items to work on

In this post, I am not talking about prioritization frameworks. I aim to present you with some of my learnings about pre-PMF prioritization, most of which I had to acquire the hard way; by making mistakes.

Pre-PMF-Prioritizing-the-right-items-to-work-on

Pre-product-market fit is one of the most challenging stages of a company's lifecycle. The harsh realities of this stage affect the product team more than any other team. In the vast majority of cases, it is that time when the size of the team is small; consequently, the team's capacity is limited too. The company runway is also narrow, and there's tremendous pressure to move a step closer to PMF. In other words, to find something that sticks.

To make matters worse, the direction is not yet crystal clear at this point, since there's lots of uncertainty. As a result, there are many voices, and many of them say things about what the product team should do, which is also plausible to be right. Of course, this makes your job as a product manager even more complicated. Especially today's macro-environment amplifies the above realities.

With all that in mind, there's only one truth that you should listen to: Your team's time is the one thing that you can never get back. So, you need to be ruthless when it comes to what you pick for your team to work on. In other words, you must nail prioritization, which is key for early-stage companies.

In this post, I don't want to talk about prioritization frameworks. There are so many of them; ICE, RICE, MoSCoW, Value/ Complexity. So you pick your own poison. I aim to present you with some of my learnings, most of which I had to acquire the hard way; by making mistakes.

Never commit to something long-lasting unless you are 150% certain about the results

"Thank you, Captain Obvious," someone would say. This looks like a no-brainer, but I've seen so many teams making this mistake. Having your team working on something for a couple of months and then realizing that the results are far off what was expected. Usually, this is the result of poor research.

At these early stages, even if just one person commits to working on something with subpar results for two months, this is a significant opportunity cost for your company. As a product manager, you have to ensure that, given this high cost, the results will be there. That means you must do an outstanding job in your research and evaluation before prioritizing such a big item. It's imperative that you challenge your assumptions as hard as possible.

If you're even remotely uncertain about the impact of something that big, you must go out there again. If necessary, talk to more users to get more confidence in your assumptions. Or, if this is part of a partnership, get back to your research and try and get more clarity on the expected impact. In case a powerful stakeholder is pushing for this, then make sure that the data they present you with are right and that they are not overselling it. You must do whatever is necessary to minimize uncertainty, occasionally including being the bad guy.

There is no space for "small improvements"

This might sound harsh, but the reality is that an improvement of 2% on a metric at this stage of the company's life will not change the company's future. The problem with "small improvements" at this stage is twofold:

This improvement is never that small in terms of implimentation effort, so this means that the cost is almost always underestimated. Aside from the implementation cost, there's always the planning, speccing, and design (occasionally), not to mention the potential ripple effects of a release that people rarely consider.
But even if the cost is indeed small, at this stage, you don't have the scale so that this 2% improvement will have a meaningful reflection in the company's objectives.
As easy as this sounds, it's not. Stakeholders will always push you with "come on, it's just a small change" or something similar. However, you must help them realize the opportunity cost included. Something that could help is that occasionally you can be opportunistic and make this small improvement as part of a broader initiative. But the main takeaway here is that your team's time is precious and it cannot be allocated to things that will not move the needle. Minor improvements and optimizations have no place in your roadmap when you are pre-PMF.

What if you realize that the value / cost ratio doesn't make sense after you committed?

To my experience, this scenario usually plays out as follows: You are a few days into developing a feature, and at that point, you realize that it will take way longer than expected. Once you reach that point, there is only one option that makes sense: Kill it off.

It sounds harsh, and it will definitely frustrate people. After all, some amount of work will have already been done and will be thrown away. However, it's way better to do this rather than cripple your team's capacity while working on something that will not pay off. The mistake usually made in this case is that people are reluctant to stop because they are already invested into this. However, it's always better to cut your losses early rather than get your team into a spiral that you don't know where will end.

I realize that many of the points mentioned above sound straightforward. They are way more difficult in practice, though. Being ruthless means, you will disappoint or even frustrate many people. People that are your stakeholders, and you need to maintain a relationship of trust with. However, you must always put the impact and the value for your users forward and ask yourself: "Will my users be significantly better off when I ship this to production?"

Past Newsletters

ISSUE #16 - APRIL 19, 2023

Don't rely on NPS to make decisions for your product. Here's why.

NPS is flawed by nature as a product metric. In this post, I'm showcasing why it's not a good idea for product leaders to use it as a metric based on which they..

Read here

ISSUE #15 - MARCH 28, 2023

10 Books that you MUST read as a Product Manager

A list of books that I found particularly useful to my product management journey up to now. And probably one of the few that doesn't contain Inspired.

Read here

ISSUE #14 - FEBRUARY 24, 2023

Hiring Product Managers: Formulating the interview process

In this post, I am sharing my thoughts on formulating a solid interview process for hiring a product manager, given the role requirements and the available..

Read here

The Product Notebook by Manos Kyr.

Once every month, I’m sharing my thoughts on product, growth & entrepreneurship.

Latest Newsletters

ISSUE #25
What to do when you don't know what to do next

ISSUE #24

When good docs go bad: Learning from a PM's misstep

Copyright © Manos Kyriakakis