Being a product manager for a growing B2B product

In this post, I’m going to specifically address product management in the B2B space. It has its own unique challenges as compared to handling a B2C product. The key difference is that in B2B product management, you are up against a lot more stakeholders than in a B2C scenario. Some points highlighted below may be applicable to B2C as well philosophically but you’ll have to deal with it differently.

Product Management, as a job title, is a serious misnomer when it comes to managing a software product. 80% of the time, you are really not worried about the product, but about the people who have stakes in it — users, management, engineers, sales, support teams, and many more.

For simplicity's sake, let’s put across a linear scale for the product lifecycle.

Though I have experiences in all these three stages, I’m going to talk about the “Growing” stage and how to deal with some common tricky situations.

Focus on quality:
Poor quality is the biggest drain on any product company. You don’t want something to keep pulling the product, the team, and the company back. Identifying and fixing a bug takes 3x time than preventing it. Don’t compromise on this irrespective of the pressure you get from different directions. Hold every team working on the product pipeline accountable for quality issues including self.

• Put a quality matrix that is always measurable and trackable. Review this weekly.
• Track defects diligently with all metadata needed for analyzing, root cause analysis and ensure that people understand the impact of that defect (users impacted, etc)
• Engineers get usually finicky when it comes to discussion about quality as they would feel that they are being targeted. Make them see, through data, on how much time they are spending fixing things than building things. Let them come with preventive mechanisms.
• Hire good testing automation engineers
• Give your team (engineers, QA, design) what they want when it comes to making a high-quality product. Don’t cut corners here.
• Try not to build features that introduce a lot of test cases. It’s easier to build in more configurability to handle different types of requests, but you are also introducing complexity into the product and thereby the risk of a defect creeping into it. Think about this when you are designing the product.

People will use jargon like “move fast and break things”, but don’t fall for it. Hold the entire team responsible for the highest product quality.

Features will come automatically:

You really don’t have to do anything groundbreaking at this phase of the product life cycle. You probably have a long list of feature requests from clients, users, support teams, account managers, sales, and management. They would all be trying to do your job of coming up with new features that the product should have. Treat this positively and don’t believe that you alone should decide what should be in the product. All you have to do is pick the right problem to solve and that’s actually not difficult. Focus on the problem statement rather than the feature request and when this happens you’ll realize that many feature requests will start merging to a common underlying problem.

Most feature requests are usually driven by a user experience problem. 70% of my backlog was always about not being able to do things more efficiently in the existing system rather than solving a new problem that a specific client wants. Next to quality, User Experience is the topmost thing that I’ll focus on. Keep making the user’s interaction with the system better. They’ll love it! Make users go WOW and that’s good enough to keep the users keep using the platform.

Create a framework on how you are evaluating a feature request — product alignment, users impacted, industry alignment, future scalable, revenue impact — $ and timeline, and more areas which you are comfortable with. But stick to that framework and evangelize it throughout the team. If a feature request is rejected, say that it is deferred for a reason.

Listen to Sales and don’t listen:

Just like the sales team sells the product to the customer, they will try to sell the client to you and pushing you to commit to new features even before the sale is made. Your company has already sold the product to a few customers by now and you have every right to believe that the sales team should be focused on finding customers who will buy the product for what it is today. Well, it doesn’t work that way, does it?

Try not to commit to future development to a sales team. Even in an extreme case, commit to the future development of new features ONLY IF the client signs the agreement, and development will start only after that and nothing before it. If the client pushes back, push back harder. If the client is not ready to put money on the table for what the product is today, then don’t sell to this client. Walk away. There would always be better opportunities in the market and your sales team’s responsibility is to find those and net getting stuck to one or two opportunities and make it work. You may be overpowered by the management in several cases and that’s OK. It’s not your call anyways and you are not accountable in this case. Record your disagreement if you have one.

Don’t share your long term roadmaps with sales teams. They may end up selling the future and you would be caught between a rock and a hard place. Just give like a 3-month roadmap which has a 60% to 70% chance of completion and not anything more.

But don’t shut out the sales team. It’s an exceptionally hard job where they are trying to sell what you are making. Keep listening to them on what is happening during the sales process. You’ll get superb insights on how business leaders are seeing your product. If your sales team is obsessed with features, there is something wrong more than the product itself and that needs to be fixed.

Collaborate and conquer:

Collaborate with stakeholders from each group and prioritize based on their collective needs instead of an individual need. If you try to tackle every individual account manager or salesperson, you are set up for mental exhaustion and negotiation overload.

• Ask them to rank the biggest problem to solve. If an account manager is coming up with a request for his /her client, ask the person to collaborate with account managers, and come back with the top 5 requests across all clients. The same goes for the Sales team. Ask them to collaborate and come up with the top 3 or 5 things to sell better. You may disagree with the top items, but at least you know what is important.
• Talk to them through common forums rather than individual discussions so that everyone is aware of what one person is asking. I’ve found this extremely useful. When one account lead asks for something that his client wants, another account lead is more likely to help how to handle that situation.

Make the engineering team your closest ally:

Engineers build what you envision. They are the ones who bring to life what you design. If they do a shoddy job at it, you’ve got a product that’s good in idea, but bad in execution. Trust your engineers when they say that they can build a new user story in a more robust way, but they need additional time. Don’t take shortcuts in doing patches and rolling out features.

At a growth stage of your product, 40%-50% of your engineering team’s efforts should be on non-functional areas like upgrading technology, refactoring code pieces that are inefficient, keeping technical debt at a manageable level, improving quality, and so on. These efforts should lead you to make changes faster at a lower risk of breaking something. Don’t undermine these areas because when you are growing they’ll come back to bite you with a vengeance.

In summary, the problems to be tackled is a product manager at a growing stage of a company is unique and more challenging than any stage. The key thing to remember is that product is already validated by the market and your focus should be on areas to scale faster so that you can deliver faster for your client with superior user experience and reduced support/maintenance. Add features that complement the existing product or leverages your existing strength. No need for anything groundbreaking/disruptive at this stage.

Thyagarajan Delli | Manager, Artificial Intelligence | Accenture