Evolution Of Product Management From A Startup To An Organisation

During an organisation’s initial years, the product team will essentially comprise of a few members faced with the difficulties typical of the startup phase, but as the organisation grows, the team size and product management practices will need to scale as well to achieve growth proportionate to that of the organisation.

Speed is of the essence for a startup and even more so when you are in a hyper-growth phase. As the business scales, every product manager will have to deal with multiple stakeholders. This is where your skills in conflict management and your ability to take tough decisions become critical.

Such decisions will involve trade-offs and not every stakeholder can be satisfied, but as a product manager, you have to implement the changes you find necessary in the interest of the business and to propel the speed of execution.

During the growth phase, a good practice that can be adopted is to decentralise the concept of feature building by dividing your existing team to sub-teams who will be responsible for the product they are allocated with. This approach will certainly aid faster decision-making, remove bureaucracy and drive accountability.

When there are multiple stakeholders depending on the product team to drive business outcomes, it becomes integral to create a culture of transparency on the specifications, timelines, issues, delays, etc. This will require a tool that can be adopted across the organisation, thereby initiating a big change from the startup environment where all this information was restricted to shared drives and group discussions to set expectations that are visible to the entire organisation.

Based on this context, the entire concept can be broken down into key points to get a detailed insight on scaling the product management vertical in a startup.

Decision Making

The best way to go about this is to decentralise the process by allowing decisions to be made within each product team, taking into consideration the inputs or suggestions from stakeholders. It will be the prerogative of the particular team to decide feature releases or to work in sprints.

While the level of autonomy in decision-making will vary across organisations, tasks broken down and distributed in this manner will guarantee that every unit of work is delivered. Additionally, this model will help reduce delays, improve accountability and help in workload management.

One thing that every product manager has to ensure while making decisions is to keep in mind critical factors such as compliance, security, fraud controls, user access, etc. and ensure that there is no personally identifiable information that can be misused.

Often Product Managers will encounter or debate on multiple features that need to be developed for various end users of the product. Product Managers have to keep in mind the entire stack of features while taking the decision on what to build with the limited bandwidth available in every sprint. Point-based matrix could be one method that could be used to evaluate while making decisions, Each row signifies a feature and the column is evaluated with a score on:

• Technical feasibility
• Business Impact
• Time to release
• Customer experience

The feature with the highest weightage can be prioritised, as you will experience tangible outcomes faster.

Road Mapping

For any product, it is considered a good practice to design a roadmap for the set of features that need to be built, the entire plan set within a time limit of 6 to 8 weeks. In today’s world, necessities change rapidly and the true test of the validation on a feature comes from the data provided.

During the growth phase, product management should be driven by customer feedback or data. On the contrary, road mapping in the startup phase is an entirely different process where decisions are gut-based, which may or may not be impactful.

Think about which is the minimum viable product to launch and go to market accordingly, so that the end user will experience and pay for the product. For example, one may decide to launch an email platform just to send and receive emails, but the customer may provide feedback that they require the option of attaching documents, storing contacts or even organizing emails into different folders.

This is how products evolve based on feedback, eventually leading to the creation of a comprehensive product suite.

Communication

Following a standardised communication process extended to all internal and external stakeholders well in advance ensures further transparency of operations.  While it may sound bureaucratic, one key behavioural change that can be adopted in the transition is to get sign-offs at different stages ahead of execution. Release notes, demos / UAT, go live intimations, updates, etc. become critical to the process for audits in the future.

Adopting the above practices will enable you to carry out operations faster than the conventional way of performing the same.  Scaling product management to an organisational level is never smooth sailing, but following simple practices in a systematic manner simplifies the quantum of changes that accompany the transition.