Starting to feel the pain of not having product managers? Read this!

Victor Landau

·

Follow

Published in

Point Nine Land

·

19 min read

·

Apr 22, 2021

--

2

Listen

Share

Intro

Guest post: Hi, my name is Victor. I co-founded a company called Spotistic back in 2012, which we sold to Uberall in 2015. Since then, I have been leading Uberall product team, which we’ve scaled from 3 people to 12 people over the past 5 years. We grew from less than a million to several tens of millions of ARR (Annual Recurring Revenue) during that time.

There are many posts out there explaining how startup co-founders should “land the first sales, then hire the first 2 sales and when to hire a VP sales”. But, in my experience, there’s very little written about what is the equivalent for Product Management.

I’ll try to make up for that in this post covering how to get started with Product Management (PM) in your company tackling 5 key aspects:

1. When and how to hire your first PM?
2. How to transition out of founder-led product management?
3. How to efficiently collect feedback from customer-facing teams?
4. How to build and maintain your first roadmap?
5. How to get the company informed and excited about what Product is building?

The whole article is very tactical and is based on my own experience with the Uberall product team. Not everything is going to work for everyone. We learned most of the things the hard way and we are actually still iterating and learning about many of those aspects.

The article is using the word “growth” a lot. This refers to the improvement of your main output metrics. Most of the time in Saas, it is going to be ARR (Annual Recurring Revenue) but it can be anything. If your mission is to reduce CO2 emissions, you can (potentially should) make this your main output metric.

My hope is that:

• 70% of this post is just going to make sense to you and is kind of obvious (or it might just help you structure thoughts you already had)
• 20% might lead to a true “needle moving” discovery for you and your team
• 10% is going to be complete BS, because you already figured out a much better way. Please report back on those, I also want to learn!

1. When and how to hire your first PM

Louis already wrote about this with his VC hat and discussing with Pauline, the VP Product at PlayPlay (check out his post here) but I thought I’d also give you my take on this question to complement his. Just like your first sales are being done by one of the co-founders, the first product concepts are being done by one of the co-founders. And they are probably doing that among other things: leading the engineering team, coding, hiring, selling, fundraising,…So PM isn’t their full-time job.

The healthy ratio of full-time PMs to dev is typically between 1:5 to 1:9. So when you have around 5 developers, the founder who is leading product might start experiencing a few pains like:

• An increasing mismatch between product requirements and delivered products
• An overwhelming amount of customer feedback to handle and prioritize
• More friction between software engineers and customer-facing teams
• And probably many more…

When you see the first symptoms, start the hunt for your first PM. Start early as finding the right PM for your company might take a while (often a few months).

Here is a non-exhaustive list of things to look out for:

• A good level of compatibility with your product philosophy: where do you get feature ideas from? How are you coming up with the best solutions? How do you organize your work?
• An experience that is well aligned with your product: has the candidate been working in B2B vs B2C? In SaaS vs. marketplaces?
• A good ability to work in an early-stage setup, i.e. to thrive with little guidance and figure things out by him/herself
• Some typical important PM skills: be an all-rounder, decisive, a quick-learner and/or be capable of supporting in a sales pitch as well as querying the database.

All-in-all, this is not uncommon to screen through more than 100 applicants to find 1 fit.

As interviewing 100 applicants can be quite draining, I recommend the following process:

1. A quick HR interview

2. A written assignment with 4 tasks:

• A feature task. Ask the candidate to come up with a concept for a feature that is in your roadmap or that you recently released. This is your opportunity to test how they can adapt to your industry and the kind of problems you have to solve.
• A prioritization task. Give the candidate ~5 real examples of the kind of things you have to prioritize: customer integrations, feature requests, strategic releases, bugs, database extracts, opportunistic features… and ask them to prioritize.
• An organizational task. Share with the candidate your current team headcount (full-stack, backend, frontend, designers,…) and ask them how they would organize the work that has to be done: customer integrations, strategic releases, bugs, database extracts, opportunistic features,…
• Self-assessment on important skills: business analysis, software development, writing product requirements e.g. Please rate your experience with software development: I’ve never had the chance to work closely with developers, I’ve worked with development on several projects, I’ve managed or lead projects with developers on the team, I used to be a developer

3. If you like what you read in 2. Invite the candidate to a face-to-face or a Zoom interview. Ask more questions around the tasks and what they do in their current role with the perspective to understand if they would thrive in your environment.

4. Culture fit interview. The PM will have to interact with a lot of stakeholders in the company and sometimes make a lot of hard decisions. If they are not a culture fit, these discussions might be very hard…for everyone!

By the way, some companies start with 2. Try it out if you have limited HR resources.

2. How to transition out of founder-led Product Management

You just hired your fist PM. Are you done with product management? No, don’t drop the ball just yet (or ever)! You woke up one day thinking that you would dream to solve this big problem for this big, fast growing market and that you were the right person to do that. It wouldn’t make sense if you stop being in the product team from one day to another.

Now the question is: how do you go from being co-founder and PM to being a C-level and a leader for the product team as well as other functions of the companies?

First, act as Group Product Manager, a hybrid role between individual contributor and manager:

• As an individual contributor, you continue to be the product manager for features that are dear to you and you don’t feel like delegating just yet. This is a way to lead by example and work “in product” to better understand how things work, identify operational bottlenecks and iterate on your product culture. You are a sparring partner for other PMs, proofreading their concepts to make sure they are sound and clear. And respectively!
• As a manager, you make sure your first PMs (up to 3) are working according to your product philosophy and understand your vision. Usually, top performers in PM teams don’t need much guidance and don’t necessarily like it either, so there should not be too much hand-holding. Start by giving them 1 feature (e.g. As a user, I want to be able to invite another user), then 1 epic (e.g. Collaboration tools 1.0). As soon as they are able to do those with no/little help, let them figure out what they should do next. So your main task is to make sure things are going in the right direction and that your PMs are growing and becoming more independent. There are a bunch of generic management tools to help you achieve that such as seniority matrix, regular 1o1s, performance reviews, regular update meetings and/or offsites.

When you have 3 PMs, this is about time to think about having someone else than you to lead the team. 2 options:

1. Promote one of your team members. If you have a high performer in the team, with some good management potential, you can promote them to a group product manager role. The great thing about this option is that this person already knows your industry and where the product is heading. It is also very flexible. If everything goes well, this person is growing in the VP Product role as they get more reports and successfully overcome the challenges of the growing organization. And if they don’t get there, you always have the option to hire a VP Product. Then the GPM can either stay where they are or become a very senior (principal) PM.
2. Hire a VP Product. This is the option you can trigger as soon as you have 2 PMs or later (as explained in 1). Just like for any VP role, don’t rush it. It is very easy to get impressed by someone who seems to “have done it before”. Are you hiring someone who can really bring you as far as you want to go from where you currently are? Do you really know what “good” looks like? If you don’t have anyone in your company who has worked closely with a VP Product in an organization at the stage where you’re heading to, or has been one themselves, don’t hesitate to ask for external help at least to come up with a good process, or help you hiring. Actually, don’t hesitate to reach out to me, I am happy to help!

Whichever option you choose, stay close to the product team as long as necessary:

• Be part of the interview process
• Hang with the product team
• Monitor product releases and ask questions when it doesn’t seem to be following the vision and product philosophy

3. How to efficiently collect feedback from customer-facing teams?

As your company grows, the customer facing teams (sales, customer support, customer success,…) are growing and the number of questions flowing to the product teams is growing:

• Is it possible to do this? How is it working?
• When are we going to do that?
• Why is this not working?

In early-stage startups in the pre-2020 area, it was very common to have people simply run to one of the product managers’ desks or to one of the engineers with one of those questions. Today, I can imagine people simply starting a Slack call. This is killing your PMs and engineers’ focus time, and therefore lowering the quality of your end product.

On the other hand, if those questions get lost you get a complete disconnect between product managers and the customer-facing teams. You can prevent that by setting up healthy asynchronous communication channels:

1. Setup an internal “How-to” channel for questions like “Can we do this? How do we do that?”. You should also have an internal knowledge base and the most common questions should be answered there but there will always be questions that are not addressed in your knowledge base. So, you need to open a channel for these. We have been using a Slack channel for the following reasons:

• Everybody in the company can read. So one person asking a question can help many other people at the same time
• Everybody in the company can answer. This way, employees outside the product team can also answer
• One can search in the channel for already answered questions

You can use any other channel that checks the 3 marks above.

2. Set up a ticketing system for feature requests and bug reports. We use a separate Jira project for the following reasons:

• Jira because it is well integrated into…Jira where we manage all our developers’ tickets.
• A separate project because we don’t want the whole company to be able to create tickets directly in our main projects. When this was the case, we had a lot of tickets being created in an “invisible” part of our project and therefore, not correctly triaged or sometimes completely forgotten.

You can use any other relevant software for that and I believe there are tons of options in the market. The most important is that every feature request and bug report get into this system. Whenever you get them anywhere else, ask people to put them in the right place, otherwise things get lost. It also makes sense to have bug reports and feature requests in the same place (with different types), as sometimes the separation between the two isn’t that obvious for everyone.

For those 2 channels (Slack and Jira), maintain an “Inbox 0” policy. If you don’t, people will start losing trust in them and this is the beginning of an inflation that will burn your team out. First, they will use channel 1 and 2 at the same time for the same thing, then they will use 1 and 2, plus send a private message to one of your PMs, you get the idea.

Here are the things that have to be done with those incoming messages and tickets:

• Dispatch them the right channel. E.g. Ask people who come up with feature requests or bug reports in channel 1 (Slack) to write a ticket on channel 2 (Jira).
• Identify duplicates. Close duplicates and link them to relevant tickets, or let someone know that there is already a ticket for what they are asking about, or already a knowledge base article, or already another discussion.
• Assign the right priority to bugs and the right status for them to be picked up by developers today (for critical bugs) or later (for non-critical bugs).
• Move feature requests to the backlog. The vast majority of the time, this is just not worth discussing now. If the feature isn’t in your current roadmap, you just don’t know if and when you’re going to ship it. Even when you’re 100% sure right now that you will never do it, you still don’t know whether this feature will become relevant in the future. So just move it to a well organized backlog, say that this isn’t in the current roadmap and be thankful for the feedback. The only time where it is worth discussing now is when this has the ability to land you very significant growth right now and for sure (more than 1–5% depending on the stage of the company). More on that later.

As a result of this process, and the growth of your customer-facing teams, you quickly grow a very significant backlog, sometimes multiple years of development. Let those tickets compete for your attention. Set up a maturation process based on customer-facing teams’ feedback:

• Colleagues will watch tickets they are interested in.
• They might comment on them.
• You will close incoming tickets as duplicates of backlog tickets and link them to those.
• Ask to link tickets with customers/prospects who showed interest in them.

Basically make sure you keep a record of any signal that makes a ticket just a little bit more worthy of your attention than it was before. Once this is in place, you should create a scoring system based on all those signals. Put together a process that scores your entire backlog based on this (with Jira it can be done by exporting all your tickets in a spreadsheet, and a few formulas). But there are also dedicated tools for that, if you are not satisfied with Jira.

On a regular basis (every 3 months to 1 year depending on how quickly your backlog evolves and how often you iterate on your roadmap), look at the top tickets (top 10% and minimum score) and take some decisions about those: either add them to your roadmap, or keep them in the backlog and add some explanations on why you decided not to move forward with this yet, as a comment in the ticket. Remember there are tons of reasons (not) to say “yes”.

4. How to build and maintain your first roadmap

In early-stage startups, roadmaps are either a running gag or a very controversial topic. Why would you come up with a 24 months roadmap when you just have funding for another 6 months and still didn’t figure out your product-market fit? If you apply Paul Graham’s “Startup = Growth” logic to product management, you come to the conclusion that in early days, being very reactive and tactical might be the best product strategy. The product that lands you 5% growth every week is probably better than the one that is just blindly following a very visionary strategic product roadmap that was put together when the company was founded. There might be exceptions to that out of the software world, for things that require longer development and production cycles.

As long as you have only 1 product, more than 20% month-of-month growth, and a very active feedback loop from existing users/customers, the tactical strategy might remain the good one for a while. The process explained in Part 3 will go a long way in helping you prioritize between a ton of things that really just seem like must-haves and will clearly help you capture more growth. As a result of that process, the top of the backlog will become more and more stable, so you will always know the things that have to be done for the next 4–5 sprints.

You are now ready to have a rolling 3-month roadmap:

• Each month, you perform your backlog analysis, figure out the tickets that are most likely to bring that growth in, and you add them to the end of your 3-months roadmap.
• The 3-month roadmap has a proper timeline and you try to stick to it. Stay agile on the scope of each functionality. Also, don’t hesitate to minimize (half, not half-assed) to be able to ship on time and avoid overgrowing your product. You will always be able to come back and add more if you get good traction, in a couple of months
• While you do your backlog analysis, collect a few hot topics that you are not able to work on in the next 3 months and add them to an uncommitted roadmap without any specific ETA. Those are the next things you are going to work on if nothing else more important comes up in the next month. Spoiler: things come up all the time! And when they do, it is a good sign, it means that your company has a lot of immediate opportunities for growth!

The easy growth, reactive 3-month roadmap is a phase and it doesn’t last forever. At some point, your product reaches a higher level of maturity, your revenues are a lot more significant and more and more feature requests seem like they are only going to benefit a few of your customers. In short, they don’t always have significant growth potential, and if you keep going like this, you will probably fall into “the Build Trap”. You can’t win with each move any more, and need to think a couple more moves ahead. It is time to be a lot more strategic, and for this you have to plan on a longer time frame. 12 months is a good start because it creates alignment with everything else: other departments’ planning, vacation days, seasonalities, customer’s contract lengths,…

A product roadmap is not a list of features and release dates. This is what a lot of people want it to be but this is not what it should be. A part of your roadmap can be that, and sometimes should be, but this isn’t the main point. Just like before, it is about optimizing for growth: a roadmap is a 12-month resource-allocation framework optimized for long-term growth. If your roadmap doesn’t have a list of features and dates but achieves higher growth, everybody is better off.

How do you put together this framework? Start by figuring out the strategies that will bring you effective, efficient and long term growth. This is an exercise that should be done with input/feedback of the leadership team. Here are a few examples of strategies that can apply to Saas:

• Self-service
• Enterprise-readiness
• SMB-readiness
• Easy/simple
• Internationalization
• Retention
• Activation
• Recommendation engine
• Reporting
• Platform (vs Point-solution)
• Integrations
• Operational efficiency
• KPIs that are important to your customers: e.g. booking rates if you are a hotel booking SaaS
• …

Then put together a strategy/tactic/metric map, to make the link between those strategies and your relevant backlog features/projects/ideas, aka your tactics. Figure out the growth potential of each strategy in different scenarios: this strategy will bring x% growth if I manage to deliver the following bucket of tactics (when you know what to build to get there) or this strategy could bring x% growth (output metrics) if I manage to move the input metrics by y% (when you need the process to be more explorative).

Once you know the growth potential of the different strategies, you need to allocate your resources accordingly. If your company goal is to grow 2X (+100%) each year, a strategy that can give you ~10% growth in a certain timeframe (1 quarter, 1 year or 2 years) should be allocated up to 10% of this same timeframe’s resources.

Now, get a quick estimate of the resources needed to deliver each tactic and figure out if your strategies are possible and efficiently driving growth according to the following criteria: resources needed for delivering tactics < max resource allocation based on growth potential. It helps to measure resources in dev-sprints. You have a number of devs in your team, and a number of sprints in a year ((number of working days — paid time-off)/10 if you work with 2 week sprints). The multiplication gives you a number of dev-sprints to allocate. The more engineers you have, the more dev-sprints you have, so the easier it becomes to find strategies, and at the same time the more recurring revenues you already have and the higher the growth target, the harder it gets. Over time you will get to know what is your company’s typical New ARR Target /dev and you will right-size your engineering team.

Now, you can deliver your roadmap by prioritizing strategies and tactics that deliver the highest growth potential with the lowest ressources and put together a timeline of when you are going to allocate resources to what. Sometimes you’ll know more or less what is going to be delivered when, then there is no reason to hide it. Sometimes you know that you will be working on improving something with a number of engineers and during a number of quarters, you have a reasonable metrics target but you really don’t know which features are going to be delivered, then better present it that way.

In any case, make sure that you are not planning more resources than what you actually have at any point of time. This seems obvious but it is easy to fool oneself and try to aim for an unrealistic roadmap: e.g. “I can have one dev working on those two things at the same time”, or “We will have hired 20 more developers next month”. This never works, creates unnecessary stress and wrong expectations.

This process requires a lot of assumptions and is not hard science but the key is to focus on growth of your main output metrics. You are not an agency and this isn’t enough to do stuff that just pays off your engineers, you need to optimize your resources to generate the highest growth.

5. Get the company informed (and excited) about what Product is building

This is probably the hardest and always improvable part of the job. The amount of information, training, content and repeating that needs to go from product teams to marketing and customer facing teams is never too much. Many teams underestimate that.

Let me give you a list of things you can (should) start doing sooner rather than later:

• Release notes. This is the most basic one. If you have releases (which I guess you have) and you are not having release notes, you are in great danger. Your colleagues don’t know whether you finally developed the password reset, some others actually think it was even there and it disappeared. And they will rightfully ask you, multiple times per day. Good luck! We put our release notes in one single Google Doc, this way people can search, they are “bullet-pointy”, short and sweet and they have links and/or screenshots to make it easier for people to understand what it’s all about.
• Epics. Group tiny features into bigger epics. The company cannot make sense of the 50 tiny tickets you have just shipped. They don’t want to read that you moved this button from left to right, added an undo link there, re-factored the password reset, added 3 fields on screen 2 and removed 1 on screen 4. This is not even how you should think about this yourself. You just revamped the onboarding experience. Group features by epics that have a “before” and an “after” and create value for customers
• Showrooms. Organize a product showroom at the end of every release cycle (every 2 weeks, for instance) to show and explain what has been shipped. We used to go with just preparing a bunch of tabs and showing everything one after the other and this was not valuable enough. You need to prepare a nice presentation with things your colleagues can take away: more value and benefits, less features and tech details. Not everything has to be demoed, just the really cool things, sometimes gifs and screenshots are enough. Nobody really cares about all the complexity you had to go through to make your features super simple for your users. Keep it simple, all the way.

• Roadmap. Present and make your roadmap available to the company as soon as you have one, and make updates. Work on a high-level version that can also be shared with customers and prospects.
• Launch documents. Put together documents about your biggest upcoming releases stating why you are developing this feature, who it is for, when it is going to be released and basically all the info people keep asking you about.
• Storytelling. Start looking into storytelling frameworks to make your product presentations more engaging. At the moment, I am a big fan of Andy Raskin’s (also here), as it applies really well to B2B, and it isn’t typical personal storytelling that is not natural to most PMs.
• Reviewing customer facing content. Look into sales pitches, demos, webinars,… Did your presentations/contents translate well into what we are showing to prospects and customers? Are there opportunities for improvement? Those disconnects can create mismatches between customer expectation and delivery and therefore friction in the organization.
• Product Marketing. This is the function in the organization that is really going to amplify the product messaging in your company, and the other way around. Good product marketing is not going to do any of the things above but will just make those a lot more effective.

Conclusion

Thanks for reading. I hope you got at least a few things out of it. Try them out! Don’t copy them, steal them: adapt them to your company and your needs and iterate. Product management is also a product: it also iterates based on feedback, strategy and performance. Don’t hesitate to reach out to discuss what you have read, or share other challenges you’re having. I’d love to come up with 5 other points soon!