The Startup Product Managers Manifesto

Uncovering betters way to manage products in a startup by doing and helping others do.

After spending 5 years in the exciting world of startups, I realized that there is a specific product mindset that thrives in that world. That mindset, if carried over to established organizations or large corporates, can have some devastating effect on the Product manager. However, in short sprints, this mindset is great to get off the plateau and rise higher.

As a startup grows, the role of the product manager (or the product team) evolves. Where they were initially driving macro gains through a dogged focus on low-effort-high-value items, they now drive more strategic optimizations that tie-in with the overall product strategy. Their initial dogma revolves around independent decision-making, learning things about the team, the customer, and the product. As time progresses and the Product-Market Fit is achieved, the backlog changes to a more strategy-driven one.

Product focus with time in a Startup

The Startup Product Managers’ Manifesto

But before that, a product manager in a startup should abide by the following:

The Startup Product Managers’ Manifesto

There are a few tenets that drive these items:

  1. Every member of the development team is working together — egos have no place.
  2. Business focus is paramount here. Do whatever it takes to make the business successful, even if it means the customer experience is sacrificed in the short term.
  3. The team is independent to do what is right for the business. Trust in the team. The term ‘independence’ is bound to be misinterpreted here. The team takes the right decisions — the product manager only facilitates the conversation and conveys them across the board.
  4. Removing hurdles, immediately, in the way of success (or potential success) is required
  5. Agile practices, can and will be disregarded to achieve business success. The debt that it incurs will be handled in the later stages
  6. Processes will be formed, broken, and formed again. There is no process that above change/improvement.
  7. Time is a valuable resource — the longer you take to decide on a strategy, the lower the team’s enthusiasm will be…
  8. Everyone is guilty, until proven innocent.

Let’s look at each item one by one.

Humility Over Ego

Keep your ego aside. The ability to say ‘I don’t know’ is critical to the success of the product function. You have to know when to bullshit and when to admit defeat. Note that saying ‘I don’t know’ doesn’t mean you give up! It only means that right now, as of that moment, you’re not in a position to answer. The ‘I don’t know’ has to be followed by ‘but I’ll find out by X date/in X hours’.

Ego is the biggest creator of bad products. Once egos come into the picture, you would have lost a part of the team and the faith of the stakeholders. You have to be humble — your successes are those of the team, your failures are your own.

With humility, you learn — so adopt a method of learning through failure.

Remember, no one asked you to show up — you are there on your own time making sure there is alignment. A complete loss of a product function will not stop the organization from functioning the same way the loss of engineering teams (or even some key engineering team members) would. You are a proxy function, and your opinions are just that — an opinion, amongst a thousand others. Build that humility and adopt a servant-leadership style.

Product over politics

In the early stages of a startup, there is bound to be some level of politics. Founders usually bring their trusted people to the decision-making committee. Hence, there will be some level of toe-stepping, hurt egos, and the subsequent group formation. Each team overriding each other priority that can cause massive roadblocks in product delivery.

We deal with that by advertising, in plain and simple language, that the product is above all things politics. The founders/leaders need to know and trust the team to make the right decisions for the product and partake in guiding them/providing them with information to those decisions.

Similarly, inter-development team politics should be identified and rooted out.

Personal agendas and individuals glory take a back-seat. Highlight members suspect of this and clearly outline how these things are not driving the product goals.

Working Iteration over perfection

A working product is better than a perfect product. Usually, both the technology and design teams fall victim to perfection. The myopic view is derived as a function of improper communication.

In the startup product role, we value a working product, that performs the goals it has been assigned, without the need to find perfection. This can mean forgoing A/B tests to identify the best-possible iteration OR spending extra time to avoid technical debt.

The tradeoff between technical debt (which can be both design & code) and the working product is a no-brainer. Incurring technical debt is a trade-off and should not be avoided. The debt, however, should be present in the backlog — to be taken up for a later time.

Delivery & Ownership Over Discussion & Process

In an unknown land, it is easy to spend days discussing the best way forward. People will site their previous experiences and offer ways to navigate. These discussions stall and delay the value delivery pipeline.

What helps in this phase of startup product management is the understanding of the following:

  1. The team is responsible for the outcome. There has to be a sense of ownership — a pride that together the team has delivered the outcome — good or bad.
  2. Failure won’t be chastised — it should be a learning going forward.
  3. Moving is more important than stalling

As the saying goes, ‘nothing ventured, nothing gained’.

Actuals Over Possible

This ties in with the above two items. We prefer established routes over possible good-to-explore routes. This can mean blatantly copying of competitor approaches or even going by the collectively decided approach.

Practically, this means we focus on reducing options in our approaches and focus on the actual value delivered. We focus on directly impacted metrics, leaving the speculative in-direct metrics to fend for itself.

Breaking Barriers Over Living in the Comfort Zone

This applies both to the product manager and the team involved. For a product manager, it’s about getting their hands dirty — the data team is busy with work on something? Get access and build your reports. QA team is taking time to clear off some test cases? Do it yourself!

Similarly, for the team — standard conventions cannot get in the way of the business goals. “We used to do it this way in my previous organization” is a phrase we’ve to discourage. Every norm has to be vetted before the team collectively agrees on it.

Capacity Pushing Over Capacity Planning

Startups usually do not have a lot of resources but have a tremendous amount of work to be done. The excuse that we do not have enough people to launch a feature within a given time should not be entertained. Find ways to get things done and achieve them together. Capacity has to be pushed before we can start the capacity planning. The reason I added this as a part of the Startup product management is that teams have this need to assign items to the future. I.E. Knowing that 3 new devs will join, they’ll push those items till those devs join. We’ve to fight this attitude and stoke a constant fire in the team.


Startup product managers are in a unique position to mold the product to their liking. The key aspect of the product function is prioritization. But if you cannot build your own priorities, how can you prioritize work for others?

I’ve found that being disciplined is crucial to success. Some of the great product folks I know lead a very disciplined life. While you may be starting out, set the foundation right now for a better tomorrow! Hopefully, the manifesto I’ve outlined will help you create those priorities, and lead a more disciplined product work-life!

Thank you!

Simplifying Complexities for a Living |

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store