I’ve often been asked what is it like building products at an early startup. I would describe the experience as building an airplane while it is in flight! Not just that, often fellow passengers and crew make you sit in the pilot’s seat too, especially when the plane hits turbulence!
I was given the mandate of supporting the servicing of the customer vehicles of a fledgling electric vehicle startup in Bengaluru. Fledgling startups do not have a lot of things figured out –
- the functional processes that your internal stakeholders follow are at the inception stage and constantly in flux, as the stakeholders themselves are figuring out the way of working;
- many of the supporting functions for Product are non-existent – Program, Project & Process Excellence (3Ps);
- engineering and design resources are often sub-optimal and are often horizontals shared across different products.
A Product Manager at such a fledgling & effervescent startup needs to be comfortable wearing different hats, but foremost needs to be able to thrive in chaotic and ambiguous business environments. Jotting below few of the strategies that helped me navigate choppy waters.
Born On The BAU
One of the key responsibilities of a Product Manager is to always be cognizant of the stakeholders’ imperative to keep the wheels turning at all times, which is to say status quo of Business-As-Usual (BAU) needs to be maintained at all times. I resorted to employing one or a combination of the following strategies as per the resources available and criticality of the business scenario. #LifeProTips to keep the BAU going:
- High business criticality and dev resources available: Since you have dev bandwidth available, it is always better to build than to purchase, so as to retain full control over highly critical business processes. However, it takes time to build in-house. So, when you are in the process of building the various versions of your well-thought-out epics, it is a good idea to release pre-MVP prototypes of a stripped down version of your product to support BAU in a low/no-code platform such as Retool, Appsmith or even Airtable. The added advantage is that this helps test out your assumptions IRL.
- High business criticality and no dev resources available: Explore vendors who can white label their platforms to your, and always be sure to deploy high business critical systems on-premise with on-call downtime support available from the vendor.
- Medium to Low business criticality: A good PM is always a good quick on-the-feet thinker. A PM is primarily a problem solver, and the solution to a given problem statement might not involve tech at all. A business process can always be supported by a no-tech solution such as a well designed spreadsheet accompanied by a well-designed SOP clearly charting out roles & responsibilities of the various team members responsible for maintaining the spreadsheet.
Flexible Systems Architecture
At an early stage startup, the business processes are always in a constant flux. The software systems, thus, need to be designed in such a fashion so as to accommodate the constantly shapeshifting on-ground realities. A good product is one that is empathetic to its users’ changing needs. Hence, employing an architecture or choosing a platform that allows for quick changes to the process is essential to stakeholders to test out their nascent processes. In fact, I built the first version of the Vehicle Service Management System by hacking JIRA since JIRA allows for visually constructing a process diagram with associated scripted post-functions that could trigger APIs to carry out the actual blocks of business logic. This allowed me to quickly iterate different versions of the process with quick feedback loop from the stakeholders. A microservice architecture over a monolithic architecture is also desirable at this stage. A flexible low-code Business Process Modeling Notation (BPMN) orchestration engine such as Camunda could also be considered.
Short-term Manual SOPs, Long Term Scaffolding
“Knowledge is power” is a truism more so in the case of a start-up. A growing business is always hungry for data but the modalities for ingesting data are not mature yet. In such scenarios, Product Managers also need to be adept in designing future-proof data systems as well as designing well crafted SOPs (Standard Operating Procedures) that relevant downstream team members can employ to populate the said data systems. SOPs that are well designed and executed manually initially can be replaced by automations later in the products owned by the PMs.
Supporting L1 Support
An early stage business tends to attract plenty queries, issues and bugs raised by the end users. It is the Product Manager’s responsibility to have the foresight to build a set of tools alongside the MVP version of the product to enable the customer support teams resolve the customer queries and issues in a quick and equitable manner. This set of tools could be as simple as a Postman API collection released specifically to the TechOps L1 support team alongside a ticketing process handled by the customer support team. These initial projects could later spawn full-fledged elaborate internal products in their own respect.