The Product Manager is an essential player in the software development process. Yet, we often find ourselves answering a troubling question when sitting down with eager prospective clients.
"Why do I need a PM? I already know what I want to build."
One aspect of the Product Manager's role is addressing and finding the perfect balance between building the right product and building the product right.
What’s the difference, you say? Let’s take a look at the parts that make up this process.
Are we building the right product?
First and foremost, a PM’s focus should always be on building the right product. Before charging down a particular path, there are a number of Questions to Cover in Your Product Discovery Kickoff before writing a single line of code.
Completing a Product Discovery in some form is doing your due diligence to make sure that you are not building a product based on faulty assumptions and ignorance toward the goals and user requirements of all stakeholders (i.e., users, administrators, investors, etc.)
To further ensure you are building the right product, the PM is concerned with the following:
The Product Owner
The Product Owner is the team member who is empowered to make decisions about the product (alongside the PM's guidance). They are the key stakeholder who is often responsible, from a business perspective, for the consequences of successes and failures of the project. The Product Owners should also have deep domain knowledge.
There are a number of common pitfalls and things to keep in mind when choosing the right Product Owner, but if you’re a large product team, you may want to review Why Products Built by Large Teams Fail So Often.
Users
Understanding your users is key to building the right product since, of course, if they don’t use it then it wasn’t right, by definition. Everything centers around solving your users' problems and the other parts of building the right product (i.e., research, analytics, etc.) are a means to that end.
Users do not always know how to articulate their problems and certainly do not always know the solutions. To build the right thing, a PM must get the users and the Product Owner to correctly articulate their problems and must then identify opportunities and use high-quality research and analytics to identify the appropriate solutions.
Research
Research should be used to both validate the business problems ("is this really worth solving?" and "have we properly identified the problem?") and potential solutions (i.e., putting together a list of potential solutions and validating if the proposed solutions do actually solve the problem.)
Research can take many different forms. It can mean competitive analysis, it can mean reading the documentation, or it can involve prototyping solutions. Research can also mean shadowing someone while they complete their job or it can mean user interviews.
Priorities
Prioritization is deciding which problems are most important to solve and in which order. There are many subtleties to prioritization but, at its core, it means balancing value, risk, and cost.
If the high-value parts of your product are particularly risky, it’s important to first to de-risk those areas and identify unknowns. This may require building a complete solution or may only require research or prototyping.
When you feel you have discovered most of the unknowns, prioritization becomes about focusing features that are high-value and have acceptable costs.
One other dimension to consider is that technical challenges may drive prioritization. One feature that is of high-value may require a low-value feature because it builds on top of the code. These trade-offs are important to consider and discuss with your tech team.
Opportunities
Just because you have identified a problem and a solution does not mean users will adopt your solution — the market might be full of similar solutions.
Identifying opportunities means analyzing your market and finding your place within the market. You must find your differentiator. Competitive analysis is an important part of identifying opportunities.
Analytics
Analytics allow you to continue to build the right product after you have launched. Or, if you did not build the right product the first time, analytics can help you to adjust.
When setting up your analytics it is important to decide which are the right questions to ask of your data. The tooling should be driven by the business questions. Outputs should be actionable. It’s ideal to decide, before you add the analytics, what questions you have, what potential answers could be and how you would adjust the product depending on the answer.
Are we building the product right?
If you’re only concerned with building the product right, you run the risk that the product only fulfills the plans of the developers and satisfies the conditions imposed at the start of each development sprint.
If you're a non-technical founder or Product Owner, this is often where a PM's experience becomes invaluable. To find that balance between the technical necessities and product goals, the PM is concerned with:
Technology
Each technology has a trade-off, everything from speed to ease of understanding. The agreed-upon solution for the business problem should drive the choice of technologies, and the trade-offs should be acceptable based on the business requirements.
Technologies include both the tools you use (i.e., which tech stack, where you're hosting it) and any third-party integrations you may need. Technologies should be thoroughly vetted (especially third-party tools) before they are chosen.
Architecture
Application architecture is key to ensuring that once the software is built, it can adjust and scale to meet needs. It’s about executing today and planning for tomorrow at the same time.
Good architecture requires that PMs provide a well-defined roadmap and are involved in all of the trade-offs, including cost. The requirements always drive the architecture.
Architecture takes time and is an ongoing process. Do not rush it and be sure to re-visit it regularly.
Engineering
Ensuring you have the right team in place, with the right skills, is essential to ensuring you can build the product right. This is an often overlooked part of the PM's job.
The relationship and trust between a PM and their tech lead is one of the most important factors in determining if a project is successful because they need to balance each other’s skills and trust that they are each making informed decisions. Engineers need well-defined requirements and clear success criteria. They need feedback from PMs early and often. And PMs need to trust them to do their job.
Ensuring you're building the product right also means continuously improving the quality of the engineering through regular, thoughtful refactors. It’s important to ensure technical debt is accrued intentionally and managed thoughtfully.
Design
Designing the product right requires the PM and design team iterate continuously from the least defined version of the product to the most well-defined version. It means building an information architecture, user work flows, wireframes and high-fidelity comps.
It’s important to validate your work at each step. Everyone has an opinion on design — validation does not mean only asking the product owner or user if the work is correct. It involves extensive user testing throughout the process and requires the PM to filter out the noise.
Design is also about your brand and its identity. It needs to be clear and, ideally, distinct. Designing your product right means you must take your distinct identity and embed it throughout your application so that it actually helps users understand and navigate your product.
Process
The development process will be different for every project but should adhere to some key principles. Roles and responsibilities should be clearly defined. There should be buy-in from key stakeholders at regular intervals (this may be for each ticket for some stakeholders and each major milestone for others). It should be a self-improving process, meaning part of the process should be getting feedback on the process itself and responding to that feedback with changes. It should make sure you catch mistakes and correct them as early as possible.
A process that is working well will ensure everyone is confident they are working on the right things; it will reduce mistakes, it will improve development speed, it will make everyone excited to work on your project!
Tests/QA
Ensuring your product works as designed is of the utmost importance. It requires thought and patience, as it is very easy (and extremely costly) to lose the trust of your stakeholders or users.
Both automated tests and manual QA should be part of the process. QA should involve a team that is part of the process from step one (involved in sprint planning, standups, etc.) so that they have an in-depth understanding of the application’s intention. Ideally, they would review each ticket before it goes in front of stakeholders.
Automated tests should be used judiciously. They can be valuable if they are done right as they help you quickly to verify your software is working, allowing your developers to move faster as well. They also require a significant amount of overhead to maintain. If they are built incorrectly, then they will be more expensive to maintain than the cost savings they provide.
Conclusion
The PM’s superpower lies in their ability to advocate for every bullet point above and strike a balance between building the right product and building the product right. This ensures the product not only functions well, but delights users, performs optimally, and provides value long into the future.