In this post, I’m going to specifically address product management in 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 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 sake, let’s put across a linear scale for 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 pressure you get from different directions. Hold every team working on the product pipeline accountable for quality issues including self.
People will use jargon like “move fast and break things”, but don’t fall for it. Hold the entire team responsible for 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 top most 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 sales team should be focussed 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 a future development to a sales team. Even on an extreme case, commit to 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 be 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 your 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 about 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 sales person, your are setup for a mental exhaustion and negotiation overload.
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 making 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 being 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 of anything groundbreaking / disruptive at this stage.