Introduction

When developing a product, it's surprisingly easy to make the process more difficult than it needs to be. Even if the founder/Product Manager duo are experienced professionals, a slight miscommunication or too much pressure to deliver results may quickly lead to a feature frenzy. But how can this happen if no one intended to rush potentially useless features to the product?

In today's article, we're exploring the relationship between a founder and a Product manager and how this pair can find themselves in a feature frenzy mode, also known as a feature factory. Unfortunately, the roads to such an unproductive state are quite common, and we hope that once you are aware of them, you can avoid a feature rush in your product.

How do the founder and PM work together?

Now, the common definition of a Product Manager states that:

"A Product manager leads a product that solves a problem, in a measurable way, using a team of talented individuals and technology in order to deliver value."

Based on it, in the ideal world, the founder is best qualified to act as a Product Manager to his/her, likely, small team. This person holds all the knowledge about the market, users, and opportunities in order to guide the development of a successful product. No technical skills are required, just a solid idea with a good basis in data and research coupled witha strong product strategy.

However, this can only work if the founder can be close to the development team and help them with every (product) doubt. That being said, the founder might not be that available, especially when his/her time is spent on investor-hunting or shared between several projects. In this case, it's likely that to keep things moving efficiently, a dedicated Product Manager will be needed for the product team. There are many versions of the founder/PM cooperation, but the one that appears to work the best is when the founder builds clear expectations of the product (or its results) and the Product Manager is tasked with making that happen as she/he sees fit. As long as the PM delivers on the expectations, the founder should feel relaxed and rather "hands-off".

It isn't of course always as ideal. Whether due to the founder's controlling nature or disappointment with the results, micromanaging can creep into the relationship, pushing the PM into more of a project manager role. Alternatively, the pressure might result in the Product Manager issuing a feature rush in the product, usually to its decrement. It could be that it's not anyone's choice, but the negative product situation just creeps in. Thus, let's explore:

PM's road to feature rush scenarios:

Too many goals

We might as well call this paragraph "not enough focus", but multiple, even conflicting goals, might push a Product Manager into nervously trying to achieve them all. Of course, it's the founder's prerogative to issue as many Product goals as needed, but there is a difference between making things challenging and making them plain impossible. It's worth mentioning here that it's not only the founder's fault - after all, the product needs to be profitable ASAP and no one can't blame the founder for expecting a return on investment. The Product Manager also needs to be able to identify that too much is being expected and in order to comply, sacrifices need to be made.

Our suggestion: Good old "rule of three" should make things easier for the founder/PM duo. Fewer is even better, but with a reasonable amount of time given, a skilled Product Manager with a good team should be able to move towards set goals in a civilized manner: with good tempo and quality!

Founder's constant interference

In the previous case, the lack of PM's focus was self-imposed. Here, the distraction comes from the founder, who, in theory, passed on the control to the PM. In reality, said founder prefers to stay in control. At the same time, the founder is likely not to have enough time, which might prevent him/her from seeing the big picture and understanding every little detail of the product development. Thus, in this scenario, the Product Manager will likely be running multiple projects at the same time with ever-changing scope and requirements, not to mention new initiatives being started regularly. This might sound like the evil founder is making PM's life miserable, but far from it. The two individuals can have an excellent working relationship, genuinely enjoy each other's company, and still fall into this pattern, especially when the Product Manager "doesn't want to disappoint her/his friend, the founder".

Our suggestion: it's mostly having the founder be mindful enough to limit his/her involvement and trust the PM to do a great job. It's hard to let go, especially with the high investment involved, but it's necessary to get the optimal output. Of course, PM can also flag that there is too much interference. Simply put, a lot of problems can appear when:

PM just can't say "no"

We will admit that two previous scenarios could easily fall under this section, but generally, if the hired Product Manager is not able to firmly stand on his/her own two feet, a lot of things might go wrong. Developers might force a more technically simple solution that will negatively affect the UI, Business Analysts might try to get out of super complex analysis or important features might be scrapped altogether. However, for the purpose of this article, the keyelement here is for the Product Manager to feel it is possible to say "no" to the founder without fearing for his/herposition. The unwanted feature rush will likely appear if the PM is afraid of the founder or at least tries to please her/him at every step, regardless of whether it makes sense or not.

Our suggestion: This is something that needs to be dealt with on the hiring level. The founder needs to establish if the PM candidate can say "no" and confront the founder. He/she also needs to be open to criticism and stress the PM's autonomy so the dynamic of the two key Product figures starts correctly. The founder may also choose to take a "biblical" action and ask the Product Manager to do something ludicrous with the Product just to assess the reaction. If the PM passes the test, there will be a funny story to recall later!

Too many developers for a single PM