Head of Product. Creator of productmanagementexercises.com.
Before I answer this question, let me share my background with you: I've worked at large companies (a retailer and a bank) and tech startups as a product manager, am currently head of product at a tech startup in San Francisco, and have built a few tech products such as Product Management Exercises with good traction from scratch.
My answer: It’s very different.
The younger a company or a product is, the more it is more of an art-than-science to build the product. The more mature the product, the more it makes sense to follow conventional product management methodologies.
Here are five main differences I can think of:
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.
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.
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.
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.
When you manage a mature product that has various stakeholders and support teams, it’s easier to rely on the expertise of other team members during decision making process. However, the younger your product is, the less likely it is that you have access to such experts in a timely manner.
One way to address this challenge for a PM is to self educate on each topic that their product is affected by - to an extent that they can become a bit knowledgable on the subject matter.
This allows you to move faster without having to find an expert to run a decision by. It also helps you to have a more meaningful conversation with experts when you get a chance to run your decisions and ideas by them. And fortunately, there are so many great books in every subject matter these days.
During the past year, I spent my free time learning more about product marketing, SEO, data analytics, gamification, and data science as growth was a priority for my product.
And I can already see the positive impact of making higher quality growth hacking decisions at a faster rate. My broader knowledge base has helped me do a lot of the trade offs in my head quickly.
When I worked as a product manager at a bank, the company had so many experts and resources across the organization that it was easier and time efficient for me to pick up the phone and talk to the relevant expert. Afterall, they were getting paid to be the subject matter experts for the company.
In the end, there are certain things such as ‘good communication with stakeholders’ that a product manager has to do well regardless of the size of the company they are in or the phase of the product lifecycle. But when you are a product manager at a startup, the hows of some of those tasks change.