Product management at young companies, much like most things there, is like getting a huge ball to move. We keep pushing, never knowing if the ball will move. And, if we are lucky, after much pushing it eventually moves. This uncertainty makes building and managing products at early-stage companies challenging.

I wanted to share a few things I learned from my experiences at TaxiForSure and now at Rocketium. TaxiForSure represents an established company with a proven business and well-defined customer segments. Rocketium represents a company that is still establishing its business and discovering customer segments.

Before beginning, I want to call out the standard disclaimer that no two startup journeys are alike. Product management is (even in 2017) the amorphous term for doing whatever it takes to create a product and make it successful. This may be done by anyone, not necessarily a product manager - founder, marketer, developer, designer. This is especially true in a company’s early days when the team is very lean. It is imperative that someone is responsible for managing the product, and neither 'no one' nor 'everyone'.

I believe a few factors make product management very different at early-stage companies compared to more mature organisations:

• The product is the business. At the beginning, there is just one product and it is indistinguishable from the business. A poor product decision can have a much bigger impact at this stage than when there are multiple products, more established operations, and a sticky customer base.
• Creation is not optimisation. Early-stage companies take the product from zero to one, not from one to n. There is nothing to aim at, no existing problems or improvement areas. Experienced operators can improve an existing product, but it takes different skills to create something from nothing.
• Customer feedback is nonexistent. A well-worn product that customers use regularly will have a huge backlog of pain points, feature requests, and improvement ideas. No such luxury with a new product that customers are still trying to wrap their head around.
• Data, what data? Just as with customer feedback, a brand-new product has little to no usable data that can be used to make decisions. A/B testing landing pages or product experience with 50 daily visitors is often worse than deciding based on the feedback of a few early users.
• Everyone has an opinion. Everyone in the team thinks a little differently about what we are building and how we should build it. They might want to compete with unrelated products, take too much inspiration from established patterns, or have wildly divergent opinions.
• We are always out of time. Larger companies have the luxury to evaluate options, build more than one version, do months of beta testing, and maybe even scrap the product before launching. On the other hand, early-stage companies demand consistently good choices and progress.

With this background, I wanted to share three things that helped us at TaxiForSure and Rocketium to build products that customers loved and delivered business results while balancing all our constraints.

1. Follow a process, even if it is simple

When we start, there are no customers, investors, or specific deadlines (except the date when we run out of money) to guide our decisions. At such a time, it is important to put in place a process that helps to build the product while minimising costs and risks. Even the simplest of processes helps. Setting boundaries on what we will do, in how much time, and in what manner is usually more liberating than having no constraints at all.

At TaxiForSure, our process in the early days was to release a new app version every month. Our iOS developer, who had previously built the excellent Cleartrip app, thought it was crazy to follow a strict cadence. “We should release a new version only when we have something important to launch,” he claimed. TaxiForSure was at a different stage than Cleartrip, which had an established brand and product. I wanted quick updates to fill product gaps. We also needed a deadline, even if it were arbitrary, to ensure we did the best we could each month without getting bogged down by analysis-paralysis.

At Rocketium, we are now following a '40-40-20 rule': forty-percent time for building something new, 40-percent time for bug fixes and improvements, and 20-percent time for unexpected work that might come up. This split used to be '80-10-10' in our first six months when we were building our product from scratch, and '20-70-10' in the two months after that, when our product got more complex and buggier than we liked.

These two may not even look like a process, but they helped put a structure around what would otherwise have been a haphazard way of building whatever came to our minds.

2. Decide using inputs from multiple sources

When there is no product, deciding what goes into it is incredibly difficult. There are so many places from where we can get inputs - ideas from the team, customer requests, features from similar products, and insights gleaned from data.

Each of these must be considered and given appropriate weights to decide what form our product ultimately takes. This could be done iteratively. This could be done collaboratively with consensus from all parties. This could be done authoritatively by a single person or committee. Whatever the approach, we should take inputs from multiple sources and consider them before deciding.

While redesigning the TaxiForSure driver app, we could have done what we were doing with our consumer app - ask our operations teams about the top driver pain points and solve those. However, we felt that we should understand the problems more deeply. Along with the design studio that was working on this project, we interviewed drivers and operations teams. We built mockups and showed them to drivers and operators in two cities with very different driver profiles. I personally drove a taxi and serviced customers to experience what a driver goes through. All this ensured a smooth rollout of the new app and glowing reviews by our driver partners.

At Rocketium, we get ideas from Clevertap data, requests on Intercom chat, and our team. Today, our decisions favour our intuition and customer feedback more than data. For example, when we spoke with the Gizmodo group, they requested richer video editing and finer timing control - two areas we never thought we would touch given our focus on simplicity. We spoke with existing customers and found that these features would help them too. Without waiting indefinitely for more validation or data, we built these features in days, not weeks, made the product richer without sacrificing simplicity, and gained an engaged new customer in the process.

3. Change the process as the company evolves

Just like no two companies are alike, a company is never the same at two points in time. Depending on the stage, we could be figuring out who the customers are, what they want, how much money we can make, how to deal with competition, or how to win that big customer. Along with revenues, also growing are our customer base, team, product complexity, and technical debt. These factors combine uniquely to determine the top priority at every stage and it is crucial to keep evolving the product management process. It is dangerous to follow generic principles without suitably customising them first. The scrappy team loved by early customers for daily product changes will need to change or risk being detested by large customers who prefer stability and consistency.

At TaxiForSure, we saw some of the most rapid scaling in startup history. Every metric went up 10x-100x in 18 months - team members, cab rides per day, driver partners, cities in which we operated. With this scaling, the complexity of software, processes for rolling out new features, and communication challenges within the organisation also went up. We started with simple release update emails to relevant teams. We then started training internal stakeholders before rolling out changes. We moved to detailed meetings with drivers and operations teams before building new features. We evolved this to proactive discussions with our top operators and city heads to identify what we need to build.

At Rocketium, we went from customers not knowing what they wanted, to customers satisfied with what we had, to customers reaching out with improvements, to new business partners suggesting entirely new products. At each stage, we followed a different process and changed how we made decisions. When there were no customers, we decided based on our intuition alone - the riskiest approach. When we had a few customers, we built most of their feature requests. And now when there is a deluge of customer requests, we choose based on how general the problem is, its revenue impact, and the longevity of the partnership with the customers.

Though very high level, these three principles have guided our approach to product management. We are still learning and evolving and are excited to see how we build products in the years to come.

(Disclaimer: The views and opinions expressed in this article are those of the author and do not necessarily reflect the views of YourStory.)