it makes sense to follow conventional product management methodologies. Here are four main differences I can think of:
1. Your objective is different
Before building a new product and shipping it, product managers should know the objective of that project. Knowing the objective helps you navigate through product specifications, areas of focus, and user groups you’d like to target. Your objective generally changes according to the phase of the product lifecycle the product is in. If you have a new product, your objectives are more qualitative. Examples are, “Is there a demand for my product?”, “What is my ideal user group?”, “I just want to learn how the users interact with my product” or “What problem am I solving exactly and for who?”. In all these cases, you are trying to ship a product quickly so you can learn more about the market and your target market.
It’s important to keep a Minimum Viable Product (MVP) mindset at this phase of product development. Meaning, make some decisions around narrowing down the functionalities you are going to deliver. Minimize efforts on enabling the users to change settings. Focus on getting the default product settings right for your audience.
When I decided to build Product Management Exercises, my first MVP was a WordPress blog. I posted an exercise and an answer, shared the link on Reddit, and asked people to share their feedback. In less than 24 hours, 13 people informed me what they liked and didn’t like about the product. The feedback helped me make a bunch of other product decisions that resulted in what I have today with over 10,000 monthly active users. However, this approach will not be applicable in the case of a more established product.
Product management in the early phases of product lifecycle relies heavily on intuition. This is why having a person with some key insight about the industry, the target market or the new technology will provide significant value.
The later you are in the product lifecycle, the more you know about your users, their behaviors, and the environment under which they interact with your product. This means that as a product moves towards maturity, the product manager’s decisions rely more on historical user behavioral data, customer feedback, and market research. When I was a product manager at a bank, we would have to go through a few rounds of product ideation, prototyping, user testing, and collaboration with other product teams to ensure that the new product feature does not impact any other aspect of the business in a negative way.Think of it this way. When you are building a completely new technology, you will be betting that new use cases of your technology will emerge as your product matures. And your objective in the initial days of the product is to find out what those early use cases are so you can focus on building for them.As your product becomes more mature, you have a better idea of who wants your product and what they want more of. This gives you a chance to rely more scientific approaches of product management to extract the information you need to enhance your product.
2. You will care about different set of metrics.
Since your objectives are different, it’s expected that you’ll be caring about different set of metrics at a startup. Mature products’ PM’s focus on metrics such as engagement within a portion of the product, higher revenue per client, smoother client onboarding, and retention. Whereas, a new product’s PM generally focuses on higher level metrics such as total number of sign ups. At Product Management Exercises, my first metric to track was the number of page views per user. The numbers gave me an indication that people found the website valuable.As things progressed, I started looking at more meaningful metrics such as the number of comments per user and the retention rate. After all, a high number of page views will not always represent meaningful engagement. Maybe your users are not able to find what they are looking for.With my previous employer, we paid attention to activity-based metrics such as the number check deposits per user and the number of bill payments per user.
3. You must be flexible to changing plans.
Startups have limited resources. They generally have anywhere between a few months to just a couple years to grow to their next phase. It’s important to be very strategic about your resources and what you’re building. The earlier you are in your product lifecycle, the more nimble you must be with your product roadmap. You are building something new for the first time and don’t know if your target users like the product. You might realize there are some technical challenges that you haven’t accounted for. So, how do you deal with this dilemma? I like planning ahead (6 weeks roadmaps in the case of an early stage startup) but staying very open to change of plans when new information arises that tells me I need to move in a different direction. A startup PM should critically look at their roadmap and backlog every week and ask themselves, “Are we building the right thing?”. Don’t get me wrong, request for new things to fit into your roadmap is a constant in product management. This is actually one of the challenges that all PM’s deal with throughout their whole career but as a product becomes more mature, the PM can do more planning because they have a clearer idea of what the users want and what they can build with their tech stack. What’s really dangerous is for a tech startup PM to try to make the product development process too efficient by planning too far ahead and forcing the team to continue building something that is not going to add value. I remember launching a new feature on my website and planning to move on to the next feature right away. However, after a few days of launching the first feature, I realized that users were confused about the new feature’s interface. So, I changed my priorities and focused on fixing the UI before moving to my next task.I’ve also been a part of startup teams whose priorities have changed overnight based on an announcement made by their partners or their competitors.Compare this to a PM role for a more mature product, where the roadmaps are generally determined and planned ahead. With my previous bank employer, we did a series of prototyping and user testings prior to launching and this reduced the amount of follow-up works we had to do. In addition, the company priorities were determined at a higher level and we were not expected to change them on a frequent basis.
4. Spend more time with your users.
You are just starting out and are trying to learn more about your target user and their needs. And given you have limited resources and run-way, your knowledge of your users and how and if they interact with your product has a direct impact on the survival rate of the startup you are a part of.The sooner you know their opinions about your product, the earlier you can adjust your plans in terms of resources and the higher likelihood of reaching your next milestone of hitting your next goal before you run out of money. For consumer products, I try to spend a few hours per week with my early adoption users. For enterprise products, I spend about 30 minutes per week with a selected group of clients each week to ensure that I understand the world they operate under, their needs, and their true feelings towards the product. When I started Product Management Exercises, I spoke to 3 to 5 users each week to understand their needs, things they like and don’t like about my products, and competitive offerings.However, with my previous bank employer, the user interviews came in batches and were more specific to the feature lifecycle and the particular capability that we were building. The user interviews generally would happen during the research phase and user testing with very specific objectives related to that particular feature.