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
This might sound like something counter-intuitive, right? If the Product Manager has a big team or several teams, that would probably mean there should be enough capacity to achieve anything the right way, right? Well, perhaps so, but atthe same time, anything that goes into the product should take its time in research and discovery; the design needs time to polish its work, etc. Rushed projects are at risk of being poor quality. At the same time, the Product Manager cannot afford to waste the founder's investment and keep the teams idle or working on something of low priority while initiatives are in the "oven." Thus there is a natural, inner pressure to keep every dev working on something meaningful. This can cause half-baked product initiatives to make it to development prematurely.
Our suggestion: Jeff Bezos said that a team should be fed by 2 pizzas. This is a good point of reference for how many people can work with a single PM. However, if you can afford so many developers that the Product Manager can't keep up, you probably can take on a few junior/mid-product people to help out your key PM to keep up with the demand.There is, however one other way that keeps things a tad too quick:
No/Not enough tech standards or procedures
While paperwork, procedures, and tech standards are hated in the biggest companies, the truth is they also slow things down to help the Product Manager get enough time with new initiatives before they are ready for development. However, in a typical start-up environment, the procedures and actions meant to secure the long-term health of the product are yet to emerge. All that counts is to release the first version of a stable product, get some clients and marketing going, and grow, grow, grow! This may result in a super quick release of the product, true, but it can also mean it will go online with lots of unpolished features that no one has asked for.
Our suggestion: While we don't suggest you develop new products like the biggest companies operating established apps, there is a middle ground. Ensure that your technical team consists of at least one senior who can decide on the basic technical standards and scalability features. The goal is to keep things dynamic but still give the Product Manager time to breathe and devs to deliver new product features in a quality-favoring way. Of course, if you have an established product that still rushes features to market, please consider slowing down and allowing the dev team and PM to examine the product's technical state and propose investments that will secure its security and stability for years to come.
Closing words
As you can see, it doesn't take much for even the most skilled Product Manager to push the founder's product into a feature frenzy. It can come from anything like expecting too much, not being able to focus on the right things, or even having too many people to work with. Preventing this, or at least having a feature frenzy by choice, comes down to both the PM and the founder knowing the best set-up for producing quality products. We hope the five scenarios where this goes wrong will help you avoid accidentally slipping into this potentially unfavorable situation.
