One of the most important parts of being a Product Manager is making sure that your stakeholders and developers understand not only what you’re trying to do, but the surrounding circumstances in which you’re trying to do it. Often, this is a matter of discussing and managing scope; at other times, it’s making sure that people understand the schedule and resources working on the improvement; and at still other times, it’s ensuring that what comes out at the end of an iteration is what everyone wanted at the beginning of the iteration. But there’s a larger set of considerations that are of key importance to aligning your teams on — because they significantly impact the overall success of what we’re trying to do. All too often we ignore these three components to our peril, and when we do there’s an even chance that they’ll come back to bite us in the ass…
Assumptions Make an Ass Out of You and Me…
Every single choice we make has assumptions baked into it. The problem, thus, is not that we have made assumptions — we do that all the time, and we must do it if we want to avoid “analysis paralysis”. The problem is that, all too often, we move forward with assumptions in place that we aren’t aware of, or that we haven’t clearly communicated and validated with our stakeholders and our customers. We assume that users will have a current OS version or browser. We assume that our clients will have access to a mobile device to confirm their identity. We assume that our stakeholders understand the technical complexity of the work we’re asking our developers to do. Each of these assumptions might be true — or they might be entirely false. And while we don’t necessarily want to test and confirm every single assumption that we make, we should try to document as many of these assumptions as we can, and share them with others, so that the load of challenging those assumptions is distributed amongst the team. Each person has a unique perspective that they’re bringing — which is why we keep them around and why we engage with them. And each of those perspectives has the chance to shine the light of awareness on assumptions that we might want to actually verify. But if we never consider the assumptions that we’re making, they’ll remain hidden in the shadows waiting to leap out when we least expect them.
Risk Isn’t Just a Board Game
Similar in nature to assumptions, and sometimes positioned as the inverse of them (if we assume that users have access to a smartphone, there’s a risk that they won’t), there are sometimes risks that are entirely separate from our assumptions. Many of these are external risks, such as regulatory agencies or changes in the law (GDPR is a very recent, impactful example of this!), but some of them might be internal risks as well. It’s critical as a good Product Manager that we carefully examine the things that we’re trying to do, how we’re going to do them, and who we’re relying on to get them done. As with assumptions, we can’t let risks control our destiny — we shouldn’t wait to see what a new law might do before we move forward, but we should be cognizant of the fact that some new law might have an effect on our efforts. We can’t not do some technical requirement because there’s only one team member with expertise with the underlying framework, but we should understand that if something happens to that team member we just might be left high and dry. We need to catalog the risks that we’re facing and determine which can be mitigated and which can’t; which are likely to have a large effect and which will have a small effect; which are more likely to happen and which are less likely. Building out this list helps us and our teams to understand and take action on the risks that are likely to matter, while keeping those less likely or less impactful risks at least on our radar. We ignore risks at our peril, as they tend to come to fruition at the least practical time possible.
Constraints Drive Creativity
We all know the stakeholders who believe that the development teams have unlimited time, money, and resources, and who ask for the sky and the stars and the moon and won’t accept anything less. We also know designers and developers who take on work that’s far beyond what they are likely to be able to actually deliver, or who take something that is intended to be simple and create an implementation plan that’s so overly engineered and highly complex that it misses the point entirely. As Product Managers, however, we know that the truth is that we’re generally rather tightly constrained in what we can do, when we can do it, and how we can get it done. We have internal constraints such as team sizes, project budgets, matrixed resources, and so many others. We have external constraints such as marketing and sales readiness, pending deals, customer issues, release dates, and other efforts depending on our work. It’s up to us to clearly communicate these constraints within our organization — to ensure that stakeholders understand that while vision is great, execution is king; that they won’t always get what they “want” but we can ensure that they get what they “need”. We need to ensure that the service teams that we work with — architecture, documentation, design, etc. — all share a common understanding of the constraints we’re operating under. If the architecture or UX teams are delivering work that will take us 6 months to build, and we’ve only got two sprints of time, we’re going to run into major impasses as we move forward on the project. It’s far better to establish and define the scope and effect of constraints up-front so that we don’t have to fight those battles further down the line. The more we ignore constraints, the more likely we are to wind up in a situation where our delivery cannot match the expectations of those upon whom we rely for information and assistance. It kills our credibility and destroys our social capital.
