There are many different functions within a company that require varying degrees of collaboration. Salespeople can often be independent agents selling products to a portfolio of clients while support and operations roles tend to require a bit more connection with the rest of the company. Product management might be the most inherently collaborative as it requires you to get features developed, supported by the entire team and used by customers. It is a role where you have to constantly check-in with the entire company, including and especially customers, to make sure that everyone is on the same page with the overall product direction.
The description below is not a golden role for product management in all organizations and contexts. It is focused on the product managers operating in startups, scaleups and larger organizations that have already implemented an agile or scrum method. I will be doing a post, later on, covering the transition to an agile process from a waterfall one and managing the team through this process transition.
To help people interested in this area of work, I’ve categorized the position requirements into a few key areas:
- The lean learning style
- Working with developers
- Managing stakeholders
- Keeping up to date with your boss
- Building for customers
- Validate the ideas and challenge yourself!
The Lean Learning Style
The seminal book by Erik Ries, the Lean Startup, really breaks down the core tenants of software and startup businesses operating with lean product development. The goal is to have a team that has synced rhythms for learning, developing, and implementing cycles so that there is no lost time or effort between new features or products launches, the analysis time needed to understand whether the feature was successful or not, and the appropriate business reaction from sales, marketing or any other teams. Mike Tyson said it best when he said that “everyone has a plan until they get punched in the face.” Please take this to mean that your understanding of how your market will react to your new feature or product will always be different than what will actually happen and the faster you can react to the real situation, the more successful you will be.
There are always many ideas that can be supported, and the first step to success is identifying the right ideas. The second step is then validating those ideas with business cases, customer investigations, requirements gathering and stakeholder meetings for collective buy-in. Sometimes great leaps are needed and those leaps need to be supported with the right decision-making mechanisms to ensure success!
All teams plan and deliver products in a different manner according to their customers, development-release cycle and team dynamics. For these deliveries to be successful, the teams need time to build and to be enabled with guidance as they build so that they do not need to stop or multitask. More stable build cycles from well-planned releases, stable requirements and well-documented user stories lead to releases with higher quality, impact and frequency.
“No plan survives contact with the enemy.” The market and customers are always going to be the judges of success and failure for any business plan. Sales, marketing, support and other customer-facing teams will provide amazing insight into what works and what does not, but the ultimate revealer will always be in the metrics. Adapting to these insights are the keys that move the business forward: user acquisition, user activation, revenue per customer, cost per customer, retention, referrals and attrition.
Working With Developers
Product management is the ultimate exercise of soft power. Often, none of the people who you need to do something end up reporting to you. So your job is to influence and work with them to spend their time in the best possible interests of the company, according to your best understanding and analysis. Developers are no different from the rest of the company in that they have ideas and responsibilities that cover more than what you understand or need them to do. Among other jobs, they have to maintain a bug-free product, keep the computer infrastructure secure, update the technology stack so that it’s up to date with new operating system requirements and learn constantly about the new technology systems being developed.
Your job is to get what you need while respecting that they have other jobs to do. The best way you can accomplish this is by finding your counterpart on the technology team who can be your handoff point for user stories or product feature requirements.
You need to build a backlog of features that solve real customer problems and will either grow revenues, decrease costs, increase customer adoption, improve product usage/stickiness or facilitate a larger strategic objective. This list is something that you should review on a regular basis to ensure that the most important requests are always at the top with all requirements are sufficiently detailed that no questions come back to you from developers. Please be aware that there is a difference between the overall backlog of requests for features that you have and the requests the developers are currently, or just about to be, working on.
As best possible, the requirements should also be mutually exclusive, but not exhaustive (meaning they can each be launched to customers independent of each other), and small enough requests that they can be built, tested and launched in one build cycle.
You should always have two primary contacts in a development team: 1. the Scrum Master and 2. the person responsible for ensuring the overall integrity of the product with a vision of how it will be built in the future. The latter person will help cover your knowledge gaps and ensure the tech team has a sufficiently long-term vision that new, crucial technologies are constantly integrated with a stable and scalable product. Other roles in the tech team like testers, dev ops and QA do emerge as the team scales and specializes. Designers can be included in the tech team though, from my experience, it’s best that they follow their own build rhythm and cycle.
As the product manager or owner for a specific product, you are ultimately responsible for its success or failure, but that does not mean that you alone direct the future of the product. Sure, if you’re right 100% of the time, then you can get away with making all the critical decisions, though if you admit that 1% of the time you will be wrong, then your approach can be enormously improved by including the ideas of others. Not only will your decisions be better, but you will be able to improve buy-in from other people in the company managing critical functions needed for your product to be successful. These team members can work in sales, marketing, operations, development, design or even in senior management roles. You need to connect with your stakeholder team on a regular basis to communicate your vision for the product, along with your reasoning, so that it can be improved by the ideas of your peers. They need to have an opportunity to adjust your vision so that it meets with their goals as well.
Keeping Up With Your Boss
At the end of the day, everyone involved in the operations of a business report to someone except for those rare entrepreneurs who are able to self-finance their own businesses. Employees report to managers, managers to executives, executives to senior executives, senior executives to a board, and a board to the equity/debt holders of a company. You need regular feedback and direction from your business to understand whether you’re correctly prioritizing the different projects and goals you’re focused on. Improving user engagement by 10% could be an amazing achievement, but if your business is struggling to grow and get new customers, that achievement won’t impact the bottom line like you want it to. Google and other leading companies like to use a system called ‘Objective and Key Results’ or OKRs. I personally am a big fan of this system as it forces you to have a regular conversation with your boss and your team on the critical objectives for the next quarter and for the management team of a company to understand the matrices of goals throughout the business. Beyond the goal setting, a regular 1:1 meeting can provide valuable insights on the progression you are having towards those goals and give your boss an opportunity to eliminate any blockers you’re encountering along the way.
Building For Customers
The goal for everyone on your team is to create value for customers, your coworkers and your shareholders. The easiest way to simplify the triple equation is to focus your efforts on the customer. They are the ones who at the end of the day will be deciding whether or not to use your products and generating revenues for your coworkers’ salaries and shareholders’ coffers. Maintaining this focus is what’ll allow you to keep everyone on the same page and get buy-in for your initiatives. To do this, you’ll need to be the number 1 customer expert in your organization.
A key problem that managing organizations choose to focus a lot of time and resources into is the identification of who the customers actually are. They can be summarized into user personas, usually developed in conjunction with the marketing team, that are then communicated more broadly across the organization to ensure we’re all talking and focused on the same people. These personas evolve and change over time as the product-market fit of the team becomes more and more established. Any successful product manager will be able to tell you the different types of users that their products are using, the key demographic information about them and most importantly, what they care about.
Customers surveys and interviews need to be sources of intelligence that you develop on a regular basis for all new initiatives. Whatever your reasoning for proposing new product features or directions, you need to get customer feedback and validate your assumptions on their expected behaviour. This information combined with data on the adoption and usage of product features will give you all the insights you need to understand how customer behaviour is trending so that you can lead your team ahead of it. Frequently use tools like Survey Monkey, Calendly (for scheduling interviews), Segment, Heap Analytics and Intercom to stay connected with your customers. Ideally, you’re going through these analyses with an expert in user experience and human-centred design and if you are that expert, even better!
Validate Your Ideas!
There are many different team types and roles, and a consistent feature across all of them is that you can right or wrong, and sometimes both. Some days you will get a feature developed and released with a predicted 10% customer growth with millennials, and while you get the 10% growth, it’s specifically with female baby boomers. Driving unanticipated growth is not a bad thing, but not understanding why will leave you with unpredictable growth and use behaviour, which can be a very bad thing. Understanding the ‘why’ behind customer decisions will help you to identify the growth drives for your business and be able to build around them to drive the 10x return your boss is looking for. The process of identifying and learning about these drivers is going to be iterative. It will take time and there will be some failures along the way, but as long as the overall business is focused on the right market and you are right when you need to be, you will find your way.
Project management is nothing new and there is little difference between the tenents of product vs. project management. In both roles, you have to operate within the triple constraints of Time, Budget and Quality. Your consistency in meeting all three objectives is going to test your creativity, your personal grit or drive and your ability to communicate/collaborate with a wider team. Good product managers deliver on two of these objectives and great product managers consistently deliver all three.
The difference between product and project management comes from iterative and rapid learning with a clear understanding of the overall business strategy. Product managers propose their own projects based on their ideas and the ideas of their colleagues and flesh out these ideas into user stories based on their clear and comprehensive understanding of the customer. They often have no direct control or influence over the team members responsible for critical aspects of the projects so they have to rely on their charisma and reasoning to motivate a team to deliver. Their relationship with the development team, their reporting manager and the wider group of stakeholders in the company tests their ability to collaborate and achieve consensus in dynamic business environments.
Best of luck, stay positive and always look for growth opportunities!